October 2009 - jboss-dev-forums - Jboss List Archives

[jBPM Development] - Some bugs and feature requests on jBPM 4.1

by camunda

Hey guys. On a workshop at the customer this week we used jBPM 4.1 for a prototype, which we created on the fly. There are some issues I found on the way. Unofrtunately I don't have the time now to really investigate all of them, but I wanted to document them at least here! 1. Classloading problems When you put you EventHandlers, Java delegation classes and/or process variable types in an EJB3 deployment and redeploy that, jBPM still holds a reference to the old class definitions, which results in class cast exceptions. My guess is, that this is becasue EventHandler and such are reused/pooled? So there we might have to discuss, what scenario we want to support. 2. Invalid types.xml doesn't result in a parsing error We changed the types mapping and had a small XML error in that file. But this didn't resulted in a parsing exception, the parsing just stopped at this line and our type mapping wasn't read (which puzzled us for quite a while ;-)): | <type name="..." class="..." variable-class="...EntityVariable">  | <type name="serializable" class="serializable" | converter="org.jbpm.pvm.internal.type.converter.SerializableToBytesConverter" | variable-class="org.jbpm.pvm.internal.type.variable.BlobVariable" /> | Now every Serializable process variable was rejected... Some issues I maybe just don't know how to do it: 3. Bind e.g. integer value to EventListener field by expression This didn't work, and I don't know how to get it to work: | <custom class="de...jbpm.NoopActivity" g="83,61,143,50" name="xxx"> | <on event="start"> | <event-listener class="de.....SomeEvenetListener"> | <field name="programm"><int value="#{programm}"/></field> | </event-listener> | </on> | <transition g="14,-11" name="ok" to="b"/> | </custom> | The only possibility with expressions seems to be the which results in a field type doesn't match problem: | <custom class="de...jbpm.NoopActivity" g="83,61,143,50" name="xxx"> | <on event="start"> | <event-listener class="de.....SomeEvenetListener"> | <field name="programm"><object expr="#{programm}"/></field> | </event-listener> | </on> | <transition g="14,-11" name="ok" to="b"/> | </custom> | Some feature requests: 4. Should be possible to set Subprocess Key by expression If you start a nw sub process instance, this normally has no special key, thus a key is created for it. It would be really convinient, if the main process could influence the sub process key by an expression (e.g. "#{execution.key}.SubXX.#{someUniqueVariableForIt}). maybe this need some more thoughts (what in case the key is not unique? ...?), but I think it could get handy in lot of situations. And there are some pretty annoying issues in thee GPD, which should be fixed ASAP: 5. Writing in propteries panel is reversed I am pretty sure this bug is known (as I remeber it right, Koen showed it to me once). Would be pretty good to fix it anyway. 6. type of is removed by the GPD sometimes In the workshop the type attribute disappeared a couple of times (but only this attribute). Don't know when and why exactly, but this is really annoying. This is the example from the workshop: | <java class="de....service...Service" g="118,66,112,52" method="druckeEtikett" name="Etiketten drucken"> | <arg type="long"><object expr="#{xxx.charge.id}"/></arg> | <arg type="java.lang.String"><object expr="#{xxx.ident}"/></arg> | <arg><object expr="#{xxx.number}"/></arg> | <transition g="-135,-18" name="to Zustand erfassen" to="Zustand erfassen"/> | </java> | 7. Signavio by the way, using the Signavio Editor for a already running process results in a lot of attributes beeing removed when saving with Signavio. It should be somehow the default, to keep everything, it doesn't know. I think I remember a discussion, that this is pretty hard to implement. But I think it is crucial for real live use cases. At least for use cases I have in mind for Business-/-Alignment. But maybe we can discuss that in the next meeting in Berlin. And last but not least I started to implement 8. Support EJB3 Entities as process variables I think this is a pretty important feature, since a lot of projeects start with EJB3 today. Since Tom fixed a bug in the binding code, I think I can go ahead with that. Will post something as soon I had time to work on it again. If anybody else putting effort into this, please let me know! Puh, this is it. Sorry for the long post and not splitting it into several posts, looking up or creating JIRA-Issues. I really have to work on the book today, just wanted to have it documented. Maybe some of you can tackle some of the issues, otherwise I will come back to it as soon there is some time for it. Cheers Bernd View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260868#4260868 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260868

16 years, 5 months

1
0
0 / 0

[JBoss Remoting Development] - Re: Remoting 3: Type-safe client API

by david.lloyd＠jboss.com

BTW, if you want to quickly glance over the API definition without checking out the project, check out this link: http://is.gd/4mWNm View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260841#4260841 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260841

16 years, 5 months

1
0
0 / 0

[JBoss Remoting Development] - Remoting 3: Type-safe client API

by david.lloyd＠jboss.com

Leaving aside the fact that it's been an amazingly long time since I've had a chance to post in here... I've recently added additional type-safe methods to the Client interface in trunk. The purpose of these methods is to allow a service to be defined such that the result type of the invocation depends not only on the client's defined reply type, but also the type of the request you're sending. There are two ways to use this feature. The first way is to use the new form of invoke()/send() which accepts as a second parameter, the expected return type. The second way is to have your request type extend the new TypedRequest interface, which defines the reply subtype for each request type. If this is the case, invoke()/send() will use a third form in which the argument extends TypedRequest and the reply type is defined accordingly. This feature is optional; the regular invoke()/send() methods still exist on the Client interface for simpler use cases. Please let me know what you think of this idea. The implementation was actually quite trivial, since per-request type checking is already built into the SPI. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260840#4260840 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260840

16 years, 5 months

1
0
0 / 0

[JBoss Identity Development] - Announcing JBoss Authz 1.0.Alpha1

by sohil.shah＠jboss.com

A "Rule based" Authorization Framework for Java Applications. Details at: http://authz.blogspot.com/2009/10/announcing-jboss-authz-10alpha1.html Thanks Sohil View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260827#4260827 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260827

16 years, 5 months

1
0
0 / 0

[JBoss Transactions Development] - Re: beanifying the config

by jhalliday

Time for phase two of the cunning plan to beanify the world... - Now that the properties file is flat rather than hierarchic, it makes no sense to continue having per-module properties files. There should be a single, global properties file from which all beans are populated. - The per-module build time properties are similarly little used, with the exception of values that could just as well be global: sourceid (i.e. svn tag) and such. Can anyone see a reason for sticking with a custom per-module build properties file, rather than using META-INF/MANIFEST.MF? - The per-module Info.java classes and the Configuration.java classes should be removed in favour of bean properties, a method to dump the state of the EnvironmentBeans and a method to dump the global build time data, which are more useful in the modern world. comments? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260822#4260822 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260822

16 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] - Re: Adding a ClassLoader import exclusion filter

