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 deploy
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 se
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
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 the
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 processe
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
were
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.
>
>
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
Sent: Friday, August 30, 2002 1:57 PM
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, beca
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 th
> 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
he is only talking about not deploying one component, not the rest of
the system.
> warning log message is
tt Stark
> Chief Technology Officer
> JBoss Group, LLC
>
> - Original Message -
> From: "Dain Sundstrom" <[EMAIL PROTECTED]>
> To: "JBoss-dev" <[EMAIL PROTECTED]>
> Sent: Friday, August 30, 2002 1:32 PM
> Subj
MAIL PROTECTED]>
Sent: Friday, August 30, 2002 1:32 PM
Subject: [JBoss-dev] DeploymentException does NOT stop deployment
> My startup code throws DeploymentExceptions if an error is detected in
> the configuration, and this used to cause deployment t
f Dain Sundstrom
> Sent: Friday, August 30, 2002 4:33 PM
> To: JBoss-dev
> Subject: [JBoss-dev] DeploymentException does NOT stop deployment
>
>
> My startup code throws DeploymentExceptions if an error is
> detected in
> the configuration, and this u
My startup code throws DeploymentExceptions if an error is detected in
the configuration, and this used to cause deployment to stop. I doesn't
anymore.
In org.jboss.system.ServiceController.start(ObjectName) we have the
following code on line 366 (HEAD):
// Call start on the service Proxy
tr
15 matches
Mail list logo
