Ken,
I am assuming most of your code uses Thread's context class loader,
which in your case is WebAppClassLoader, to load classes. With my latest
changes to application class loading hierarchy (see an earlier to dev@
on similar subject), most of your problems should go away even when you
don't use HK2-Import-Bundles and GlassFish-require-services headers. I
strongly recommend limited use of them as the classloading does not
follow a well defined delegation policy in the presence of those
entries, so there can be hard to debug ClassCastExceptions in webapp.
They are OK as far as resource finding goes. I once tried running
admingui without those entries in my local workspace, and it did not
work because JSF could not find faces-config.xml from two other bundles
that your admingui depends on. I did not pursue further. But, if that is
the only problem, then it should JSF's responsibility to solve this
issue in an OSGi environment using some kind of extender.
What other classloading requirements do you have?
Thanks,
Sahoo
Ken Paulsen wrote:
>
> Hi Sahoo,
>
> I've had the Class.forName issue in the back of my mind for a while
> now. Web framework code does this a lot (JSF does, jsftemplating
> does, woodstock does). Are the fixes Jerome provided
> (Glassfish-require-services & HK2-Import-Bundles) enough to work
> around all the problems? I haven't seen any issues come up, but I
> haven't been deploying multiple applications which use these OSGi
> bundles concurrently.
>
> I'll look for the ant bnd plugin, that's exactly what I need...
>
> Ken
>
> Sahoo wrote:
>>
>>>
>>> Ken Paulsen wrote:
>>>>
>>>> Hi,
>>>>
>>>> In GF v3 just about everything is an OSGi bundle. This including
>>>> all our plugins to our admin console as well any code those plugins
>>>> rely on. This means, in order to use the Woodstock UIComponents
>>>> (or any other woodstock code) from a plugin, then woodstock needs
>>>> to be packaged as an OSGi bundle.
>>>>
>>>> We can either repackage the webui.jar (and potentially others --
>>>> I'm already doing dataprovider.jar) as an OSGi bundle during our
>>>> build process. However, doing that does not help anyone else that
>>>> wants Woodstock as an OSGi bundle. It would be very nice if you
>>>> added the MANIFEST.MF entries necessary to use your jar files in an
>>>> OSGi environment. Nothing else would need to change, just the
>>>> MANIFEST.MF file.
>> Without looking at the code, I can't say that. If it does
>> Class.forName or META-INF/services lookup, then in order to be used
>> in pure OSGi environment, those code have to be revisited.
>>>>
>>>> I'm not sure how to best automate this using ant (Sahoo, do you
>>>> know?). Although I can show you how this can be done using the
>>>> maven bnd plugin. Either way, this would be better than
>>>> creating/maintaining the MANIFEST entries by hand.
>> Yes, there is an Ant plugin to bnd as well. Just search for it; I
>> don't have the link handy.
>>
>> Thanks,
>> Sahoo
>>>>
>>>> If you want help doing this, I'm willing to do the work.
>>>>
>>>> Thanks!
>>>>
>>>> Ken