+1 for DS Data. Really required to get it usable in JTA context. JLouis
2014-02-07 10:02 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>: > not only, data module for insatnce is not that usable while not linked > to transactions so we need to see how we link modules between themself > (basically that's done for security at least) and get something > working out of the box (a basic JTA integration and another one with > @Transactional would be awesome). > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > > 2014-02-07 Jean-Louis MONTEIRO <jeano...@gmail.com>: > > +1 > > The core is very stable. > > Users are afraid by 0.5 or 0.6 in terms of quality. > > From my experience with DS, core module at least is very stable. > > > > JSF and Data work fine as well. > > Currently, we don't have a 1.0 mainly because some other modules are not > > totally merged nor stable maybe, right? > > > > Jean-Louis > > > > > > 2014-02-07 Mark Struberg <strub...@yahoo.de>: > > > >> Agree, it sounds good but I'd rather focus on (finnally!) shipping > DS-1.0 > >> for now. > >> > >> I'll give it a tough test drive in the next weeks to see what we miss > >> before the milestone. > >> > >> John, you could probably do a draft on github? > >> > >> LieGrue, > >> stru > >> > >> > >> > >> > >> On Friday, 7 February 2014, 6:15, Romain Manni-Bucau < > >> rmannibu...@gmail.com> wrote: > >> > >> Hi > >> > > >> >I see the use case but deltaspike needs so much work on existing code > >> (jsf, > >> >security, transactional, data for the one I see) that I think we > shouldnt > >> >add new things while we dont propose something working fine out of the > >> box. > >> > > >> >Wdyt? > >> > > >> >Le 7 févr. 2014 02:31, "John D. Ament" <john.d.am...@gmail.com> a > écrit : > >> > > >> >> Hi all > >> >> > >> >> I've been working a bit on a POC. The idea is to run a light weight > >> >> Java SE application that does some basic bootstrapping and container > >> >> services. The SE app would be configured with a basic socket listener > >> >> using Netty and delegate requests to a REST provider. The idea > behind > >> >> it is that CDI forms the low level core of the "container", where a > >> >> developer can deploy services they build on their own. The > >> >> application is meant to be an API type server (deploy REST APIs) that > >> >> runs using Netty, starts up a CDI container using DeltaSpike > Container > >> >> Control API. The launch module would handle the basic bootstrap of > >> >> the rest provider, instantiating the CDI container using > >> >> ContainerControl, and handle the necessary bootstrap for lookup up > >> >> resources and registering with the provider. This type of module > >> >> would compete with Spring Boot. > >> >> > >> >> Currently what I have leverages Weld 2.1.1 and RestEasy. The > >> >> equivalent should work for CXF. There's no hard dependency on Weld. > >> >> > >> >> I was thinking the module structure would include an api, spi, > >> >> impl-resteasy and impl-cxf. > >> >> > >> >> Some things I'd like to add: > >> >> > >> >> - Automatic bootstrap of JPA (via JPA module) > >> >> - Transaction intercepting (probably need to pull in the Geronimo > lib) > >> >> - Probably also register some providers automatically as well. > >> >> > >> >> Let me know your thoughts. > >> >> > >> >> John > >> >> > >> > > >> > > >> > > > > > > > > -- > > Jean-Louis > -- Jean-Louis
