August 2006 - jboss-dev-forums - Jboss List Archives

[Design of JBoss jBPM] - Re: Variable type definition in processdefinition.xml (yes a

by tom.baeyens＠jboss.com

"kukeltje" wrote : But if added, the GPD (or a simple ant task) could take a freemarker template or an xslt and generate a basic form. | i don't care how koen does the generation of the .xhtml facelets template it in the gpd. probably programmatic would be the easiest and most portable. at runtime, the forms will be rendered with facelets. "kukeltje" wrote : hmm... I used date/integer from JSF in the webapp for 3.1 and did not need any conversion property or so. Displaying a date object in the process as a human readable string worked without a problem. | the problem is when you want to create a form field to enter a new integer process variable. since the task form variables are in a hash map, taskInstance.variables['myNumber'] will be stored as a string if no conversion is specified. i was hoping that specifying a conversion on the input field could do the trick to convert the submitted text to integer before it was inserted in the untyped hashmap. "kukeltje" wrote : Ohhh and... btw, when is the variable-type in the PD???? ;-) | what use cases do you see other then generating forms ? it will be a challenge to find a clean and natural behaviour of the system. some people want to use it as a free hashmap. others want the types of variables to be checked. some want the variables to be created at start time, others want lazy initialization,... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3965462#3965462 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3965462

19 years, 7 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: default generated forms

by tom.baeyens＠jboss.com

btw, the origin of this discussion is kukeltje's jira comment on http://jira.jboss.com/jira/browse/JBPM-732 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3965454#3965454 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3965454

19 years, 7 months

1
0
0 / 0

[Design of JBoss jBPM] - default generated forms

by tom.baeyens＠jboss.com

previously, a form could be generated from a task based on the default task controller. originally, all process variables were not visible from task instances. so if variables were needed in a form, it was mandatory that they were copied from the process variables and stored as separate task instance local variables. with that background, at the time, we could generate a default form based on the configuration of the default task controller. but now things have changed. task instances now CAN see process variables. so a task controller only becomes necessary if you want to create task local copies of the process variables. so in general, i think that the task controllers will be less used. and hence they can't be used as the source information to generate default task forms. afaik, a forms.xml was always necessary, no ? so the idea we have now is that the graphical process designer will have to be used to generate forms. the graphical process designer will still be able to generate the default form based on a few process variables as input. but now, a facelets .xhtml form will be generated that could potentially have the same layout as before. variable declarations in the process definition would help a lot, i think. but overall, do you think that we could provide a simpler way to distill the task forms ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3965452#3965452 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3965452

19 years, 7 months

1
0
0 / 0

WebHosting Profesional.

by Hostex

19 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Bean instantiate order with contextual injection

by alesj

Found it. :-) | KernelControllerContext context = visitor.getControllerContext(); | ClassLoader cl = Configurator.getClassLoader(context.getBeanMetaData()); | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3965432#3965432 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3965432

19 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Bean instantiate order with contextual injection

by alesj

I've added TypeProvider interface - to help me with determinig the class type of injectee in describeVisit method. | public interface TypeProvider | { | | Class getType(MetaDataVisitor visitor); | | } | There are certain classes (ParameterMD, MapMD, ...) that have String value of the injectee class - if this value is set that's what we are looking for, else we go down the stack. But how to get the actual class - where to get ClassLoader? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3965419#3965419 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3965419

19 years, 7 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: Problem starting profiler

by rufik

Should I use this boundled zlib or from my linux distro? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3965415#3965415 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3965415

19 years, 7 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: Problem starting profiler

by rufik

