I had the same issue. This is a split package (2 packages exporting
the same package). In that case, the behavior you have seen is the
same as what I have seen. I believe if the other bundle tries to read
LocalStrings, then it will get its own b/c OSGi will only recognize 1
in the system (I could be wrong, though).
If you can change the pom.xml to avoid exporting the c.s.e.admin.cli
package from anywhere, I think bnd makes them private packages and it
might work OK. In my case I had documentation resource files that were
split like this... so this solution worked for me.
Good luck!
Ken
Byron Nevins wrote:
LocalStrings
is a class that handles strings coming from a file named
LocalStrings.properties
admin-cli.jar has such a properties file in it:
c.s.e.admin.cli.LocalStrings.properties
Now a completely separate OSGi module is developed that happens to also
have its own c.s.e.admin.cli.LocalStrings.properties. This module has
admin-cli.jar as a dependency.
At runtime a call is made to fetch a string -- but it does NOT look
inside its own module -- instead it looks in the properties file in
admin-cli.jar!
The call to getResource("c.s.e.admin.cli.LocalStrings.properties")
picks up resources from outside the module that is making the
call in preference to resources inside the module.
That seems unpredictable and weird to me.
Why does OSGi do that -- is it predictable?
Is there some OSGi way to force getResource() to look only in the
current module?
(This is an actual bug that just appeared in a CLI extension module)
--
Byron Nevins - Sun Microsystems, Inc.
Home: 650-359-1290
Cell: 650-784-4123
Sierra: 209-295-2188
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: dev-help@glassfish.dev.java.net