Hi David! Thanks for this valuable input!
I guess I need to think about that and put it up in a sample app to test it's usability. I always need some piece of code to verify if it is _really_ working. Btw, are we still d'accord that we like to support EE5, EE6 and EE7 servers with our stuff? Maybe we could provide a 'legacy path' for EE5 and another one for EE6 and 7 servers? We should also make sure that this way does work _without_ any EE server as well - means with pure JPA. Because that is was is used in most unit tests. LieGrue, strub ----- Original Message ----- > From: David Blevins <[email protected]> > To: [email protected]; Mark Struberg <[email protected]> > Cc: > Sent: Sunday, May 6, 2012 10:47 PM > Subject: Re: [DISCUSS] deltaspike-jpa module features > > > On May 6, 2012, at 1:32 PM, David Blevins wrote: > >> I recall your app and I'd guess the heart of your distaste is that you > essentially configure two datasources and then pick one at runtime. >> >> In static code, this is possible (there is equivalent xml): >> >> @DataSourceDefinition(name = "java:app/test/ds" ....) >> @DataSourceDefinition(name = "java:app/prod/ds" ....) >> @Resource(name = "java:app/ds", > lookup="java:app/prod/ds") >> public class SomeCdiBean { >> } >> >> Two datasources are declared and one symlink that the application can use > safely. Clearly the above "symlink" is still hardcoded, so to get > some more dynamic behavior you could potentially put the "@Resource" > link on a separate class in a separate jar. Perhaps a "prod.jar" to > hold all the mappings for production and a "test.jar" to hold all the > mappings for test, then make sure only one of them is in the application at > any > given time. >> >> Still limited of course as changing the archive is required and often that > isn't allowed between test and production. > > For the sake of completeness, I should also say that swapping the descriptors > out without modifying the archive is the reason for the alternate deployment > descriptor functionality (alt-dd) all full profile certified servers > support. > So even that concept has been addressed at the spec level. > > One of the things not supported by plain Tomcat or Jetty, so also not > commonly > known or used. > > > -David >
