deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: [DISCUSS] deltaspike-jpa module features
Date Sat, 05 May 2012 22:14:34 GMT
Yes, we should first concentrate on the other 2 things. We can try to find an even better solution
than the ConfigurableDataSource.

But I fear the @DataSourceDefinition from EE6 is completely useless for most real world apps.
The problem which I see with it that you can only have 1 of it per 'real' DataSource. Of course
that would change if there would be a way to create the 'real' DataSource via CDI producers.


But I have no idea yet how to hand over a CDI produced DataSource to a JPA.


LieGrue,
strub



----- Original Message -----
> From: Romain Manni-Bucau <rmannibucau@gmail.com>
> To: deltaspike-dev@incubator.apache.org
> Cc: 
> Sent: Saturday, May 5, 2012 11:29 PM
> Subject: Re: [DISCUSS] deltaspike-jpa module features
> 
> With my note on datasourcedefinition i wanted to avoid to add sthg new. I'd
> prefer to fix existing API/specs.
> 
> Adding sthg new simply creates another mess...no?
> 
> - Romain
> Le 5 mai 2012 22:39, "Paul Dijou" <paul.dijou.dev@gmail.com> a 
> écrit :
> 
>>  Hi,
>> 
>>  Big +1 for all suggestions from Mark.
>> 
>>  Also +1 for some util classes for common operations like CRUD and
>>  pagination. Maybe inspiration from Seam Application Framework (Home, Query,
>>  Controller) in Seam 2 [1] or from DataValve [2].
>> 
>>  Regards,
>> 
>>  Paul.
>> 
>>  [1]
>>  http://docs.jboss.org/seam/2.2.2.Final/reference/en-US/html/framework.html
>> 
>>  [2] http://www.andygibson.net/blog/projects/datavalve/
>> 
>>  2012/5/5 Romain Manni-Bucau <rmannibucau@gmail.com>
>> 
>>  > Maybe using a datasource bean managed by cdi as a jpa datasource 
> source
>>  can
>>  > be added to jpa or cdi (it is always a bit hard to decide which specs
>>  > qhould contain a new feature ;))?
>>  >  Le 5 mai 2012 00:55, "Romain Manni-Bucau" 
> <rmannibucau@gmail.com> a
>>  > écrit :
>>  >
>>  > > 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 <gerhard.petracek@gmail.com>
>>  > >
>>  > >> 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 <struberg@yahoo.de>
>>  > >>
>>  > >> > 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
>>  > >> >
>>  > >>
>>  > >
>>  > >
>>  >
>> 
> 

Mime
View raw message