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.
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
>