Here the jndi name should be respected. So lookup on the name you provided. Le 5 mai 2012 12:17, "Mark Struberg" <[email protected]> a écrit :
> 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 > >> > > >> > > >
