[jBPM] New message: "Re: JBPM4.3 should be JBPM5.0"
by Ronald van Kuijk
User development,
A new message was posted in the thread "JBPM4.3 should be JBPM5.0":
http://community.jboss.org/message/523229#523229
Author : Ronald van Kuijk
Profile : http://community.jboss.org/people/kukeltje
Message:
--------------------------------------------------------------
hahaha, yes I was aware that you were promoting jBPM. The only thing is that your post came out of the blue. It looks like a response to something that is not there.
But regarding your statement, let me tell you why I disagree.
* BPMN is in incubation.* It is not by a long shot as stable (and spec tested) as jPDL is.
* Only a subset of BPMN2 is implemented (expect more in 4.4)
* JPDL in jBPM 4 has a lot of room for improvment (see the Jira)
* History stuff
* additional fork (for-each)
* lots of small (not so less visible) improve
* ID generator issue
* Task closing issues
Regarding the releases, the choice was made to have periodical releases so users can depend on that. So expect 4.4 not to be far around the corner. The version where we think BPMN implementation is stable might become jBPM 5 Since the BPMN 2 spec is not even finalized yet, it is not valid to make jBPM already a 5 version (but thanks for the compliment....)
Regarding the spring issue, discuss it in the forum and check if there are already Jira issues for it. If not make them after discussing it in the forum first. If there is one, vote for it to give it a 'higher priority' (no guarantee)
Cheers,
Ronald
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/523229#523229
14 years, 7 months
[jBPM] New message: "Re: JBPM 4.3 EL cannot read process property with null value"
by Ronald van Kuijk
User development,
A new message was posted in the thread "JBPM 4.3 EL cannot read process property with null value":
http://community.jboss.org/message/523228#523228
Author : Ronald van Kuijk
Profile : http://community.jboss.org/people/kukeltje
Message:
--------------------------------------------------------------
What I meant whas that you could have put whatever variable name in the check, it always returns null, even if the variable is not threre at all. Sorry if I formulated that wrongly.
So the current behaviour is:
|| *Case* || *Java* || *EL* ||
| var exists and has a non-null value | value | value |
| var exists and has value of 'null' | null | fails |
| var does not exists | null | fails |
This should at be identical I think, at least for the case where the variable exists. I created a little patch that solves this (all unit tests still are green). If you file a jira issue about this, I'll attach the patch to it that make EL return null if the variable exists but has a value of null. It does make the last case identical (not it should, and if it should, shoud it fail? or should EL also return null?) Ask that in the Jira issue to.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/523228#523228
14 years, 7 months
[JBoss Cache] New message: "Re: Jboss Cache clustering in standalone mode"
by Taran Sodhi
User development,
A new message was posted in the thread "Jboss Cache clustering in standalone mode":
http://community.jboss.org/message/523224#523224
Author : Taran Sodhi
Profile : http://community.jboss.org/people/dony908
Message:
--------------------------------------------------------------
Thanks, I could see both caches in cluster, as I can put an object and retrieve from another after replication.I have same configuration file for each instance of JBoss cache hosted outside JBoss EAP.
But I would like to know how merely having same cluster name for cache can cause 2 seperate instances of cache hosted on seperate boxes talk to each other. Is it something due to JBoss server being started in clustering mode, but remember my cache application is hosted outside EAP as above and it also doesn't have same cluster name as JBoss server. I'm newbie in this field and any pointers are highly appreciated.
Many thx in advance,
Regards,
TS
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/523224#523224
14 years, 7 months
[jBPM] New message: "Re: JBPM 4.3 EL cannot read process property with null value"
by Ronald van Kuijk
User development,
A new message was posted in the thread "JBPM 4.3 EL cannot read process property with null value":
http://community.jboss.org/message/523219#523219
Author : Ronald van Kuijk
Profile : http://community.jboss.org/people/kukeltje
Message:
--------------------------------------------------------------
In your test I see no test for this. In fact, the difference between a non-existent variable and one with the value of 'null' is none when retrieving from java. The executionService.getVariable(pi.getId(), "NoneExistentVariable") returns null as well, so null is seen by jBPM as 'none existent'. That is basically the bottom line. I'll try to find out more.So it is not that retrieving the value of a variable with null succeeds ;-)
Regarding your test, you can even reduce more. if you use the deployment method in JbpmTestCase, the teardown of the super class does the undeploy automagicallly. And there are also interesting additional assertions.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/523219#523219
14 years, 7 months
[EJB 3.0 Development] New message: "Re: Externalizing Scope: Resolving EJB References and Endpoints"
by Pete Muir
User development,
A new message was posted in the thread "Externalizing Scope: Resolving EJB References and Endpoints":
http://community.jboss.org/message/523217#523217
Author : Pete Muir
Profile : http://community.jboss.org/people/petemuir
Message:
--------------------------------------------------------------
The motivation for this is to allow Weld to cluster with EJBs in JBoss AS - currently it won't work.
CDI specifies the session and conversations contexts as being passivation capable, both of which are ultimately backed by the HTTP session. The appraoch Weld uses with Managed Beans is to put an object into the HTTP session which references both the Bean (the metadata) and the contextual instance. We take the same approach with EJBs - except that in this case the contextual instance contains not the "real" instance, but a SessionObjectReference which Weld uses to retrieve the underly EJB.
I'm not fussed how we solve this problem, whether by changing the way Weld works, or adding something to EJB 3. I don't have a good idea how to change this in Weld tho ;-)
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/523217#523217
14 years, 7 months