[karstendausb]

"kukeltje" wrote:
please.... what is so difficult about my previous post.... this is JSF stuff, not jBPM. So please ask in the correct forum and learn JSF!!!!

I wouldn't say this is totally wrong, but it is pretty far away from the truth, as jBPM is probably very well involved in this problem.

I ran into the same problem today, and spent many hours to figure this out. There are many postings in this forum, but not a solution. I will describe a workaround and one possible cause for this problem.

Setup:
jbpm-3.2.1-ear on jboss 4.0.4

Same problem as Riket44: After adding a collection of SelectItem as a process variable like this in an actionhandler

Collection selectItems=new ArrayList();
selectItems.add(new SelectItem("BLA","Fasel"));
selectItems.add(new SelectItem("BLoe","Fasel2"));
executionContext.getContextInstance().createVariable("selectit1",selectItems);

using it in a task form like this:

...
 <h:selectOneMenu id="bla22" value="#{var['userselection']}">
<f:selectItems value="#{var['selectit1']}" />
</h:selectOneMenu>
...

got me this Exception:

java.lang.IllegalArgumentException: Argument Error: An option for component j_id48 was not an instance of javax.faces.model.SelectItem. Type found: java.util.ArrayList.

I also tried
* List of SelectItem
* Collection of SelectItem
* SelectItem []
,all with similar Exceptions.

When I changed the form to

 <h:selectOneMenu id="bla22" value="#{var['userselection']}">
<f:selectItem value="#{var['selectit1'][0]}" />
</h:selectOneMenu>

I got this very nice Exception:

java.lang.IllegalArgumentException: "Argument Error: An option for component bla22 was not an instance of javax.faces.model.SelectItem. Type found: javax.faces.model.SelectItem.
 at com.sun.faces.renderkit.RenderKitUtils.getSelectItems(RenderKitUtils.java:315)

Wow. How is that? It is not a SelectItem, it is a SelectItem!

Looking at RenderKitUtils.java I found that the comparison

(value instanceof SelectItem)

must have returned false. This is weired, because instances of javax.faces.model.SelectItem is exactly what has been put into the collection in the actionhandler.

I am not sure what causes this. I first thought that it would be a persistence-related classloading problem (persistence layer using myfaces-jars from tomcat-sar instead of sun's ri vom jbpm-ear), but that doesn't seem to the problem: I replaced the myfaces-jars in tomcat-sar/jsf-libs with the sun-ri-jars, but that didn't help.

Any ideas? I would love to here the solution to this (not only, but especially from Ronald (time to prove that this is a JSF-problem ;-)) ?

Ah, I promised a workaround:
Furtheron in the code, I found that the value attribute of SelectItems also takes a map (key->label, value->value). So I tried this one, and that worked like it was expected to be:
Put

Map mymap=new HashMap();
mymap.put("bla", "fasel");
executionContext.getContextInstance().createVariable("selectit1",mymap);

in the handler.
And the snippet

 <h:selectOneMenu id="bla22" value="#{var['userselection']}">
<f:selectItems value="#{var['selectit1']}" />
</h:selectOneMenu>

in the form.

Hope this helps, but I would very much appreciate a proper solution!

[kukeltje]

pretty far from the truth....

hmmm... I read your post and do not see where jBPM is involved in a way that it is causing this problem. Everything you describe is JSF, the only thing is that you put selectItems in a variable, but that is just like you would do in in a bean. So basically all this is jsf stuff and jbpm is only invloved in a minor way. So I disagree that it is 'pretty far from the truth'

Yet, I do not disagree that a nicer solution would be 'handy' and seam provides parts of that for you. what you encounter now is in the grey area of the webconsole. What is it intended for? Production systems? well, the management part should be. Is it intended for end-users? No currently not. So some things are not in there and personally I use the storage of variables only in the RAD/Prototype part of a project. For productionsystems we have a separate domain model and use a separate database for that (with separate ui) so the list of selectitems comes from there and not jBPM. The selected value goes into jBPM.

(time to prove that this is a JSF-problem ;-)) ?

I'm not saying what *you* encounter is a jsf problem, but up to where you are now was just JSF stuff. Could be that this instance-of thing is related to jBPM.

And yes, I will investigate since it would indeed be nice if the webconsole supported this out of the box in a fairly easy way. Care to help and build a nice more complex example of a ui with this in there?

[karstendausb]

