Peter Williams wrote:
>
>
> Bill Shannon wrote:
>> Richard S. Hall wrote:
>>>
>>>
>>> On 5/19/09 4:08 PM, 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?!)
>>>
>>> If I understand correctly, it sounds like JAF expects to be able to
>>> access every available JAR file by accessing the context class
>>> loader. This is a recipe for failure in OSGi.
> I don't know that JAF was expecting to access *EVERY* available jar file
> (perhaps), but certainly most of them and very likely any of them that
> actually contained "META-INF/mailcap" would be in the "most of them"
> list (e.g they won't be in weird agent jars or bootloader stuff, just
> plain application or library jars).
Right, any jar used by the application should be accessible.
Since the application needs to be able to load classes from any
of these jars, why shouldn't it be able to see resources from
any of these jars?
> Anyway, see below.
>
>>>
>>> Typically, these sorts of situations involve some sort of extender
>>> listening for bundles with mailcap files and then the information in
>>> them can be injected where appropriate.
>>>
>>> Unfortunately, I don't know enough about JAF to say in detail how
>>> this might work.
> I can help with JAF if you can help me interpret OSGi.
>
> Can you tell me why, even though JAF accessed a classloader that knew
> about javax.mail.jar, the file at META-INF/mailcap in that jar was not
> accessible. Is this because javax.mail.jar does not export META-INF?
> (I had problems attempting this, but I don't have the errors handy right
> now -- glassfish build issued a bunch of split package warnings though,
> I'm guessing because META-INF is present in all jars).
>
> Assuming the file can be located and processed though, it will contain
> fully qualified class names for the implementations of a particular
> public interface. The implementations will be in private packages of
> javax.mail.jar.
>
> Do you think JAF be able to instantiate these classes? If not, they'll
> need to be exported (e.g. public) too, correct?
I would expect those internal classes to need to be exported.
We probably need to change the maven-bundle-plugin configuration
to export these things.