-
1. Re: when is ejbLoad method called?
chrisxsb Oct 22, 2003 9:59 AM (in response to chrisxsb)Here's a little more information: not only is ejbLoad not called, the MDB is not instantiated until a message matching the message selector arrives on the queue.
Does anyone know if it's correct for MDBs not to be instantiated until a message matching the message selector arrives on the message queue?
More importantly (for my purposes), does anyone know how to force instantiation of MDBs when JBoss starts up?
Thanks.
--Chris -
2. Re: when is ejbLoad method called?
raja05 Oct 22, 2003 10:58 AM (in response to chrisxsb)AFAIK there is no ejbload contract for a MDB as per the EJBSpec. Look at the Spec Section 15.5 and all it has is a ejbcreate and remove and onmessage to process the message.
The MDBs get instantiated at startup and the number of instances for a MDB are based upon the configuration on ur standardjboss.xml. The default is a maximumsize of 100.
Your MDB should be automatically picking up messages as they arrive based on the message selector. Is this what you see?
-Raj -
3. Re: when is ejbLoad method called?
chrisxsb Oct 31, 2003 1:39 PM (in response to chrisxsb)I'm not sure what this "Watch" thing is supposed to do, but I wasn't emailed when a reply arrived.
Anyway... ejbLoad is eventually called, but only when the first message that matches the message selector arrives.
As messages that match the selector arrive, my MDB is picking them up -- that's not a problem.
The problem is that I'd like the MDBs to register themselves through a session bean interface, so that later some other component knows what kinds of messages will be picked up (based on the message selector).
Does that make sense?
Thanks. -
4. Re: when is ejbLoad method called?
adrian.brock Oct 31, 2003 5:21 PM (in response to chrisxsb)mdb instances are stateless, the pool is lazily constructed
(i.e. the first instance isn't instantiated until the first message
arrives)
what you want to do is at the container level (the container
implementation is outside the spec)
you have two options:
1) Use a spec compliant mechanism like binding
<env-entry>s into the ENC of whatever is sending the message
2) Something more dynamic (not portable because it outside
the spec) - e.g. modify JBoss's MDB container to perform
some extra work at deployment.
Only the container knows what the selector, this is
transparent to the mdb.
Before you ask me how to implement it, you should seriously
consider what you are trying to achieve and whether
portability is important to you.
Regards,
Adrian