June 2009 - jbpm-dev - Jboss List Archives

[Design of JBoss jBPM] - Re: Transaction interceptor changes

by heiko.braun＠jboss.com

https://jira.jboss.org/jira/browse/JBPM-2344 I consider this a blocking issue. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238754#4238754 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238754

15 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Transaction interceptor changes

by camunda

I already tackled that problem, but I saw I just send it to Tom via Mail and forgot the mailing list, sorry... Here the JIRA issue for it: https://jira.jboss.org/jira/browse/JBPM-2339 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238752#4238752 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238752

15 years, 8 months

1
0
0 / 0

[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

15 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Transaction interceptor changes

by heiko.braun＠jboss.com

@Tom: Btw, if you would have kept the integration tests I did provide a while ago, this would have occurred in the nightly QA. So I'd say the current integration tests are insufficient. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238748#4238748 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238748

15 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - Transaction interceptor changes

by heiko.braun＠jboss.com

Most recent TX interceptor changes, break the console and the deployer: | Caused by: org.jbpm.api.JbpmException: invalid transaction state: STATUS_ACTIVE | at org.jbpm.pvm.internal.tx.jta.JtaTransactionInterceptor.execute(JtaTransactionInterceptor.java:60) | at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:54) | at org.jbpm.pvm.internal.repository.RepositoryServiceImpl.createProcessDefinitionQuery(RepositoryServiceImpl.java:77) | at org.jbpm.integration.console.ProcessManagementImpl.getProcessDefinitions(ProcessManagementImpl.java:54) | ... 45 more | | Basically you cannot run within a provided transaction context (like ejb REQUIRED semantics). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238746#4238746 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238746

15 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Undeployment in JBosss Deployer

by heiko.braun＠jboss.com

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. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238744#4238744 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238744

15 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: EJB 2.1 Beans in jbpm 4?

by camunda

I think the problem there is, that some stuff is not pre fetched at the server. This is what we tackled with the Commands as well in jbpm 3 (overwrite and access object graph on the server side). Don't know how that can be tackled easily in jbpm 4 without using commands... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238741#4238741 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238741

15 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Undeployment in JBosss Deployer

by 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. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238736#4238736 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238736

15 years, 8 months

1
0
0 / 0

[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

15 years, 8 months

1
0
0 / 0

[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

15 years, 8 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jbpm-dev June 2009