Hi,
What about that issue?
It looks like an important change to me.
Is EJB 3.2 the good opportunity to introduce such a change?
I guess other specs are also affected.
Jean-Louis
2011/10/11 dblevins (JIRA) <jira-no-reply_at_java.net>
> "Managed" Session Bean type
> ---------------------------
>
> Key: EJB_SPEC-26
> URL: http://java.net/jira/browse/EJB_SPEC-26
> Project: ejb-spec
> Issue Type: New Feature
> Reporter: dblevins
> Fix For: 3.2
>
>
> I think it's going to become clear to us over the coming weeks/months how
> overloaded one of our most important lifecycles is, the Stateful session
> bean.
>
> The root idea discussed with Ken last time around was to make ManagedBean
> our plain-cheese-pizza bean. I.e. a bean type where no particular services
> were enabled by default and all were possible. Certainly this means
> splitting the services out as we already plan to do. Making them available
> "outside" EJB is great as well.
>
> That said, there's certainly something to be said about splitting the
> services up and making them available "inside" EJB as well. Simply making
> it possible to declare @ManagedBeans (or something similar) as a session
> bean would be a great start. I think we'll only get so far if we're solely
> thinking on how our services could be used externally.
>
> Perhaps we start by splitting things up and figuring out how they apply to
> a "Managed SessionBean" and then where it fits we apply them to
> @ManagedBean in general. I think it would give us a critical buffer that
> we currently lack. When "ManagedBean" is truly a pojo under our control,
> many services are far easier to split out. When "ManagedBean" is a
> Servlet, that's a far different proposition.
>
> So rather than let that slow us down, we could first do our work on
> "<session-type>managed</session-type>" beans which would simply have all
> pojo defaults and no "enterprise" defaults. We get the concept of services
> working "idividually" on this bean type. Once we get things carved out, we
> see what we can do about exporting the ones that can apply to any
> @ManagedBean.
>
> Split first, then export where needed.
>
> Some things that we split may not make sense to export to @ManagedBean in
> general. That being said, other specs may decide that some of the things
> we split and do not export to @ManagedBean still do apply to their models
> and could be free to add such requirements in their individual
> specifications. A concrete example is servlets might not choose to adopt
> our split out @Asynchronous concept, but CDI might.
>
> If we make split services usable inside EJB, using them outside EJB will
> be a whole lot easier.
>
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://java.net/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>