Sorry, I meant Remote component, i.e. 2.x. So if your bean doesn't
expose it, it doesn't have it.
"this" (#1) users shouldn't use.
As we are discussing getBusinessObject() on another thread, I'll bring
it up there.
thanks,
-marina
Jon wrote:
> I created three simple test scenarios using Glassfish 3.1.1. First, I
> created a stateful bean and tried passing "this" as the payload in an
> ObjectMessage. Next, I passed getBusinessObject. Finally I tried
> passing the result of getObject. My stateful EJB uses a remote
> interface view.
>
> When the MDB fires, the first two scenarios failed saying:
>
> Caused by: org.omg.CORBA.BAD_OPERATION: The delegate has not been
> set! vmcid: 0x0 minor code: 0 completed: No
>
> The final scenario failed saying:
>
> Caused by: java.lang.IllegalStateException: EJBObject not available
>
>
> This could be a bug in GlassFish, but I really see it as an oversight
> in the EJB spec, or I could be completely wrong in my understanding of
> the spec. Please let me know!
>
> Thanks,
> -Jonathan
>
> On Mon, Oct 10, 2011 at 7:14 PM, Marina Vatkina
> <marina.vatkina_at_oracle.com <mailto:marina.vatkina_at_oracle.com>> wrote:
>
> 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>
> <mailto: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>>
> <mailto: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>>
> <mailto: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>>
> <mailto: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.
>
>
>
>
> --
> 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.