David-
But you might consider making
"org.apache.openjpa.conf.ProductDerivation" a directory that holds
files that contain the implementation class names. Then you can
have more than one in a jar.
That would solve the problem, but since there is no generic
classloader-based way of getting a list of resources beneath a
certain directly, I would be uncomfortable with that approach, since
it makes a lot of packaging assumption (it looks like it only works
if the resources are stored in a top-level jar or on the file
system). What if the resources are embedded in multiple levels of
jars (like in a WAR or RAR)? Or what if an exotic custom classloader
(common in EJB containers) is being used to load the classes that
doesn't report a protocol in a way that ResourceFinder understands,
or if it is using a network ClassLoader?
Also, it will be nice to remain compatible with the upcoming JDK 1.6
java.util.ServiceLoader utility.
It's probably safer just to manually append he services files, even
though it requires writing something to manage the merging of the jars.
On Aug 15, 2006, at 3:14 PM, David Blevins wrote:
On Aug 15, 2006, at 12:56 PM, Marc Prud'hommeaux wrote:
David-
are there any jars of our own that contain the same file in the
same place in the jar and those contents are different and need
to be merged together?
The only cases I know of are some of the files in services/. E.g.:
openjpa-jdbc/src/main/resources/META-INF/services/
org.apache.openjpa.conf.ProductDerivation
openjpa-persistence-jdbc/src/main/resources/META-INF/services/
org.apache.openjpa.conf.ProductDerivation
openjpa-persistence/src/main/resources/META-INF/services/
org.apache.openjpa.conf.ProductDerivation
It's probably not rocket science to fix these (we would would just
need to figure out a way to append them to each other), but it
would prevent OpenJPA from working if we were to just merge the
jars and overwrite same-named files.
I've had this issue too. I wrote a small library (one class) in
xbean to spin the /META-INF/services/ concept any way you like
pretty much.
This would cover the way you do things now:
import org.apache.xbean.finder.ResourceFinder;
ResourceFinder resourceFinder = new ResourceFinder("META-INF/
services/");
List<Class> classes = resourceFinder.findAllImplementations
(org.apache.openjpa.conf.ProductDerivation.class);
But you might consider making
"org.apache.openjpa.conf.ProductDerivation" a directory that holds
files that contain the implementation class names. Then you can
have more than one in a jar.
Here's an example directory:
http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/
src/test/resources/META-INF/java.net.URLStreamHandler/
Here's how you'd get your implementations:
import org.apache.xbean.finder.ResourceFinder;
ResourceFinder resourceFinder = new ResourceFinder("META-INF/");
Map<String, Class> streamHandersMap =
resourceFinder.mapAllImplementations(java.net.URLStreamHandler.class);
You could just grab all the values from the map and be done with
it. But the keys will the file name under "META-INF/
java.net.URLStreamHandler/", which can be useful for all sorts of
things.
Here is the full test case: http://svn.apache.org/repos/asf/
geronimo/xbean/trunk/xbean-finder/src/test/java/org/apache/xbean/
finder/ResourceFinderTest.java
-David
On Aug 15, 2006, at 12:46 PM, David Blevins wrote:
On Aug 15, 2006, at 11:40 AM, Craig L Russell wrote:
On Aug 15, 2006, at 11:06 AM, David Blevins wrote:
On Aug 15, 2006, at 6:37 AM, Patrick Linskey wrote:
Note that that will not merge anything you need in the META-INF
directory. It does do it for plexus components.xml files
though, so
maybe it's a good time to make that pluggable.
It'll definitely add the files from all the META-INF
directories into
the resulting jar. I guess you are talking specifically
about some
pluggable strategy to merge two files of the same name such
as two
META-INF/persistence.xml files or two META-INF/ejb-jar.xml
files?
Actually, I was thinking about META-INF/MANIFEST.MF and
META-INF/services/*. But yes, merging of resources.
Everything in META-INF/services/* will be copied into the new
jar and you can redefine MANIFEST entries for the new jar using
the same syntax as for the maven-jar-plugin. But it won't
intelligently concatenate the contents of individual matching
files from the source jars as I assume Brett was referring to
with the plexus components.xml.
So would it be easier to write a merge-manifest method or to
restrict manifest services with the same name to one of the
build modules?
Sorry, I think I'm making things clear as mud :) I get the
feeling we don't even have the issue Brett was mentioning. Aside
from the MANIFEST.MF file itself, are there any jars of our own
that contain the same file in the same place in the jar and those
contents are different and need to be merged together?
It's pretty easy to make a new MANIFEST.MF that better describes
the new "uber" jar.
-David
