deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: AW: [DISCUSS] deltaspike-jpa module features
Date Sun, 06 May 2012 09:58:52 GMT
Mark,

I dont see why you find dsdef limited.
Le 6 mai 2012 11:38, "Mark Struberg" <struberg@yahoo.de> a écrit :

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message