[Design of JBoss jBPM] - Re: Transaction interceptor changes
by heiko.braun＠jboss.com
For completeness, here's the Deployer error:
| Caused by: org.jbpm.api.JbpmException: couldn't lookup 'java:comp/UserTransaction' from jndi: UserTransaction not bound: UserTransaction not bound
| at org.jbpm.pvm.internal.tx.jta.JtaTransaction.lookupFromJndi(JtaTransaction.java:131)
| at org.jbpm.pvm.internal.tx.jta.JtaTransaction.lookupJeeUserTransaction(JtaTransaction.java:110)
| at org.jbpm.pvm.internal.tx.jta.JtaTransactionInterceptor.execute(JtaTransactionInterceptor.java:46)
| at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:54)
| at org.jbpm.pvm.internal.repository.DeploymentImpl.deploy(DeploymentImpl.java:91)
| at org.jbpm.integration.spi.DeploymentAdaptor.deploy(DeploymentAdaptor.java:62)
|
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238749#4238749
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238749
17 years
[Design of JBoss jBPM] - Re: Undeployment in JBosss Deployer
by kukeltje
anonymous wrote : 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.
anonymous wrote : 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)
anonymous wrote :
| 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.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238735#4238735
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238735
17 years
[Design of JBoss jBPM] - Re: Undeployment in JBosss Deployer
by 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
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238730#4238730
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238730
17 years