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

[Design of JBoss jBPM] - Re: Making the BPM API more generic?

by thomas.diesler＠jboss.com

Mark anonymous wrote : | This api will be able to wrap, to some degree, other process engine apis. Our PVM will also be capable of executing their models. As proof of concepts krisv has done partial implementations for BPEL, OSWorkfow and jBPM. BPEL runtime is almost complete (Drools is able to execute most examples), although it has not been wired up to WS and still needs work on XML assignment issues. OSWorkflow and jBPM runtime mappings are about 70% complete. | Whow ... so its high time we actually get together and consolidate what can get consolidated. I'd like to present you and Kris our ideas show you whats there and line up roadmaps. Lets take this off-line and try to find a way to get together. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168575#4168575 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168575

15 years, 10 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Ejb3Deployment.resolveMessageDestination

by scott.stark＠jboss.org

The org.jboss.injection.ResourceHandler should just be looking at the mappedName/jndiName/resolvesJndiName and throwing an exception if its not set. This is the change I made in the client container version and then fixed the message-destination-ref link resolution in the MappedReferenceMetaDataResolverDeployer. The org.jboss.injection.ResourceHandler is not looking to the resolvedJnidName curently. Should be something like: | private static void loadXmlMessageDestinationRefs(InjectionContainer container, Collection<MessageDestinationReferenceMetaData> refs) | { | for (MessageDestinationReferenceMetaData envRef : refs) | { | String encName = "env/" + envRef.getMessageDestinationRefName(); | if (container.getEncInjectors().containsKey(encName)) continue; | String jndiName = envRef.getMappedName(); | if (jndiName == null || jndiName.equals("")) | { | // Look for a resolved-jndi-name | jndiName = envRef.getResolvedJndiName(); | if (jndiName == null) | { | throw new RuntimeException("message-destination has no jndi-name/resolved-jndi-name " + envRef); | } | } | ... | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168571#4168571 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168571

15 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Making the BPM API more generic?

by thomas.diesler＠jboss.com

anonymous wrote : | The API is a product not related in any way to jBPM | Branding is not decided yet. For now I'd like to call it JBossBPM, which comprises API + RI + CTS. Yes it is not related to jBPM anonymous wrote : | The PVM is an improvement of jBPM but not related to the API | The jBPM4 project is expected to take part in the JBossBPM API design and eventually provide an implementation of it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168570#4168570 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168570

15 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: MainDeployer MBean methods in JBoss 5

by Wolfgang Knauf

Made my way through the JBoss testcase, and as a result, I wrote this Wiki article: http://wiki.jboss.org/wiki/JSR88Client Maybe you can take a look at it and comment on it. Best regards Wolfgang View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168564#4168564 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168564

15 years, 10 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: R3 transports to implement

by david.lloyd＠jboss.com

"ron.sigal(a)jboss.com" wrote : "david.lloyd(a)jboss.com" wrote : | | 2bb. we would have to provide a Remoting 2 facade for Remoting 3 so that InvokeRemoteInterceptor doesn't need to know which version of Remoting is running. | | | | A "2bc." could be to go with the original plan to provide a Remoting 3 facade for Remoting 2 invocations. Then the invoker client would simply always use Remoting 3 and it use the service discovery mechanism to figure out how the request moves across the wire. | | A similar thing could be done on the server side: create an emulation service that receives invocations and forwards them to a Remoting 3 RequestHandler. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168536#4168536 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168536

15 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: Marshalling Regions

by bstansberry＠jboss.com

No, I didn't play with it in great detail. To replace marshalling regions with it, you'd have to be able to use it for Fqn elements as well, as the Fqn can include custom types. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168532#4168532 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168532

15 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Paging discussion:

by timfox

What you're saying is that different queues bound under the same address could end up with message references in different orders after a cancel condition. That's correct, but I don't see what relation it has to paging. Paging occurs at the address level - *before* the message is routed. Paging is done at the message and address level, not the queue and message reference level. Once a message has been routed there's no paging involved. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168527#4168527 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168527

15 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: Custom data versions

by bstansberry＠jboss.com

"manik.surtani(a)jboss.com" wrote : no, it won't be applied to side-effect nodes - perhaps one way to do this is to create the "side effect nodes" explicitly with the option? :-( That's the hack I have now. Try to track whether the region root nodes exist or not, and then before doing any writes, do a separate call to create the region root if necessary. It's ugly and fragile. Possibly I could replace the "try to track whether the region root exists" bit and just do a PFER for the region root w/ cacheModeLocal=true before every write. Eliminates complexity in the integration code at the cost of a lot of unnecessary PFER calls. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168524#4168524 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168524

15 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Paging discussion:

by timfox

What is the "Binding Queue"? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168523#4168523 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168523

15 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Paging discussion:

by clebert.suconic＠jboss.com

anonymous wrote : Can you elaborate more why you need different files for messages and message references? I found it hard to understand from your wiki. | I'll reformulate the WIKI, but let me explain this part here. - Say you have one Address with 10 Messages: Msg1, 2, 3, 4, 5, 6, 7, 8, 9, 10 - You have two consumers on that Binding. One of them consumed messages 1,2 and 3, the other one consumer 4, 5 and 6. Now the first consumer rolled back the ACKs while the second consumer committed the messages: After these two Consumers operation, the Binding Queue will have: Msg1,2,3, 7, 8, 9 (4,5 and 6 are gone) While another Binding of the same address could still have: Msg 1,2,3,4,5,6,7,8,9,10 so... because of that we will need the references on a separated data structure. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168520#4168520 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168520

15 years, 10 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 August 2008