dev@glassfish.java.net

Re: [v3] OSGi Fragment ClassLoading help needed...

From: Richard S. Hall <heavy_at_ungoverned.org>
Date: Thu, 27 Aug 2009 19:19:28 -0400

Sounds odd. Give me the steps to reproduce and I will take a look at it.

-> richard

On 8/27/09 7:14 PM, Ken Paulsen wrote:
>
> Hi Richard,
>
> Thanks for the response. I have been preparing to check some files in
> so that you can reproduce the scenario. I am unsure of how to do it
> outside our application in a more simple way, so I think this will be
> easiest.
>
> I have also been doing more testing and have found that it is not
> "xml" files that are the problem, but the "location" of the files.
> File located in: META-INF/* seem to be found correctly (such as
> META-INF/en/help/index.xml). All files, regardless of type, under any
> other directory exhibit the problem I described below. Any file in
> the root of the bundle fragment .jar file, also is found correctly w/o
> any problem (as shown in my "test.file" example below -- moving
> test.file to any subdirectory causes it to fail too).
>
> I will have have files checked in soon so that you can try it out.
>
> Thanks,
>
> Ken
>
> Richard S. Hall wrote:
>> Any chance you can boil this down to a test case which you can attach
>> to an issue in Felix' issue database (preferrably) or send to me
>> directly?
>>
>> It sounds like it could be a bug in Felix' fragment support, but I
>> won't know for sure until I can see an example. If it is, we still
>> have time to get it fixed for the Felix 2.0 release...
>>
>> -> richard
>>
>> On 8/27/09 15:24, Ken Paulsen wrote:
>>>
>>> Hi,
>>>
>>> I've been debugging this problem for a couple days now and have
>>> finally narrowed down my testing enough that I can describe the
>>> problem I am seeing...
>>>
>>> I have 2 bundles and 2 fragments for those bundles. Each of the 2
>>> fragments adds additional files (localized help content) including:
>>>
>>> en/help/index.xml
>>>
>>> When I ask bundle #1 for this file, it finds it from #1 and returns
>>> it. When I ask bundle #2 for this file, it finds it *from #1* and
>>> returns it!!
>>>
>>> I do think this is a OSGi fragment related problem b/c if I move the
>>> en/help/index.xml into bundle #1/#2 and do away with the fragments,
>>> it correctly pulls out each XML file. Another thing that is
>>> interesting... if I bundle a non-XML file in the 2 fragments (I
>>> tested with a file named "test.file" and with an image), I can
>>> correctly access them from both bundle #1 and #2. So it *seems*
>>> that in addition to being a problem related to OSGi fragments, it
>>> may be limited to certain recognized file types, such as .xml files.
>>>
>>> Here is some of the code I am using that exhibits this issue:
>>>
>>> // Get the OSGi bundle's classloader
>>> ClassLoader loader = provider.getClass().getClassLoader();
>>> System.out.println("** CL: '" + loader + "'");
>>> url = loader.getResource(name);
>>> System.out.println("URL " + provider.getClass().getName() + "
>>> == '" + url + "'");
>>>
>>> Here is the output when I do not have fragments present and instead
>>> bundle the en/help/index.xml file inside the 2 "host" bundles (this
>>> is the case works correctly):
>>>
>>> INFO: ** CL: '153.0'
>>> INFO: URL org.glassfish.admingui.common.plugin.CommonUtilPlugin
>>> == 'bundle://153.0:1/en/help/index.xml'
>>> INFO: ** CL: '21.0'
>>> INFO: URL org.glassfish.web.admingui.WebConsolePlugin ==
>>> 'bundle://21.0:1/en/help/index.xml'
>>>
>>> Here is the output when I try to use fragments (this is the only
>>> case that fails, notice 154's CL returns a URL to 21 not 154):
>>>
>>> INFO: ** CL: '154.0'
>>> INFO: URL org.glassfish.admingui.common.plugin.CommonUtilPlugin
>>> == 'bundle://21.0:2/en/help/index.xml'
>>> INFO: ** CL: '21.0'
>>> INFO: URL org.glassfish.web.admingui.WebConsolePlugin ==
>>> 'bundle://21.0:2/en/help/index.xml'
>>>
>>> Here's the output when I attempt to access a different file
>>> (difference being non-xml?? or perhaps something else). This case
>>> still uses the above bundles and test.file is provided by those
>>> bundles... I didn't even stop the server or change anything between
>>> this run and the failed case immediately above this one:
>>>
>>> INFO: ** CL: '154.0'
>>> INFO: URL org.glassfish.admingui.common.plugin.CommonUtilPlugin
>>> == 'bundle://154.0:2/test.file'
>>> INFO: ** CL: '21.0'
>>> INFO: URL org.glassfish.web.admingui.WebConsolePlugin ==
>>> 'bundle://21.0:2/test.file'
>>>
>>> Can someone either explain to me what I'm doing wrong, or let me
>>> know who I should talk to about getting this problem fixed?
>>>
>>> Thanks!
>>>
>>> Ken Paulsen
>>> x42083
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net For
> additional commands, e-mail: dev-help_at_glassfish.dev.java.net