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>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 <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-24>
>> http://java.net/jira/browse/**EJB_SPEC-25<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.
>>
>>
--
Jon | 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.