[Design of JBoss jBPM] - Re: GPD New Generation Extensibility
by koen.aers＠jboss.com
Hi Mohan,
You are completely right as for what you found about the architecture of the GPD.
the dom adapters will probably be completely generic in the future; as you may have remarked much of the implementation is mere mapping information.
the editparts and their associated figures are probably the area where still a lot of work is needed to make things really pluggable. I am afraid there is at the moment no easy way to work around this problem. All the creation factories are implemented with switch statements based on instanceof logic. All this will be replaced by a generic factory that will instantiate configurable classes in the future... To plug-in your own representation, you would have to break open these factory classes. A quick patch would be for me to enable extenders of the GPD to add the label and icon information to the extension definition. If you would like this, file a JIRA issue and refer to this thread. I cannot however promise to implement this in the coming days. I think it will take at least a month before this change would make it into the codebase.
you are right also about the extensibility using the syntax. This is however a limitation of the implementation of the engine. In jBPM 4 it will probably change, but of course this does not help you now. The good news is that you can do something like you want to do with the current extension point:
<element
| id="mySpecialMailNode"
| name="node"
| adapterClass="org.jbpm.gd.jpdl.model.xml.MySpecialMailNodeDomAdapter"
| modelClass="org.jbpm.gd.jpdl.model.MySpecialMailNode"/>
I hope this helps you a little bit. However, I need to stress that the GPD and its extension mechanism are moving targets at the moment. The extension points and the API will without doubt still change in the near future. Let's keep this discussion going on so that you stay up to date with the latest changes.
Regards,
Koen
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4014091#4014091
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4014091
19 years, 1 month
[Design of EJB 3.0] - IsLocalInterceptor not detecting local container
by bstansberry＠jboss.com
Some unit tests I'm writing are showing a problem with nested SFSBs where the IsLocalInterceptor doesn't treat a call from a parent SFSB to a nested SFSB as local, but Remoting optimizes it locally. This leads to an exception in the transaction propagation handling. Key points are highlighted:
Caused by: java.lang.RuntimeException: cannot import a transaction context when a transaction is already associated with the thread
| at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:62)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.stateful.StatefulInstanceInterceptor.invoke(StatefulInstanceInterceptor.java:93)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.remoting.ReplicantsManagerInterceptor.invoke(ReplicantsManagerInterceptor.java:51)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
| at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:105)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.stateful.StatefulContainer.dynamicInvoke(StatefulContainer.java:333)
| at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106)
| at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
| at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:1008)
| at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:98)
| at org.jboss.remoting.Client.invoke(Client.java:589)
| at org.jboss.remoting.Client.invoke(Client.java:581)
| at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.remoting.ClusterChooserInterceptor.invoke(ClusterChooserInterceptor.java:77)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:53)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:85)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.stateful.StatefulClusteredProxy.invoke(StatefulClusteredProxy.java:105)
| at $Proxy110.increment(Unknown Source)
| at org.jboss.ejb3.test.stateful.nested.base.ParentStatefulBean.increment(ParentStatefulBean.java:58)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:121)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:110)
| at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
| at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.cache.StatefulReplicationInterceptor.invoke(StatefulReplicationInterceptor.java:51)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.entity.ExtendedPersistenceContextPropagationInterceptor.invoke(ExtendedPersistenceContextPropagationInterceptor.java:57)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
| at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:193)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.stateful.StatefulInstanceInterceptor.invoke(StatefulInstanceInterceptor.java:93)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.remoting.ReplicantsManagerInterceptor.invoke(ReplicantsManagerInterceptor.java:51)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
| at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:105)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.stateful.StatefulContainer.dynamicInvoke(StatefulContainer.java:333)
| at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106)
| at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
| at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:1008)
| at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:857)
| at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:454)
| at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:527)
| at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:261)
What happens here is the parent bean has an increment() method, which delegates to a nested SFSB's increment() method. The nested bean is @Remote. For some reason the IsLocalInterceptor is not recognizing it should invoke the call locally.
This happens in a unit test where I force the failover of the parent SFSB. This is done with the standard trick of adding a server side interceptor that checks a condition and if met throws GenericClusteringException. The stack trace above is *not* from the call that fails over; that works fine. It's the next call to the parent, and is the first call after failover that the parent delegates delegates to the nested bean.
What's really got me stumped is AFAICT IsLocalInterceptor and AOPRemotingInvocationHandler are both dealing with Dispatcher using the same Invocation and the same metadata. But when IsLocalInterceptor queries Dispatcher, it says the container isn't registered, while when AOPRemotingInvocationHandler asks Dispatcher to handle the invocation, it finds the container just fine.
Any thoughts???
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4014012#4014012
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4014012
19 years, 1 month
[Design of JBoss jBPM] - Re: GPD New Generation Extensibility
by mohankishore
Thanks for the reply Koen.
Like I said, even a few one liners would probably go a long way in helping me. From what I have been able to figure out, we have the following structure:
- the plugin.xml defines two kinds of objects:
a) "core" objects - model or semantic elements
b) "ui" objects - also known as notation elements
- the model elements are associated with DomAdapters that serialize/deserialize the model into XML.
- the ui elements have corresponding EditParts to render them in the graphical editor or the tree view. The problem here is that the label/icon mapping is currently hard-coded in the code.
- we already have the ability to use a model element and plug it into the palette using an extension point. But am running into a fundamental problem with the XML schema itself...
The jBPM schema has elements like <fork ..> and <join ..>, whereas I think it might be more extensible if it were <node type="fork" ..> etc. Right now when my custom node gets added to the ProcessDefinitionDomAdapter, it automatically creates an XML element with the same name as the "id" of my model object in the plugin.xml.
Do you have any comments on this disconnect and the best way to solve it?
To repeat my underlying requirement: suppose I have an EmailActionHandler that I anticipate being used multiple times within a single workflow. I do not want my users to keep browsing and finding the action mapping. I want to provide a custom icon on the palette, which when placed in the flow will translate to a node with a pre-associated action-handler. (Am currently doing the pre-association by extending the Node class to create my own model object, which associates the action-handler in its constructor).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4013979#4013979
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4013979
19 years, 1 month