For your fragments, why are they exporting the "en" packages? Do you
want other bundles to be able import them?
Since the are fragments, they do not need to be exported for the host to
access them, since they literally become part of the host's class path.
You only need to make sure the fragment packages you want the host to
access are on the fragment's bundle class path...in this case "." is
sufficient, which is the default value so you don't need to specify it
explicitly.
So, I would recommend that you do NOT export the fragment's localization
packages.
However, if you really want to export them, then I would recommend that
you export them with the "-noimport:=true" directive in your osgi.bundle
file.
As it currently stands, your fragments are importing AND exporting the
localization packages, so I believe what is happening is your one host
ends up importing these localization packages from the other host, which
is not what you want.
-> richard
On 8/27/09 21:08, Ken Paulsen wrote:
>
> Ok, here are the steps:
>
> 1) Checkout and rebuild admingui/plugin-service, admingui/core:
>
> * svn co admingui (if you don't already have it in your GF workspace)
> * cd admingui/plugin-service
> * svn up
> * mvn clean install
> * cd admingui/core
> * svn up
> * mvn clean install
>
> 2) Copy the files to the right places (including those attached to
> this email):
>
> * cp admingui/plugin-service/target/console-plugin-service.jar
> <gfv3_root>/modules/.
> * cp console-common-help.jar <gfv3_root>/modules/. (This is a
> fragment, augments console-common.jar)
> * cp console-web-help.jar <gfv3_root>/modules/. (This is a
> fragment, augments console-web-plugin.jar)
> * rm
> <gfv3_root>/lib/install/applications/__admingui/WEB-INF/lib/console-core-3.0-SNAPSHOT.jar
> * cp admingui/core/target/console-core.jar
> <gfv3_root>/lib/install/applications/__admingui/WEB-INF/lib/.
> * cp test.jsf <gfv3_root>/lib/install/applications/__admingui/.
>
> 3) Start GFv3 and goto: http://localhost:4848/test.jsf
>
> Let me know if you have questions or problems. Note some output will
> be shown in the server.log... but the key information should be shown
> right in the browser.
>
> Thanks,
>
> Ken
> x42083
>
> Richard S. Hall wrote:
>> 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
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net