On Feb 2, 2007, at 2:35 PM, Jacek Laskowski wrote:
On 2/2/07, David Blevins <[EMAIL PROTECTED]> wrote:
A strange thought occurred to me now that we have undeploy
functionality. We previously had (and still have) the ability to
scrape the system classpath for ejb-jar.xmls or beans that are
annotated. It's not technically the system classpath, more like the
classpath of OpenEJB itself. This could be stuff in the lib dir etc.
So here's the interesting question. Should we allow these things to
be undeployed? We could get rid of everything but the classes
themselves, those would more or less be stuck. It could technically
be possible to reload any ejb-jar.xml data they have if someone
wanted to have them deployed again.
Does 'these things' equals to 'ejb-jar.xml files'? Are you thinking
about a way to override (well, you mentioned about replacement, but
that's the same unless I misunderstood your point) configuration
contained in these files? What specifically have you came across that
had made you think it might've been of help? I can't imagine a
situation where configured beans could be re-configured without their
redeployment which (unless I'm mistaken) is possible now. Am I
following your idea carelessly?
That's a lot of questions :) I'm not sure I understood them all.
Basically what I'm saying is should we allow an ejb app in the system
classpath to be redeployed even though it's classes could never fully
participate in that concept. Everything else but the classes could
be recycled, though, so we may want to allow it (or not disallow it
depending on your frame of reference).
-David
