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
>