Byron,
Please fix this as suggested by Bill. It is a bad idea to have same
named resource or same package in two different bundles unless they are
identical. In your case, they are not identical otherwise you would not
have probably cared where it gets loaded from.
Thanks,
Sahoo
Bill Shannon wrote:
> You're going to move all this stuff to its own package, right?
>
>
> Byron Nevins wrote on 11/12/09 1:25 PM:
>
>> Your surmise is correct, sir!
>>
>> It is interesting because I'd like to know how dupes are resolved in
>> OSGi. Probably one half a man day was spent figuring out this
>> particular issue.
>> I know exactly how it works in regular non-OSGi java: first one found wins.
>>
>>
>> Bill Shannon wrote:
>>
>>> Why do two jar files have a resource file of the same name?
>>>
>>> A Java package (classes and resources) should really be in only one
>>> jar file.
>>>
>>> Don't tell me, run-script didn't get moved into its own package
>>> when it was moved out of the admin CLI package?...
>>>
>>>
>>> Byron Nevins wrote on 11/12/09 10:34 AM:
>>>
>>>
>>>> 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_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
>>>
>>>
>>>
>> --
>> Byron Nevins - Sun Microsystems, Inc.
>> Home: 650-359-1290
>> Cell: 650-784-4123
>> Sierra: 209-295-2188
>>
>> --------------------------------------------------------------------- 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
>
>