openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Prud'hommeaux <mprud...@apache.org>
Subject Re: Update version to SNAPSHOT
Date Tue, 15 Aug 2006 23:48:15 GMT
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
>>>
>>>
>>>
>>
>


Mime
View raw message