Sahoo wrote:
>
>
> Bill Shannon wrote:
>> Richard S. Hall wrote:
>>>> If I have an OSGi bundle and I want to export all my resources in
>>>> META-INF, I should export the "package" META-INF? There's no way
>>>> to export an individual resource?
>>>
>>> Conceptually, you are correct, but in practice that really doesn't
>>> make a lot of sense in pure OSGi since in this model you want to be
>>> able to see more than one (or all) META-INF "packages", but a bundle
>>> importing "META-INF" will only be able to see it from one bundle.
>>>
>>> This is why the extender pattern is used here, since it probes all
>>> META-INF directories, which is what you want.
>>
>> The problem is we're not in a pure OSGi environment. In many ways OSGi
>> is just an implementation detail. At best we're in a transitional stage
>> where things need to work in an OSGi and non-OSGi environment.
>>
>> If there's a way to probe all the META-INF directories, why can't the
>> OSGi
>> class loader do that when I try to load a resource?
>>
> Although this is doable, it kinds of breaks modularity, so it has not
> been done for all kinds of resources. We had implemented it for
> META-INF/services only and now we added support for META-INF/mailcap.
> Those two make sense, as the bundle that's looking for the resources
> does not want to know about the bundle supplying the resources. Are
> there other such resources?
As I mentioned in my other email:
META-INF/javamail.providers
META-INF/javamail.address.map
>
> An alternative way to achieve this is to package such resources in a
> separate jar and make the jar available in glassfish lib directory.
True, but it breaks backwards compatibility and the customer would have
to know they need to do this. These systems are supposed to "just
work". Some failures may be hard to diagnose, especially since they
will be unexpected (due to compatibility expectations). In other
situations, it may not be clear there even is a failure -- just some
weird and rare seemingly random problem.
-Peter
>
> Thanks,
> Sahoo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>