David Jencks wrote:
As soon as you get the first error, the deployment should stop and
unroll. Correct?
I don't think so. This tends to produce behavior like stopping the server
when your ejb doesn't deploy on server startup.
Yes. I don't want a half deployed application. It either
On 2002.09.01 19:06:31 -0400 Dain Sundstrom wrote:
David Jencks wrote:
As soon as you get the first error, the deployment should stop and
unroll. Correct?
I don't think so. This tends to produce behavior like stopping the
server
when your ejb doesn't deploy on server startup.
David Jencks wrote:
As soon as you get the first error, the deployment should stop and
unroll. Correct?
I don't think so. This tends to produce behavior like stopping the
server
when your ejb doesn't deploy on server startup.
Yes. I don't want a half deployed application. It either
David Jencks wrote:
4. The ejb deployment system appears to parse the entire jbosscmp-jdbc.xml
file for each ejb, and match up the listed fields with those declared in
ejb-jar.xml for the entire file each time. Therefore, if there is an error
in one ejb config, all ejb's can't be processed.
On 2002.08.31 12:30:06 -0400 Dain Sundstrom wrote:
David Jencks wrote:
4. The ejb deployment system appears to parse the entire
jbosscmp-jdbc.xml
file for each ejb, and match up the listed fields with those declared
in
ejb-jar.xml for the entire file each time. Therefore, if there is an
I don't know where the new trace puke comes in where we know all about
the deployment, but it really contains no useful information in most
cases (like the one you describe below) and is really scary in its
format. Let the verifier do the job and let's get rid of this waiting
on stuff in the
That was a conscious decision. If we are going to get to 24x7
available kernels it means never restarting the server. Bad apps
should be fixable without taking down the server. The warning
log message is necessary if an admin is to be informed that
a deployment has failed. Otherwise your letting
Yes I agree about 24x7, but the application (ejb-jar) still deploys.
This is a test case and I can execute test the just fail. It total
breaks the server, because my code (and others) assume that if a
DeploymenException is thrown it rolls back the deployment.
Anyway this code catches
marc fleury wrote:
yes, but not in its current form. Have you seen the logoreah of stuff
that gets printed to the screen? We were there once with like 10 stack
traces for every error, we went back down to almost a presentable
If the deployment of a package (ear/jar/war/sar) stopped when the
Subject: Re: [JBoss-dev] DeploymentException does NOT stop deployment
Yes I agree about 24x7, but the application (ejb-jar) still deploys.
This is a test case and I can execute test the just fail. It total
breaks the server, because my code (and others) assume that if a
DeploymenException
I'll take a look at this tonight.
Repetitive logging should be possible to eliminate.
I'm not at all convinced that stopping deployment of anything except the
mbean that won't finish is desirable, practical, or possible. Even that
mbean I'm not so sure of.
If you are deploying many components
David Jencks wrote:
I'll take a look at this tonight.
Repetitive logging should be possible to eliminate.
I'm not at all convinced that stopping deployment of anything except the
mbean that won't finish is desirable, practical, or possible. Even that
mbean I'm not so sure of.
If you
OK, there were several problems here, thanks for pointing out the
situation.
1. I installed some bugs in ServiceController when I made a state machine
for mbean state. It wasn't possible to get into NOTINITIALIZABLE or
NOTSTARTABLE states, so mbeans could get stuck in RUNNING even when they
13 matches
Mail list logo
