See reply below...
Peter Williams wrote:
> Hi Sahoo,
>
> So this issue affects more than just mailcap. The same design pattern
> (JAF trying load all occurrences of META-INF/mailcap) also affects
> JavaMail.
>
> JavaMail loads all occurrences of META-INF/javamail.providers and
> META-INF/javamail.address.map. These files could potentially be found
> in library jars provided by the user in some appropriate location
> (application, glassfish/lib, etc.)
>
> This ties into what Bill is saying about our desire to have *any*
> resource in META-INF available regardless of location because the
> name/path of a given resource and the loader of the jar containing it
> is not easily defined.
>
> Otherwise, this has an adverse impact on backwards compatibility.
See responses to that email. Resources from libraries will be found just
like they were found when we were not OSGied. It's an issue with
resources which are part of OSGi bundles. Let's say, JavaMail is looking
for one of these files (say META-INF/javamail.providers), and the file
actually is in JavaMail OSGi bundle, and JavaMail uses
ContextClassLoader to find the resource then it won't find it. JavaMail
has to use its own classloader to locate the file.
>
> One further comment below as well.
>
> Peter Williams wrote:
>> Sahoo wrote:
>>> Good to know that patch worked. I will commit it to trunk. I hope
>>> you don't want this to be fixed in 3.0-Preview, do you? If you do,
>>> then you need to raise the priority to P1 so that Abhijit can take a
>>> call.
>>>
>>> w.r.t. changes osgi.bundle file, use this patch instead.
> Did you mean to attach or include a patch, as you reference above. I
> don't see it.
>
PFA the patch for osgi.bundle file.
Sahoo