Undeployment in JBosss Deployer

[camunda]

Hi!

I have a small change I discussed with several people already, including two of our bigger customers: Undeployment of processes with the JBoss Deployer.

In the current code base undeploying a process archive (sorry, a "bar" ;-)) means deleting the process definition and all instances from database. This is a bit rude and can cause a lot of trouble, even if it was "just" a user error or whatever. The deleted process instances are gone then.

So I will change the logic from deleting to suspending a process definition when the archive is deleted. Then it must be deleted by an administrator explicitly or you can reactivate it if it was by mistake.

For me it is important that this goes into GA already. Any objections?

Cheers
Bernd

[jbarrez]

Bernd

- Are the code changes related to the deployer only? Tom intends to move the deployer to 'incubation' anyway (ie unsupported for customers) so if there are no code changes I dont see any objections

- I believe the engine already suspends when an undeployment happens, so the JBoss deployer is out of sync there and should have the same logic ...

[heiko.braun]

you can reactivate it if it was by mistake

Why should it be different then any other Java EE deployment? You guys always try to come up with extraordinary requirements for processes. If you delete an EAR there is no backup either. I think people are smart enough to understand the impact.

But in general you should discuss wether or not to keep the deployer at all.
The way it was written, it did intend additional changes to the core runtime. Especially classloader association upon deployment. In order to get the classloader scoping right, we would need to associate the classloader that the deployer framework provides and not write class info to the database. Similiar to what Bernd did to jbpm3.

If we would complete it in that way, the question of deletion versus suspension would become different.

But honestly, that whole deployment discussion has been going on since december last year and I am tired of repeating myself.
I'd say either you complete the deployer or you remove it at all.

[camunda]

Hi Heiko.

Heiko wrote:

Why should it be different then any other Java EE deployment?

Basically I think because it is different to other Java EE deployments. The engine itself is a typical Java EE deployment. But the processes are different, it is a persistent long running entity.
Imagine a webshop, you cannot delete all the orders in the database, just because you undeploy the ear with the webshop.

Why do you think deleting running process instances is a good behaviour when undeplyoing? You definitely loose processes instances!

Anyway, suspending the process definition seems to be a good way in the middle. Currently the other jbpm guys agree, all customers I discussed it with agree as well, so I think it is a good way to go.

Heiko wrote:

The way it was written, it did intend additional changes to the core runtime. Especially classloader association upon deployment. In order to get the classloader scoping right, we would need to associate the classloader that the deployer framework provides and not write class info to the database. Similiar to what Bernd did to jbpm3.

I agree with you. But this is what is currently done, no?
The tricky thing is still how to bind the class loading right, but this is independant of the other questions, or not?

Heiko wrote:

If we would complete it in that way, the question of deletion versus suspension would become different.

I don't get why. In the jbpm 3 deployer (running productive at 1&1) no processes are deleted if you undeploy a process.

Heiko wrote:

I'd say either you complete the deployer or you remove it at all.

Okay, I go for it. In GA it will be incubating, so no problem here. I will change it to suspend the process definition, which cannot harm anything.

And later I will come up with a proposal how the Java EE lifecycle can be mapped to the jbpm process deployment/definition lifecycle better (questions like redeployment, get a suspended process instance back to live, exceptions during undeployment, ...). I already have some ideas in my mind and will discuss that with a customer further on later this month.

So I will take care of the issue. It will just not be there from the beginning but added later on. But I think that is no problem in terms of the GA.

If you think different please let me know...

Cheers
Bernd

[kukeltje]

Why should it be different then any other Java EE deployment? You guys always try to come up with extraordinary requirements for processes. If you delete an EAR there is no backup either.

Correct, but normally you do not loose your date in the database that belongs to the application. I do not think Bernds suggestion is that out of the ordinary.

I think people are smart enough to understand the impact.

Well, I do want to generalize, but the people at ASP/ISP's that do deployments or people within companies themselves can do and will do strange things and often. Even if they have a script (paper that is in some cases)

But in general you should discuss wether or not to keep the deployer at all.
The way it was written, it did intend additional changes to the core runtime. Especially classloader association upon deployment. In order to get the classloader scoping right, we would need to associate the classloader that the deployer framework provides and not write class info to the database. Similiar to what Bernd did to jbpm3.

If we would complete it in that way, the question of deletion versus suspension would become different.

But honestly, that whole deployment discussion has been going on since december last year and I am tired of repeating myself.
I'd say either you complete the deployer or you remove it at all.

The idea was/is not that wrong, it got the discussion about versioning in the right direction. Personally I do like it but I also do not mind if a kind of startup-servlet did this (AS independent) and took everything from e.g. the war but uses the same versioning rules.

[camunda]

Ronald wrote:

The idea was/is not that wrong, it got the discussion about versioning in the right direction. Personally I do like it but I also do not mind if a kind of startup-servlet did this (AS independent) and took everything from e.g. the war but uses the same versioning rules.

I would really prefer the JBoss deployer, since it is a quite natural way, we have angles for classloading and I think it is the best for the SOA platform.

Feedback on the jbpm 3 deployer back my feeling here that it is the right way to go.

[heiko.braun]

I would expect a process deployment artifact to contain all the classes and resources a process requires for execution. So, if you rely on the classloader you receive from the AS deployer framework and the the deployment artifact get's removed, then you basically leave the process in an unusable state. Hence it can be deleted right away, IMO.

But of course, if you keep writing class information to the database and deal with classloading and scoping on your own then you don't have this problem in the beginning. But I don't believe you easily leverage advanced AS features if you keep providing custom solutions for things that the AS already provides.

[camunda]

Heiko.

would expect a process deployment artifact to contain all the classes and resources a process requires for execution. So, if you rely on the classloader you receive from the AS deployer framework and the the deployment artifact get's removed, then you basically leave the process in an unusable state.

Right, this is why it is suspended. So it cannot be signaled any more.

Hence it can be deleted right away, IMO.

Not right, because we just don't want to delete the unfinished process instances.

But of course, if you keep writing class information to the database and deal with classloading and scoping on your own then you don't have this problem in the beginning. But I don't believe you easily leverage advanced AS features if you keep providing custom solutions for things that the AS already provides.

This has nothing todo with it. I agree, classes should go in the ear or whatever. See answer above.