The reason I asked is because -- standard or not (I'm well aware I am
violating the intent of a web-application's classloading strategy) --
there is strong demand for this functionality based on feedback from the
community. People want to create applications which allow plugins.
Spring is allowing this now, how long should we wait until we support
this officially?
I'm fine w/ the "modules" directory. Although I suspect other people
will use it and may complain about the convenience of placing files in 2
places instead of 1. Otherwise, no big deal.
Thanks!
Ken
Sahoo wrote:
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>