Hi Ronald,

"kukeltje" wrote:

hmmm... I read your post and do not see where jBPM is involved in a way that it is causing this problem. Everything you describe is JSF, the only thing is that you put selectItems in a variable, but that is just like you would do in in a bean.

I am pretty sure that the problem is caused by the jbpm persistence layer, see below. JSF just compares by instanceof, that is a standard procedure and should be fine anyway.

Yet, I do not disagree that a nicer solution would be 'handy' and seam provides parts of that for you. what you encounter now is in the grey area of the webconsole. What is it intended for? Production systems? well, the management part should be. Is it intended for end-users? No currently not. So some things are not in there and personally I use the storage of variables only in the RAD/Prototype part of a project. For productionsystems we have a separate domain model and use a separate database for that (with separate ui) so the list of selectitems comes from there and not jBPM. The selected value goes into jBPM.

Thanks a lot, I haven't seen that so clear so far. I should reconsider my approach here.

And yes, I will investigate since it would indeed be nice if the webconsole supported this out of the box in a fairly easy way. Care to help and build a nice more complex example of a ui with this in there?

Provide an example usage of how to feed task forms? Yes, I can do that.

First I would like to show that this problem is most probably JSF-unrelated:
The following process definition runs fine when using it with a junit test and _without_ persistence. All instanceof comparisons return true.

<?xml version="1.0" encoding="UTF-8"?>
<process-definition
 xmlns="urn:jbpm.org:jpdl-3.2"
 name="A_SelectItemsTest">
 <start-state name="start">
 <transition name="to_state" to="first">
 </transition>
 </start-state>
 <state name="first">
 <event type="node-enter">
 <script>
 List test=new LinkedList();
 javax.faces.model.SelectItem si=new javax.faces.model.SelectItem("hallo","test");
 test.add(si);
 executionContext.getContextInstance().setVariable("selectitems", test);
 System.out.println("first.node-enter: directly after setting variable: instanceof selectitem:"+(test.get(0) instanceof javax.faces.model.SelectItem));
 System.out.println("item "+test.get(0)+" is "+test.get(0).getClass().getName());

 </script>
 </event>
 <event type="node-leave">
 <script>
 List l1=executionContext.getContextInstance().getVariable("selectitems");
 System.out.println("first.node-leave: instanceof selectitem:"+(l1.get(0) instanceof javax.faces.model.SelectItem));
 System.out.println("item "+l1.get(0)+" is "+l1.get(0).getClass().getName());
 </script>
 </event>
 <transition name="to_second" to="second">
 </transition>
 </state>
 <state name="second">
 <event type="node-enter">
 <script>
 List l2=executionContext.getContextInstance().getVariable("selectitems");
 System.out.println("second.node-enter: instanceof selectitem:"+(l2.get(0) instanceof javax.faces.model.SelectItem));
 System.out.println("item "+l2.get(0)+" is "+l2.get(0).getClass().getName());
 </script>
 </event>
 <transition name="to_end" to="end">
 </transition>
 </state>
 <end-state name="end"></end-state>
 </process-definition>

But...when deploying it to jbpm and running it in the console - without the use of any jsf-task-forms!!! - the first instanceof-comparison returns true, but the second and third do not:

16:08:41,752 INFO [STDOUT] first.node-enter: directly after setting variable: instanceof selectitem:true
16:08:41,770 INFO [STDOUT] item javax.faces.model.SelectItem@f3a37f is javax.faces.model.SelectItem

16:09:29,251 INFO [STDOUT] first.node-leave: instanceof selectitem:false
16:09:29,253 INFO [STDOUT] item javax.faces.model.SelectItem@b52821 is javax.faces.model.SelectItem

16:09:29,315 INFO [STDOUT] second.node-enter: instanceof selectitem:false
16:09:29,317 INFO [STDOUT] item javax.faces.model.SelectItem@b52821 is javax.faces.model.SelectItem

Again...I am neither an jbpm nor an hibernate expert, so I cannot say what is going wrong here. But the problem only occurs if the process variable is persisted.
Maybe all the people in this forum facing this problem have a faulty jbpm setup (database e.g.)?

Where to look next? Any ideas?

Karsten

btw: @Ronald: Thanks for your effort, you have definetely helped a lot of people in this forum!

[kukeltje]

