[jBPM Development] - Re: Creating domain specific nodes into a jbpm-editor
by koen.aers＠jboss.com
"barteljan" wrote : Yes I fear that's true, I thought of a situation where I give a customer just the editor to create processdefinitions without a possibility of testing or executing them. It could even happen that I want him to model a process with actions which have to be implemented in the future.
| In such a situation it would be a bit of annoying to provide java-classes or some stubs for him, but a config-file (even if this could be in the jbpm.config.xml) isn't really better ....
|
The only good solution in my opinion is a plugin-based solution. IE every node you want to contribute is an extension to the extension point that defines how to add new nodes to the editor.
The different elements of information that are needed to do this in its most simplified form are:
- a description of the node that has to be added (the properties of the node)
- how to serialize the node
- how to deserialize the node
Additionally the following elements are optional:
- description of the figure representing the node
- the icon and/or text that have to appear in the palette
- the path in the palette where they have to be added
Of course, you can even more generalize the possible extensions by defining a generic node type what is always serialized/deserialized in the same way and of which the properties are simple attributes and/or some well-known child elements. In this case the 'pure' xml solution comes in the picture. Nevertheless, I have a preference of describing these extensions in the plugin.xml of a plugin that adds these custom nodes instead of adding a jar file containing these xml files somewhere on the classpath (either by configuring a preference in the workspace or adding a jar file in a projet).
The latter solution (including the xml config in a jar file) is a more specific case of the former one. The former solution is not yet completely implemented at present. Roughly the following things need to be done first:
- define an extension point for serialization/deserialization
- define an extension point for the palette items
If you want to dive deeper into this, take a look at the Registry class in the package org.jboss.tools.flow.jpdl4.io and the JpdlPaletteFactory class in the org.jboss.tools.flow.jpdl4.editor package. The first step is to refactor these two classes and let them do their job based on information that is contributed in the plugin.xml by extensions of two new extension points. Another thing that you definitely want to look into is the already existing extension point for adding elements to the GPD (defined in the plugin.xml of the org.jboss.tools.flow.common plugin and used in the plugin.xml fo the org.jboss.tools.flow.jpdl4 plugin). It will show you how to create and use extension points. More in particular the class ElementRegistry in the package org.jboss.tools.flow.common.registry will be a good source of information.
I'll add a reference to this thread to GPD 292 and we can continue the discussion there. Also feel free to attach patches if you're fiddling around (or happen to define the extension points) so that i can test them. Make sure you sign the contributor's agreement if you're going to do this.
Cheers,
Koen
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254509#4254509
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254509
15 years, 4 months
[JBoss ESB Development] - SOAPProxy initialization and deployment ordering
by dward
When the SOAPProxy action is constructed, it pulls the wsdl url as configured. The normal use case for a webservice proxy is that the webservice is "someplace else" and already available, and if it's not available, it rears itself as an initialization exception of the SOAPProxy.
However, what if the webservice is deployed in the same server as the esbservice containing the SOAPProxy? Well, right now, the war containing the webservice needs to be deployed first before the SOAPProxy, and the HTTP connector has to be started and available.
I'm starting this thread because I would like input on the following options (add more if you like):
1. Change nothing. Aren't proxied webservices normally external and should already be available?
2. *Lazily* initialize SOAPProxy on it's first real usage/invocation. I don't like this one because it's really a lie then if the esbservice seemingly successfully deploys, when in reality there's something wrong (in the case where the wsdl URL is bad or not available).
3 .Investigate using deployment.xml (<jbossesb-deployment>web applicationweb container</jbossesb-deployment>)? If this would work, I think it would be the best option.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254498#4254498
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254498
15 years, 4 months
[JBoss Microcontainer Development POJO Server] - Re: Servlet 3.0 annotation processing requirements
by alesj
"remy.maucherat(a)jboss.com" wrote :
| a) Per JAR annotation scanning. Due to the fact that the order impacts
| annotations, the deployer should produce a set of attachements keyed by
| JAR name for web annotations (like what happens for the web fragments,
| so that way I can merge the fragment metadata for a given jar, then
| merge the annotation metadata, then move to the next jar in the order).
|
This one doesn't look hard to do.
As we do deployer per all deployment units.
Meaning all you need to do is create 2 new deployers:
* one that would collect the fragment info
* the second one that would apply it
"remy.maucherat(a)jboss.com" wrote :
| b) The ServletContainerInitializer feature. I have no idea how to handle
| the @HandlesTypes annotation (reminder: the annotation contains a list
| of classes, and I need to build a set of Class that are in the webapp
| that implment, extend, or are annotated by any item in the list of
| classes).
|
Yeah, this one sounds pita. Another performance bottleneck on the horizon.
I see 3 ways of doing this:
* part of generic scanning (== preparing info for any resource); hence only a single scan
* on-demand checking (+ some caching); can be done now, but it's slow
* another new Jesper's Papaki project for class info (need to check if this could be part of Reflect)
"remy.maucherat(a)jboss.com" wrote :
| c) The access control annotations were added to Servlet 3.0, and classes that extend HttpServlet can have these annotations as method level annotations (on doGet, doPost, etc; actually all the doXXX methods defined in HttpServlet).
|
Easy. Simple AnnotationEnv usage.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254496#4254496
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254496
15 years, 4 months
[jBPM Development] - Re: Creating domain specific nodes into a jbpm-editor
by barteljan
"kukeltje" wrote :
| That is not what I meant, I meant looking at the droolsflow editor to see how the extensibility is done there. I pretty confident an example in drools would work (I tested one myself here ;-))
|
I really did some SOA today, it looks like it leaves me a bit of braindead .... which is at least better than the first translation of this term.
Looking at the DroolsFlow editor is a good idea ....
I hope that I don't repeat things you already knew, but my first impression of the architecture involving workItems is the following:
DroolsFlow divides the definition of workItems in some sort of MVC concept ....
At first there is a MVEL-Definition in your META-INF folder which describes how to represent a node type in the editor and it's abstract parameters and properties. And secondly there is a additional Representation of a WorkItem at runtime with a WorkItemHandler. Such a handler is itself a class implementing the WorkItem-Interface with a central executeWorkItem method containing your domain specific code. WorkItemHandlers are normal java objects which are intanciated by the developer and passed to a WorkItemManager at runtime. Those handlers are then notified when a process instance signals a workItem node.
"kukeltje" wrote :
| Maybe a solution where the designer could pick up classes in the project and runtime adapt the pallet to those classes that are just within this project. Then just adding a jar to your project would be sufficient.
|
Yes adding such an option to the GPD could be a solution .... or did I miss the point again :-/ .
"barteljan" wrote :
| I would prefer an option to configure it with a xml-jungle, but defaults which are using reflection or annotations ....
|
"kukeltje" wrote :
| hmmm.... where do you leave this config file then... I think it is more cumbersome than to just add a jar to your project.
|
Yes I fear that's true, I thought of a situation where I give a customer just the editor to create processdefinitions without a possibility of testing or executing them. It could even happen that I want him to model a process with actions which have to be implemented in the future.
In such a situation it would be a bit of annoying to provide java-classes or some stubs for him, but a config-file (even if this could be in the jbpm.config.xml) isn't really better ....
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254491#4254491
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254491
15 years, 4 months
[JBoss Serialization Development] - OutOfMemoryError
by lawc
Hi,
I get the following exception when serializing/deserializing an object of type: javax.management.openmbean.OpenType,
anonymous wrote :
| Type: java.lang.OutOfMemoryError
| Message: Java heap space
| Stack trace:
| at java.lang.AbstractStringBuilder.(AbstractStringBuilder.java:45)
| at java.lang.StringBuffer.(StringBuffer.java:91)
| at org.jboss.serial.util.StringUtil.readString(StringUtil.java:295)
| at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readUTF(DataContainer.java:757)
| at org.jboss.serial.persister.ObjectInputStreamProxy.readUTF(ObjectInputStreamProxy.java:196)
| at org.jboss.serial.objectmetamodel.FieldsContainer.readField(FieldsContainer.java:147)
| at org.jboss.serial.objectmetamodel.FieldsContainer.readMyself(FieldsContainer.java:218)
| at org.jboss.serial.persister.ObjectInputStreamProxy.readFields(ObjectInputStreamProxy.java:224)
| at javax.management.openmbean.OpenType.readObject(OpenType.java:378)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:1)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:597)
| at org.jboss.serial.persister.RegularObjectPersister.readSlotWithMethod(RegularObjectPersister.java:103)
| at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:269)
| at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
| at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
| at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
| at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
| at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
| at org.jboss.serial.persister.ObjectInputStreamProxy.defaultReadObject(ObjectInputStreamProxy.java:78)
| at alchemy.mx.mbean.SimpleTabularDataSupport.readObject(SimpleTabularDataSupport.java:971)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:1)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:597)
| at org.jboss.serial.persister.RegularObjectPersister.readSlotWithMethod(RegularObjectPersister.java:103)
| at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:269)
| at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
| at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
| at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
| at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
|
The code fails in StringUtil.readString(DataInput, StringUtilBuffer) method when it tries to instantiate a StringBuffer:
| if (strbuffer==null)
| {
| strbuffer = new StringBuffer((int)size);
| }
|
The size variable at this stage has a value of 42238343537016.
I am trying to write a test case to reproduce the error, but my test code gives a different exception:
| OpenType[] itemTypes = new OpenType[] { SimpleType.STRING,
| SimpleType.STRING, SimpleType.STRING };
| String[] itemNames = new String[] { "Item1", "Item2", "Item3" };
| String[] itemDescriptions = new String[] { "Item 1", "Item 2", "Item 3" };
| CompositeType rowType = new CompositeType("composite", "Description",
| itemNames, itemDescriptions, itemTypes);
|
| ByteArrayOutputStream byteOut = new ByteArrayOutputStream();
| JBossObjectOutputStream os = new JBossObjectOutputStream(byteOut);
| os.writeObject(rowType);
| os.flush();
|
| ByteArrayInputStream byteInpt = new ByteArrayInputStream(byteOut
| .toByteArray());
| JBossObjectInputStream is = new JBossObjectInputStream(byteInpt);
| rowType = (CompositeType) is.readObject();
|
Exception:
anonymous wrote :
| java.io.IOException
| at org.jboss.serial.persister.RegularObjectPersister.readSlotWithMethod(RegularObjectPersister.java:107)
| at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:269)
| at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
| at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
| at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
| at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
| at org.jboss.serial.io.JBossObjectInputStream.readObjectOverride(JBossObjectInputStream.java:163)
| at java.io.ObjectInputStream.readObject(ObjectInputStream.java:345)
| at alchemy.measure.TestInterfaces.testSerialization(TestInterfaces.java:90)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:597)
| at junit.framework.TestCase.runTest(TestCase.java:168)
| at junit.framework.TestCase.runBare(TestCase.java:134)
| at junit.framework.TestResult$1.protect(TestResult.java:110)
| at junit.framework.TestResult.runProtected(TestResult.java:128)
| at junit.framework.TestResult.run(TestResult.java:113)
| at junit.framework.TestCase.run(TestCase.java:124)
| at junit.framework.TestSuite.runTest(TestSuite.java:232)
| at junit.framework.TestSuite.run(TestSuite.java:227)
| at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
| at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
| at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
| at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
| at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
| at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
| at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
| Caused by: java.lang.reflect.InvocationTargetException
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:597)
| at org.jboss.serial.persister.RegularObjectPersister.readSlotWithMethod(RegularObjectPersister.java:103)
| ... 27 more
| Caused by: java.io.EOFException
| at java.io.DataInputStream.readFully(DataInputStream.java:180)
| at org.jboss.serial.util.StringUtil.pullDataToBuffer(StringUtil.java:191)
| at org.jboss.serial.util.StringUtil.readString(StringUtil.java:238)
| at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readUTF(DataContainer.java:757)
| at org.jboss.serial.persister.ObjectInputStreamProxy.readUTF(ObjectInputStreamProxy.java:196)
| at org.jboss.serial.objectmetamodel.FieldsContainer.readField(FieldsContainer.java:147)
| at org.jboss.serial.objectmetamodel.FieldsContainer.readMyself(FieldsContainer.java:218)
| at org.jboss.serial.persister.ObjectInputStreamProxy.readFields(ObjectInputStreamProxy.java:224)
| at javax.management.openmbean.OpenType.readObject(OpenType.java:378)
| ... 32 more
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254487#4254487
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254487
15 years, 4 months
[jBPM Development] - Re: Creating domain specific nodes into a jbpm-editor
by kukeltje
"barteljan" wrote : "kukeltje" wrote :
| | Might be interesting to also have a look at the RuleFlow editor (not sure if all the latest things are in the drools or jboss tools svn or there at all). Since we seem to be going to borrow/share something that Koen had an idea for a long time ago and Kris seems to have implemented it in quite a nice a way.
| |
|
| I could write a simple drools-eclipse-project using some workItems if you want a simple example using the latest stable drools release (5.0.0).
| But if you have good connections to Kris, asking him would be excellent ....
|
That is not what I meant, I meant looking at the droolsflow editor to see how the extensibility is done there. I pretty confident an example in drools would work (I tested one myself here ;-))
"barteljan" wrote :
| "kukeltje" wrote :
| | So to summarize:
| |
| | We need a way to specifiy
| | - A node type (name)
| | - reference to a pallet icon
| | - reference a node icon (process diagram level but could be the same as the palet icon)
| | - a reference to a custom node implementation (java class) that has to be included in the process archive
| | - some way to edit 'properties' of this node in a user friendly way (non-xml)
| |
| | Designing these should be almost as easy as defining custom node, maybe by having the class implement a specific interface and find all implementing classes via reflection or use annotations or whatever and add them to the pallet on runtime. No XML hell... right ;-)
| |
|
| Avoiding xml-hell sounds good,but what should we do if there are classes in the classpath who are correctly annotated or implement the right interface, but which shouldn't be shown in the editor (thinking of the example nodes provided in the jmpm.jar or the jar of project x, which uses nearly the same classes, but different "action-type nodes").
|
Maybe a solution where the designer could pick up classes in the project and runtime adapt the pallet to those classes that are just within this project. Then just adding a jar to your project would be sufficient.
"barteljan" wrote :
| Another problem is that this means that the implementation class is needed while designing the process, which might be unwanted ....
|
Au contraire mon ami, I think you want to have them available for unittesting. Maybe they are even one and the same class (why not?)
"barteljan" wrote :
| I would prefer an option to configure it with a xml-jungle, but defaults which are using reflection or annotations ....
|
hmmm.... where do you leave this config file then... I think it is more cumbersome than to just add a jar to your project.
"barteljan" wrote :
| "kukeltje" wrote :
| | Would be good if we could break up all these things in jira and maybe some underlying things for Koen so it is clear what needs to be done etc.
|
| Hmm .... seems like i will spend my weekend with jbpm :-P.
| More with the GPD, and be glad it is not with a SOA (depending on your native language)
"barteljan" wrote :
| I would suggest starting a new forum-thread summarizing all requirements, so that we can split them up into different jira-issues.
| Would you agree with that ?
|
Yep, or even start a wiki page... Is even better I think and just post a link in this new topic if someting changes.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254448#4254448
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254448
15 years, 4 months
[jBPM Development] - Re: Creating domain specific nodes into a jbpm-editor
by barteljan
"kukeltje" wrote :
| Then you are already further then I am ;-) Lets see how Koen can help, he is the 'master' ;-)
|
that sounds good ;).
"kukeltje" wrote :
| Might be interesting to also have a look at the RuleFlow editor (not sure if all the latest things are in the drools or jboss tools svn or there at all). Since we seem to be going to borrow/share something that Koen had an idea for a long time ago and Kris seems to have implemented it in quite a nice a way.
|
I could write a simple drools-eclipse-project using some workItems if you want a simple example using the latest stable drools release (5.0.0).
But if you have good connections to Kris, asking him would be excellent ....
"kukeltje" wrote :
| So to summarize:
|
| We need a way to specifiy
| - A node type (name)
| - reference to a pallet icon
| - reference a node icon (process diagram level but could be the same as the palet icon)
| - a reference to a custom node implementation (java class) that has to be included in the process archive
| - some way to edit 'properties' of this node in a user friendly way (non-xml)
|
| Designing these should be almost as easy as defining custom node, maybe by having the class implement a specific interface and find all implementing classes via reflection or use annotations or whatever and add them to the pallet on runtime. No XML hell... right ;-)
|
Avoiding xml-hell sounds good,but what should we do if there are classes in the classpath who are correctly annotated or implement the right interface, but which shouldn't be shown in the editor (thinking of the example nodes provided in the jmpm.jar or the jar of project x, which uses nearly the same classes, but different "action-type nodes").
Another problem is that this means that the implementation class is needed while designing the process, which might be unwanted ....
I would prefer an option to configure it with a xml-jungle, but defaults which are using reflection or annotations ....
"kukeltje" wrote :
| Would be good if we could break up all these things in jira and maybe some underlying things for Koen so it is clear what needs to be done etc.
Hmm .... seems like i will spend my weekend with jbpm :-P.
I would suggest starting a new forum-thread summarizing all requirements, so that we can split them up into different jira-issues.
Would you agree with that ?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254441#4254441
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254441
15 years, 4 months