deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <>
Subject Re: [DISCUSS] deltaspike-jpa module features
Date Sun, 06 May 2012 22:11:38 GMT
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.


----- Original Message -----
> From: David Blevins <>
> To:; Mark Struberg <>
> 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

View raw message