Craig L Russell wrote:
Sorry, correcting email address.
On May 20, 2009, at 4:27 PM, Craig L Russell wrote:
Hi Felix Devs,
I'm curious about the issue contained in this thread.
My understanding of the issue is this:
If an application is running in an OSGi environment and declares a
dependency (its OSGI manifest imports the java mail packages) does its
context class loader see the javax.mail jar in its entirety? My guess
is: not. The OSGi class loader implements the getResources call and
filters for exported artifacts.
So, in order for the application to see the META-INF/mailcap.default
resource, this file would need to be exported explicitly and then the
getResources as implemented by OSGi container would find it.
It's actually just META-INF/mailcap ("mailcap.default" was a typo on my
part). And it's not just the mailcap from JavaMail although that one is
important. A 3rd party library jar that implemented or otherwise
referenced custom handlers could include it's own META-INF/mailcap and
JAF should be able to load that file as well and instantiate the
handlers therein on demand (such as when processing an email message
that required them).
I'm hoping Richard will tell me that I can somehow have such mailcaps
exported or otherwise made available, but all of my research so far
suggests this is not possible.
As for the service layer, I'm interested in Richard's response on that
as well.
-Peter
Similarly, if an OSGi bundle wants to makes its
META-INF/services/some.implemented.Interface file available, the OSGi
manifest would have to explicitly export it.
Does the user then need to explicitly name the
META-INF/services/some.exported.Interface in order to access all the
implementations via getResources?
Thanks,
Craig
Begin forwarded message:
From: Peter Williams <[email protected]>
Date: May 20, 2009 1:08:15 PM PDT
To: [email protected]
Subject: Re: OSGi confusion...
Reply-To: [email protected]
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).
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?
FWIW, it looks like another company (guess :)) using OSGi is having
similar problems, as I ran across their (unresolved) bugs on this
issue while research solutions.
Thanks
-Peter
This is a fairly common pattern in the JDK, and one we've recommended
in Java EE for quite a few years. This is essentially the same as
java.util.ServiceLoader.
It's fine if an OSGi bundle has to explicitly export these classes so
they can be loaded by (e.g.) JAF, but JAF needs to be able to load
these
classes using the context class loader.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:[email protected]
P.S. A good JDO? O, Gasp!
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:[email protected]
P.S. A good JDO? O, Gasp!
