EJBObject represents a remote ref :)
-marina
Jon wrote:
>
> I guess I'm feeling ignorant: I'm unsure as to the exactly what
> ejbObject represents. Ill try some of the scenarios you listed tonight
> on Glassfish and see if I can get it to work.
>
> -Sent from my HTC Evo
>
> On Oct 10, 2011 6:31 PM, "Marina Vatkina" <marina.vatkina_at_oracle.com
> <mailto:marina.vatkina_at_oracle.com>> wrote:
>
> 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>
> <mailto: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>
> <mailto: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>
> <mailto: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.
>