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