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

[Design of Clustering on JBoss] - Removing SFSB in HttpSessionListener

by tkimura＠redhat.com

Suppose we have a web application which uses stateful session beans, and we have HttpSessionListener like this: | public void sessionDestroyed(HttpSessionEvent event) { | event.getSession().getAttribute("sfsb").remove(); // Make sure to call SFSB's @Remove method | } | This behavior is what Seam does. The HttpSessionListener.sessionDestroyed() would be called in session invalidation, session timeout and during redeploy/shutdown for cleaning up local resources. This happens in both cases, clustered and non-clustered . However, in clustered environment, the sfsb.remove() method call in HttpSessionListener becomes a cluster-wide operation. So when we shutdown one node, HttpSession is still available on the other node for fail over but SFSB is missing. I don't think the application is doing something wrong. Possible solution is to separate the node from cluster before applications undeploy. This makes the sfsb.remove() method call local-only. Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164658#4164658 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164658

17 years, 8 months

1
0
0 / 0

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

by tom.baeyens＠jboss.com

anonymous wrote : Closely linked to BPMN 1-1 is a set of standard BPM Patterns. They're not closely linked. But You have convinced me that it might be worth while reviving the BPM patterns examples. I had given up on those as they are not clearly defined and the creators of the patterns were always finding new problems with the reports we created without being clear upfront. What we surely can do is just post our own report, even if their validation might come to different results. Relevance of BPM patterns has declined in the last years. 3-4 years ago it was a hot topic. So we should only do it if we can do it with minimal effort. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164657#4164657 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164657

17 years, 8 months

1
0
0 / 0

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

by tom.baeyens＠jboss.com

anonymous wrote : Ultimately we will have BPMN conform process model that can somehow be executed on the ProcessEngine No. We'll provide a single direction BPMN to jPDL export functionality. http://processdevelopments.blogspot.com/2008/05/big-problems-ahead-for-bp... explains how I see the analysis to implementation iterative process: An analyst can optionally produce an analysis diagram (BPMN) as input for the software automation requirements. Then the developers build an executable process that looks exactly like the analysis diagram. (sometimes business analysts are also capable of drawing the diagram part of an executable process) But once all tech details are added, an executable process is a piece of software and should be under control of developers. The added value comes from the fact that the developers how have a process based on a diagram that analysts can understand. The iterative development should only take place on the executable process. I don't think it is feasible/desirable to create round tripping between different analysis and implementation models. Thats why I don't think we should pursue of making BPMN executable. It creates the false illusion that analysis models automagically can be made executable. That is a false promise that many BPM vendors promote and that gives BPM its bad reputation. We get our recognition from being more modest but honest. The real value lies in building a process language that is very flexible in terms of diagram. Meaning that developers always need to be able to build an executable process that looks exactly like the analysis diagram. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164656#4164656 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164656

17 years, 8 months

1
0
0 / 0

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

by tom.baeyens＠jboss.com

anonymous wrote : The API closely follows the BPMN 1-1 Specification. Doing so we leverage an established standard to describe Business Processes. The ProcessEngine executes that model. | Using BPMN is not a good idea. Most importantly is that we use names that are as clear as possible. We can use names from any process language or modelling notation, as long as it is unambiguous. In many cases, we'll need to establish our own names cause there is no standard with a proper name for it (mainly the runtime execution concepts) or the standards use the term in different ways. It's very hard to find unambiguous names in workflow land. I have already tried to do this in PVM, but I'm sure that improvements can be made. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164654#4164654 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164654

17 years, 8 months

1
0
0 / 0

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

by tom.baeyens＠jboss.com

anonymous wrote : The situation with jbpm-3.2.3.GA and below is that there is no stable public API defined for it. As a result, application code depends on implementation detail that might change without prior notice between releases. | | To fix this we are going to define a BPM API which is going to be the standard of how you work with BPM in JBoss. i don't see this as a problem that needs to be fixed. all the architectural set up is required and will be kept. there are only 2 things missing and that need to be added in another iteration: 1) is a session facade that sits in front of the object model. it will be based on commands and we should be able to cover 95% of the API use cases with that. 2) the domain model itself needs to get interfaces so that implementation methods don't have to be exposed. currently this is done in the pvm (still completing the test suite update of that refactoring). i have established 3 separate interface views on the domain model: the external client api, the activity implementation api and the event listener api. These 3 views are mainly realized by 3 different types of executions that are used, exposing only the appropriate methods. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164653#4164653 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164653

17 years, 8 months

1
0
0 / 0

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

by tom.baeyens＠jboss.com

"kukeltje" wrote : Personally I think there is a little to much emphasis on BPMN and the workflow patterns +1 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164651#4164651 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164651

17 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: Scoping of war/jar file embedded in sar service archives

by scott.stark＠jboss.org

jira is down so I'll create it when its back up. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164642#4164642 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164642

17 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: Scoping of war/jar file embedded in sar service archives

by scott.stark＠jboss.org

Yes, the issue is JBAS-5773 and the test which shows the behavior using the staticarray.sar with: staticarray1.jar staticarray2.jar staticarray-web1.war referring to staticarray1.jar via a classpath entry staticarray-web2.war referring staticarray2.jar and staticarray1.jar via a classpath entry I'll create a deployers issue as well for the WARStructure change. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164640#4164640 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164640

17 years, 8 months

1
0
0 / 0

[Design of JBossCache] - Re: Service threads

by manik.surtani＠jboss.com

Perhaps a custom Executor that would block until your integration code is ready to run a background process, and then it takes the Runnable passed in to the Executor and deals with it? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164630#4164630 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164630

17 years, 8 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Please don't use IDE auto format on commit

by clebert.suconic＠jboss.com

"skajotde" wrote : Yes, I know I don't work on project ;) Your mistake! By participating on this forum *you are* working on the project :-P Don't be shy and you're welcome to contribute more ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164606#4164606 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164606

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