by jason.greene＠jboss.com

"alesj" wrote : You can already do all of these things, | most of if just requires proper ClassLoadingMetaData / jboss-classloading.xml configuration. | AFAICS a deployment can only exclude classes that it contains (excludes) or that it exports (excludeExport). A deployment could achieve this by defining all the package requirements for every EE and JBoss API it uses, however this could end up being overly verbose compared to a simple exclusion. What I am talking about would be something like a new excludeImport value which would take precedence over any import (either importAll or via module imports). However, I don't want to add it if this would violate the intentions of the design, or if you guys think it would be a bad practice. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260818#4260818 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260818

16 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Testing Deployers with new Reflect + ClassPool

by alesj

"flavia.rainone(a)jboss.com" wrote : | That fixed the tests for me. Could you please check if they pass for you as well? | Yup, it passes now. "flavia.rainone(a)jboss.com" wrote : | Just an observation: I haven't made a new snapshot of jboss-classpool, so you need to build that project first before running deployers-vfs tests. I deployed a new snapshot. Now - as discussed - you need to add proper .war CL deployer + fix assertClassPool to understand this hierarchy cl notion. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260814#4260814 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260814

16 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Testing Deployers with new Reflect + ClassPool

by flavia.rainone＠jboss.com

"alesj" wrote : ClassLoading::getClassLoaderForModule(Module). That fixed the tests for me. Could you please check if they pass for you as well? Just an observation: I haven't made a new snapshot of jboss-classpool, so you need to build that project first before running deployers-vfs tests. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260806#4260806 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260806

16 years, 5 months

1
0
0 / 0

[JBoss AS Development Deployment Framework] - Re: Redundant WAR deployer redundancy

by david.lloyd＠jboss.com

Well, I'm not updating it in two places, and leaving "mock" code around is rather useless I would say. So... take your pick ;) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260801#4260801 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260801

16 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Testing Deployers with new Reflect + ClassPool

by alesj

"flavia.rainone(a)jboss.com" wrote : | But how do I get the Module's classloader if Module.getClassLoader() is protected? | ClassLoading::getClassLoaderForModule(Module). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260785#4260785 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260785

16 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2009