Even Handle does not work in all scenarios as the HandleDelegate might
not be available.
For example the JMS layer might want to store the ObjectMessage. It
would be outside of any java:comp scope.
(java:comp/HandleDelegate)
Carlo
On 10/11/2011 05:56 AM, David Blevins wrote:
> I see. The passing semantics I referred to in my previous email are in regards to client/server passing over a remote EJB interface. Many things in this scenario are easy, such as it's the server doing the serialization on both ends and it knows how to deserialize its own references. Typical vendor plumbing involves subclasses of ObjectInputStream and thread state setup before deserialization.
>
> Storing a bean reference in a JMS message is the same concept as storing to disk and pulling it out from anywhere. The JMS layer is pluggable and not controlled by the platform strictly speaking. This kind of thing is what "handles" were used for in EJB 1.x and something we didn't add to business interfaces in EJB 3.x
>
> We could potentially add something like this. We'd just need a clean API.
>
>
> -David
>
> On Oct 10, 2011, at 7:25 PM, 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> 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>> 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.
>>
>>
>>
>>
>> --
>> 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.