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