On Jun 12, 2010, at 2:28 PM, Jacek Laskowski wrote: > On Fri, Jun 11, 2010 at 7:51 PM, David Blevins <[email protected]> wrote: >> >>> On Thu, Jun 10, 2010 at 10:44 PM, David Blevins <[email protected]> >>> wrote: >>> >>>> I'd like to experiment with integrating JCDI much deeper into the core >>>> code. > ... >> Reza (Resin guy) and I have chatted about this and share a similar vision >> for both the two specs and how to implement them. Who is atop who is almost >> irrelevant in the sense that the two models are essentially the same. Both >> are proxy based component models with several container features >> (interceptors, decorators, etc) interjected on method calls with some >> transactional awareness and dependency. >> > > Am I right that you're interested in pursuing better > OpenEJB-Tomcat-OWB integration? Is that what you meant having said > "playing with JCDI" and "deeper into the core code" or are you > following Resin/Reza's idea to lay one on the other, be it EJB3.1 atop > CDI or vice versa?
Both. Though I would never describe it as following Resin/Reza. We chatted about it quite a bit before he ever joined up with Resin. I also wouldn't describe it as one on top of the other. What I imagine is a straight merge of the technologies. A flattened set of rules that are the same regardless of what kind of bean you have. A much larger vision is that I'd really love to take EJB and break it up into tiny little pieces. It's difficult to describe without writing a big manifesto. I in fact have one that I started in July last year but never finished an never published. I went ahead and published it anyway: http://blog.dblevins.com/2010/06/if-software-is-pizza-ejb-is-house.html I don't think it adequately expresses the conecept, but it's a start. > >> The biggest difference between them is Sun owns EJB and Redhat owns JCDI. > > Does it really matter? I've never been involved in such a thinking who > owns what, and as a matter of fact I don't like the the proliferation > of managed bean-centered specs like JSR-299 (CDI), JSR-330 (DI) and > there was something else I don't remember now. When I first touched > the specs I could get my head around them and was wondering why there > are so many of them. What's your take on it? (asking as you're closer > to the sources :)) The one you can't remember is the Java EE 6 ManagedBean spec. Using the metaphor from my blog it was just a continuous process of people saying "I want a pizza, but I don't like all the stuff yours has on it, so I'm going to make a new kind of pizza, like yours, but without the stuff I don't like and I might even add a new topping or two." They were all essentially created in this order: 1. EJB 2. JCDI 3. @Inject 4. Java EE 6 @ManagedBean Essentially the habit we are in at the spec level is continuously subsetting each others specs because there's something in it we don't want and would rather just focus on a few specific parts. Those parts do get improved, but the old version is still there causing confusion and tied with many other good features. Java EE 6 @ManagedBean is not even really a spec yet, but rather the promise of a spec. @Inject is straight dependency injection with scopes and context. JCDI is that plus some enterprise features. EJB is that plus some more enterprise features and a lot of legacy features. The end result is that users have to sort all this out on their own and we all suffer for it. If you start with a lower level spec and one day discover you need something from the next layer up, it usually involves migration and incredible pain. So here we are an EJB container. We're required to support all of these specs. Do we do it in a way where users are forced to deal with the dividing lines created by the spec groups, or do we just flatten it out and free them from having to decide. A bean is a bean is bean. It doesn't really matter what it's lifecycle is. If you want to use @Asynchronous on it, you should be allowed to do that. If you want to put @Decorators on it, you should be allowed to do that too. It's the annotations that provide the services that are the interesting part. You should be able to start with a plain bean and just add the annotations you want without having to worry about what spec they come from. -David
