[jBPM] New message: "Re: jBPM 4.3 - Which JTA config to use for non-JBoss platform."
by Ronald van Kuijk
User development,
A new message was posted in the thread "jBPM 4.3 - Which JTA config to use for non-JBoss platform.":
http://community.jboss.org/message/524246#524246
Author : Ronald van Kuijk
Profile : http://community.jboss.org/people/kukeltje
Message:
--------------------------------------------------------------
> Command<T> to try and get those from hibernate but to be honest
> as this needs to be done for all non JBoss servers the changes should
> really be made in the trunk code as otherwise everyone using Jta will
> have to implement this !.
If you have a test, I'm more then willing to test it on JBoss and if it works, check it in.
> I wonder how many people are really running on non-JBoss platforms !.
jBPM3 a lot, jBPM4 not sure. The jta transaction jndi name is (afaik) only a problem on WLS the other appservers have it identical to JBoss so....
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/524246#524246
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/524245#524245
Author : Ronald van Kuijk
Profile : http://community.jboss.org/people/kukeltje
Message:
--------------------------------------------------------------
> VegaMilano wrote:
>
>
> > jedizippy ha scritto:
> >
> > Your custom class would implement the ExternalActivityBehaviour
>
> Well, the custom class - MyClass in the example I posted - is a third-party class and I can't modify it; I have to call its method as-is and I'd like to handle the exception.
>
> Because it's not the only class and method I would like to call in the process and they have different input and output parameters it's not feasible to wrap all of them with implementations of ExternalActivityBehaviour.
> Is it not possible to make the same things with XML elements in the jpdl.xml file?
No, currently it is not and there is no priority for it. Simply because handling low level exceptions like java exceptions should normally not 'bubble up' to the processlevel. In 3 it was also not adviced to change the process state runtime in exceptionhandlers... So.... Personally if there are java exeptions , I would just want them to roll back my transaction to the state it was and have a retry. What I do not get is why you would not want to wrap them in another java class but do want to handle the exeption in a certain node where you most likely need to create custom java classes per class you have.
How many classes are we talking about? 4? 6? 100?
If there are many, you can always look at the implementation of JavaActivity and JavaBehaviour and create ONE custom node that does waht you want AND can direct/steer the process.... So... be creative, be patient, be polite....
Cheers,
Ronald
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/524245#524245
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/524241#524241
Author : Ronald van Kuijk
Profile : http://community.jboss.org/people/kukeltje
Message:
--------------------------------------------------------------
> Actually, we are not able to implement even a simple "start - execute java - catch exception - end" process; we also open a thread:
>
> http://community.jboss.org/thread/146114
>
> but we get answer only from one user and no code sample to prove something is possible to solve the problem.
First, if there already *is* another thread, there is no need to highjack another one. And the answer that user is giving is GOOD. Java exceptions should normally not come to the process level... Changing the state from exceptionhandlers was also in jBPM 3 *not advised* and not used a lot (afaik)
Code examples of how to use the suggestions made by the user are planty.. There are examples in the source, testcases etc... so...
> We are thinking to downgrade to JBPM3 or probably evaluate another product, if JBPM is going to do not handle such simple scenarios like this.
It IS handling such simple scenarios, just not like you want it. You have made just 4 posts in this forum on just ONE day and you are already complaining? May I ask why that is?
> We suspected we are facing problems because we are newbies on JBPM, but
> the lack of answers of our questions are starting to reveal deficiency
> in the JBPM.
The lack of answers???? Wow, sorry but this really surprises me... the answers to your other topic are good. Might be that you do not directly understand where they are directing you. If that is the case, ask politely and were more then willing to help. And saying that a lack of answers is revealing the real deficiency is even a bigger surprise. If that realy is your feeling in a COMMUNITY (help from peers!!!!) forum after this short period, maybe it is beter for you to find another engine and move on... Sorry...
> I hope someone here is able to give us answers to our doubts. I am
> starting to ask to myself what do you call or manage inside JBPM
> tasks...
Again, answers to what? The answers in your other topic are spot on.... And by starting to wonder what you manage inside jBPM tasks, I think you should read the basic userguide and maybe some blogs on the internet... Personally (and without wanting to offend you) I get the feeling you blame us for your (at this moment) lack of understanding of jBPM.
Peace...
Ronald
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/524241#524241
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/524239#524239
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
I got AS trunk started with the indexing dependency resolver, unfortunately I did not see any difference in startup speed worth mentioning :-(
So, although we only try to increment the contexts that have actually had a dependency resolved, at the moment there is a lot of work going into determining what those contexts are. Maybe too much?
An overview of what I have so far is probably best described with an example. I deploy
<bean name="Bean" class="...">
<property name="prop"><inject bean="Other"/></property>
</bean>
Since this is an explicit dependency on a name which is required in the CONFIGURED state and Other reaches the INSTALLED state, this is recorded in the NameDependencyResolverMatcher under
[INSTALLED->["Other"->{Context[name="Bean"]}]
(Read as when a bean called "Other" reaches the Installed state, the Context named Bean is a candidate for injection)
We then try to push Bean as far through the states as we can, in this case it will stop in the INSTANTIATED state since Other is not available yet when we try to resolve the dependencies to enter Configured.
Now if we deploy
<bean name="Other" class="…"/>
We push this through the states. There is a stateIncremented(ControllerContext) method in the resolver called by the controller whenever a context has its state incremented which calls through to all the dependency resolver matchers. For Other in PRE_INSTALL, …, START nothing is found in the matchers so we just keep on moving Other through the lifecycle. Once stateIncremented(ControllerContext) is called for Other when it hits the INSTALLED state we then check all the dependency resolver matchers. We hit the NameDepedencyResolverMatcher and for INSTALLED we find
["Other"->{Context[name="Bean"]}]
We then look up "Other" in this map and find
{Context[name="Bean"]}
in other words the context called Bean has been waiting for Other to reach the INSTALLED phase, we then check that Bean has its other dependencies resolved and then attempt to push it through the states as before.
I have not tried profiling anything yet, but for simple dependencies like the one above I think the above mechanism should be fast. However, there are a few other factors that could well slow it all down.
====== Contextual Injection (and Callbacks) =========
If we first deploy
<bean name="Bean" class="...">
<property name="prop"><inject/></property>
</bean>
where the type of the prop property is 'interface SomeInterface'. This becomes a ContextualInjectionDependencyItem, and is recorded in ContextualInjectionDependencyResolverMatcher as
[INSTALLED->[[interface SomeInterface]->{Context[name="Bean"]}]
As before Bean is moved to the INSTANTIATED phase.
Now we deploy
<bean name="Bean" class="SomeClass"/>
where SomeClass somewhere in its inheritance hierarchy has SomeInterface as a parent. When installing Bean, each time its state is incremented it checks the matchers for matching contexts. It will find nothing in NameDependencyResolverMatcher nor in ContextualInjectionDependencyMatcher for PRE_INSTALL, …,START. When it gets to INSTALLED, again it finds nothing in NameDependencyResolverMatcher, but when it hits ContextualInjectionDependencyMatcher it finds this for INSTALLED
[interface SomeInterface]->{Context[name="Bean"]}
Now it checks if SomeClass is there, nothing. Then do the same for all the superclasses and interfaces until it finally finds the Bean Context under SomeInterface. We then check Bean's other dependencies and push it through the remaining states.
I am not sure how extensively contextual injection is used in the AS, but the point here is that if contextual injection is used *at all* and we have contexts registered as waiting for a few other states, whenever other contexts reach one of those states we have to do all the work of looking up all the superclasses/interfaces to see if any of the waiting contexts can be removed.
Also, this work is duplicated since we also have a CallbackDependencyResolverMatcher which effectively does exactly the same but for CallbackDependencyItems.
====== Scoping =======
We only record the dependencies in the matchers for the controller into which the context owning the dependency was installed. If a context has its state incremented, there might be contexts with dependencies on it waiting in one of the child controllers. So the stateIncremented(ControllerContext) method ends up calling stateIncremented(ControllerContext) on all the child controller resolvers as well, which in turn will invoke all the matchers for each child controller.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/524239#524239
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/524226#524226
Author : nick bauman
Profile : http://community.jboss.org/people/nick.bauman
Message:
--------------------------------------------------------------
Flavio,
I hear ya, man. I'm struggling with JBPM4 still.
We have a way to do subworkflows that work ok for us in JBPM3 (we just can't allow the subworkflow to have a wait state, pretty big limitation but we've worked around it so far). As far as transactions are concerned, we actually DO NOT want ANY persistent store because we use clustered memory that reads from hardware devices in the field. IOW the process instance runs in an environment that is not the System of Record: what's going on in the field where the hardware is the "truth" and if our process defintion blows up, we simply go back to the field to read the correct state of the system. Since we have realtime requirements, using any kind of disk database is much too slow anyway.
Alternatives? Writing a simple FSM isn't that hard, by the way. Its main purpose is to limit the amount of mutable state visible in your application. It accomplishes this by seperating what gets done from deciding what to do. What JBPM does for you on top of this is to give you all the integration and GUI tools to work with, and a community of people making it better and better.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/524226#524226
16 years, 5 months