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.
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.
Thanks
-Peter
> Every class in that package is a data handler. So exporting the
> entire thing made more sense to me -- if for whatever reason a new
> data handler is added to JavaMail, no further changes are required.
> It'd doubtful a private helper class for a data hander would be added,
> but if so, it could be put in another package. Filtering seems more
> fragile to me.
>
> -Peter
>>
>> If you know the class names you want to make visible as opposed to
>> making every class of the packages available, then you can use "Class
>> Filtering." Something like this:
>> com.sun.mail.handlers; version=${mail.version} ; Include="Foo, Bar"
>>
>> If you do decide to do this, please send me the file for review.
>>
>> Thanks,
>> Sahoo
>>
>> Peter Williams wrote:
>>> There is an additional issue logged in issue tracker --
>>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=6753
>>>
>>> You were correct that the handlers need to be exported after this
>>> change and the patch works as expected.
>>>
>>> The only aspect I haven't checked is if there was a third party jar
>>> that included a META-INF/mailcap, would that be loaded also, but
>>> from tracing the code it looks like that would work as well.
>>>
>>> I had some trouble with the exports -- what I have now is to add the
>>> following to javaee-api/javax.mail/osgi.bundle:
>>>
>>> Export-Package: javax.mail.*; version=${spec.version},\
>>> com.sun.mail.imap; version=${mail.version},\
>>> com.sun.mail.pop3; version=${mail.version},\
>>> com.sun.mail.smtp; version=${mail.version},\
>>> com.sun.mail.util; version=${mail.version},\
>>> com.sun.mail.handlers; version=${mail.version}
>>>
>>> This produces the correct result and also emits two warnings that
>>> I've not been able to make go away:
>>>
>>> [WARNING] Warning in manifest for
>>> org.glassfish:javax.mail:jar:3.0-SNAPSHOT : Superfluous
>>> export-package instructions: [com.sun.mail.handlers,
>>> com.sun.mail.pop3, com.sun.mail.util, com.sun.mail.imap,
>>> javax.mail.*, com.sun.mail.smtp]
>>> [WARNING] Warning in manifest for
>>> org.glassfish:javax.mail:jar:3.0-SNAPSHOT : Did not find matching
>>> referal for *
>>>
>>> Is there a way to eliminate these warnings? I wasn't able to.
>>>
>>> What I'd wanted to add (and would be far more maintainable) was just
>>> this:
>>>
>>> Export-Package: com.sun.mail.handlers; version=${mail.version}
>>>
>>> since we're just repackaging mail.jar and the existing jar already
>>> exports the other packages. It appears BND does not support this
>>> (or I just can't figure out how to do it).
>>>
>>> -Peter
>>>
>>> Peter Williams wrote:
>>>> There is already a bug logged (perhaps more than one -- IIRC there
>>>> is also one logged in Glassfish issue tracker).
>>>>
>>>> Bugtraq id is 6839696.
>>>>
>>>> -Peter
>>>>
>>>> Sahoo wrote:
>>>>> I am making the change. In the mean while, can you please file a
>>>>> bug and send me the bug id? I want to record the discussion in
>>>>> issue tracker for future reference.
>>>>>
>>>>> Thanks,
>>>>> Sahoo
>>>>>
>>>>> Peter Williams wrote:
>>>>>> Thanks. This is more what I had in mind.
>>>>>>
>>>>>> I'll confer with Bill to ensure that META-INF/mailcap is the only
>>>>>> file impacted (and if it's not, I'll send you a list w/
>>>>>> justification).
>>>>>>
>>>>>> Looking forward to testing your patch. I can sync with JavaMail.
>>>>>>
>>>>>> Thanks again.
>>>>>> -Peter
>>>>>>
>>>>>> Sahoo wrote:
>>>>>>> Looking at the all the emails, I decided to reply to the
>>>>>>> original posting to avoid confusion. Our class loader hierarchy
>>>>>>> looks something like this (-> indicates classloader delegation):
>>>>>>>
>>>>>>> /Application Class Loader (e.g., WebAppClassLoader) -> //Common
>>>>>>> Class Loader (lib, domain/lib, etc) -> //"API Class Loader" ->
>>>>>>> Extension Class Loader (java.ext.dirs) -> Bootstrap Class Loader
>>>>>>> (null)
>>>>>>> /
>>>>>>> (Some intermediate loaders have been excluded from the above
>>>>>>> delegation chain)
>>>>>>>
>>>>>>> "API Class Loader" is a gateway to OSGi world. It already takes
>>>>>>> care of META-INF/Services files. We can change this class loader
>>>>>>> to be friendly with JAF and search META-INF/mailcap files in all
>>>>>>> installed OSGi bundles. Once we do this, the only change
>>>>>>> JavaMail folks have to do is to export the implementation
>>>>>>> classes (I suggest them to use *Class Filtering* if they don't
>>>>>>> want to export all the classes from that package), as any
>>>>>>> exported class can be loaded by our "API Class Loader." As long
>>>>>>> as JavaMail is used by Java EE applications in GlassFish, this
>>>>>>> will work.
>>>>>>>
>>>>>>> With this solution, because of delegation hierarchy, a call to
>>>>>>> /
>>>>>>> "Application Class Loader."getResources("META-INF/mailcap") /
>>>>>>>
>>>>>>> would return mailcap files found in any of the following places:
>>>>>>> rt.jar,
>>>>>>> any jar in java.ext.dirs,
>>>>>>> any OSGi bundle (this includes javax.mail.jar),
>>>>>>> any jar in any of glassfish library directories,
>>>>>>> application archive itself (.war or ejb.jar etc.).
>>>>>>>
>>>>>>> I think this is the correct behavior.
>>>>>>>
>>>>>>> Peter,
>>>>>>>
>>>>>>> I can send you a patch privately to try out. You have to change
>>>>>>> JavaMail bundle to export those classes to get things working.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Sahoo
>>>>>>>
>>>>>>> Peter Williams wrote:
>>>>>>>> I'm investigating a JavaMail failure in V3 that is caused by
>>>>>>>> the current OSGi configuration and I'm trying to figure out how
>>>>>>>> to fix it.
>>>>>>>>
>>>>>>>> The issue is this: Code in the JDK (JAF in this case) is
>>>>>>>> calling getResources() on the current context classloader (web
>>>>>>>> app classloader in my test case, but probably could another
>>>>>>>> one) to locate any available mailcap files. It's trying to
>>>>>>>> find META-INF/mailcap.default in javax.mail.jar. This fails,
>>>>>>>> the code breaks. Outside of OSGi, this all works fine.
>>>>>>>>
>>>>>>>> So what needed to happen here to make this work? Should
>>>>>>>> javax.mail.jar be exporting META-INF? How? Does the JDK have
>>>>>>>> to import this? (how?!)
>>>>>>>>
>>>>>>>> Once this is resolved, I'm worried about the next step -- the
>>>>>>>> definitions in the mailcap file refer to implementations of
>>>>>>>> DataHandlers (JAF interface) that are in a private package of
>>>>>>>> javax.mail.jar. I hope I'm wrong, but I suspect JAF will be
>>>>>>>> unable to access these classes to instantiate them. What is
>>>>>>>> the solution? Export those packages too? Even though they are
>>>>>>>> supposed to be private?
>>>>>>>>
>>>>>>>> -Peter
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> 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
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>