February 2009 - jboss-dev-forums - Jboss List Archives

[Design of JBoss jBPM] - Re: Command implementation as part of public API

by heiko.braun＠jboss.com

anonymous wrote : | The second: Isn't that code already implementation specific? | Yes it is. But it's very likely that people will work with those commands. And if we publish the CommandExecutor (i.e. EJB) then need to give ammunition to it as well, don't you think? Hence my question in the first place. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4208228#4208228 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4208228

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: Command implementation as part of public API

by camunda

Wait a second: The one Command-Interface goes in the API or all Command-Implementations? The first: Sure! The second: Isn't that code already implementation specific? And yes, I agree, an additional interface for every command is NOT my vote as well. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4208223#4208223 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4208223

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Problems with change in ConstructorInstantiator

by camunda

Hi Alex. I updated to your latest changes locally and have a problem with the change in ConstructorInstantiator. The new version throws a NullPointerException if you specify "constructor" configuration without a configuration. This may make sense, but in the current ESB integration the "org.jboss.soa.esb.services.jbpm.cmd.AsyncProcessSignal$AsyncSignalAction" is created as "constructor-configured" but with "configuration" null. So after updating to the new version every started process instance within the ESB environment fails with a NPE. So in the sense of not breaking compatibility I would propose to add the behavior as before the change to the new code, means: If configuration is null, type is assumed to be String and value is null. Got what I mean. D'accord? Then I can commit it... Cheers Bernd View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4208220#4208220 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4208220

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: Command implementation as part of public API

by heiko.braun＠jboss.com

IMO these command implementations are a good example of "grey zone" in an API. But I don't see a reason why we shouldn't make them publicly available. Another option would a typed interface with clear functionality. We had this discussion quiet a while ago when I was complaining about the command pattern in place, rememeber? There is actually no difference between a typed interface with specific scope and an untyped interface (Command) with scoped implementations. The later is what we currently encounter. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4208215#4208215 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4208215

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: Command implementation as part of public API

by jbarrez

Bernd, I find it a bit messy to create an interface for every command ... in reality it will always be the same interface, no :p I don't see what's wrong by exposing the Commands as they are in the public API. They all implement the same interface, so they shoud be changeable in future versions View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4208210#4208210 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4208210

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: Command implementation as part of public API

by heiko.braun＠jboss.com

I think the Command<T> [1] is sufficient for now. [1] http://jbpm.dyndns.org/jbpm4/jbpm-api/apidocs/org/jbpm/cmd/package-frame.... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4208209#4208209 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4208209

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: Confused about versioning

by camunda

Still more confused, seems all the jbpm 3.2.6 scommits go in jbpm3-HEAD? Can somebody shed some light on me? Thanks... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4208204#4208204 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4208204

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Are there any tests for the config schema?

by jmesnil

there is a test to check that default values are properly set but it was not run by the test suite (FileConfigurationTest2 class name does not match our naming convention). I'll rename the class and make sure we test all default values View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4208203#4208203 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4208203

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: Command implementation as part of public API

by camunda

Hi Heiko. But then we should introduce interfaces for every Command, or? Maybe this is the cleanest way, even if that is a bit unhandy... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4208201#4208201 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4208201

17 years, 1 month

1
0
0 / 0

[Design of JBossXB] - Re: 2 root elements question

by jeff.zhang

Hi Alex, Could you give me some tip about how to use this feature in the metadata test framework? Almost testcase use like this: public static SchemaBindingResolver initResolver() { DefaultSchemaResolver resolver = new DefaultSchemaResolver(); resolver.addClassBindingForLocation("jboss-ds_5_0.xsd", ManagedConnectionFactoryDeploymentGroup.class); return resolver; } And unmarshal. I tried and another root element class into resolver, but testcase fail. I saw your change (Revision 2956) only modify JBossXBBuilder and JBossXBNoSchemaBuilder. That mean the testcase should use these XBBuilder directly? Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4208197#4208197 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4208197

17 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums February 2009