[jBPM Development] - why jbpm5.3 usertask support only one incoming connection?
by gao haijun
gao haijun [https://community.jboss.org/people/vavi] created the discussion
"why jbpm5.3 usertask support only one incoming connection?"
To view the discussion, visit: https://community.jboss.org/message/741623#741623
--------------------------------------------------------------
I have a process, contains approve and reject. if reject,the process should return to usertask1.
if I write the process definition file using hand(without the eclipse plugin),it will throw a exception:
*ProcessLoadError: unable to parse xml : Exception class java.lang.IllegalArgumentException : This type of node cannot have more than one incoming connection!*
imo, what I said should be a *common request/case*.
so why jbpm5.3 usertask support only one incoming connection?
Hope someone can answer my question,thx a lot.
PS:the process difinition details:
<itemDefinition id="_conditionWhoItem" structureRef="Object" />
<itemDefinition id="_2-conditionWhoItem" structureRef="Object" />
<itemDefinition id="_4-conditionWhoItem" structureRef="Object" />
<itemDefinition id="_5-conditionWhoItem" structureRef="Object" />
<process processType="Private" isExecutable="true" id="com.sample.bpmn" name="Sample Process" tns:packageName="defaultPackage" >
<!-- process variables -->
<property id="conditionWho" itemSubjectRef="_conditionWhoItem"/>
<!-- nodes -->
<startEvent id="_1" name="StartProcess" />
<userTask id="_2" name="1" >
<ioSpecification>
<inputSet>
</inputSet>
<outputSet>
</outputSet>
</ioSpecification>
<potentialOwner>
<resourceAssignmentExpression>
<formalExpression>FME</formalExpression>
</resourceAssignmentExpression>
</potentialOwner>
</userTask>
<exclusiveGateway id="_3" name="Gateway" gatewayDirection="Diverging" />
<userTask id="_4" name="3" >
<ioSpecification>
<inputSet>
</inputSet>
<outputSet>
</outputSet>
</ioSpecification>
<potentialOwner>
<resourceAssignmentExpression>
<formalExpression>SLE2</formalExpression>
</resourceAssignmentExpression>
</potentialOwner>
</userTask>
<userTask id="_5" name="2" >
<ioSpecification>
<inputSet>
</inputSet>
<outputSet>
</outputSet>
</ioSpecification>
<potentialOwner>
<resourceAssignmentExpression>
<formalExpression>SLE1</formalExpression>
</resourceAssignmentExpression>
</potentialOwner>
</userTask>
<endEvent id="_6" name="End" >
<terminateEventDefinition/>
</endEvent>
<!-- connections -->
<sequenceFlow id="_5-_2" sourceRef="_5" targetRef="_2" />
<sequenceFlow id="_1-_2" sourceRef="_1" targetRef="_2" />
<sequenceFlow id="_2-_3" sourceRef="_2" targetRef="_3" />
<sequenceFlow id="_3-_4" sourceRef="_3" targetRef="_4" name="SLE2" >
<conditionExpression xsi:type="tFormalExpression" >return conditionWho == "SLE2";</conditionExpression>
</sequenceFlow>
<sequenceFlow id="_3-_5" sourceRef="_3" targetRef="_5" name="SLE1" >
<conditionExpression xsi:type="tFormalExpression" >return conditionWho == "SLE1";</conditionExpression>
</sequenceFlow>
<sequenceFlow id="_4-_6" sourceRef="_4" targetRef="_6" />
</process>
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/741623#741623]
Start a new discussion in jBPM Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 5 months
[JBoss AS 7 Development] - Server Instance Work directory
by Bernd Eckenfels
Bernd Eckenfels [https://community.jboss.org/people/b.eckenfels] created the discussion
"Server Instance Work directory"
To view the discussion, visit: https://community.jboss.org/message/751242#751242
--------------------------------------------------------------
Hello,
in domain mode (and standalone mode) the application servers are started in a way, that the base directory of the AS7 is the current working directory. This directory should not be writeable by a runtime user, and it is shared between multiple VMs. Some components (like some malconfigured libraries, native trace files) and even JVM diagnostics (hs_err files), dumps and even operating system (core)dumps are typically generated in this directory. (yes some of them can be configured to be generated somewhere else, on the other hand it would be good to have a sane default for that directory).
This is for 3 reasons a problem:
- no write permissions for runtime user (hopefully)
- shared between multiple vm instances
- not in a directory intended for modifications and high data volumes
- hard to find diagnostic files for a specific server instance
For this reason I see 3 possible methods, personally I typically use the first one:
a) start the application server instance with the server-specific log directory as current directory
b) start the application server instance with the server-specific data (or temp) directory as current directory
c) invent a new instance specific main directory
Using the log directory is most often the most sensible way, as it is sized to hold all kind of dumps+ diagnostics.
What do you think? In my case it is less imporatent for PC and HC, on the other hand it would not hurt to use the respective log firectories for those as well.
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/751242#751242]
Start a new discussion in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 6 months
[JBoss AS 7 Development] - ClientLoginModule support
by Tarek Hammoud
Tarek Hammoud [https://community.jboss.org/people/thammoud] created the discussion
"ClientLoginModule support"
To view the discussion, visit: https://community.jboss.org/message/750773#750773
--------------------------------------------------------------
Hello,
We are migrating from JBOSS 4.x to 7.1.1. A client is trying to access a remote EJB. Previously, code like below worked by propogating the credentials to the server:
LoginContext lc = new LoginContext("client-login", new UsernamePasswordHandler(userName, password.toCharArray()));
lc.login();
....
InitialContext ctx = new InitialContext(...);
Server s = ctx.lookup();
s.invoke();
With 7.1.1, we are basically doing the same:
LoginContext lc = new LoginContext("client-login", new UsernamePasswordHandler(userName, password.toCharArray()));
lc.login();
......
jndiProps.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
jndiProps.put("jboss.naming.client.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT", "false");
jndiProps.put("jboss.naming.client.ejb.context", true);
jndiProps.put("jboss.naming.client.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS", "JBOSS-LOCAL-USER");
Context ctx = new InitialContext(jndiProps); *<<=== Throws exception*
Caused by: javax.security.sasl.SaslException: Cannot get userid/password [Caused by javax.security.auth.callback.UnsupportedCallbackException]
at com.sun.security.sasl.ClientFactoryImpl.getUserInfo(ClientFactoryImpl.java:157)
at com.sun.security.sasl.ClientFactoryImpl.createSaslClient(ClientFactoryImpl.java:94)
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities$1.run(ClientConnectionOpenListener.java:352)
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities$1.run(ClientConnectionOpenListener.java:350)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:350)
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:214)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333)
at org.jboss.naming.remote.client.EndpointCache$EndpointWrapper.connect(EndpointCache.java:105)
at org.jboss.naming.remote.client.NamingStoreCache.getRemoteNamingStore(NamingStoreCache.java:55)
... 8 more
We would like to avoid having to sepcify the credentials as part of the InitialContext properties. Any help will be greatly appreciated.
Thank you
Tarek Hammoud
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/750773#750773]
Start a new discussion in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 6 months
[JBoss AS 7 Development] - Re: CLI non-interactive mode improvements
by Alexey Loubyansky
Alexey Loubyansky [https://community.jboss.org/people/aloubyansky] created the discussion
"Re: CLI non-interactive mode improvements"
To view the discussion, visit: https://community.jboss.org/message/714239#714239
--------------------------------------------------------------
About the environment properties, makes sense. Although, I think it's a different issue from interactive value prompting.
While conditions and force are interesting features, you can achieve repeatable script executions by using batches which make a script an atomic action, i.e. everything in the script will be applied or rolled back.
The force in the suggested form (for operations especially) won't be implemented. For some commands, perhaps. In general, though, I, personally, don't like the idea... but I see your point. Conditions are interesting.
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/714239#714239]
Start a new discussion in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 6 months