compiling jvmti: ./compile.sh | ../native-src/jbossAgentJNI.cpp: In function `void | Java_org_jboss_profiler_jvmti_JVMTIInterface_notifyInventory(JNIEnv*, | _jobject*, unsigned char, _jstring*, _jstring*, _jobject*)': | ../native-src/jbossAgentJNI.cpp:814: warning: cast from pointer to integer of | different size | ../native-src/jbossAgentJNI.cpp: In function `_jstring* | Java_org_jboss_profiler_jvmti_JVMTIInterface_getMethodName(JNIEnv*, | _jobject*, long long int)': | ../native-src/jbossAgentJNI.cpp:920: warning: cast to pointer from integer of | different size | ../native-src/jbossAgentJNI.cpp: In function `_jstring* | Java_org_jboss_profiler_jvmti_JVMTIInterface_getMethodSignature(JNIEnv*, | _jobject*, long long int)': | ../native-src/jbossAgentJNI.cpp:941: warning: cast to pointer from integer of | different size | ../native-src/jbossAgentJNI.cpp: In function `_jclass* | Java_org_jboss_profiler_jvmti_JVMTIInterface_getMethodClass(JNIEnv*, | _jobject*, long long int)': | ../native-src/jbossAgentJNI.cpp:961: warning: cast to pointer from integer of | different size | compiling jvmpi with -Wall: ../src/jbossInspector.cc: In function `void writeHeader(signed char, jlong*, | jlong*, void*)': | ../src/jbossInspector.cc:622: warning: unused variable `jlong lastClock' | ../src/jbossInspector.cc: In function `void writeHeaderPadrao(signed char, | const jlong*, const jlong*, FILE*)': | ../src/jbossInspector.cc:643: warning: unused variable `jlong lastClock' | ../src/jbossInspector.cc: In function `void objectAlloc(JNIEnv*, _jobjectID*, | _jobjectID*, int)': | ../src/jbossInspector.cc:797: warning: unused variable `jint ret' | ../src/jbossInspector.cc:802: warning: unused variable `jint ret' | ../src/jbossInspector.cc: In function `void objectFree(JNIEnv*, _jobjectID*)': | ../src/jbossInspector.cc:837: warning: unused variable ` | ThreadHandler*threadHandler' | ../src/jbossInspector.cc: In function `void gcstart(JNIEnv*)': | ../src/jbossInspector.cc:853: warning: unused variable ` | ThreadHandler*threadHandler' | ../src/jbossInspector.cc: In function `void gcfinish(JNIEnv*)': | ../src/jbossInspector.cc:867: warning: unused variable ` | ThreadHandler*threadHandler' | ../src/jbossInspector.cc: In function `void enterMethod(JNIEnv*, _jmethodID*&, | _jobjectID*&)': | ../src/jbossInspector.cc:1231: warning: unused variable `jint ret' | ../src/jbossInspector.cc:1283: warning: unused variable `jint ret' | ../src/jbossInspector.cc:1236: warning: statement with no effect | ../src/jbossInspector.cc: In function `void exitMethod(JNIEnv*, _jmethodID*&)': | ../src/jbossInspector.cc:1327: warning: unused variable `jint ret' | ../src/jbossInspector.cc:1332: warning: statement with no effect | ../src/jbossInspector.cc: In function `jint JVM_OnLoad(JavaVM*, char*, void*)': | ../src/jbossInspector.cc:1791: warning: unused variable `int uniqueNames' | ../src/jbossInspector.cc: At top level: | ../src/jbossInspector.cc:442: warning: `long int maxSize' defined but not used | .so libraries are built. ldd libjbossInspector.so | linux-gate.so.1 => (0xffffe000) | libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xb7efb000) | libm.so.6 => /lib/tls/libm.so.6 (0xb7ed8000) | libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7ecf000) | libc.so.6 => /lib/tls/libc.so.6 (0xb7db5000) | /lib/ld-linux.so.2 (0x80000000) | but when .so moved to different directory, ldd shows "not a dynamic executable". View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3965414#3965414 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3965414

19 years, 7 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: late binding for sub processes

by tom.baeyens＠jboss.com

http://jira.jboss.com/jira/browse/JBPM-733 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3965408#3965408 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3965408

19 years, 7 months

1
0
0 / 0

[Design of JBoss jBPM] - late binding for sub processes

by tom.baeyens＠jboss.com

"Jeff" wrote : it | | appears to me that jBPM binds the sub-process at | | super-process deployment time, not at run-time as I would | | have expected. Late binding (aka dynamic subprocesses is a | | really nice feature of a sub-process. That way if the | | subprocess changes you get the latest version. | | | | Looking at how to implement it though is not trivial, the way | | the current classes are structured. SubProcessResolver takes | | an Element, and it is not straightforward to add an Element | | to the hibernate mapping. But in any case it is something we | | should look at doing. | makes definitely sense. it didn't fit my original picture where i thought that managing sub process bindings was something that only an operator could do explicitely. that's why it isn't there in the first place. david, managing sub process bindings is definitely something that would make sense in the admin concole. to implement it late binding, it only takes an extra field/column for the process name. and resolve the process at execute time, rather then at parse time. an extra attribute binding="late" should be added as well to maintain backwards compatibility. if you have a failing test case for this, please add it to the sources on HEAD. i'll make sure the test succeeds. should only require some small, local surgery to get this working. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3965407#3965407 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3965407

19 years, 7 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 August 2006