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