Thanks David. I'll arrange my tasks to work on this. I'll probably report back in a few weeks, as I have other tasks before digging into this one. -- Luis Fernando Planella Gonzalez
Em Sexta-feira 09 Outubro 2009, às 17:07:32, David Blevins escreveu: > 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-co > re/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-co > re/src/test/java/org/apache/openejb/config/AutoConfigPersistenceUnitsTest.j > ava > > 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 >
