openejb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luis Fernando Planella Gonzalez <>
Subject Re: Resolve datasource from the application name
Date Thu, 19 Nov 2009 11:46:59 GMT
I'd love to keep helping on this issue...
However I have an imminent issue: My daughter will be born on saturday, so 
I'll be off for a week or so.
Afterwards, we can resume the subject.

Anyway, that algorithm should be used only when neither jtaDataSource nor 
nonJtaDataSource are used, right? At least for what I saw in code, it's 
possible to have only nonJtaDataSource (making a new jta datasource to be 

So, my guess would be to make the chunk of code I added to deploy(app, 
persistenceModule) a private method, let's say, locateDataSource(id), which 
would look for a jta data source with that name, then a non-jta, then an 

So, could it be something like:
* if explicit datasources are used, use them
* if neither jta-data-source nor non-jta-data-source, try to guess:
*** try locateDataSource(persitenceUnit.getName())
*** if not found, try locateDataSource(persistenceModule.getModuleId()) // Is 
it really necessary? As I saw, PersistenceModule.getModuleId() is always null
*** if not found, for each WebModule try 

What do you think?

Luis Fernando Planella Gonzalez

Em Quinta-feira 19 Novembro 2009, às 01:20:19, David Blevins escreveu:
> On Nov 16, 2009, at 5:21 AM, Luis Fernando Planella Gonzalez wrote:
> > Well, assuming that my assumptions are right, I've patched AutoConfig
> > to use the first WebModule's root context name as a guess to the
> > DataSource name.
> > I've attached the patch, as well as complete files for AutoConfig and
> > AutoConfigPersistenceUnitsTest in
> >
> > As this is my first code contribution to OpenEJB. So, please, correct
> > me if I did anything wrong...
> > Feedbacks are appreciated.
> This is a great start, thanks!  I've gone ahead and committed it.
> Would be great to get the other searches in there described in
> OPENEJB-1027 such as linking based on the persistence unit name, etc.
> I'm not sure the code is setup to make this easy now because the
> getResourceId() method is perhaps too aggressive -- it always finds an
> id no matter what -- but but at a high level it seems like something
> like this would be really cool.
>      List<String> strings = new ArrayList<String>();
>      strings.add(jtaDataSourceName);
>      strings.add(persistenceUnitName);
>      strings.add(moduleName);
>      strings.add(applicationName);
>      String resourceId;
>      for (String string : strings) {
>          resourceId = getResourceId(string);
>          if (resourceId != null) break;
>      }
>      // use the resourceId ....
> That's the high level thought at least.  Lot's of ways that could be
> rolled out with the existing code.  Maybe we just change
> getResourceId() so that the 'String resourceId' is actually a var-arg
> and move it to the end of the signature.  Or something.
> Open to ideas.
> And just as a side note, you're under no obligation to keep working on
> this, but you're doing great and we can always use the help! :)
> -David

View raw message