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
>