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: [DISCUSS] deltaspike-jpa module features
Date Sun, 06 May 2012 06:08:31 GMT
@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-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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message