Great that it works!
-> richard
On 8/28/09 16:37, Ken Paulsen wrote:
>
> Hi Richard,
>
> The pom.xml I was using was mostly empty, I didn't intentionally
> import/export anything -- I just took the defaults. I should have
> checked the imports/exports, I didn't even think of it! :-[
>
> I added the following to my pom.xml file (not sure if this is the best
> way to ensure nothing is exported):
>
> <plugin>
> <groupId>org.apache.felix</groupId>
> <artifactId>maven-bundle-plugin</artifactId>
> <configuration>
> <instructions>
> <Export-Package></Export-Package>
> </instructions>
> </configuration>
> </plugin>
>
> After this change, it no longer imported or exported anything, but
> instead had "Private-Package: ...". After trying this out, it worked
> perfectly. Thank you! Thank you!
>
> Attached is my pom.xml... if you have any other recommendations on
> what I'm doing, please let me know.
>
> Thanks for your help!!
>
> Ken
>
> Richard S. Hall wrote:
>> 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
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net