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

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Adding Ordering Group Features in JBM 1.4

by clebert.suconic＠jboss.com

AFAIC, The EAP-CP Release process is taking in parallel. https://jira.jboss.org/jira/browse/JBPAPP And I've sent a private email about that yesterday... (BTW the EAP is an internal process.. so.. this should be a private thread). If you don't agree with that, we just change the docs... that's it.. not big deal about it. I don't get why this is being such a big deal in public. I only tagged the release so Howard would be able to keep his work, and we could make any minor other changes on the TAG later. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180790#4180790 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180790

16 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Adding Ordering Group Features in JBM 1.4

by ataylor

What/Where is the release process. It probably should be a JIRA then things wouldn't be forgotten. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180789#4180789 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180789

16 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - queue settings vs queue attributes

by ataylor

I am re enabling redelivery delay on canceled message deliveries. The current (commented out) tests need to be able to change this delay setting on a queue. To be able to do this we would need to add an attribute, redeliverydelay, to queue. The question is do we want to allow some queue attributes to be changed after queue deploy time. There is also the maxDeliveryAttempts and possibly others that could be exposed. Alternatively I can just change the tests to deploy some queue settings specific to a test queue. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180787#4180787 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180787

16 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Dependency on jboss-native

by alessio.soldano＠jboss.com

Hi, I see the following in the AS5 ejb3 module's pom.xml: | <dependency> | <groupId>org.jboss.ws.native</groupId> | <artifactId>jbossws-native-jaxws</artifactId> | </dependency> | What's the reason for this dependency? Ideally you should not depend on a specific ws stack, but on jbossws-common / jbossws-spi Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180777#4180777 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180777

16 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: meeting context

by heiko.braun＠jboss.com

anonymous wrote : | These 3 aspects | * node pluggability | * pluggable aspects | * embeddability | lead to the design goals of the PVM based approach to jBPM 4. | Good point. Let's talk about design goals, but in the context of the upcoming meeting. AFAIK the meeting is about the API and CTS, right? Then we should put the focus on questions related to that domain. Thomas came up with a list of basic concepts that he would like to see addressed in the API: - ProcessEngine, Process, ProcessDefinition - StartEvent (None, Signal, Message) - Task (None, Send, Receive) - EndEvent (None, Signal, Message) - Gateway (Inclusive, Exclusive, Parallel) - Process, Activity Properties - Process, Activity Assignments - Signal, Message - SequenceFlow This however is not married to BPMN it merely borrows terminology. Why? Becasue BPMN terminology is very precise and avoids redundancy. All of these items do have associated semantics and it should be our first task to make sure everyone has same understanding of what this actually means. This will predict the implementation that follows. Starting off with the jbpm4 code base and API doesn't work because a successful discussion with all participants requires a certain level of abstraction. We need to talk about what should be there instead of what is possible with the current implementation. Once we agree on how these basic concepts relate to each other (and I hardly believe that we manage to so in 3 days) then we could move on to topics that build upon that: Process dialects - handling multiple process dialects - extending process dialect elements - extending the core engine capabilities Embeddability - transactions - persistence - security View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180773#4180773 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180773

16 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Adding Ordering Group Features in JBM 1.4

by timfox

"clebert.suconic(a)jboss.com" wrote : | This is not true.. .It has happened before, but it doesn't happen every single time. | It's happened at least four or five times. ALL by the same person! ;) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180772#4180772 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180772

16 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Adding Ordering Group Features in JBM 1.4

by timfox

"clebert.suconic(a)jboss.com" wrote : kes the JAR... no docs. This is not a complete community release. | It doesn't matter. A release is a release. The documentation and readme must be accurate. It will cause one hell of a confusion if the readme and documentation talks about 1.4.1beta and older versions of remoting and other jars. People DO read the readmes for CP releases. (I have referred support customers to it before). They use the readme and documentation to determine what correct versions of remoting etc to use. The proper release procedure MUST be carried out for every release. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180771#4180771 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180771

16 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Adding Ordering Group Features in JBM 1.4

by clebert.suconic＠jboss.com

"timfox" wrote : | This same mistake of not updating readme and documentation seems to happen regularly every single time.. :( This is not true.. .It has happened before, but it doesn't happen every single time. The CP update only takes the JAR... no docs. This is not a complete community release. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180769#4180769 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180769

16 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Cancelling a task fires task-end event

by tom.baeyens＠jboss.com

instead of hijacking this thread (which i'm now doing anyway:-) i have hijacked a completely new topic for the meeting context. http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180766#4180766 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180767#4180767 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180767

16 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - meeting context

by tom.baeyens＠jboss.com

"heiko.braun(a)jboss.com" wrote : | Agree, it's API stuff. But I was referring to this | anonymous wrote : | | Questions were more about declaring vars, typing them, giving default values etc | | | My concern was more about granularity of the discussion. I.e. Thomas reply is more likely what I consider an appropriate level to have a discussion at the team meeting. | Does that make sense? In the first couple of years as we build jBPM, we had a lot of "can you do this process construct?" type of questions. We realized that by overwriting the Node's execute method, we could just implement any behaviour we want in plain Java. The focus then quickly shifted to the runtime data structure (the tree of executions). As only that becomes the limiting factor of what kind of process constructs the engine can handle.We also realized that this way, we can implement any process language as it is just a set of process construct implementations. Next came pluggable aspects. Swimlanes in jPDL don't make sense in BPEL. Even other process languages that include task management (like bonita) have other interpretations of process roles. Correlation sets only make sense in BPEL. So it must be possible to plug these kinds of aspects on top of the core execution data. And the last factor was the different environments: BPEL runs in an ESB-like environment (based on WSDL services). jPDL runs in any kind of Java environment and wants to bind to different transaction demarcation technology. Pageflow executions must be able to persist themselves in the http session, and so on. These 3 aspects * node pluggability * pluggable aspects * embeddability lead to the design goals of the PVM based approach to jBPM 4. So IMO it makes sense to see if the BPMN constructs can be build on top of the PVM. But I'm pretty confident that is going to be possible. That is not where the challenge is IMO. We'll be pursuing following process languages: * jPDL * BPEL (Bull) * XPDL (Bull) * Pageflow (SEAM) * Thread Control Language (TODO) * Executing BPMN directly from the STP-BPMN file format could be another potential candidate. In the context of those target languages, I don't think that a dogmatic adoption of BPMN has the answers. We should look at the executable process parts of BPMN and see to what extend it makes sense to align jPDL with BPMN. Then we should use the BPMN figures in the designer where appropriate. The real challenge with BPM and the process languages that we target is to identify the common parts and define how we're going to add the process language specific parts. The PVM is focussed on the common parts, but with a clear strategy on how all of those specific process language features can be build on top. In terms of the API, we are currently far enough advanced to see that a common API is possible that is shared between all these process languages. This means one API for all kinds of workflow. Another challenge is the impact of persistence. The more you try to hide that aspect, the more it pops up in unexpected places. Over the last years, we found out that the clue has been to align jBPM's persistence with the user's domain model persistence. That is why embeddability is such a crucial part of what we do. By making the embeddability of jBPM easy into a Java project, we make our own market. A real discussion point in this sense could be JPA. As more projects start with non-hibernate based JPA persistence, we loose a big part of our embeddability. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180766#4180766 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180766

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