+1
On Fri, Sep 21, 2012 at 9:08 AM, Markus Eisele <myfear_at_web.de> wrote:
> Hi all,
>
> that somehow slipped through my unread-filter. Sorry. I need to find a
> better way of tracking the "open" issues.
> Any ideas to make this easier appreciated.
>
> Anyway. Reading this over and thinking about this since some time now
> I believe I prefer Pete's idea. (referred to as D)
> We do have technologies which have a reach outside Java EE. There has
> to be a chance for them to
> decide if this is going to be a hard dependency or if they try to
> duplicate stuff on their own.
>
> The recent projects I have seen always facilitate CDI and it turns out
> that _not_ having it enabled by default is error-prone. This is the
> number one feature everybody knows about and is willing to use!
>
> Bottom line: CDI should be mandatory for all JSRs contained the
> umbrella. But they are free to provide alternative
> implementations running standalone. I would love to think about
> another requirement which could prevent unintended usage of the
> standalone-alternatives.
> What about defining kind of a container indicator which could be used for
> that?
>
> - M
>
> On 21 September 2012 08:56, Bill Shannon <bill.shannon_at_oracle.com> wrote:
> > I've heard from a few of you on this, but I'd like to get feedback
> > from the rest of the expert group. There's 20 people on this
> > expert group, surely you all joined the expert group because you had
> > opinions about Java EE, right? You wanted to help us direct the
> > future of Java EE. You wanted to give us the benefit of your experience.
> > If you just wanted to watch, you could've joined the users list instead
> > of the expert group...
> >
> > Let's hear it! What do you guys think?!?
> >
> > (If you already responded to this thread, please resist the temptation
> > to jump in again. Let's let the others have their say.)
> >
> > Thanks.
> >
> >
> > Bill Shannon wrote on 08/30/2012 01:58 PM:
> >> From many of our recent discussions, it seems clear that CDI is
> >> becoming more central to the Java EE programming model. For example:
> >>
> >> - The expanded use of @Stereotype in my previous message.
> >>
> >> - The use of CDI interceptors to provide container managed
> >> transaction support beyond EJB.
> >>
> >> - The potential future use of CDI interceptors to provide container
> >> managed security support beyond EJB.
> >>
> >> - The use of CDI interceptors to support Bean Validation method
> >> level validation.
> >>
> >> - The discussion of "implicit producers" to allow use of @Inject
> >> instead of @Resource to inject Java EE resources.
> >>
> >> - The discussion around alignment of CDI managed beans and the
> >> separate @ManagedBean spec.
> >>
> >> - The introduction of a transaction scope and its use in the JMS
> >> spec to simplify the programming model.
> >>
> >> - The change being considered by the CDI expert group to enable
> >> CDI by default, making it more attractive to use it for all
> >> the items above.
> >>
> >>
> >> At the same time we're finding that some specs, e.g., JAX-RS, are
> >> hesitant to introduce a hard, or even soft, dependency on CDI,
> >> instead insisting that all their new features must work in an
> >> environment where there is no CDI.
> >>
> >> In many ways this parallels what we saw with annotations. In
> >> the beginning we found many people who didn't want to use annotations
> >> and wanted us to make sure everything worked without use of
> >> annotations. Now we're seeing many things that *only* work with
> >> annotations, and annotations are well accepted by Java EE developers.
> >> I suppose there's a natural lifecycle to acceptance of new
> >> technologies, and I wonder where we are in that lifecycle with CDI?
> >> Has CDI become a mature and accepted technology that we should use
> >> widely?
> >>
> >>
> >> I'd like to get a sense from this group as to what direction we
> >> should provide to all the Java EE specs in regards to their use
> >> of CDI. Here's a few obvious options:
> >>
> >> A. Technologies that see a significant standalone (non-Java EE) use
> >> should be fully functional without CDI. If necessary, any
> >> required features that are similar to CDI features should be
> >> defined and implemented in a way that doesn't depend on CDI.
> >>
> >> B. Technologies should provide all major features in a way that
> >> works without CDI. Some features may also be provided in a
> >> different way that works well with CDI. Some less essential
> >> features may only work with CDI. The implementation should
> >> only have a soft dependency on CDI at most.
> >>
> >> C. Technologies should provide features that work well with CDI
> >> without duplicating any functionality in CDI. Use CDI wherever
> >> it fits. The implementation may have a hard dependency on CDI
> >> and may require CDI even when used in a standalone environment.
> >>
> >> I'm sure you can think of other options as well.
> >>
> >> What advice do you think we should give to other Java EE specs?
> >>
> >
>
--
Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead
Twitter @wernerkeil | #Java_Social | #EclipseUOMo | #OpenDDR
Skype werner.keil | Google+ gplus.to/wernerkeil
* Chip-to-Cloud Security Forum: September 19 2012, Nice, French Riviera.
Werner Keil, JCP Executive Committee, JSR-321 EG Member will present
"Trusted Computing API for Java™"
* Eclipse Day Delft: September 27 2012, Delft, Netherlands. Werner Keil,
Eclipse Committer, UOMo Lead, Mærsk Build Manager will present "Triple-E
class Continuous Delivery with Hudson, Maven and Mylyn"
* JavaOne: September 30-October 4 2012, San Francisco, USA. Werner Keil, JCP
Executive Committee Member will present "Standards for the Future of Java
Embedded", "Eclipse UOMo, STEM, and JSRs e.g. 331 or JCP.next"
* JMaghreb: November 2-3 2012, Rabat, Morocco. Werner Keil, JCP EC Member
and Agorava Committer, will present "Java Social JSR, it's alive"
* DevoXX: November 13 2012, Antwerp, Belgium. Werner Keil, JCP EC Member
and Agorava Committer, will present "Java Social JSR, it's alive"