On 11/12/09 20:16, Byron Nevins wrote:
> What happened is that a developer was trying to use my string utility
> class (common-util). It didn't work right. I investigated and found
> that there were duplicate resource files with the same name.
> I recommended fixing by changing the package name.
>
> The question still hangs in the air though. I wonder why OSGi doesn't
> notice duplicates and warn you?
For OSGi to notice duplicates, it would have to scan JAR files in
advance to make sure bundles didn't contain stuff you were also
importing. My guess is, people wouldn't like the performance of this.
The search order for OSGi is explicit:
1. A request for a class in java.* packages are boot delegated, if
not found then stop searching with an exception.
2. A request for a class in an imported package is delegated to
exporter, if not found then stop searching with an exception.
3. A request for a class in a required bundle is delegated to the
required bundle, if not found then searching continues.
4. The bundle's local class path is searched (this includes
fragments), if not found then searching continues.
5. The bundle's dynamic imports are searched, if not found then throw
an exception.
So, if you create a split package across your imported package and your
bundle contents, then you can conclude from the above search order that
the import will completely shadow the internal content (i.e., OSGi does
not allow split packages, since searching stops if the package is
imported and the class/resource is not found).
In your case, I imagine you must be importing the package in question,
thus your bundle is always seeing what is available in the exported
package, which is what is expected.
The most important point to remember: split packages are bad. :-)
-> richard
>
> 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
>>
>>
>
> --
> 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