Disregard this mail. I was drafting it up and pressed send by mistake.
The HandleDelegate only comes into play on getEJBObject.
Carlo
On 10/11/2011 11:57 AM, Carlo de Wolf wrote:
> 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.
>