[Design of JBoss jBPM] - Major GPD Changes for Extenders
by koen.aers@jboss.com
Hi all,
This is a post that will be of interest to everyone extending the GPD.
Most of you will have noticed that the packages had a 'common', 'jpdl' and 'pf' category. During the last few days I have moved these different categories to their own plugins. The idea is of course to be able to build a graphical editor for a new dsl using the functionality and extension points that are available in the common part.
More in detail, we have now:
- a plugin called 'org.jbpm.gd.common' which lives in the module 'jbpm.3/designer/common
- a plugin called 'org.jbpm.gd.jpdl' which lives in the module 'jbpm.3/designer/jpdl
- a plugin called 'org.jbpm.gd.pf' which lives in the module 'jbpm.3/designer/pf
If you want to build a graphical editor supporting your own dsl than you most likely only need the first one. The second and thirs one are supposed to be examples of how you would extend the first one to support a particular dsl. I will come up with a third example in the future.
The most important thing to notice is that the extension points that previously lived in the 'org.jbpm.gd.jpdl' plugin are now moved to the 'org.jbpm.gd.common' plugin with the annoying result that their names have changed. So if you are extending already now, you will have to visit the extensions you have made to change the name of the used extension point. Sorry for this compatibility break but the changes should be fairly straightforward.
Another thing to notice is that I have dumped the dom4j dependency in favor of jaxp. Now this change is absolutely not because jaxp has the better api, well on the contrary. But it reduces the dependencies and hence the configuration management because jaxp is present in the Eclipse platform. Normally this should have no implications on extenders.
Please take a look at the changes. I am of course open to suggestions and improvements. Feel free to discuss them here or in JIRA.
Regards,
Koen
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119470#4119470
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119470
18 years, 2 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Something up with the in vm transport
by timfox
When I run in vm tests on TRUNK I notice a typical stack trace to a server method looks something like this:
| at org.jboss.jms.server.endpoint.ServerSessionEndpoint.send(ServerSessionEndpoint.java:397)
| at org.jboss.jms.server.endpoint.ServerSessionEndpoint$SessionAdvisedPacketHandler.handle(ServerSessionEndpoint.java:1803)
| at org.jboss.messaging.core.remoting.PacketDispatcher.dispatch(PacketDispatcher.java:93)
| at org.jboss.messaging.core.remoting.impl.invm.INVMSession$PacketDispatcherCallable.call(INVMSession.java:118)
| at org.jboss.messaging.core.remoting.impl.invm.INVMSession$PacketDispatcherCallable.call(INVMSession.java:103)
| at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
| at java.util.concurrent.FutureTask.run(FutureTask.java:123)
| at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
| at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
| at java.lang.Thread.run(Thread.java:595)
|
So the INVM transport is being used, but I would expect to see the execution done on the same thread all the way from the client.
Any idea what this thread pool is doing?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119408#4119408
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119408
18 years, 2 months