On Jun 20, 2010, at 2:12 AM, Mark Struberg wrote: > Hoi David! > > To add another point to the discussion: > I recently realized that one of the strong parts of EJB is it's well defined > behaviour as 'shared backend' for multiple WARs in an EAR scenario. This > classloader scenario is completely left out of the CDI spec, so it's not even > defined if @ApplicationScoped in an EAR situation means 1 instance for the > whole EAR bundle or 1 instance per WAR.
If the component was defined outside a war, then i'd definitely assume 1 instance shared by all. I guess that'd be the behavior I'd want as a user anyway, since I could get the other one by simply moving the bean definition into the war. > I'm not in favour though of having hardcoded connections between OpenEJB and > OWB in the core. Both should be able to communicate with each other via kind > of open integration APIs. That's what the sandbox is for. We're basically going to tightly integrate. How, no idea just yet. But with the aggressive goal we have of merging EJB into CDI and CDI into EJB, doesn't really make sense on our end to try and keep a distance. -David > > LieGrue, > strub > > --- On Sun, 6/20/10, David Blevins <[email protected]> wrote: > >> From: David Blevins <[email protected]> >> Subject: Re: graduation >> To: [email protected] >> Date: Sunday, June 20, 2010, 12:03 AM >> >> On Nov 11, 2009, at 10:02 AM, David Blevins wrote: >> >>> I wonder what the group would think about potentially >> graduating into OpenEJB. Perhaps as a subproject for >> this spec cycle, but with the longer term goal of becoming >> part of the same codebase. >>> >>> Vision-wise, I'd like to offer @TransactionManagement, >> @ConcurrencyManagement, @Asynchronous, @Schedule, and >> various other "EJB" feature sets to "WebBeans". As >> well I'd like to offer Decorators and more to "EJB". I >> admit that I see a large number of JDCI features as next >> generation EJB and next generation DI. The only >> difference between javax.ejb and javax.enterprise is that >> "javabean" was removed :) I'd really like to offer the >> industry some consistency and unity where the JCP has failed >> to provide it. >> >> On, Sat Jun 19 16:53:58 PDT 2010 >> irc.freenode.net/#openwebbeans >> [14:59] <gerdogdu> thinking to add EJB features >> for managed beans >> [14:59] <gerdogdu> like Resin guys doing >> >> Door is still open on the OpenEJB side if that is a >> goal. We're executing on the vision I mentioned above >> right now in OpenEJB. I mentioned this in the >> graduation thread, but at that time there was significant >> interested in staying free from EJB. >> >> Feel free to jump in on this thread: >> >> http://openejb.979440.n4.nabble.com/JCDI-sandbox-td2250998.html#a2250998 >> >> Got a sandbox there we can play in too. >> >> >> -David >> >>> >>> In terms of graduation, it really depends on where >> everyone's head is at in terms of implementation/project >> independence over the long haul. Very interested in >> thoughts there. >>> >>> >>> -David >>> >>> On Nov 11, 2009, at 9:00 AM, Kevan Miller wrote: >>> >>>> It's been a while since the community has >> discussed graduation. What are your current thoughts? >>>> >>>> I've mentored about all that I can mentor... ; -) >>>> >>>> From the last time I kicked off the discussion: >>>> >>>> On Sep 8, 2009, at 11:00 AM, Kevan Miller wrote: >>>> >>>>> IMO, this community displays nearly all of the >> characteristics that I would look for from a successful >> Incubator project: you've successfully created several >> releases while operating in a clear, open, and welcoming >> manner. All of this while facing some significant challenges >> as the JSR 299 spec has been an ever shifting target. >>>>> >>>>> I'd like to see us moving towards graduation. >> To start things off, is the community interested in becoming >> a top-level project? Or would you rather graduate as a >> sub-project of an existing TLP? >>>> >>>> I think we're ready. Graduation is going to take a >> concerted effort by the community. I'm certainly willing to >> help, but the community is going to need to help drive >> this. >>>> >>>> --kevan >>>> >>> >>> >> >> > > > >
