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> 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 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
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.