[jBPM Development] - JBPM Custom Editor ----- For parameter mapping
by ashish totade
ashish totade [http://community.jboss.org/people/ashpcs] created the discussion
"JBPM Custom Editor ----- For parameter mapping"
To view the discussion, visit: http://community.jboss.org/message/629390#629390
--------------------------------------------------------------
Hi All,
I am currently facing a problem in custom editor.
I want to create a custom task editor where user should be able to do parameter mapping similar to whats shown in prperties tab.
The current dialog from properties section ask user both parameter and process variable. I want to create a custom editor where I will show use parameter and user needs to select process varia ble from list,
It seems that I can take only Work and workdefinition in custom editor. I have looked into the *org.drools.eclipse.flow.ruleflow.view.property.workitem.WorkItemParameterMappingDialog* and feel that workItemNode used in that class should do the trick.
Is there any way to get *org.jbpm.workflow.core.node.workItemNode* in custom editor*?*
Regards,
Ashish
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/629390#629390]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
12 years, 6 months
[jBPM Development] - Re: Oryx: Not able parse the knowledge when adding Message Events or Send Task Node
by uvijayreddy657
uvijayreddy657 [http://community.jboss.org/people/uvijayreddy657] created the discussion
"Re: Oryx: Not able parse the knowledge when adding Message Events or Send Task Node"
To view the discussion, visit: http://community.jboss.org/message/630018#630018
--------------------------------------------------------------
Tihomir,
I tried with the both latest wars designer-1.0.0.055-jboss.war and guvnor-distribution-5.3.0.CR1.war.
*Now I am not getting exception for Message Intermediate Event.* But when adding "Send Task" node getting the following exception.
For Send Task Node:
java.lang.IllegalArgumentException: No messages found
at org.jbpm.bpmn2.xml.SendTaskHandler.handleNode(SendTaskHandler.java:50)
at org.jbpm.bpmn2.xml.TaskHandler.end(TaskHandler.java:188)
at org.drools.xml.ExtensibleXmlParser.endElement(ExtensibleXmlParser.java:414)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:601)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.endElement(XMLSchemaValidator.java:795)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1772)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2923)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:645)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:508)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:807)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:395)
at org.drools.xml.ExtensibleXmlParser.read(ExtensibleXmlParser.java:293)
at org.drools.xml.ExtensibleXmlParser.read(ExtensibleXmlParser.java:172)
at org.jbpm.compiler.xml.XmlProcessReader.read(XmlProcessReader.java:46)
at org.jbpm.compiler.ProcessBuilderImpl.addProcessFromXml(ProcessBuilderImpl.java:249)
at org.drools.compiler.PackageBuilder.addProcessFromXml(PackageBuilder.java:516)
at org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:560)
at org.drools.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:28)
at com.emirates.sds.workflow.mbean.CWorkflowDesignerMBean.getWFProcessNodesList(CWorkflowDesignerMBean.java:279)
at com.emirates.sds.workflow.mbean.CWorkflowDesignerMBean.getProcessNodesList(CWorkflowDesignerMBean.java:1071)
at com.emirates.sds.workflow.mbean.CWorkflowDesignerMBean.mapForms(CWorkflowDesignerMBean.java:249)
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.apache.el.parser.AstValue.invoke(AstValue.java:172)
at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
at com.sun.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:68)
at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:84)
at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:98)
at javax.faces.component.UICommand.broadcast(UICommand.java:311)
at org.ajax4jsf.component.AjaxActionComponent.broadcast(AjaxActionComponent.java:55)
at org.ajax4jsf.component.AjaxViewRoot.processEvents(AjaxViewRoot.java:329)
at org.ajax4jsf.component.AjaxViewRoot.broadcastEventsForPhase(AjaxViewRoot.java:304)
at org.ajax4jsf.component.AjaxViewRoot.processPhase(AjaxViewRoot.java:261)
at org.ajax4jsf.component.AjaxViewRoot.processApplication(AjaxViewRoot.java:474)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:77)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:97)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:114)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:308)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:206)
at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:388)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:515)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:349)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:619)
org.drools.compiler.ProcessLoadError: unable to parse xml : Exception class java.lang.IllegalArgumentException : No messages found
Thanks for your quick replies.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/630018#630018]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
12 years, 6 months
[JBoss Transactions Development] - Re: Remote txinflow: XID changes
by David Lloyd
David Lloyd [http://community.jboss.org/people/dmlloyd] created the discussion
"Re: Remote txinflow: XID changes"
To view the discussion, visit: http://community.jboss.org/message/630596#630596
--------------------------------------------------------------
> Tom Jenkinson wrote:
>
> Certainly we are adding this for remoting in the first instance so we want it to play nicely with that!
>
> One issue is the diamond question, e.g.
>
> -> TM2
> TM1 -> TM4
> -> TM3
>
>
> If we don't know the parent then both TM2 and TM3 will potentially try to recover TM4 for all indoubt transactions related to transactions initiated at TM1 which will have undesirable recovery results.
Okay that makes sense, though isn't the parent info in the gtid?
> Tom Jenkinson wrote:
>
> The other point is the bqual must have the EIS (JNDI) name in it as we have had introduced this functionality for customers before to assist them in debugging transaction related issues so we would definitely need to maintain this. That said, you were able to get 600 resources into 3 bytes (out of the 64 available) so I dont anticipate leaving space for the name being an issue (so long as we have a delimiter).
Ah okay. It seems odd to me not to have that info just in the gtid - I suppose it's a space issue at that point?
> Tom Jenkinson wrote:
>
> Finally, I maybe am not understanding your proposal correctly, a worked example would help. What I can't quite understand is how the address space of the bqual will work in a pyramid.
>
> e.g:
> -> TM2 -> RM1
> TM1 -> TM3 -> RM2
> -> RM3
>
> Can you let me know what the resource number of each of the TMs and RMs are in that picture so I can understand a little more clearly?
I think it would be like this:
* TM1->TM2: *0001* 0000
* TM2->RM1: *0001 0001*
* TM1->TM3: *0010* 0000
* TM3->RM2: *0010 0001*
* TM1->RM3: *0011* 0000
The 0000 are there to pad it out to a byte. Though this isn't actually a diamond. Trying out a couple more just for the exercise...
In your top diamond where there are just four TMs in a diamond...
* TM2's prefix is 0001
* TM3's prefix is 0010
* TM4's prefix depends on whether TM2 or TM3 inflowed the work in question, it could be 0001 0001 or 0010 0001.
> Tom Jenkinson wrote:
>
> Also, even with a solution to the diamond/pyramid approach (which I guess is achieved because you pack the history into the bqual) for an example such as: 1000 0000 1000 0000, how would I know whether or not this was a sequence of two sevens, and not 712 (comprised of 128 for the binary +1 for the algorithm, +528 for the start of the range).
>
> With our proposed approach you do not need to maintain the history of nodes in the bqual as this can be determined from the top-down recovery scanning of parent/child node names packed in the bqual resulting in a constant space use in the bqual of two ints.
>
> Can we restrict the remoting node names down to values that can be converted uniquely to an int ;)
Two sevens would be: 1000 0000 1000 0000, whereas 712 would be: 1110 0000 1000 0001
The number of leading '1' bits tells you how many additional nybbles to read. Put another way:
* 0xxx
* 10xx xxxx
* 110x xxxx xxxx
* 1110 xxxx xxxx xxxx
* 1111 0xxx xxxx xxxx xxxx
* 1111 10xx xxxx xxxx xxxx xxxx
etc., thus every sequence is unique, and every row has 8 times more possible values than the previous row.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/630596#630596]
Start a new discussion in JBoss Transactions Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
12 years, 6 months
[JBoss AS7 Development] - Module Compatible Classloading Guide
by Jason Greene
Jason Greene [http://community.jboss.org/people/jason.greene] modified the document:
"Module Compatible Classloading Guide"
To view the document, visit: http://community.jboss.org/docs/DOC-16701
--------------------------------------------------------------
h3. Introduction
Modular classloading has a much greater focus on isolation and separation than traditional heirarchical models, so it is far less forgiving about using the "wrong" classloader. Unfortunately, this means that any dynamic classloading code you have written in the past may need to be updated to play nicely in a modular environment. However, the good news is that code that is module compatible is more correct, and therefore less error prone in traditional environments. This article provides some background infromation along with some pointers on how to make this transition.
h3. Common Terms
This article assumes that the following terms are well understood.
*Defining Classloade*r - The classloader which loaded the calling class. This is what is used when you use Class.forName() without specifying a classloader. It's also what loads classes that you reference statically (e.g. via an import). It can be obtained by calling *getClass().getClassLoader()* on the respective class.
*Thread Context Classloader (TCCL)* - The classloader which has been assigned to the calling thread. It's meaning is specific to the environment it was assigned in. In Java EE code, the TCCL is always the classloader of the relevant deployment. *+The TCCL is the most commonly misused classloader.+*
*Dynamic Classloading* - Loading a class by name using a ClassLoader. This is typically used for pluggable architectures that discover some kind of extension. An example is an API framework that supports multiple implementations/providers (e.g. JAXP). It dynamically loads the provider by name using some kind of service discovery mechanism (a file in META-INF/services, a system property, etc). Another example is application server code which needs to operate against a deployment's classes. Since they are logically isolated, and may even be hot-deployed, static linking (imports) can not be used.
*JDK Service Provider Loading* - The common pattern used by Java SE and Java EE frameworks to load different providers / implementations of an API. This is done by checking a system property, a special properties file, and more commonly looking for files in META-INF/services. See the http://download.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html ServiceLoader javadoc for more info on how the process works.
*Module* - A single consistent class loading namespace. It encompases classes/resources directly available in the module (contents of one or more jar(s)) local to the module, as well as all module dependencies defined on the module. Every module has it's own ClassLoader which it uses to load all classes that can be loaded from the module.
*Deployment* - A deployment is a user provided package of components. In AS7, every deployment has a Module. In some cases a deployment may contain nested deployments or other artifacts. Those are often represented by a module of their own.
*System Classloader* - Also commonly referred to as the "application classloader". It represents everything that is defined on java.class.path, and commonly includes java extensions and some jdk classes.
h3. Picking the "Right" Classloader
The key to loading classes in a modular environment is to use the correct classloader. In the past many frameworks, including many Java standard APIs, expect that the users classes (or the deployment classes) and the framework classes are accessible via the same classloader.* +The problem with this assumption is that it prevents proper isolation of the framework implementation classes and a user's classes.+* In many cases though it would work in a heirarchical model (as long as there was no name conflicts), since class sharing is done by inheritance rather than explicit links as is the case in a modular environment. This single bad assumption makes it impossible to achieve capabilities like allowing a user to use their own XML parser.
The correct way to pick a ClassLoader is to always use the one that is directly associated with the class you are trying to load. So if a framework wants to load a class from one of it's dependencies +*then it should use it's defining classloader.*+ Likewise, If the framework wants to load a class from a deployment, then it should use the deployment's classloader. In some cases, like in the case of service provider discovery, a framework might want to look for a particular resource in both it's classloader (say a default provider), and the user Classloader. Under this scenario the framework should check both ClassLoaders following the order that best suits it's needs.
h3. *FRAMEWORKS, NEVER LOAD YOUR CLASSES FROM THE TCCL!!*
If you expect portability between different classloading environments, it is always wrong for a framework to load it's classes from the TCCL. +*Instead use the right classloader, which is most often the defining classloader.*+ If the defining classloader is not the right classloader, then look for a way to get the right loader and use it to load classes. Even if you have an inheritance model with a heirarchy that sees the classes you want, it is always more correct to pick the classloader that "owns" the classes.
The TCCL should be used with extreme care. EE code is required to see the defining deployments classloader as the TCCL. Beware though that other frameworks may have different rules, and may set it to another value when executing in their context. I+*f you have access to the classloader you want it's always better to use it over the TCCL.*+
Note that AS7 subsystems that are executing within any kind of EE context can safely asssume that the TCCL will point to the deployment classloader. They should, however, never attempt to load AS7 code from the deployment classloader.
h3. What To Export/Expose
The only thing that a module should ever expose is classes that make up it's API contracts. In most cases this means that an AS7 module should not export it's dependencies. This allows for the module and it's calling module to use completely different versions of the same dependency. Deployments can, for example, use commons-bah 1.2 and AS7 code can happily use commons-blah 1.0.
h3. How to deal with "Bad" dependencies
If your module/deployment/framework depends on something that isn't compatible with a modular environment. Then you have a couple of options that may workaround the issue. However in some cases the only workable solution is to patch the bad framework.
Common workarounds include:
* *Swapping TCCL* - If a call to a framework method incorrectly uses the TCCL to load it's classes/resources, and the same call does not need to see deployment classes, then temporarily set the TCCL to the framework's defining classloader. (e.g. Thread.currentThread().setContextClassLoader(frameworkClass.getClass().getClassLoader()
* *Prefer calls which have a CL argument* - If you can pass a classloader, prefer that to calls which try to guess (usually picking the TCCL) if possible.
* *Heirarchical Emulation -* This is a worst case workaround that should only be used as a last resort. In the unfortunate case where a framework expects both deployment classes and it's own classes to be on the same classloader, a custom classloader can be created which delegates first to the deployment classsloader and second to frameworks defining classloader. This classloader can the be swapped to the TCCL as described above, or somehow passed to the framework via a mechnism it exposes. This has the undesirable effect of a possible conflict between a user's implementation choices and the frameworks. However, it at least does not pollute the deployment module.
If you have a bad dependency then file a bug to get it fixed/replaced. In particularly if you have to use heirarchical emulation.
h3. How to use JAXP and other service provider APIs from AS/Framework code
EE applications can safely use the no-arg newInstance() methods provided by JAXP. However framework code must either not use them, or use the swapping TCCL workaround described in the "bad" dependencies section above. This ensures that either the container's xml parser is used or the parser explictly imported by the frameworks module (requires a service import). Not doing this will result in the deployments xml parser being used (since the deployment CL is often the TCCL), which may be incompatible.
The following is an example of setting the TCCL to the framework's defining classloader. It's recommended to create a simple utility method for every occurence of this in your framework.
public static DocumentBuilderFactory createDocumentBuilderFactory() {
ClassLoader cl = Thread.currentThread().getContextClassLoader();
DocumentBuilderFactory factory;
try {
Thread.currentThread().setContextClassLoader(Util.class.getClassLoader());
factory = DocumentBuilderFactory.newInstance();
} finally {
Thread.currentThread().setContextClassLoader(cl);
}
return factory;
}
h3. Serialization
See the aritcle on http://community.jboss.org/docs/DOC-17244 Modular Serialization.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16701]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
12 years, 6 months