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

[Design of JBoss jBPM] - Re: Process definition element label attribute

by tom.baeyens＠jboss.com

this might actually make sense. currently, we use the name field for display, but that is also used as an id field. the important thing is that the current approach of combining is and label in the 'name' attribute should be kept. but coming to think of it, nothing keeps us from adding a label attribute that is optional. the label returns the label or the name in case there is no specific label specified... let me think some more. i think this might be a good idea. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007958#4007958 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007958

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: web console problem

by tom.baeyens＠jboss.com

"david.lloyd(a)jboss.com" wrote : I agree this is a problem. The current logic of the transition button is that if the attribute is not there, or if its value is "default", then the default transition will be taken. A value of "" will translate into a lookup for a transition named ""... this is not really optimal. | | Koen, is it possible to modify the GPD so that if there is only one transition, that the "to" attribute is not emitted? | i don't quite get the point you're trying to make. 'to' is a required attribute on the transition. only the name is optional. it should be unique in case there are multiple leaving transitions. afaik, the designer already left out the name in case there is only 1. but in case the designer should put in name="", that should work as well. mayeb the problem is in the forms.xml generation... if you want to reproduce this, just build the suite from head and create a simple new process with a start state and 1 task node. add a task to the start state. generate a minimal form for it, deploy the process, start it and end the start task. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007955#4007955 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007955

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: web console problem

by tom.baeyens＠jboss.com

"david.lloyd(a)jboss.com" wrote : "tom.baeyens(a)jboss.com" wrote : also it appears that the console has become very slow. do you see the same ? do you think the cause is the navigation layout and increased page contents ? | | My laptop is pretty fast so I didn't notice anything too slow. But I think I'm going to run the console with a profiler just to see if there are any bits that can be optimized. then this will probably be something else on my system. i'll try again tomorrow. before the navigation rework, it took approx .5 second for a page to show. now it was approx 7-10 seconds. if you don't have this problem, it will be something local. i'll figure it out first. profiling should not be necessary at this point. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007954#4007954 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007954

17 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Issues with passivation of nested SFSBs

by bill.burke＠jboss.com

@Remote beans are not supposed to be nested. They are separate because they may be located in another server (@Remote). Ok, i got you on the shared refs...I'll put some thought into it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007953#4007953 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007953

17 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Issues with passivation of nested SFSBs

by bstansberry＠jboss.com

JIRA for broken lifecycle dependency is http://jira.jboss.com/jira/browse/EJBTHREE-854 . View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007945#4007945 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007945

17 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Issues with passivation of nested SFSBs

by bstansberry＠jboss.com

"bill.burke(a)jboss.com" wrote : | Nested SFSBs have to share the same lifecycle as their parents. They also have to share the same Extended Persistence Contexts the reference! OK, good; that's a clear rule that makes deciding how to handle everything else simpler. :) This is broken if the nested SFSB declares @Remote. This test fails: | ParentStatefulRemote stateful = (ParentStatefulRemote) ctx.lookup("testParentStateful/remote"); | | assertEquals("Counter: ", 1, stateful.increment()); | | NestedStateful nested = stateful.getNested(); | | stateful.remove(); | | // Confirm nested no longer works following parent remove | try | { | nested.increment(); | fail("Nested bean still exists following destruction of parent"); | } | catch (Exception good) | { | // this is what we want -- nested has no independent lifecycle | } | I'll open a JIRA for this. Hopefully one of you guys can figure it out. I've been digging around trying to understand what's going on. For some reason, if the nested bean declares @Remote, when a StatefulCache calls Pool.get(), it gets back a standard StatefulBeanContext rather ProxiedStatefulBeanContext. This has to be a function of how calls are nested (i.e. the nested bean gets created *before* the parent, thus the parent hasn't been pushed onto the ThreadLocalStack when the nested bean is created.) As for the initial issue of the ProxiedStatefulBeanContext not being removed from the cache when it's parent is, I think I found that -- it was a bug in StatefulTreeCache. anonymous wrote : Another thought I had was to actually store the Nested Bean's instance inide of its proxy and propagate it to the Nested Bean's EJB container via the invocation object. If the invocation object had the actual bean instance already set, then the EJB container would not look in the cache. | | I don't remember why I didn't do this....Maybe I didn't think of it at first? Was this thought sparked by my last post re: replicating the proxy? That is, if we store the bean instance in the proxy and replicate it, that solves the issue? If so, I think the reason you didn't do it that way was because you wanted the nested beans to always be serialized as a unit with the parent. Otherwise after deserialization you no longer have shared refs to things like ExtendedPersistenceContext. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007942#4007942 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007942

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Process definition element label attribute

by kukeltje

There already is a description element which could be used for this if not filled in to 'prosaic'. Displaying it in the GPD is another story View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007913#4007913 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007913

17 years, 4 months

1
0
0 / 0

[Design of JBoss Portal] - Re: DB test matrix

by prabhat.jha＠jboss.com

Nuked mysql4 tables to see if that takes care of "object already exists" error. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007909#4007909 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007909

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Process definition element label attribute

by paolodt

I'm a new to jBPM and it seems to be a great tool. One of the most interesting feature is the Graphical Process Designer that permits to design and show a "business" view of the process workflow. Anyway I think would be very useful to have "label" attribute as well as the "name" attribute for each process definition element (nodes, tasks, transitions, .. ). In this way it would be possible to have a displayable name showed in the jBPM designer (for the business users / analysts interested to the graphical model diagram) and a element name to use as identifier in the application / workflow coding. What do you think? Any plan to support that? Thanks a lot, Paolo View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007907#4007907 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007907

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: web console problem

by david.lloyd＠jboss.com

I agree this is a problem. The current logic of the transition button is that if the attribute is not there, or if its value is "default", then the default transition will be taken. A value of "" will translate into a lookup for a transition named ""... this is not really optimal. Koen, is it possible to modify the GPD so that if there is only one transition, that the "to" attribute is not emitted? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007897#4007897 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007897

17 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 January 2007