December 2007 - jboss-dev-forums - Jboss List Archives

[Design of JBoss jBPM] - Re: ProcessInstance vs. Execution

by tom.baeyens＠jboss.com

processinstance and token will be merged into a class called execution in jpdl 4. on the PVM-level, only execution will exist. it might be that specific process languages like jPDL introduce a JpdlProcessInstance and a JpdlExecution. in which case JpdlProcessInstance would inherit from JpdlExecution. jpdl 3.x will remain token / process instance as is. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114980#4114980 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114980

16 years, 4 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: WS-RM Prototype Ready for Preview

by thomas.diesler＠jboss.com

Thanks. I propose to get the initial implementation going first. Then we investigate the pros/cons of a standalone decoupled RM implementation. After all, if a RM implementation cannot provide reliable messaging (because of its coupling) - it is pointless to use it from the customer point of view ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114974#4114974 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114974

16 years, 4 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: WS-RM Prototype Ready for Preview

by richard.opalka＠jboss.com

"thomas.diesler(a)jboss.com" wrote : | Using your implementation, would it (eventually) be possible to deploy the RM Sender/Receiver as separate HA components (i.e. on dedicated boxes)? No with the current version of prototype :-( View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114971#4114971 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114971

16 years, 4 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: WS-RM Prototype Ready for Preview

by richard.opalka＠jboss.com

"thomas.diesler(a)jboss.com" wrote : | | On the contrary, if the RM Sender is coupled with the client proxy or the RM Receiver is coupled with the Endpoint, it would in my opinion defeat the purpose of RM. In other words, if the RM Receiver is only available if the Endpoint is available, the client might as well talk to the Endpoint directly. | | Using your implementation, would it (eventually) be possible to deploy the RM Sender/Receiver as separate HA components (i.e. on dedicated boxes)? Hi Thomas, you're absolutely right. The fact that both RM Sender / Receiver are coupled with client proxy/endpoint defeat the purpose of RM. The reason I decided to provide the initial prototype this way was to support WS-Security as well. If we will want to support WS-Security and decouple both RM Sender / Receiver we need to move WS-Security one level lower (that is to move it from handler to transport marshallers). Other option is to forget about WS-RM + WS-Security combination and to decouple the RM Sender/Receiver. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114969#4114969 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114969

16 years, 4 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: WS-RM Prototype Ready for Preview

by thomas.diesler＠jboss.com

Hi Richard, while working with the RM implementation I was wondering about the Quality of Service (QoS) aspect of WS-RM. In my understanding the RM Sender/Receiver must be high available (HA) components such that the Client can (always) communicate with the RM Sender and likewise the RM Sender can always communicate with the RM Receiver. | Client <--> RM Sender <-------> RM Receiver <--> Endpoint | QoS QoS | On the contrary, if the RM Sender is coupled with the client proxy or the RM Receiver is coupled with the Endpoint, it would in my opinion defeat the purpose of RM. In other words, if the RM Receiver is only available if the Endpoint is available, the client might as well talk to the Endpoint directly. Using your implementation, would it (eventually) be possible to deploy the RM Sender/Receiver as separate HA components (i.e. on dedicated boxes)? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114954#4114954 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114954

16 years, 4 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: WS-RM Prototype Ready for Preview

by thomas.diesler＠jboss.com

anonymous wrote : | Other possible option that comes in my mind is to don't close sequences at all, because this step isn't required by RM protocol. Closing the sequence is optional protocol operation. | This seems reasonable, with the option to use proprietary API when needed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114950#4114950 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114950

16 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileServiceUnitTestCase value/type misuse

by alesj

"scott.stark(a)jboss.org" wrote : | Because the ManagedProperty can be used on the server with any value. | Its only the remote client view that should be restricted to meta values. | | "alesj" wrote : | | How come then the get/setValue API doesn't already enforce metavalue usage? | | | We should then have some nice OO distinction between client side ManagedProperty and server side. To be strict regarding plain object value usage vs. generic serializable MetaValue for client view. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114946#4114946 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114946

16 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileServiceUnitTestCase value/type misuse

by alesj

"scott.stark(a)jboss.org" wrote : | You can't pass in non-meta values. The api does not do conversion | automatically. In general the admin client will not have access to the | underlying ManagedProperty type, and so it should only use the meta | value wrappers. | Looks like we agree. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114943#4114943 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114943

16 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileServiceUnitTestCase value/type misuse

by alesj

"scott.stark(a)jboss.org" wrote : There was the question of primative types vs SimpleMetaType and whether the ManagedProperty should be accepting primatives and autoboxing these into SimpleValues. I think we should look into doing this. | | The question also came up of enforcing a check against the ManagedProperty.getMetaType().isValue(Object) for the values passed into ManagedProperty.setValue(Object). Could be done with aop, but I don't think we can assume jboss aop is available/used in the admin client. It could also be done via a wrapping proxy that imposed this behavior, as well as the autoboxing. | Looking at this piece of horrible code - which I added :-( - we really must clear up the confusion about this values/types. | // TODO - decide what is the type of value when we set it | // since currently get always returns MetaValue, but we see some cases | // where plain Serializable is enough | Serializable serializable; | MetaValue metaValue; | Object value = prop.getValue(); | if (value instanceof MetaValue) | { | metaValue = (MetaValue)value; | MetaType metaType = metaValue.getMetaType(); | if (metaType.isSimple()) | serializable = ((SimpleValue)metaValue).getValue(); | else if (metaType.isGeneric()) | serializable = ((GenericValue)metaValue).getValue(); | else | serializable = null; | } | else | { | serializable = (Serializable)value; | metaValue = MetaValueFactory.getInstance().create(value); | } | | if(serializable != null) | ctxProp.setValue(serializable); | // todo - should this also dispatch to runtime component? | Object componentName = getComponentName(ctxProp); | if (componentName != null) | dispatcher.set(componentName, ctxProp.getName(), metaValue); | I would expect a ManagedProperty to take MetaValue (so that it can also take non-serializable 'composite' values) and a runtime dispatcher to take plain object value. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114940#4114940 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114940

16 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - New Project to Validate External API

by ALRubinger

With the addition of the EJB3 External API, we've clearly-defined a contract for Bean Providers such that this artifact and the JavaEE EJB3 API should suffice for compile-time constraints in developing EJB3 on JBoss. However, we currently do not have tests to ensure that the API is complete, that all required libraries for the compile-time classpath are in ext-api. It'd be nice if we could move the current EJB3 Testsuite and have it not depend on core, but it tests internals (rightfully so!). So, I propose the addition of a new, small test project that contains definitions of arbitrary EJBs, using each of the classes in ext-api. If this project compiles, ext-api is valid and complete. Any time we introduce a dependency outside, the test project won't compile. Thoughts, or more simple ways of validating ext-api? S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114919#4114919 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114919

16 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums December 2007