So DeltaSpike is not designed to run on full application servers? We (and I think a lot of other people) use CDI with EJB because of pragmatism: security, thread safety, asynchronicity. Of course we can write security handling and some thread safe scope on our own, but we prefer spending time on writing business logic - not inventing frameworks.
Best regards, Konrad On Fri, Mar 3, 2017 at 9:49 AM, Remo Meier <[email protected]> wrote: > Hi > > We make use of a setup with Deltaspike with Weld, JBeret, RestEasy, > narayana, jnpserver and hiberate. That gives many of the EE7 features > (except EJBs, which we don't really need). It is a bit of an effort to > setup. If there is any interest, maybe that could be contributed as a more > advanced flavor of the deltaspike weld integration (a "deltaspike wildfly" > resp. "deltaspike weld+) or something). > > (should somebody be able to get an entire wildfly running in deltaspike, > that would of course also be quite intresting. Not sure whether that is > possible or not with their module architecture or wildfly swarm) > > Regards Remo > > > > > Am 3/3/2017 um 9:38 AM schrieb Instantiation Exception: > >> Hi, >> >> In my company projects we use WildFly. In the past I tried few times to >> use >> DeltaSpike Data, but it didn't work. I configured everything according to >> documentation. In pure CDI scenario it worked. But when I created >> @Dependent @Repository and injected it to @Stateless EJB I got some >> transaction errors when tried to call EJB methods. In documentation I see >> warning: >> >> Some containers do not support BeanManagedUserTransactionStrategy! As JTA >> >>> has still some portability issues even in Java EE 7, it might be required >>> that you implement your own TransactionStrategy. We will think about >>> providing an acceptable solution for this. >>> >> >> Is it about WildFly? Is WildFly supported? >> >> Best regards, >> Konrad >> >>
