@mark: +1 regards, gerhard
Am Fr., 7. Apr. 2023 um 09:45 Uhr schrieb Mark Struberg <[email protected]>: > > a) I'd rather keep the current names. Just because of backward compat and > adoption. Maybe the names are not perfect, but they are rather fine. It > should really be mostly a package renaming and be done > > b.) @Romain, there is a HUGE difference between DeltaSpike @Transactional and > javax.transaction.Transactional: > We have a very clear rule when it comes to Exceptions. In DS, if an Exception > appears we will do a rollback, otherwise we will do a commit. > In javax/jakarta @Transactional only RuntimeExceptions and > ApplicationExceptions with rollback=true will create a rollback, all other > Exceptions will still cause a commit. This was 1:1 taken from EJB (which is > imo also rather broken). Most people don't even don't realise that they might > get a FileNotFoundException in the middle of their business code and STILL > all the half done changes will be committed. > > Otoh if you have a RuntimeException in some nested Services ,A.fn() calls > B.fn(), which is not catched when returning from the EJB 'Business Method' > B.fn() the whole transaction will get marked as rollbackOnly(). Even if you > would have catched this very Exception in A.fn(). That's another major pain. > > I wrote a lengthy blog post about it many moons ago: > https://struberg.wordpress.com/2015/04/21/transaction-and-exception-handling-in-ejbs-and-javaee7-transactional/ > > All this was the reason why we introduced the DeltaSpike @Transactional. It > has a very clear semantic: > On the very layer ('business method' invocation) where the transaction got > opened we do the check. If there is any Excpetion thrown -> Rollback, > otherwise -> Commit. > Any subsequent nested calls into @Transactional business methods are > completely transparent. > > You can also mix this with EJB and leverage any platform provided features if > you use our TransactionStrategy which uses an injected UserTransaction to get > the best of both worlds. > > DeltaSpike @Transactional is btw also used in projects which do not use our > data module. Thus I'd leave everything in place. Please also think about the > poor souls which just want to move from javax to jakarta *without* having > such a deep knowledge about DeltaSpike as we do! > > > LieGrue, > strub > > > > > Am 04.04.2023 um 10:06 schrieb Romain Manni-Bucau <[email protected]>: > > > > Hi, > > > > Do we have some visibility about the usage? > > Think jpa/tx feature tend to disappear in new applications because JTA got > > it (we like or not the design is another thing but feature is there > > built-in now comared to when DS was created). > > So for a new major we can aim at dropping it - keeping in 1.x. > > About data module I guess the adoption is not that high even if module is > > really "cool" - guess we miss the jaxrs bridge but we never got any request > > about it - so not sure its future. > > It can likely be the same for almost all core module which is now almost > > standard in CDI or Microprofile/coming Jakarta (idea being to not bring > > things without added value in time for a new major). > > > > So overall I wouldnt aim at renaming but more pruning what is built in or > > will be soon and make DS lighter now resources are very low and the need of > > the project really less important than years ago. > > > > Hope it makes sense. > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://rmannibucau.metawerx.net/> | Old Blog > > <http://rmannibucau.wordpress.com> | Github > > <https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > > > > > > Le mar. 4 avr. 2023 à 09:57, Thomas Andraschko <[email protected]> > > a écrit : > > > >> JPA is also about reading the JPA XML descriptors and resolving > >> EntityManagers, which is both heavily used in the Data module. > >> So its currently much more than TX. I would rename it to ds-persistence and > >> ds-faces. > >> > >> Am Mo., 3. Apr. 2023 um 19:20 Uhr schrieb Gerhard Petracek < > >> [email protected]>: > >> > >>> hi thomas, > >>> > >>> we need to fix the rat-check (see [1]). > >>> > >>> @renaming the modules: > >>> the jpa-module was always mainly about the "entitymanager" + > >>> "transaction" (see the package-naming)... with the main focus on > >>> transactions (see @Transactional and @TransactionScoped as the main > >>> api). > >>> therefore we almost renamed it to ds-tx (in the beginning). we just > >>> kept 'jpa', because it wasn't clear what we might add later on. > >>> maybe we should just start a community-poll about it. > >>> > >>> regards, > >>> gerhard > >>> > >>> [1] > >>> https://ci-builds.apache.org/job/DeltaSpike/job/DeltaSpike%20RAT-Check/ > >>> > >>> > >>> > >>> Am Mo., 3. Apr. 2023 um 16:08 Uhr schrieb Thomas Andraschko > >>> <[email protected]>: > >>>> > >>>> Hi, > >>>> > >>>> last week i had some time and migrated almost all still existing > >> modules > >>> to > >>>> Jakarta. Only scheduler is currently not migrated. > >>>> AFAICS servlet, bean-validation has been removed, also other small > >> pieces > >>>> of core. > >>>> > >>>> I would also like to rename jpa and jsf to their new jakarta name > >>>> (persistence and faces). > >>>> WDYT guys? > >>>> > >>>> After that rename and reintroduce the scheduler module, i would be > >> happy > >>>> enough to release a RC1. > >>>> > >>>> AFAICS a big missing part are the tests on real containers?! > >>>> Any other topics we need to address? > >>>> > >>>> Best regards, > >>>> Thomas > >>> > >> >
