B
Bogus Exception
Given EJB3 and J2EE 5, I'm curious to learn what you 'd suggest for a
deployment strategy that would allow continuous adding, modifying, and
removing session, entity and message driven beans in a container.
Assume a generic, compliant container/server.
In other words, if I establish using MDBs as the asynchronous
communication vehicle, how can I modify the any part of the entire
application without causing the entire app to be restarted?
For example, suppose I want to add additional subscribers to a queue,
but without interrupting any current subscribers or the provider. I
think I'm talking about something a bit more than durable
subscriptions can handle, as I don't want to interrupt any
communication in any topics/queues-but more importantly I don't want
to interrupt non-durable elements in the app such as JCA and servlet
components.
After a bunch of research, I think I understand the container's
requirement as needing to restart any app whose jar file has had
anything added, changed or deleted from it. If that is the case, then
I am open to your thoughts as to how to architect through this
limitation/situation.
I'd like to create a situation whereby (regardless of the number of
jar/ear files) I can:
1. programmatically add new beans to the application,
2. programmatically modify existing beans (mostly with XML), and
3. programmatically remove beans from the application,
....while disrupting as little of the application as possible. I don't
have a problem with deploying each individual bean in a separate jar
file, if that is the only way to do it. Java has proven to be a truly
flexible language for me. I'm hoping that it will continue to be such
as I learn more about EJB3 in J2EE 5.
Any thoughts?
TIA!
Bogus Exception
deployment strategy that would allow continuous adding, modifying, and
removing session, entity and message driven beans in a container.
Assume a generic, compliant container/server.
In other words, if I establish using MDBs as the asynchronous
communication vehicle, how can I modify the any part of the entire
application without causing the entire app to be restarted?
For example, suppose I want to add additional subscribers to a queue,
but without interrupting any current subscribers or the provider. I
think I'm talking about something a bit more than durable
subscriptions can handle, as I don't want to interrupt any
communication in any topics/queues-but more importantly I don't want
to interrupt non-durable elements in the app such as JCA and servlet
components.
After a bunch of research, I think I understand the container's
requirement as needing to restart any app whose jar file has had
anything added, changed or deleted from it. If that is the case, then
I am open to your thoughts as to how to architect through this
limitation/situation.
I'd like to create a situation whereby (regardless of the number of
jar/ear files) I can:
1. programmatically add new beans to the application,
2. programmatically modify existing beans (mostly with XML), and
3. programmatically remove beans from the application,
....while disrupting as little of the application as possible. I don't
have a problem with deploying each individual bean in a separate jar
file, if that is the only way to do it. Java has proven to be a truly
flexible language for me. I'm hoping that it will continue to be such
as I learn more about EJB3 in J2EE 5.
Any thoughts?
TIA!
Bogus Exception
