deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: AW: [DISCUSS] deltaspike-jpa module features
Date Sun, 06 May 2012 09:37:54 GMT
Hi Arne!

For your 1. please see the 'PersistenceStrategy' trick we did in the CODI TransactionalInterceptor
[1]. Our interceptor is basically a facade which delegates all the work to the injected @Dependent
PersistenceStrategy. We would provide 2 different implementations: a resource local and a
JTA based one.


Just to stress that point again: 


> ConfigurableDataSource needs to be registered in JNDI. In Java-EE-Containers 
> this can be done with the @DataSourceDefinition annotation. 
Yes, but ONLY if you need just one single configuration! 


> In plain Tomcat or 
> Jetty servers this needs to be configured in a container-specific way.
The problem with the container specific stuff is that every container serves the xml configured
datasource on a different location in JNDI! So you cannot provide a container independent
implementation that way :/


Rest sounds good, I'll think about it the next days!

LieGrue,
strub


[1] 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



----- Original Message -----
> From: Arne Limburg <arne.limburg@openknowledge.de>
> To: "deltaspike-dev@incubator.apache.org" <deltaspike-dev@incubator.apache.org>
> Cc: 
> Sent: Sunday, May 6, 2012 11:17 AM
> Subject: AW: [DISCUSS] deltaspike-jpa module features
> 
> Hi,
> I think we have different dimensions here:
> 1. Who manages the transaction: JTA vs. RESOURCE_LOCAL (which basically means, 
> should entityManager.joinTransaction() or entityManager.getTransaction().begin() 
> be used in an @Transactional interceptor)
> 2. From where can the datasource be obtained: From JNDI or is it defined via the 
> persistence properties
> The third (minor) dimension that applies only if the datasource comes from JNDI: 
> Is it a jta- or non-jta-datasource
> 
> So the first dimension has to be respected when talking about 
> transaction-management
> and the second, when talking about datasource-configuration.
> 
> So, as I see, currently we are talking about the second:
> Now the question is, how to configure the datasource in both scenarios. And both 
> can be done with the ConfigurableDataSource:
> First scenario: The datasource is obtained from JNDI: Then the 
> ConfigurableDataSource needs to be registered in JNDI. In Java-EE-Containers 
> this can be done with the @DataSourceDefinition annotation. In plain Tomcat or 
> Jetty servers this needs to be configured in a container-specific way.
> Second scenario: The datasource is configured via persistence properties. Then 
> the ConfigurableDataSource can be configured like described in the CoDI wiki.
> 
> How can deltaspike help people here? First of all we provide the 
> ConfigurableDataSource and thus enable DataSource configuration via CDI.
> In addition, if we provide some kind of EntityManagerProducer, we can override 
> the persistence.xml via the additional properties map, that can be handed over 
> to the createEntityManagerFactory and createEntityManager methods.
> For JNDI, we can register a ConfigurableDataSource with the 
> @DataSourceDefinition under a deltaspike-specific name and then give this 
> datasource to JPA by setting the javax.persistence.jtaDataSource or 
> javax.persistence.nonJtaDataSource property in the map.
> For non-JNDI we can change the javax.persistence.jdbc.driver property to point 
> to our ConfigurableDataSource.
> 
> We even could provide a mechanism to change from JTA to RESOURCE_LOCAL (i.e. for 
> production vs. testing) by specifying the javax.persistence.transactionType 
> property.
> 
> What do you think about this?
> 
> Cheers,
> Arne
> 
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com] 
> Gesendet: Sonntag, 6. Mai 2012 08:09
> An: deltaspike-dev@incubator.apache.org
> Betreff: Re: [DISCUSS] deltaspike-jpa module features
> 
> @Mark: today using your own datasource implementation with @datasourcedefinition 
> you answer your need. The drawback compared to producers is you need to test the 
> env where producers will have stereotypes but it does the job even for 
> complicated envrt.
> 
> - Romain
> Le 6 mai 2012 05:02, "Jason Porter" <lightguard.jp@gmail.com> a 
> écrit :
> 
>>  Wasn't there another company, Software Mill?, which had some 
>>  persistence stuff we liked during formation?
>> 
>>  Sent from my iPhone
>> 
>>  On May 5, 2012, at 16:14, Mark Struberg <struberg@yahoo.de> wrote:
>> 
>>  > 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-modu
>>  les/jpa-module/impl/src/main/java/org/apache/myfaces/extensions/cdi/jp
>>  a/impl/transaction/TransactionalInterceptor.java
>>  >>>>>>>
>>  >>>>>>> [3]
>>  >>>>>>>
>>  >>>>>>
>>  >>>>
>>  >>>
>>  >>
>>  https://cwiki.apache.org/EXTCDI/jpa-usage.html#JPAUsage-ConfigurableDa
>>  taSource%28sincev1.0.2%29
>>  >>>>>>>
>>  >>>>>>
>>  >>>>>
>>  >>>>>
>>  >>>>
>>  >>>
>>  >>
>> 
> 

Mime
View raw message