Ken,
Thanks for taking time to have a lovely discussion going. This is a very
important feedback. I know there is a growing demand for such a feature
and there are some implementations that allow it to some extent. Whether
this is a good thing or bad thing is debatable, but I am inclined to be
in the camp that says it's a good thing. We do want to allow such
extensions as well. It is mentioned indirectly in *section #4.1 of
OSGi/V3 one-pager* [1] as one of the items to support in future:
/We do want GlassFish to be able to accept OSGi-ed applications,
irrespective of them being Java EE applications or not./
My current thinking is that we don't want every Java EE application to
be able to export classes for other applications or system to use. One
of the reason is that standard Java EE application's life cycle is
different from other Java EE applications and for that matter from the
system. More over, we have a server that's already been used by so many
users, so we are committed to maintain compatibility across releases.
SO, we have to be careful about how to exposing any functionality that
affects compatibility. We probably want to support some kind of *hybrid*
application model, i.e., applications that are primarily Java EE
applications, but are packaged as OSGi bundles. Since this is a
different programming model altogether, it deserves careful investigation.
I will appreciate if you add your comments of what you would like to see
in this area as review comments for the afore-mentioned one-pager. BTW,
I am for such features, although I am not committing it for prelude release.
Thanks a lot,
Sahoo
http://wiki.glassfish.java.net/attach/V3FunctionalSpecs/GFv3Prelude-OSGi-onepager-v0.2.txt
Ken Paulsen wrote:
>
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>