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

[Design of EJB 3.0] - Re: EJBTHREE-1423 Test case for @RemoteBinding

by jaikiran

Andrew, With jboss-metadata 1.0.0.Beta32, the @RemoteBinding test case passes. But the @LocalHomeBinding is not being honoured resulting in a couple of failing test cases. I have attached a patch and logs to EJBTHREE-1423, which has the failing testcases. Let me know if you need more details or if you have any review comments. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166905#4166905 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166905

17 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Defining the API Mission

by heiko.braun＠jboss.com

But thanks for the examples. I'll take a look them and get back to you. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166904#4166904 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166904

17 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Defining the API Mission

by heiko.braun＠jboss.com

anonymous wrote : | BPMN is not a proven concept. | Tom, maybe you got me wrong here. I am not talking about BPMN or BPEL as a whole. When I say concept, I mean the BPMN composites. I.e. gateway, signal, event, whatever. They all have distinct meanings and an established name. So instead of naming it a decision, you could call it exclusive gateway right away. The reason why I prefer BPMN glossary over jBPM terms is that these people did a good job finding terminology and add short, descriptive explanations to the core concepts. Whereas in the PVM, we still have 3 or 4 kinds of "Executions". If we could manage to become explicit in our jBPM4 terminology the same way, then I wouldn't complain. But currently I see a 200 pages document with very precise terminology (BPMN) and a redundant, hard to understand API (PVM) which is only obvious to it's inventor. So give me one good reason why we should chose the hard way and try to be superior to the BPMN spec leads and come up with something on our own. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166903#4166903 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166903

17 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Defining the API Mission

by heiko.braun＠jboss.com

anonymous wrote : | introducing use of BPMN terms into the execution domain, e.g., as the basis for names in an API, would be a really bad idea. | Why? Come on guys, add some meat to the discussion. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166899#4166899 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166899

17 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jBPM 4: Identity and Task projects

by tom.baeyens＠jboss.com

that is a work in progress. rough lines are in svn project. though i'm not sure what its current state is given the migration and refactorings. it will be brought in a better shape when i'm working on jPDL, which should be next month. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166891#4166891 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166891

17 years, 8 months

1
0
0 / 0

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

by timfox

If you want to support the R2 protocol that's going to force you to implement things in a certain R2 way. The main problem with the R2 design is that it has no strong relation between the user connection object (the Client object) and the actual underlying connection used, e.g the TCP connection in the case of the socket transport. This means that subsequent invocations on the same Client object can actually end up using different TCP connections since there's a client side pooling mechanism. Consequently you can end up with situations where later invocations overtake earlier invocations since they're using different connections - ordering is lost. We had to do various nasty hacks to workaround this problem in JBM. The R2 protocol also assumes a request has exclusive use of a connection until it gets a response back. I.e. get connection from pool, write request, wait for response, return connection to pool. This also leads to scalability and latency issues and ends up with large numbers of TCP connections created when you have a lot of concurrent requests. A sensible implementation would have allowed many requests and responses to be interleaved on the same connection - identifying each request/response with some identifier on the wire. Since R2 does not write any such id with the request, - it doesn't need to since it assumes exclusive use of the connection, then if you were to provide R2 protocol support you would also have to implement the same exclusive connection use and client pooling in R2 - do you really want to do that? My advice would be not to try and provide compatibility with R2 in R3. It'll just force you into implementing the same broken model, and drag you into a nightmare - R2 was broken - make a clean start! IMHO if people really want to run R2 they should just use the R2 service - nothing's stopping them just running the R2 service on the server if that's what they want to do. Also, it's normally fine to drop compatibility on major version releases. E.g. JBM 1.x is not compatible with JBM 2.0. That's normal practice. Just my 2c View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166890#4166890 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166890

17 years, 8 months

1
0
0 / 0

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

by trustin

I talked to Tim in the JBoss Messaging IRC channel to get some quick answers about the flaws of R2 protocol. They were: * Connection pooling doesn't allow you to send other commands when a request is in progress. It also causes the order of invocation get mixed up. - This issue can be fixed by fixing R3 client behavior. * The way ping works - I don't have much idea about how ping works. Someone could address this issue. * Protocol doesn't have a command type identifier - It's OK because we can bump up the version field and provide a command type identifier, sequence no, etc if necessary. Also, he suggested me to abandon R2 protocol and go straight to the whole new transport (e.g. SSH + new wireformat) because: * We are not required to be backward compatible with R2 and we should give it up to avoid maintenance difficulty. * We can run both R2 and R3 at the same time in the microkernel, so R2 users should be able to keep using R2 services or upgrade to R3. I think it makes fair amount of sense (or perhaps I am missing something big :)) except that I have no idea if it's OK for all users. It might be OK to do so considering that most users are other JBoss projects. WDYT? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166886#4166886 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166886

17 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Defining the API Mission

by tom.baeyens＠jboss.com

here's a typical example that shows how hard it is to bind executable semantics to analysis models. http://davethinkingaloud.blogspot.com/2008/07/business-process-failures-e... This is from a vendor that is based on BPMN and tries to make it executable with BPEL. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166882#4166882 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166882

17 years, 8 months

1
0
0 / 0

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

by trustin

Also, it's designed to be able to provide any underlying protocol, so a protocol-level flaw shouldn't affect the overall API design and usage, which means we can provide a completely new communication protocol for R3. However, I think the actual data representation will not change much because the request and respose format itself doesn't seem to have a problem. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166877#4166877 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166877

17 years, 8 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: How does version.properties get copied

by timfox

I think the file should be copied not recreated. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166876#4166876 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166876

17 years, 8 months

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 July 2008