September 2008 - jbpm-dev - Jboss List Archives

[Design of JBoss jBPM] - Re: Multiple 1PC resources in enterprise

by thomas.diesler＠jboss.com

BTW, why is the timer using jboss-4.0 style CMP and not EJB3? If there is no compelling reason, we should migrate simply because folks pick up from what we provide. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175784#4175784 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175784

16 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Multiple 1PC resources in enterprise

by thomas.diesler＠jboss.com

Alejandro, https://jira.jboss.org/jira/browse/JBPM-1708 If I understand you correctly, you associated the DS for the TimerEntityBean with the JbpmDS to share the same DS with the rest of the engine and not have multiple 1PC resources enlisted. | <jbosscmp-jdbc> | <defaults> | <datasource>java:/JbpmDS</datasource> | <create-table>false</create-table> | <remove-table>false</remove-table> | <pk-constraint>false</pk-constraint> | </defaults> | | <enterprise-beans> | <entity> | <ejb-name>TimerEntityBean</ejb-name> | Using the same DS for all DB related stuff seems correct to me. The EjbSchedulerTest however still fails | Running org.jbpm.scheduler.ejbtimer.EjbSchedulerTest | Tests run: 6, Failures: 0, Errors: 6, Skipped: 0, Time elapsed: 9.431 sec <<< FAILURE! | | Caused by: org.jboss.util.NestedSQLException: Transaction is not active: tx=TransactionImple < ac, BasicAction: 7f000001:bb20:48c8d180:55 status: ActionStatus.ABORT_ONLY >; - nested throwable: (javax.resource.ResourceException: Transaction is not active: tx=TransactionImple < ac, BasicAction: 7f000001:bb20:48c8d180:55 status: ActionStatus.ABORT_ONLY >) | at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:94) | at org.hibernate.connection.DatasourceConnectionProvider.getConnection(DatasourceConnectionProvider.java:69) | at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:423) | There seems to be more to it than sharing the DS. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175782#4175782 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175782

16 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - jBPM3 excluded tests

by thomas.diesler＠jboss.com

Folks, FYI here is the current list of jBPM3 tests that need to be excluded |  | <exclude>org/jbpm/jcr/JcrDbTest.java</exclude> |  | <exclude>org/jbpm/job/executor/JobLoadJoinTest.java</exclude> | <exclude>org/jbpm/job/executor/JobLoadSubProcessTest.java</exclude> |  | <exclude>org/jbpm/mail/MailTest.java</exclude> | <exclude>org/jbpm/mail/TaskMailTest.java</exclude> | <exclude>org/jbpm/mail/RealServerMailTestCase.java</exclude> |  | <exclude>org/jbpm/perf/PerfWithoutDbTest.java</exclude> | <exclude>org/jbpm/perf/StateUpdateTest.java</exclude> |  | <exclude>org/jbpm/seam/SeamPageFlowTest.java</exclude> |  | <exclude>org/jbpm/context/exe/ContextInstanceDbTest.java</exclude> | <exclude>org/jbpm/graph/node/StartStateDbTest.java</exclude> | <exclude>org/jbpm/optimisticlocking/LockingTest.java</exclude> | Any help in reducing the excludes is welcome. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175485#4175485 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175485

16 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: sar vs ear packaging

by thomas.diesler＠jboss.com

Done. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175281#4175281 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175281

16 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: sar vs ear packaging

by thomas.diesler＠jboss.com

Alejandro, anonymous wrote : | The enterprise jar exposes the command service remotely, and the jms messaging / ejb scheduler services locally. If test cases were written in terms of commands (the EjbSchedulerTest actually is) then Cactus would not be needed. | | Nevertheless, the web console is not written in terms of commands because it is meant to work either standalone or in tandem with the enterprise jar. Because (a) it relies on the local functionality and (b) it is the only client provided with the distribution, it is not like any other client component. | ok, in that case the ear serves an actual purpose and we should stick to it. I'll take JBPM-1717 and do the ear as you suggested. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175228#4175228 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175228

16 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: sar vs ear packaging

by thomas.diesler＠jboss.com

Bernd, jBPM3 has a defined set of supported target containers. http://jbpm.dyndns.org/jbpmwiki/index.php?title=JBPM3SupportedTargetConta... For this we do QA for others we don't. To state that jBPM will work in arbitrary target containers is an assumption and we cannot base our packaging decisions on that. The support for various target containers is encapsulated in the installer. i.e. we install jbpm with the installer and QA that installation - no manual or hidden steps involved. Basically, if a feature is not automatically tested or not properly documented it is not there. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175227#4175227 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175227

16 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: sar vs ear packaging

by camunda

I think the ear is a very convinient way for all people, starting with jBPM and don't knwo too much about deployment, sars & co. And as Tom mentioned, for everybody not using JBoss (which are quite some projects!) it is even more easy to start... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175222#4175222 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175222

16 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: simulation tests

by camunda

Hi Thomas, I will have a look at it as soon as possible, unfortunately a bit busy at the moment... As far as I remeber, the output was produced in DESMO-J and wasn't really configurable. So it may not be easy to get rid of it. But I am in touch with the university of Hamburg, where DESMO-J is developed, maybe we can improve DESMO-J "logging" somehow... As soon as I have more information on this I will let you know... Cheers Bernd View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175221#4175221 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175221

16 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: sar vs ear packaging

by alex.guizar＠jboss.com

anonymous wrote : Isn't the enterprise jar supposed to expose some functionality remotely? If so, the console would be a client of that functionality like any other component deployed on the container, like in fact a remote test case. If test cases could use the enterprise beans to deploy processes remotely, all that cactus stuff would not be needed, right? The enterprise jar exposes the command service remotely, and the jms messaging / ejb scheduler services locally. If test cases were written in terms of commands (the EjbSchedulerTest actually is) then Cactus would not be needed. Nevertheless, the web console is not written in terms of commands because it is meant to work either standalone or in tandem with the enterprise jar. Because (a) it relies on the local functionality and (b) it is the only client provided with the distribution, it is not like any other client component. anonymous wrote : So what is the actual benefit of using the ear packaging? From my perspective it only adds another level of component packaging. In fact, since the enterprise beans do not form an integral part with the console alone, it would be quite inappropriate to package them together with the console. It removes a duplicate set of environment references between the console and the enterprise jar. The console may not be the only possible client, but it is the only official client for sure. The ear packaging does not affect other clients: they bind their references to the JNDI names used by the jBPM enterprise beans and voila. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175188#4175188 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175188

16 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: sar vs ear packaging

by thomas.diesler＠jboss.com

But why? Isn't the enterprise jar supposed to expose some functionality remotely. If so, the console would be a client of that functionality like, any other component deployed on the container, like in fact a remote test case. If test cases could use the enterprise beans to deploy processes remotely, all that cactus stuff would not be needed, right? So what is the actual benefit of using the ear packaging? From my perspective it only adds another level of component packaging. In fact, since the enterprise beans do not form an integral part with the console alone, it would be quite inappropriate to package them together with the console. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175089#4175089 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175089

16 years, 5 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 September 2008