October 2008 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Remoting, Unified Invokers] - Re: Remoting 3: One-way requests are still the black sheep

by ron.sigal＠jboss.com

(1) and (2) aren't mutually exclusive. :) Unless (2) were "one-way requests ditched altogether". But I don't think we want to eliminate them. JBossMessaging, e.g., uses oneway sends. I think the choice should be (1) do it now, or (2) do it later. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183706#4183706 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183706

16 years, 3 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Remoting 3: One-way requests are still the black sheep

by david.lloyd＠jboss.com

If you're not familiar with the Remoting 3 API, none of this will make sense or it will not mean what you think. Fair warning given! :) One-way requests need to move off of Client on to their own thing or be dropped. They don't fit on Client - which has type parameters for the request and reply type for one thing. What kind of single request listener would support both two-way and one-way requests? What if there's confusion between the client and server as to whether it's a one-way or two-way request? The client might end up just hanging there waiting for a response which will never come, or the server might try to send a response to a one-way request, which will result in an exception, and the operation will never succeed (the server would abort the operation, though the client would never directly discover this). Yeah most of this stuff can be worked around. But I think it's a big red flag. There's a significant difference in semantics between one-way and two-way requests - the lightweight nature of one-way requests, relaxed delivery guarantees, the kinds of services invoked, etc. I think this merits its own division. I'd rather see one of two things happen: (1) one-way message clients split off into their own interface, with a corresponding split in the various intermediate request transmission types, all the way up to the final RequestListener; or (2) one-way requests ditched altogether until a later version. What do you think? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183703#4183703 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183703

16 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Expression Evaluation in ActionHandler Properties

by alex.guizar＠jboss.com

>From a SF developer's perspective, something like Sales-#{market} should evaluate to something like "Sales-London". If the JbpmExpressionEvaluator does not do it, then it probably should. This change could go in jBPM 3.3.0, tough we'd have to discuss the consequences. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183697#4183697 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183697

16 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Future of jBPM???

by koen.aers＠jboss.com

"keith" wrote : Also, will jBPM 3.5 or 4.0 move to Eclipse 3.4 from a tooling perspective? The latest release (3.1.4) of the GPD has been build and tested on Eclipse 3.4. Did you experience any problem with it? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183676#4183676 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183676

16 years, 3 months

1
0
0 / 0

[Design of Clustering on JBoss] - Re: HAJNDI access of NamingContext.localServer

by scott.stark＠jboss.org

Ok. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183663#4183663 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183663

16 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Future of jBPM???

by jbarrez

jBPM has wait states,human tasks, etc. for a very long long time now. In fact the concept of 'long running processes' is based upon this 'waiting'. I can assure you that the jBPM designers are constantly trying to build a better product. The last months were invested in reserch & design fo building jBPM, so that's why one would get the perception of idleness. But don't worry, we will al see signs of these investments in the coming months. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183655#4183655 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183655

16 years, 3 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Inconsistency in thirparty

by pgier

Ah sorry, I should have read your original post more carefully. It looks like a bug. I'll try to fix it and release a new version tomorrow. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183649#4183649 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183649

16 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Future of jBPM???

by keithnielsen

I have been researching both jBPM and Drools for sometime now and am wondering what the future holds for jBPM. This is based on my research of Drools 5, which is bringing what I would consider more BPM constructs into the core engine, things such as Wait States, Human Tasks, etc. One of the main things I don't see yet is the whole persistence and support of long running processes. My question is will the trend with Drools continue, eventually consuming jBPM? I must say that my perception is that Drools is more active which makes me wonder if I should go with Drools hoping that it builds out more BPM features going forward. Also, will jBPM 3.5 or 4.0 move to Eclipse 3.4 from a tooling perspective? Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183648#4183648 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183648

16 years, 3 months

1
0
0 / 0

[Design of Clustering on JBoss] - Re: HAJNDI access of NamingContext.localServer

by bstansberry＠jboss.com

Scott, I'd done JBAS-6023 (inject Naming into HA-JNDI) but it got reverted. I'm about to reapply it, but since your extract of the naming service from conf/jboss-service.xml isn't being reapplied, I'm now doing the injection from a legacy mbean rather than a pojo: <property name="localNamingInstance"><inject bean="jboss:service=NamingBeanImpl" property="namingInstance"/></property> If you ever redo the pojoization of the naming service, we'll need to change that to: <property name="localNamingInstance"><inject bean="LocalNamingBean" property="namingInstance"/></property> in the following files: cluster/src/etc/hajndi-jboss-beans.xml testsuite/src/resources/cluster/ejb2/passexp/partition-passexp-jboss-beans.xml testsuite/src/resources/cluster/partition/partition-restart-jboss-beans.xml View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183646#4183646 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183646

16 years, 3 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Inconsistency in thirparty

by bstansberry＠jboss.com

The problem I saw wasn't that the component-info wasn't updated, it was that the actual jar wasn't. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183623#4183623 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183623

16 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2008