Best practice for the use of an existing jar in the Liferay/Tomcat bundle

[Peter Helgren, modificado 6 Anos atrás.]

So, suppose you need to use some of the Apache commons jars as dependencies in your module (validator and digester in my case) and these jars already reside in the $ROOT/WEB-INF/lib folder. Should you just list them in your build.gradle file like any other dependency and have Imaven pull them in or is there a way to include them just to compile and then assume the modules will be available when you deploy? Also, how would you determine what versions are lurking in the $ROOT/WEB-INF/lib folder if you were going to list them as dependencies ?

Right now I have built and deployed a SB project but it only shows "Installed" because of some transitive dependencies. I can do the grunt work of adding the dependencies but if there is a "best practice" of utilizing dependencies on jars that are already in the LR bundle, I'd rather go that way...

[David H Nebinger, modificado 6 Anos atrás.]

Peter Helgren:

So, suppose you need to use some of the Apache commons jars as dependencies in your module (validator and digester in my case) and these jars already reside in the $ROOT/WEB-INF/lib folder.

Before you get much farther, you need to understand there are two different class loaders in play here...

The ROOT/WEB-INF/lib class loader is part of Tomcat and it will ensure that all classes from those jars are available to code in the web app. This also includes global jars from lib and lib/ext.

Within the scope of the OSGi container, though, this is a separate class loader hierarchy that does not have visibility to any of the jars/classes that the Tomcat class loader provides access to.

In the OSGi container, the class loader is managed much differently. First, you only have access to what your module brings to the table (in classes or jars using the OSGi dependency stuff I blogged about). Next, you do have access to classes from other modules as long as they have been declared as export packages in their bnd.bnd files (so if you include commons-codec.jar in your module, if you don't add the packages for export other modules won't have visibility to them).

Otherwise things are very isolated. This is done on purpose so you can have cases like modules using different versions of the same jar.

Should you just list them in your build.gradle file like any other dependency and have Imaven pull them in or is there a way to include them just to compile and then assume the modules will be available when you deploy? Also, how would you determine what versions are lurking in the $ROOT/WEB-INF/lib folder if you were going to list them as dependencies ?

In general you should not assume that any transitive dependencies are actually available to your module. Commons-lang and commons-io actually are, but otherwise you won't find much else.

Right now I have built and deployed a SB project but it only shows "Installed" because of some transitive dependencies. I can do the grunt work of adding the dependencies but if there is a "best practice" of utilizing dependencies on jars that are already in the LR bundle, I'd rather go that way...

You should include all dependencies in your module, including transitive dependencies. I've described how to do that in the OSGi dependency blog post you've seen. It's also the reason why I suggested that you try not to bleed your dependencies out because you'd be forcing every module using your module to also satisfy those dependencies by including the jars on their side.






Come meet me at the 2017 LSNA!

[Peter Helgren, modificado 6 Anos atrás.]

Got it...and it makes sense. My concern was what I had read about in this developer page found here where it said "As you manage module JARs, make sure not to deploy any OSGi framework JARs or Liferay module JARs" So, it is only the stuff I might see listed in the gogo shell that I might need to be careful about...not the "general" jars hanging out in Tomcat.

Thanks once again.