Yet, I do not disagree that a nicer solution would be 'handy' and seam provides parts of that for you. what you encounter now is in the grey area of the webconsole. What is it intended for? Production systems? well, the management part should be. Is it intended for end-users? No currently not. So some things are not in there and personally I use the storage of variables only in the RAD/Prototype part of a project. For productionsystems we have a separate domain model and use a separate database for that (with separate ui) so the list of selectitems comes from there and not jBPM. The selected value goes into jBPM.

Thanks a lot, I haven't seen that so clear so far. I should reconsider my approach here.

Think e.g. about
- wizards, pageflow not tasks... they do not fit in the webconsole. But are often required in a real production system. Seam has them.
- Starting processes in a scheduled way... seam (quartz) can help out
- ....

Things that are not that high on the requirementslist for a prototype.

(shameless plug ;-))

Ok, now back to the jBPM persistence problem.... yes, you got me convinced.
I'm curious though what would happen if you changed

System.out.println("first.node-enter: directly after setting variable: instanceof selectitem:"+(test.get(0) instanceof javax.faces.model.SelectItem));

to

System.out.println("first.node-enter: directly after setting variable: instanceof selectitem:"+(executionContext.getContextInstance().getVariable("selectitems").get(0) instanceof javax.faces.model.SelectItem));

I do not have access to a jBPM engine now, so cannot test this myself. This would maybe even rule out persistence .

you also ruled out a classloading issue, but showed a map works.... STRANGE...

I also wonder is something like this would work or if it would throw a classcastexception...

 public List getItems() {
 List elements = executionContext.getContextInstance().getVariable("selectitems");
 Iterator i = elements.iterator();
 List retVal = new LinkedList();

 while(i.hasNext()) {
 javax.faces.model.SelectItem element = (javax.faces.model.SelectItem) i.next();
 javax.faces.model.SelectItem item = new javax.faces.model.SelectItem(element.getId(),element.getValue());
 retVal.add(item);
 }
 return retVal;

I'll keep thinking/searching/...

[kukeltje]

just another comment... In your case you use a processvariable where jbpm comes into play. The other examples just used hibernate and a jsf bean... no jBPM ;-)

[karstendausb]

Hi Ronald,

I just found some time to try it out.

"kukeltje" wrote:

I'm curious though what would happen if you changed

System.out.println("first.node-enter: directly after setting variable: instanceof selectitem:"+(test.get(0) instanceof javax.faces.model.SelectItem));

to

System.out.println("first.node-enter: directly after setting variable: instanceof selectitem:"+(executionContext.getContextInstance().getVariable("selectitems").get(0) instanceof javax.faces.model.SelectItem));

It returns true. Just adding them doesn't persist them, so this has to work.

