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 <[email protected]> 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 <[email protected]> >> To: [email protected] >> 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" <[email protected]> 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 <[email protected]> >>> >>>> 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" >> <[email protected]> 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 <[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 >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>
