The spec is actually very specific about it: 21.2.2 Programming
Restrictions in 3.1 Final:
"The enterprise bean must not attempt to pass *this* as an argument or
method result. The enterprise bean must pass the result of
SessionContext.getBusinessObject, SessionContext.getEJBObject,
SessionContext.getEJBLocalObject, EntityContext.getEJBObject, or
EntityContext.getEJBLocalObject instead."
So the reference can be passed around, but the container can't be
involved in deserializing an *instance* in an MDB and consider it to be
a component.
Best,
-marina
Jon wrote:
> That's exactly the problem! The spec doesn't require it, so a lot of
> containers don't support it. I'd like this to become part of the
> specification so it's tested for during the certification process.
>
> I've tested passing a Stateful EJB to an MDB on Glassfish v3.1.1 and
> Websphere v7. Neither container handles the scenario. Not sure about
> JBoss.
>
> On Mon, Oct 10, 2011 at 5:20 AM, Carlo de Wolf <cdewolf_at_redhat.com
> <mailto:cdewolf_at_redhat.com>> wrote:
>
> Hi Jon,
>
> I can't find any constraints in the spec that doesn't allow
> references to be passed around.
> Maybe I missed them. Could you point them out please?
>
> Thanks,
>
> Carlo
>
> On 10/10/2011 04:38 AM, exabrial_at_gmail.com
> <mailto:exabrial_at_gmail.com> wrote:
>
> Hello everyone!
>
> I've created two new feature requests for EJB3.2:
> http://java.net/jira/browse/EJB_SPEC-24
> http://java.net/jira/browse/EJB_SPEC-25
>
> I feel like @Stateful EJBs are a forgotten and hated love
> child of the
> JEE world. I think they have a lot of potential to solve and
> simplify
> our lives. I've created two JIRA issues that would greatly enhance
> their potential usefulness.
>
> First, I'd like to see concurrency on Stateful EJBs. I think
> recycling
> the existing @Lock(READ) and @Lock(WRITE) annotations would be
> a simple
> solution. I feel like I keep writing a lot of synchronization
> code in
> my webapps, and this would allow for a real simple way to store
> concurrent user data without a lot of drama.
>
> The second is I'd like to be able to pass Stateful EJBs around
> like
> POJOs. I think a very neat scenario would be to pass a
> stateful EJB
> like a hot potato between several stateless EJBs. Imagine the
> typical
> shopping cart example. After a user finishes their order, the
> result
> has to go to a "shipping queue."
>
> Wouldn't it be neat to place the Stateful EJB on an MDB queue? The
> container could easily passivate the EJB until the MDB got
> around to
> shipping the order.
>
>
> My main motivation for creating these two requests is to solve
> some
> problems in Domain Driven Design. DDD was created to reduce
> network
> communication from SOA. SOA was created to centralize
> business logic.
> These are normally competing goals, since your implementation
> doesn't
> follow your state.
>
> These two requests would make Stateful EJBs a cornerstone in
> DDD. You
> would have both centralized business logic, but still have the
> ability
> for state to be passed around easily.
>
> Thank you everyone for your consideration, I look forward to
> comment
> and discussion.
>
>
>
>
>
> --
> Jon | exabrial_at_gmail.com <mailto:exabrial_at_gmail.com>
>
> Pessimists, see a jar as half empty. Optimists, in contrast, see it as
> half full.
> Engineers, of course, understand the glass is twice as big as it needs
> to be.