<html><body>
<p><tt>I have to second Mike's comments below. There are two paths we can go </tt><br>
<tt>here. We can integrate with the platform (accepting its faults and </tt><br>
<tt>trying to fix them) or we can buck the trend and try to build a new </tt><br>
<tt>platform. I have been working under the assumption that we wanted to </tt><br>
<tt>integrate with the platform. If that's not the case (and we'd better</tt><br>
<tt>get this agreed on ASAP), then I can go work on other things and not</tt><br>
<tt>worry about this being part of Java EE.</tt><br>
<br>
<tt>Sorry to be blunt here, but I suspect Gavin and others are feeling</tt><br>
<tt>a time crunch and we really really need to get everyone moving in</tt><br>
<tt>the same direction.</tt><br>
<tt><br>
Thanks,<br>
Jim Knutson<br>
WebSphere J2EE Architect</tt><br>
<br>
<tt>Michael Keith <MICHAEL.KEITH@oracle.com> wrote on 12/22/2008 12:05:38 PM:<br>
<br>
> Again, allow me to clarify some of the issues by starting a <br>
> discussion that is at the heart <br>
> of this concern. Hopefully this will help people understand more <br>
> about where we are coming from.<br>
> <br>
> One of the biggest concerns around JSR 299 is that it promotes yet <br>
> another component <br>
> model in addition to EJB. This is *highly* undesirable, in fact it <br>
> is a very dangerous <br>
> thing for the platform. A lot of time and effort has been put into <br>
> making EJB a <br>
> competitive component model so that it can stack up to any other <br>
> component model <br>
> out there. If EJB has not reached this state then it is a failing of<br>
> EJB, and means<br>
> that EJB should be fixed and/or modified so that it provides <br>
> whatever kind of component<br>
> that people need or want. It does not warrant adding yet another way<br>
> to develop business <br>
> logic components and then adding the functionality that may already <br>
> be, or should be, in <br>
> the existing component model.<br>
> <br>
> So, with this issue as a backdrop, I think there are two things that<br>
> this spec can do to <br>
> ensure that the platform is not fractured or schitzophrenic in certain areas:<br>
> <br>
> 1) We have to ensure that this spec makes use of existing component <br>
> models, modifying the <br>
> existing component model when necessary, and adding new features to <br>
> the model when required.<br>
> Note that this correlates exactly with what this spec originally had<br>
> as its mandate -- to <br>
> integrate existing JSF and EJB components.<br>
> <br>
> 2) Ensure that people understand what this spec is, what it is <br>
> offering, and what problems it<br>
> is trying to solve. One thing that has become abundantly clear is <br>
> that when people read the <br>
> term "web beans" they think of it as being a second/third type of <br>
> enterprise bean. This is only<br>
> natural, but can be easily avoided by changing the name to be more <br>
> in line with the value<br>
> that this spec has, and the domain in which it resides.<br>
> <br>
> So, we are really talking about more than just a name change, but a <br>
> name change is certainly<br>
> a good start!<br>
> <br>
> > -----Original Message-----<br>
> > From: Gavin King [<a href="mailto:gavin@hibernate.org">mailto:gavin@hibernate.org</a>]<br>
> > Sent: Sunday, December 21, 2008 2:32 AM<br>
> > To: Java Community Process JSR #299 Expert List; WebBeans; Matt Drees;<br>
> > Scott Ferguson; Michael Keith; Jim Knutson<br>
> > Subject: Terminology<br>
> > <br>
> > <br>
> > Oracle have proposed that we remove the term "Web Bean" from the<br>
> > specification. I'm therefore searching for alternative terminology.<br>
> > Please let me know your opinions and suggestions.<br>
> > <br>
> > Here's one possibility:<br>
> > <br>
> > Web Bean -> injectable type<br>
> > simple Web Bean -> injectable Java class<br>
> > enterprise Web Bean -> injectable EJB<br>
> > <br>
> > Or:<br>
> > <br>
> > Web Bean -> contextual type<br>
> > simple Web Bean -> contextual Java class<br>
> > enterprise Web Bean -> contextual EJB<br>
> > <br>
> > Note that "contextual type" already means something in the current<br>
> > spec, but that thing should be easy enough to rename.<br>
> > <br>
> > -- <br>
> > Gavin King<br>
> > gavin.king@gmail.com<br>
> > <a href="http://in.relation.to/Bloggers/Gavin">http://in.relation.to/Bloggers/Gavin</a><br>
> > <a href="http://hibernate.org">http://hibernate.org</a><br>
> > <a href="http://seamframework.org">http://seamframework.org</a><br>
> ><br>
</tt></body></html>