[Design of JBoss Build System] - Re: maven.opts for building thirdparty module
by jaikiran
That partially helped me solve the issue. Using
./build.sh -Dmaven.opts="-Dskip-download-sources -Dversion.org.jboss.ejb3=1.1.7 -Dversion.org.jboss.ejb3.common.client=1.0.0
| -Dversion.org.jboss.ejb3.core.client=1.1.7 -Dversion.org.jboss.ejb3.proxy.client=1.0.1 -Dversion.org.jboss.ejb3.proxy.clustered.client=1.0.1 -Dversion.org.jboss.ejb3.security.client=1.0.0"
|
from the root of trunk does let these properties be visible to the thirdparty task which generates the correct component-info.xml in the thirdparty/jboss/jboss-ejb3-core:
| <?xml version="1.0" encoding="UTF-8"?>
| <project name="">
| <component id="jboss/jboss-ejb3-core"
| licenseType=""
| version="1.1.7"
| description=""
|
| >
|
| <artifact id="jboss-ejb3-core.jar"/>
| <artifact id="jboss-ejb3-core-client.jar"/>
|
|
| <export>
| <include input="jboss-ejb3-core-client.jar"/>
| <include input="jboss-ejb3-core.jar"/>
|
| </export>
| </component>
| </project>
However when the AS is being bundled through "jboss-as-build", internally the maven:dependencies task is triggered:
| <target name="init-thirdparty-dependencies" depends="init"
| description="Initialize thirdparty dependency configuration">
| <!--
| - Initialize properties for each dependency in the thirdparty pom
| - The properties take the form "groupId:artifactId:packaging"
| -->
| <maven:dependencies filesetId="pom.dependencies"
| versionsId="pom.dependencies.versions"
| scopes="compile, runtime" type="pom, jar, zip, war"
| addArtifactFileSetRefs="true">
| <pom file="../thirdparty/pom.xml"/>
| </maven:dependencies>
| ...
which does not seem to honour the system properties being passed. Internally the maven:dependencies ant task creates a dependency set for the pom, based on what is specified in the component-matrix pom.xml (i.e. a different version 1.1.6 of org.jboss.ejb3:jboss-ejb3-core). This ultimately leads in the AS distribution containing 1.1.6 version of ejb3-core in the common/lib.
Just pinged on #maven to get some info on the maven ant-tasks project's DependenciesTask, related to system properties handling:
| (02:29:01 IST) Jaikiran: anyone here knows about maven ant-tasks project?
| (02:29:18 IST) Jaikiran: specifically the DependenciesTask http://svn.apache.org/repos/asf/maven/ant-tasks/tags/maven-ant-tasks-2.0....
| (02:30:05 IST) ***brett does, but is stepping out
| (02:30:08 IST) brett: just ask and try your luck
| (02:31:16 IST) Jaikiran: actually i have trying to get that task working by specifying system properties like -Dversion.groupid.artifactid=123
| (02:33:20 IST) Jaikiran: the pom.xml contains:
| (02:33:21 IST) Jaikiran: <properties>
| (02:33:21 IST) Jaikiran: <version.groupid.artifactid>122</version.groupid.artifactid>
| (02:33:21 IST) Jaikiran: </properties>
| (02:33:21 IST) Jaikiran: <dependency>
| (02:33:21 IST) Jaikiran: <version>${version.groupid.artifactid}</version>
| (02:33:21 IST) Jaikiran: </dependency>
| (02:33:45 IST) Jaikiran: the dependenciestask always keeps using 122 instead of the 123 version passed as system property
| (02:34:16 IST) Jaikiran: was looking for information on whether the dependenciestask is expected to consider the system properties during version resolution
| (02:39:25 IST) i386 left the room (quit: i386).
| (02:43:55 IST) tobrien left the room (quit: tobrien).
| (02:44:04 IST) b0fh left the room (quit: "leaving").
| (02:45:24 IST) mkleint: jaikiran: i doubt resolving from the repository takes System props into account..
| (02:46:39 IST) Jaikiran: mkleint: hmm, that's a bummer :(
Paul, do you see any different way we can handle this?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237826#4237826
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237826
16 years, 9 months
[Design of JBoss ESB] - Re: Problems with transmitting content from ESB to jBPM via
by Kevin.Conner＠jboss.com
"andreskusa" wrote : p1. The EsbActionHandler copies the necesary information into the replyTo-EPR of message.header.call, but BpmCallback expects this information at the to-EPR.
This is correct. The invocations from EsbActionHandler are sending messages to a target service (the To EPR) and also including the necessary information for replying (the ReplyTo EPR).
"andreskusa" wrote : So, even if you stay inside jBPM/ESB (i.e., if jBPM starts a service that immediately calls the BpmCallback action) you need to copy the replyTo-EPR to the To-EPR.
But jBPM should not be invoking the reply service, it should be invoking another service which then sends its reply to the callback service. The processing of a RequestResponse mep in the pipeline will send a response to the ReplyTo EPR and, in this way, we are no different from specs such as WS-Addressing.
"andreskusa" wrote : p2. This is not really a problem, but merely the fact that if you "leave" the ESB as I described in a. to c. above, you need to get the process information from the message leaving the ESB and set it into the new message (at Header.Call.setTo of course) entering again the ESB and attempting to call back the running jBPM problem. That is why I need to create an EPR. But this works without problems.
Okay, that explains things. It is the correlation between the internal EPR and external services that we are currently missing.
"andreskusa" wrote : Regarding the variable mappings it is like that I know now that these are also to be copied with the other process information (like tokenId etc.). But I need also specify it at all the places I described above (a-c). From your post I understand that you think that it is sufficient to define both mappings (esbToBpmVars and bpmToEsbVars) only at the start of the jBPM process, but this is definitely not the case
No, they need to be specified on every node that communicates with the ESB. They define the variables which are specific to that invocation and are not specified globally on the process.
"andreskusa" wrote : I just tested it again. Both mappings need to be specified in all jBPM nodes that leave jBPM into the ESB. If I leave out the bpmToEsb mapping, the changes done inside jPBM are not transimitted to the ESB and if I leave out the esbToBpmVars mapping at this place, the changes in the data done in the ESB are not transferred back to jBPM.
This is correct.
"andreskusa" wrote : So, the only things I would recommend are to document BpmCallback a bit better if this is really the preferred way for combining jBPM and the ESB. And maybe to get the information from replyTo, where it is already copied to. Then BpmCallback would be more intuitive to use.
One thing that would also help would be to remove the variable mapping and scope from the EPR as there is no real need for this to be included in the information sent back to the callback service. They can be retrieved automatically from the process definition.
"andreskusa" wrote : One additional thing: I figured out that if you immediately call back the jBPM process after leaving it, (or if you start several times the same process) you need to have a short stop time in between (e.g., Thread.sleep(10) is enough) in order to have jBPM up and ready. If the calls are too fast, the token is still locked. Maybe such a small pause could be included into the call back.
This is strange, the messages should be covered by a transaction and sent on the transaction boundary. Can you send me an example of this?
"andreskusa" wrote : Hope, you understand my setting better and these explanations were not too exhaustive ... :-)
I have a much better understanding, thanks for this.
Kev
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237822#4237822
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237822
16 years, 9 months
[Design of JBoss jBPM] - Re: GroupId or (groupName & GroupType)
by kukeltje
"jeff.yuchang" wrote :
| in this case, the groupId format is maintained by jBPM, and not identity component dependent. so if users/developers switch to other identity provider, they must conform this rule.
|
| In this case, we don't need to make any changes, the only one thing is just to document it?
|
| What do you think?
|
I don't think large (or even small) companies are going to switch to adapting their IDM (or more complex IAM systems) to conform to this jBPM requirement. No way. A real life example:
In an LDAP we used, the groupname was the CN, the real id is the DN, which was composed of the CN, O and C filed. How could this be adapted to the jBPM id format. In addition.
In another situation there was an additional OU in between which could also be used as a group when the users below the OU are seen as part of the group. How would the 'id' fit in here?
Would be nice if this is fully left to the users if they choose to put e.g. a DN in the assignment or an LDAP filter or maybe even an SQL statement, so consider it as a string and do not impose any rules on the formatting. For the JBoss IDM implementation there are the 'rules' but that is just for this implementation and should not impose any constraints on possible other implementations.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237819#4237819
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237819
16 years, 9 months
[Design of JBoss jBPM] - Re: GroupId or (groupName & GroupType)
by jeff.yuchang
"tom.baeyens(a)jboss.com" wrote : "jbpid_group_id_._._unit_._._sales-dept" is a very nasty id that you generate.
|
| so the real point is actually: shouldn't we switch to user-provided id's for the groups as well. just like we do with the users ?
|
| what was the reason that we didn't do that ?
I think we can have an approach to this issue.
we will use what it uses for groupId, candidate-group now. but we need to document the format for this groupId:
it is:
| String groupId = groupType != null ? groupType + "." + groupName : groupName;
|
in this case, the groupId format is maintained by jBPM, and not identity component dependent. so if users/developers switch to other identity provider, they must conform this rule.
In this case, we don't need to make any changes, the only one thing is just to document it?
What do you think?
-Jeff
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237811#4237811
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237811
16 years, 9 months
[Design of JBoss ESB] - Re: Problems with transmitting content from ESB to jBPM via
by andreskusa
Hi Kevin,
thanks for coming in into this discussion!
Let me first just briefly explain what I'm generally doing: I'm using the JBoss AS, ESB and jBPM. In the AS there are some EJBs sending messages into one central ESB gateway queue and retrieving messages from other JMS queues (not ESB aware). So the process is like that:
a. the ESB retrieves a message that starts the jBPM process with the ESB action/property BpmProcessor/StartProcessInstanceCommand. Also I add here the esbToBpmVars
b. In the jBPM process I jump back to the ESB with the ESBActionHandler. Here I need to specify the esbToBpmVars again as well as the bpmToEsbVars for transporting the changed variables into the ESB.
c. Back in the ESB I'm sending a message to an "outside" ordinary JMS queue (i.e., not ESB aware). This is retrieved by one of the EJBs and at one later point in time (i.e, completely asynchronous) this EJB sends again a message to the ESB gateway, which now does of course not start again the jBPM process, but should be able to jump back to the still running process.
In order to realize espcially c, I had to look for a method to jump back. For now we're still using ESB 4.4, but of course don't want to apply methods that won't be available in future. Since I read in the blog of Bernd that this is the case for the ESB action/command BpmProcessor/SignalCommand, I tried to use BpmCallback.
It is true that the necessary process information to get back via BpmCallback is copied into the message header when leaving jBPM with the EsbActionHandler. But there are two problems with it:
p1. The EsbActionHandler copies the necesary information into the replyTo-EPR of message.header.call, but BpmCallback expects this information at the to-EPR. I found this in the code of BpmCallback:
| EPR toEpr = message.getHeader().getCall().getTo();
|
e.g. at
http://anonsvn.labs.jboss.com/labs/jbossesb/tags/JBESB_4_2_1_GA_CP_IR9/pr...
or
http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/services/jbpm/s...
So, even if you stay inside jBPM/ESB (i.e., if jBPM starts a service that immediately calls the BpmCallback action) you need to copy the replyTo-EPR to the To-EPR.
p2. This is not really a problem, but merely the fact that if you "leave" the ESB as I described in a. to c. above, you need to get the process information from the message leaving the ESB and set it into the new message (at Header.Call.setTo of course) entering again the ESB and attempting to call back the running jBPM problem. That is why I need to create an EPR. But this works without problems.
Also it is no real problem to go around p1 by copying the information to the expected destination, although it is a bit tricky to figure out ...
Regarding the variable mappings it is like that I know now that these are also to be copied with the other process information (like tokenId etc.). But I need also specify it at all the places I described above (a-c). From your post I understand that you think that it is sufficient to define both mappings (esbToBpmVars and bpmToEsbVars) only at the start of the jBPM process, but this is definitely not the case, I just tested it again. Both mappings need to be specified in all jBPM nodes that leave jBPM into the ESB. If I leave out the bpmToEsb mapping, the changes done inside jPBM are not transimitted to the ESB and if I leave out the esbToBpmVars mapping at this place, the changes in the data done in the ESB are not transferred back to jBPM.
But again, also this is not problematic as you know how to do it :-).
So, the only things I would recommend are to document BpmCallback a bit better if this is really the preferred way for combining jBPM and the ESB. And maybe to get the information from replyTo, where it is already copied to. Then BpmCallback would be more intuitive to use.
One additional thing: I figured out that if you immediately call back the jBPM process after leaving it, (or if you start several times the same process) you need to have a short stop time in between (e.g., Thread.sleep(10) is enough) in order to have jBPM up and ready. If the calls are too fast, the token is still locked. Maybe such a small pause could be included into the call back.
Hope, you understand my setting better and these explanations were not too exhaustive ... :-)
Cheers,
Andre
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237807#4237807
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237807
16 years, 9 months