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@glassfish.dev.java.net
For additional commands, e-mail: dev-help@glassfish.dev.java.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: dev-help@glassfish.dev.java.net