openejb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: Resolve datasource from the application name
Date Fri, 09 Oct 2009 20:07:32 GMT

On Sep 30, 2009, at 9:05 AM, Luis Fernando Planella Gonzalez wrote:

> Hi.
> I've reported http://issues.apache.org/jira/browse/OPENEJB-1027 in  
> may, which
> is modifying a bit the heuristics to resolve a data source by  
> matching the app
> name (web app context in our case) if the data source has not been  
> explicitly
> specified. This was previously discussed with David Blevings, and he  
> suggested
> that way.
>
> Just to explain the use case: We're migrating cyclos (http://www.cyclos.org 
> ),
> an open source struts / hibernate application to gwt / ejb3. Many  
> people host
> several instances of the very same application in the same tomcat,  
> and to keep
> supporting that it would be necessary to unpack, change every  
> persistence.xml
> from each and repack each instance again. With this feature  
> implemented, we
> can just assume there will be a data source with the same name of the
> application context and we're done, and our users will be happy :)
>
> We can try patching ourselves, but we need some guidance on both  
> fundamental
> questions:
> * Where is this heuristic implemented?
> * How to get the current application name?

The logic is in:

http://svn.apache.org/repos/asf/openejb/trunk/openejb3/container/openejb-core/src/main/java/org/apache/openejb/config/AutoConfig.java

There's a pretty good test case for the persistence unit side of that  
logic here:

http://svn.apache.org/repos/asf/openejb/trunk/openejb3/container/openejb-core/src/test/java/org/apache/openejb/config/AutoConfigPersistenceUnitsTest.java

The javadoc was incorrect in some places, so I did a sweep through it  
and fixed it all for you.

I recommend starting with a copy of the AutoConfigPersistenceUnitsTest  
and expand it to always have two apps and spend a good amount of time  
covering all the scenarios  (what happens when there are more apps  
than data sources, what if there are no data sources that match,  
etc.)   The logic in AutoConfig is a bit of a beast.

Even if you aren't able to get the logic in, having a really good test  
case that covers more than just the "happy path" would be extremely  
valuable.  For functionality like this I spend at least 60% of the  
time on the test case, so even having that would be a major help  
towards getting this feature in.  The test case also kind of like a  
requirements doc, which is a cool thing when collaborating.


-David



Mime
View raw message