Hi Romain! You mean
http://docs.oracle.com/javaee/6/api/javax/annotation/sql/DataSourceDefinition.html https://blogs.oracle.com/Lance/entry/introducing_the_datasourcedefinition_annotation ? I'm still not sure how this works in practice (despite the fact that e.g. tomcat doesn't support it). This takes the configuration info from the annotation and binds it to the given name= ... JNDI location, right? That would be ok for the part where the app contains the credentials and stuff. Let's play some mind-games with a standard project. My App has 4 different ProjectStage configurations: * local development/unit testing * CI integration testing * user test staging area * production system (in our project we have even 2 more) Each of them can be used with the following databases: * MySQL (the default we use for local development) * Oracle (the default we use in production and staging) * PostgreSQL (the future default for our production and staging environments) That means we have quite a lot different db configurations. But that's how it often is in big real world projects... For simplicity we have default credentials (username/pwd) in our app (using CODI @ProjectStageActivated) for all the systems and configs except staging and production. For those we rely on JNDI. But depending on the server we deploy the app on (JBoss, Glassfish, WebSphere, TomEE, etc) the JNDI location for a container-configured DataSource changes heavily. Thus even in those cases we need to change the configuration: we need to adopt the JNDI location where the DataSource can be picked up. That's really a big mess in EE! How would such a scenario work using the @DataSourceConfig? LieGrue, strub ----- Original Message ----- > From: Romain Manni-Bucau <[email protected]> > To: [email protected] > Cc: > Sent: Saturday, May 5, 2012 12:55 AM > Subject: Re: [DISCUSS] deltaspike-jpa module features > > Hi, > > isn't the ConfigurableDataSource in JEE6? (datasourceconfiguration by > annotation or in the web.xml)? > > a really really big +1 for a pagination solution (typically a hades light > is a must have!) > > - Romain > > > 2012/5/4 Gerhard Petracek <[email protected]> > >> hi @ all, >> >> @ a) >> +1 >> >> @ b) >> +1 for the basic concepts, however, @Transactional and @TransactionScoped >> need to be refactored (i'm currently working on it). >> >> furthermore, we should discuss a thin query layer which supports e.g. >> pagination,... easily (we also need it for a security-jpa module). >> >> regards, >> gerhard >> >> >> >> 2012/5/4 Mark Struberg <[email protected]> >> >> > Hi! >> > >> > It's time to start the discussion about our deltaspike-jpa module > I think >> > ;) >> > >> > a.) where >> > I suggest that we create a ee-modules project with submodules jsf, > jpa, >> > etc >> > >> > b.) what >> > *) @Transactional >> > *) TransactionalInterceptor with SimplePersistenceStrategy, >> > JtaPersistenceStrategy >> > *) ConfigurableDataSource, evaluate if we can make use of a special >> > PersistenceUnitInfo for JPA2 providers, but would that work in EE >> > containers as well? >> > >> > Because I often get asked if we can add this: I think we do _not_ need > to >> > cover the (imo) broken Exception handling stuff which spring > introduced >> in >> > their transaction interceptor. An Exception is an Exception is an >> > Exception! Logical return values and Business results must get > propagated >> > via standard java return values or content holder objects. >> > >> > Oki the details: >> > >> > 1.) @Transational >> > >> > I suggest that we temporarily implement the javax.transaction.* stuff > of >> > the _new_ Transaction Specification in DeltaSpike. We can take parts > from >> > OpenEJB, some JBoss api stuff (as far as covered by the grants) and >> various >> > geronimo spec jars [1] >> > Once the spec is finished, we will move all the transaction-api.jar > stuff >> > over to geronimo-specs [1]. Since this all is ALv2 it will be no > problem >> > for JBoss folks to also just take the code and provide it in the > JBossAS >> > project once we are finished. >> > >> > 2.) I like the way we implemented the TransactionalInterceptor in CODI >> > [2]. Our interceptor basically does exactly ... *nothing* ;) >> > All the work is done via an @Dependent PersistenceStrategy which gets >> > injected into the interceptor. @Dependent because then we don't > get any >> > interceptor and it's really fast. >> > The BIG benefit of this little trick is that we are able to provide > and >> > use DIFFERENT PersistenceStrategies! A user can use @Alternative, >> > @Specializes etc to define which PersistenceStrategy he likes to use > in >> his >> > project. >> > >> > By default I'd like to provide the following > PersistenceStrategies: >> > * SimplePersistenceStrategy: does just flush on all involved >> > EntityManagers and afterwards a commit. Not JTA transaction save, but >> good >> > enough for most use cases >> > * JtaPersistenceStrategy: uses a JTA bound @UserTransaction to > control >> > the EntitaManagers. This needs some exploration how we can do it. > David >> > Blevins and Arne Limburg are pretty good into this stuff. I'm > dreaming of >> > kind of the features of EJB standard transations, but NOT just for an > EJB >> > invocation, but @RequestScoped! The first invocation starts the >> > UserTransaction, the @Disposes closes it. Just an idea ... >> > >> > >> > 3.) ConfigurableDataSource >> > You all know the dilemma: you cannot make a JNDI configuration in a > way >> > that this stuff works with multiple EE servers since the locations > where >> > you have your DataSource configured will pop up under different > locations >> > in JNDI (based on which EE server/version you take). Otoh I don't > like to >> > hardcode my credentials to the persistence.xml neither. >> > >> > Thus we came up with the ConfigurableDataSource [3]which just moves > this >> > information to a CDI bean where you can use >> > @Exclude(ifNotInProjectStage...), @Alternative, @Specializes and even >> > programmatic lookup!. I call this 'typesafe configuration'... >> > >> > >> > >> > Oki, any other ideas? >> > >> > LieGrue, >> > strub >> > >> > >> > [1] http://repo1.maven.org/maven2/org/apache/geronimo/specs/ >> > >> > [2] >> > >> > https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/jee-modules/jpa-module/impl/src/main/java/org/apache/myfaces/extensions/cdi/jpa/impl/transaction/TransactionalInterceptor.java >> > >> > [3] >> > >> > https://cwiki.apache.org/EXTCDI/jpa-usage.html#JPAUsage-ConfigurableDataSource%28sincev1.0.2%29 >> > >> >
