[jBPM] New message: "Re: Upgrade from JBPM3 to JBPM4 woes"
by nick bauman
User development,
A new message was posted in the thread "Upgrade from JBPM3 to JBPM4 woes":
http://community.jboss.org/message/524867#524867
Author : nick bauman
Profile : http://community.jboss.org/people/nick.bauman
Message:
--------------------------------------------------------------
Ronald,
> What does make me wonder though is how you asses the risk of something different but existint (jbpm 3 vs 4) in relation to something none existing
I might have not made this clear, but we're going to stay on JBPM3 for now. If we revisit upgrading we won't limit our options to JBPM4
> And migrating from jBPM3 to another BPM solution almost certainly as difficult as migrating to jBPM4
Totally agree,
> So I am truly honestly, openly interested in the ++/+/0/-/-- lists/ Balanced scrore card/SWOT-analysis leading to this without wanting to lure you back :-)
Okay, that's a fair request.
What we were looking for moving to JBPM4:
1.Better handling of subprocesses / superstates. Right now with JBPM3 we can only have subprocesses behave in a “fire and forget” fashion because any other type of subprocess assumes access to a persistent store, which we do not want. No wait state / prompt can occur in a subprocess. We were hoping this restriction would be lifted in JBPM4.
2.Better Spring integration. JBPM3 has limited Spring integration.
3.Keeping up with the rest of the JBPM world. Staying up to date on 3rd party systems means we get the benefits of increasing stability and openness to innovation over time.
What we found:
The Good
1.The interfaces are based on a service facade and the process definitions are pieced together of Composites, making the FSM better modeled. In theory it also means that handling sub processes might be simpler.
2.A process definition conversion tool exists. It's considered experimental bu it's purported to convert JBPM3 to JBPM4 process definition XML files.
3.Actions can be scripted with dynamic languages instead of Java.
4.Many different idioms for the FSM have been added, such as Swimlanes and Tasks.
The Bad
1.No binary compatibility exists between JBPM3 and 4. Not even the process definitions are compatible because JBPM4 is a complete rewrite.
2.The process definition conversion tool doesn't work. When running the conversion tool over one of our process definition it appears to assume that if any GraphElement exists that does not have an action element, it's invalid when clearly this is a perfectly valid GraphElement.
It throws an exception: invalid process xml: Could not convert a node without action element. It also assumes that any action handlers or exception handlers are on your classpath before it converts them.
3.Significant additions to our current target platform would be required. These additions imply a potential ripple effect on other subsystems and integration with our SCADA control system.
4.Spring integration seems still a back art. It may even require Hibernate integration: something we need to avoid. We have not been able to find good examples of how the Spring integration works in v4.
5.The design of JBPM4 is oriented toward a service facade which makes it less clear how we control process definitions. JBPM3 is a simple Finite State Machine with some decent GUI designers.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/524867#524867
16 years, 5 months
[jBPM] New message: "Re: Exception handling in JBPM4"
by Ronald van Kuijk
User development,
A new message was posted in the thread "Exception handling in JBPM4":
http://community.jboss.org/message/524865#524865
Author : Ronald van Kuijk
Profile : http://community.jboss.org/people/kukeltje
Message:
--------------------------------------------------------------
Sorry for the late response, totally forgot about this thread and it is not personal :-) and forget about the 'rude' thing, no sweat. Lets be constructive.
Your request about how to do 'this' is what is unclear to me. There is an example of calling a java class in the examples folder in the distribution. You can do whatever you want in that class. You can e.g. pass a variable in that as a value has the FQCN and via reflection call a method (you can also pass that as a variable).
If you go the custom node way (maybe even in the form of a kind of java activity of which you can use the source code as an basis) there also is one in the examples folder.
So please have a look at those first, be a little creative and get back with more detailed requests. We're more then willing to help out then.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/524865#524865
16 years, 5 months
[JBoss Microcontainer Development] New message: "Re: Pluggable dependency resolver"
by Kabir Khan
User development,
A new message was posted in the thread "Pluggable dependency resolver":
http://community.jboss.org/message/524862#524862
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
I mean this:
*public* *void* testPlainLifecycleDependencyWrongOrder() *throws* Throwable
{
plainLifecycleDependencyWrongOrder();
ControllerContext context2 = assertInstall(1, "Name2", ControllerState.+CONFIGURED+);
ControllerContext context1 = assertInstall(0, "Name1");
+assertEquals+(ControllerState.+INSTALLED+, context2.getState());
SimpleBeanWithLifecycle bean1 = (SimpleBeanWithLifecycle) context1.getTarget();
+assertNotNull+(bean1);
SimpleBeanWithLifecycle bean2 = (SimpleBeanWithLifecycle) context2.getTarget();
+assertNotNull+(bean2);
+assertEquals+(1, bean1.createOrder);
+assertEquals+(2, bean2.createOrder);
+assertEquals+(3, bean1.startOrder);
+assertEquals+(4, bean2.startOrder);
}
The new resolver works with
+assertEquals+(1, bean1.createOrder);
+assertEquals+(2, bean1.startOrder);
+assertEquals+(3, bean2.createOrder);
+assertEquals+(4, bean2.startOrder);
The actual hardcoded orders of beans 1 and 2 is an implemetation detail as I see it. The real check is making sure that the initial install of context 2 does not go beyond CONFIGURED and:
bean1.startOrder > bean1.createOrder
bean2.startOrder > bean2.createOrder
bean2.createOrder > bean1.createOrder
bean2.startOrder > bean1.startOrder
I've got an infinite loop in the indexing resolver when I start up AS which I need to fix before I can get any measurements of boot time, although it sounds like we won't gain much from this.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/524862#524862
16 years, 5 months
[jBPM] New message: "Re: Upgrade from JBPM3 to JBPM4 woes"
by Ronald van Kuijk
User development,
A new message was posted in the thread "Upgrade from JBPM3 to JBPM4 woes":
http://community.jboss.org/message/524861#524861
Author : Ronald van Kuijk
Profile : http://community.jboss.org/people/kukeltje
Message:
--------------------------------------------------------------
> nick.bauman wrote:
>
> *At this time we have decided to back off the migration*, deeming it too much risk...<snip>...But in the final analysis, because v4 is different enough from v3, we are now opening up the playing field at looking at other BPM workflow solutions in Java, including rolling our own.
You are always free to make this choice. What does make me wonder though is how you asses the risk of something different but existint (jbpm 3 vs 4) in relation to something none existing. I've seen in my previous job that often the choice was made to role something ourselves (themselves I should say since I never supported it). Some time later it almost always backfired in multiple ways. And migrating from jBPM3 to another BPM solution almost certainly as difficult as migrating to jBPM4.
>
> This note isn't to be taken as a knock against JBPM4. This is more about the confluence of timing, opportunity, reward and risk in our own world.
I understand I think... Well I understand it is not a knock against jBPM4, but in line with my previous remark, I do not understand. Why not 'just' continue with jBPM 3, maybe even extend it? A Basic FSM is indeed not difficult to develop, but adding all kinds of things around it, makes it more and more complex (have experience in this area with a workflow and forms solution)
So I am truly honestly, openly interested in the ++/+/0/-/-- lists/ Balanced scrore card/SWOT-analysis leading to this without wanting to lure you back :-)
Cheers,
Ronald
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/524861#524861
16 years, 5 months
[jBPM] New message: "Re: Upgrade from JBPM3 to JBPM4 woes"
by nick bauman
User development,
A new message was posted in the thread "Upgrade from JBPM3 to JBPM4 woes":
http://community.jboss.org/message/524855#524855
Author : nick bauman
Profile : http://community.jboss.org/people/nick.bauman
Message:
--------------------------------------------------------------
Ronald,
This is really good to know, thanks for the pseudocode.
I did see there were timers on transitions in the new JBPM4, but the goal is to get what we have in v3 nominally working and then evolving it toward the featureset / sweetspot of v4.
*At this time we have decided to back off the migration*, deeming it too much risk. The final straw was the conversion tool barfing on our process defintions: they insisted that an activity without an action (we had them linked to the node-enter or exit event) was "invalid" when clearly they aren't. We found the place in the conversion tool where this assumption is made, so in theory it wouldn't be too bad a fix. But in the final analysis, because v4 is different enough from v3, we are now opening up the playing field at looking at other BPM workflow solutions in Java, including rolling our own.
This note isn't to be taken as a knock against JBPM4. This is more about the confluence of timing, opportunity, reward and risk in our own world.
Thanks again,
Nick
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/524855#524855
16 years, 5 months
[jBPM] New message: "jBPM[4.3] Task definition error using BPMN"
by Jas Lam
User development,
A new message was posted in the thread "jBPM[4.3] Task definition error using BPMN":
http://community.jboss.org/message/524849#524849
Author : Jas Lam
Profile : http://community.jboss.org/people/lamj1
Message:
--------------------------------------------------------------
the four files i used are attached.
When i tried to deploy, jboss gave me the following error
12:00:13,395 ERROR [[Resteasy]] Servlet.service() for servlet Resteasy threw exc
eption
org.jboss.resteasy.spi.UnhandledException: org.jbpm.api.JbpmException:
xml validation error: cvc-complex-type.3.2.2: Attribute 'continue' is not allo
wed to appear in element 'on'. [line=10 column=42 ]: org.xml.sax.SAXParseExcepti
on: cvc-complex-type.3.2.2: Attribute 'continue' is not allowed to appear in ele
ment 'on'.
xml validation error: The prefix "jbpm" for attribute "jbpm:type" associated w
ith an element type "potentialOwner" is not bound. [line=10 column=59 ]: org.xml
.sax.SAXParseException: The prefix "jbpm" for attribute "jbpm:type" associated w
ith an element type "potentialOwner" is not bound.
error: couldn't parse xml document [line=10 column=59 ]: org.xml.sax.SAXParseE
xception: The prefix "jbpm" for attribute "jbpm:type" associated with an element
type "potentialOwner" is not bound.
any suggestions? that jbpm attribute is not bound?
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/524849#524849
16 years, 5 months
[JBoss Microcontainer Development] New message: "Re: Pluggable dependency resolver"
by Kabir Khan
User development,
A new message was posted in the thread "Pluggable dependency resolver":
http://community.jboss.org/message/524847#524847
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
I have got rid of the recursion, so the benchmark now passes with larger numbers. These are the figures:
**10,000 beans
*wrong order
-Legacy resolver: I gave up and stopped the test after 4 minutes
-Indexing resolver: 4655ms
*correct order
-Legacy resolver: 12937ms
-Indexing resolver: 2553ms
**3,000 beans
*wrong order
-Legacy resolver: 29201ms
-Indexing resolver: 1447ms
*correct order
-Legacy resolver: 2264ms
-Indexing resolver: 1173ms
Note that this is done on plain test controller contexts in the dependency project, so there should be no overhead associated with stuff happening in the ControllerContext actions such as accessing the MDR, instantiating the context etc.
Next, I'll try this revised version in AS to see if it has any influence on boot times.
What I have done breaks a few of the tests in the branch. I think they can be fixed easily, since they take into account the order that things reach the various states. For the record these tests are:
KernelAllTestSuite
All Tests
Kernel Tests
Dependency Tests
org.jboss.test.kernel.dependency.test.PlainLifecycleDependencyTestCase
testPlainLifecycleDependencyWrongOrder(org.jboss.test.kernel.dependency.test.PlainLifecycleDependencyTestCase)
junit.framework.AssertionFailedError: expected:<2> but was:<3>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:277)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:195)
at junit.framework.Assert.assertEquals(Assert.java:201)
at org.jboss.test.kernel.dependency.test.PlainLifecycleDependencyTestCase.testPlainLifecycleDependencyWrongOrder(PlainLifecycleDependencyTestCase.java:98)
testPlainLifecycleDependencyReinstall(org.jboss.test.kernel.dependency.test.PlainLifecycleDependencyTestCase)
junit.framework.AssertionFailedError: expected:<10> but was:<11>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:277)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:195)
at junit.framework.Assert.assertEquals(Assert.java:201)
at org.jboss.test.kernel.dependency.test.PlainLifecycleDependencyTestCase.testPlainLifecycleDependencyReinstall(PlainLifecycleDependencyTestCase.java:141)
org.jboss.test.kernel.dependency.test.PlainLifecycleDependencyXMLTestCase
testPlainLifecycleDependencyWrongOrder(org.jboss.test.kernel.dependency.test.PlainLifecycleDependencyXMLTestCase)
junit.framework.AssertionFailedError: expected:<2> but was:<3>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:277)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:195)
at junit.framework.Assert.assertEquals(Assert.java:201)
at org.jboss.test.kernel.dependency.test.PlainLifecycleDependencyTestCase.testPlainLifecycleDependencyWrongOrder(PlainLifecycleDependencyTestCase.java:98)
testPlainLifecycleDependencyReinstall(org.jboss.test.kernel.dependency.test.PlainLifecycleDependencyXMLTestCase)
junit.framework.AssertionFailedError: expected:<10> but was:<11>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:277)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:195)
at junit.framework.Assert.assertEquals(Assert.java:201)
at org.jboss.test.kernel.dependency.test.PlainLifecycleDependencyTestCase.testPlainLifecycleDependencyReinstall(PlainLifecycleDependencyTestCase.java:141)
org.jboss.test.kernel.dependency.test.PlainLifecycleDependencyAnnotationTestCase
testPlainLifecycleDependencyWrongOrder(org.jboss.test.kernel.dependency.test.PlainLifecycleDependencyAnnotationTestCase)
junit.framework.AssertionFailedError: expected:<2> but was:<3>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:277)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:195)
at junit.framework.Assert.assertEquals(Assert.java:201)
at org.jboss.test.kernel.dependency.test.PlainLifecycleDependencyTestCase.testPlainLifecycleDependencyWrongOrder(PlainLifecycleDependencyTestCase.java:98)
testPlainLifecycleDependencyReinstall(org.jboss.test.kernel.dependency.test.PlainLifecycleDependencyAnnotationTestCase)
junit.framework.AssertionFailedError: expected:<10> but was:<11>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:277)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:195)
at junit.framework.Assert.assertEquals(Assert.java:201)
at org.jboss.test.kernel.dependency.test.PlainLifecycleDependencyTestCase.testPlainLifecycleDependencyReinstall(PlainLifecycleDependencyTestCase.java:141)
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/524847#524847
16 years, 5 months