I also wonder is something like this would work or if it would throw a classcastexception...

 public List getItems() {
 List elements = executionContext.getContextInstance().getVariable("selectitems");
 Iterator i = elements.iterator();
 List retVal = new LinkedList();

 while(i.hasNext()) {
 javax.faces.model.SelectItem element = (javax.faces.model.SelectItem) i.next();
 javax.faces.model.SelectItem item = new javax.faces.model.SelectItem(element.getId(),element.getValue());
 retVal.add(item);
 }
 return retVal;

I'll keep thinking/searching/...

That causes a ClassCastExcpetion:

15:24:08,213 WARN [Script] exception during evaluation of script expression
Sourced file: inline evaluation of: ``List elements = executionContext.getContextInstance().getVariable("selectitems") . . . '' : Typed variable declaration : null : at Line: 1 : in file: inline evaluation of: ``List elements = executionContext.getContextInstance().getVariable("selectitems") . . . '' : ( javax .faces .model .SelectItem ) i .next ( )

Target exception: java.lang.ClassCastException: Illegal cast. Cannot cast javax.faces.model.SelectItem to javax.faces.model.SelectItem

 at bsh.UtilTargetError.toEvalError(Unknown Source)
 at bsh.UtilEvalError.toEvalError(Unknown Source)
 at bsh.BSHCastExpression.eval(Unknown Source)
 at bsh.BSHVariableDeclarator.eval(Unknown Source)
 at bsh.BSHTypedVariableDeclaration.eval(Unknown Source)
 at bsh.BSHBlock.evalBlock(Unknown Source)
 at bsh.BSHBlock.eval(Unknown Source)
 at bsh.BSHBlock.eval(Unknown Source)
 at bsh.BSHWhileStatement.eval(Unknown Source)
 at bsh.Interpreter.eval(Unknown Source)
 at bsh.Interpreter.eval(Unknown Source)
 at bsh.Interpreter.eval(Unknown Source)
 at org.jbpm.graph.action.Script.eval(Script.java:129)
 at org.jbpm.graph.action.Script.eval(Script.java:72)

Very strange. What is happening here? I have a workaround (maps) for my proto and am thinking about Seam and other solutions, so this is not to urgent for me.
But persistence layer being broken will probably cause bad problems along the way?

Karsten

[kukeltje]

thanks for trying this out. It could (one way or another) still be a classloading issue, so I'll try with another type of class

Thanks anyway

[kukeltje]

@Karsten

The reason I think it could still be a classloader issue is that you mentioned you (also?) had jsf libs on in tomcat. If these classes do not implement the serialversionid thingy, they are not identified as identical (I think) and therefor the instanceof not working. Maybe you could try removing the classes from the jbpm war / ear and see what happens.

[kukeltje]

I'm pretty sure now it is a multiple different classes /classloader issue as mentioned above. I extended the VariableInstanceDbTest with the following test:

 public void testJSFSelectItem() {
 Collection selectItems=new ArrayList();
 selectItems.add(new SelectItem("BLA","Fasel"));
 selectItems.add(new SelectItem("BLoe","Fasel2"));
 contextInstance.createVariable("selectit1",selectItems);
 processInstance = saveAndReload(processInstance);
 contextInstance = processInstance.getContextInstance();
 ArrayList selectItemsRead = (ArrayList) contextInstance.getVariable("selectit1");
 assertTrue(selectItemsRead.get(0) instanceof SelectItem);
 }

and the test works.

So try removing the jsf libs from your war/ear and only use those on the classpath. So to me it is now (until proven otherwise Karsten... ;-)) not a jBPM issue anymore

[karstendausb]

Hi Ronald,

thanks for working on that.

I tried on JBoss 4.0.4, which comes with myfaces (1.1) in tomcat5.5.sar. I removed the jars, but that didn't work either.
The only chance that this is "regular" class loading problem is that there are some faces-jars somewhere else in jboss ("find" didn't find any of them though)

I will check with a fresh install later on.

Thanks again

Karsten

PS: What persistence configuration did you use for your test?

[kukeltje]

persistencecontext: the default for the unit tests. Not sure what it is. Add my test above to the VariableInstanceDbTest.java.

[karstendausb]

Sorry, I overlooked your posting.

"kukeltje" wrote:
persistencecontext: the default for the unit tests. Not sure what it is.

Probably hsql in-memory?

Add my test above to the VariableInstanceDbTest.java.

Yes. That works - which makes things even more unclear. Tried it with PostgreSQL (8.1) and Mysql (5.0).

And even stranger: I wrote another junit test, which runs the process-definition mentioned above with persistence...guess what: that runs fine, too.
But when I start the same process in the console (identical config files...), it just doesn't work.

It might be that this is the same problem as the selectManyCheckboxlist-problems reported by others (which I can also reproduce).
Maybe it is a problem with the taglibs (jbpm4jsf and gravel), but i don't know.

[kukeltje]

I cannot imagine it is a problem with gravel or jbpm4jsf (and no I'm not going to try now ;-)) More likely 2 versions (might even be the same ones, but with classeds without) of jsf, which is (could be) only the case if you run it in the console. Look if the jbpm.war/ear contains jsf and if the appserver does to. If the latter is the case AND hibernate is in the appserver, not the ear/war than I'm pretty sure if you remove the jsf jar from the ear/war it will work!!!

[karstendausb]

Ok. I had to solve this now, as I ran into other classloading problems on the way.

The cause of this problem is a simple jar version conflict. The JBoss which is included in the jBPM Suite (3.2.1) comes with a javassist.jar which is too old to work with JSF RI 1.2.
That is probably why a javassist.jar was included in the jbpm-console, which uses JSF 1.2.

But using two different versions of javassist will not work (this is a bytecode modifier library...that's why a SelectITem is not necessarily a SelectItem any more...).
Simply replace that jar in the jboss-lib-dir against the version which comes with the jbpm-console (included in war).

[kukeltje]

Thanks for reporting back. Can you just add which version of JBoss AS it is? It might be in other posts in this topic, but it never hurts to have it close together.