[webbeans-dev] Re: Terminology

[Jim Knutson]

I have to second Mike's comments below.  There are two paths we can go
here.  We can integrate with the platform (accepting its faults and
trying to fix them) or we can buck the trend and try to build a new
platform.  I have been working under the assumption that we wanted to
integrate with the platform.  If that's not the case (and we'd better
get this agreed on ASAP), then I can go work on other things and not
worry about this being part of Java EE.

Sorry to be blunt here, but I suspect Gavin and others are feeling
a time crunch and we really really need to get everyone moving in
the same direction.

Thanks,
Jim Knutson
WebSphere J2EE Architect

Michael Keith <MICHAEL.KEITH at oracle.com> wrote on 12/22/2008 12:05:38 PM:

> Again, allow me to clarify some of the issues by starting a
> discussion that is at the heart
> of this concern. Hopefully this will help people understand more
> about where we are coming from.
>
> One of the biggest concerns around JSR 299 is that it promotes yet
> another component
> model in addition to EJB. This is *highly* undesirable, in fact it
> is a very dangerous
> thing for the platform. A lot of time and effort has been put into
> making EJB a
> competitive component model so that it can stack up to any other
> component model
> out there. If EJB has not reached this state then it is a failing of
> EJB, and means
> that EJB should be fixed and/or modified so that it provides
> whatever kind of component
> that people need or want. It does not warrant adding yet another way
> to develop business
> logic components and then adding the functionality that may already
> be, or should be, in
> the existing component model.
>
> So, with this issue as a backdrop, I think there are two things that
> this spec can do to
> ensure that the platform is not fractured or schitzophrenic in certain
areas:
>
> 1) We have to ensure that this spec makes use of existing component
> models, modifying the
> existing component model when necessary, and adding new features to
> the model when required.
> Note that this correlates exactly with what this spec originally had
> as its mandate -- to
> integrate existing JSF and EJB components.
>
> 2) Ensure that people understand what this spec is, what it is
> offering, and what problems it
> is trying to solve. One thing that has become abundantly clear is
> that when people read the
> term "web beans" they think of it as being a second/third type of
> enterprise bean. This is only
> natural, but can be easily avoided by changing the name to be more
> in line with the value
> that this spec has, and the domain in which it resides.
>
> So, we are really talking about more than just a name change, but a
> name change is certainly
> a good start!
>
> > -----Original Message-----
> > From: Gavin King [mailto:gavin at hibernate.org]
> > Sent: Sunday, December 21, 2008 2:32 AM
> > To: Java Community Process JSR #299 Expert List; WebBeans; Matt Drees;
> > Scott Ferguson; Michael Keith; Jim Knutson
> > Subject: Terminology
> >
> >
> > Oracle have proposed that we remove the term "Web Bean" from the
> > specification. I'm therefore searching for alternative terminology.
> > Please let me know your opinions and suggestions.
> >
> > Here's one possibility:
> >
> > Web Bean -> injectable type
> > simple Web Bean -> injectable Java class
> > enterprise Web Bean -> injectable EJB
> >
> > Or:
> >
> > Web Bean -> contextual type
> > simple Web Bean -> contextual Java class
> > enterprise Web Bean -> contextual EJB
> >
> > Note that "contextual type" already means something in the current
> > spec, but that thing should be easy enough to rename.
> >
> > --
> > Gavin King
> > gavin.king at gmail.com
> > http://in.relation.to/Bloggers/Gavin
> > http://hibernate.org
> > http://seamframework.org
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20090106/d664594f/attachment.html