MDB are stateless so having behavioral config per instance doesn't really make sense -- there's no way of knowing which instance handles which message as the container picks them from a pool as needed
Thanks for the reply.
Mmm, I hadn't really considered the impact of the fact that the container can create multiple instances of a particilar MDB - but that in itself doesn't negate what I'm trying to achieve - let me explain a little more about what I'm trying to achieve.
I'd like to write a little MDB 'component' that will handle reliable forwarding of messages from one JMS server to another - i.e. mainly responsible for dealing with remote communication failures. I'd like to write this component once and then be able to use it (i.e. instantiate different Beans from it with different remote queue parameters) several times. So the fact that the container could instantiate several instances of the same bean with the same configuration parameters is okay, so long as I can still create several different MDB's from the same code.
Assuming there's no problem in doing this, I think my question is still valid no?
in that case deploy the same MDB more than once with different env-entries in your deployment descriptor
Thanks - that's the mechanism that uses the importXml call-back to pickup the parameter right?
the env entry will be imported to your bean's local namespace which you can then lookup and act upon