Ken Paulsen wrote:
>
> Jerome,
>
> In our admin console app, we will require some OSGi bundles specific
> to our application. These bundles may also be referenced by plugins
> to our application. jsftemplating, dataprovider are two that exist
> today, but I am planning to add a "admin console core" bundle and some
> other existing jars may get repackaged.
>
> Question: Where should these sit in GF v3?
>
> Currently I am placing them in the "modules" directory which works
> fine and perhaps is the right place. However, do we want to support a
> place inside a .war file for easier packaging?
This violates the classloading restrictions mentioned in section EE 8.4
of Java EE 5 platform spec:
/If the application is delivered as a .ear, an enterprise bean module
delivered as a .jar file, a web application delivered as a .war file, or
an application client delivered as a .jar file, the deployment tool must
be able to deploy the application such that *Java classes in the
application are in a separate namespace from classes in other Java
applications*. Typically this will require the use of a separate class
loader for each application. Standalone resource adapters delivered in
.rar files and standalone class libraries delivered in .jar files that
become installed libraries will of necessity appear in the class
namespaces of applications that use them, and may appear in the class
namespace of any application depending on the level of isolation
supported by the Java EE product.
/
So, glassfish/modules seems to be a better alternative to me right now.
We can think of placing application specific modules in domain1/lib or
domain1/modules or something similar when we want to publish this as an
external feature. For the moment, since admingui is the only one using
this facility, glassfish/module should be sufficient.
Thanks,
Sahoo