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@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