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

[Design of JBoss jBPM] - Re: new simplified menu structure

by tom.baeyens＠jboss.com

"david.lloyd(a)jboss.com" wrote : "bazoo" wrote : Instead of "End Task", I would suggest "Proceed", to reinforce the idea that the user is moving through a process. | | The "End Task" is not terminology that is defined by the web console. The caption of each of the transition buttons is determined by the name of the corresponding transition. In this case, the "websale" example process happens to have transitions named "End Task". | if there are multiple leaving transitions, the transition names should be shown. but the web app also must have a default name in case there is 1 single anonymous transition. From the proposals that i have seen so far, i like 'Complete' or 'Finish' the most View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999435#3999435 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999435

19 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: new simplified menu structure

by tom.baeyens＠jboss.com

"david.lloyd(a)jboss.com" wrote : "tom.baeyens(a)jboss.com" wrote : Processes : Should display a list of processes similar to the current Find Processes menu screen. By default, this screen shows only the latest versions of the processes in alphabetical order. | | For the new prototype, there should be two tables for Processes. One table should have a row for each unique process name, and it should contain any information that is shared between all versions of a process (even if it is just the name). The other will be a child table of the main Process table and should contain per-version information. The main process table should have link to the Process Version table representing the current "active" version. This way, the latest version of a process can be found without having to using grouping SQL operations, and also the user can easily revert to an earlier version of a process if they need to by changing a simple link. | | This normalization will greatly simplify the querying of process information. Wouldn't this be nicer solved by a checkbox in the search criteria "Show all versions" which by default is unchecked ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999432#3999432 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999432

19 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: one central search page

by tom.baeyens＠jboss.com

can i conclude that there is concensus to have 2 separate search pages: one for task instances and one for process instances ? open questions: * will both of these have a menu item ? * will there be a process definition search as well ? * if not, what will be the way to start a new process instance of a process definition ? Maybe we should have following menu items: 'Tasks', 'Processes' (process definitions) and 'Executions' (process instances) Just a suggestion: Tasks: shows the user task list by default. I would put the search criteria form below the user task list. By default, the current actor criteria field is set to the authenticated user... Processes: shows the list of processes. By default the list will filter out all processes that are not the highest version for a given process name. Also here below the list, we could have the search criteria that can be refined by the user. Executions: shows the process instances sorted by start date descending by default. Also here i would put the dearch criteria form below the actual list. On performance: I would not be bothered by performance now. The architecture is build for scalability. Fixing issues will be dealt with later. Functionality, navigation and ease of use are more important for now. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999431#3999431 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999431

19 years, 3 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Strategy for supporting NonSerializable data

by dimitris＠jboss.org

With the switch to JDK5, accessing remotely the MBeanServer over the legacy JMXAdaptor and getting back MBeanInfo is problematic, due to non-serializable objects stored in the MBeanInfo Descriptors. We could deal with this under jdk1.4 by controling the javax.management.modelmbean.DescriptorSupport, but not when using jdk5. A possible short-term solution is to create an interceptor that filters out non-serializable stuff: http://jira.jboss.com/jira/browse/JBAS-1955 Is there any other strategy or plan dealing with this problem, by the Remoting and Serialization projects? I see org.jboss.invocation.MarshalledInvocation can delegate to Cleberts plugable Serialization - could this be used? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999404#3999404 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999404

19 years, 3 months

1
0
0 / 0

[Design of POJO Server] - DeclaredStructure ThreadLocal field

by alesj

What's the usage of activeMetaData field in DeclaredStructure class (part of structured deployers)? It is private and never unset. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999378#3999378 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999378

19 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Failover analysis

by ovidiu.feodorov＠jboss.com

OK. One pair of locks shared by all delegates belonging to one connection. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999366#3999366 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999366

19 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Expiring/DLQ same message from multiple subscriptions

by timfox

That makes sense. I suggest we do the same for JBM View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999361#3999361 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999361

19 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBossMQ delayed redelivery implementation

by timfox

Hmm, ok. But even with transaction rollback, local tx rollback just causes session recovery anyway, so the same applies. The only time the messages would get nacked back to the queue would be if the orginal local consumer that originally got the message had closed, otherwise it is just recovered directly to the local consumers. anonymous wrote : | (JMS1.1 4.4.7). | * "If a transaction rollback is done, its produced messages are destroyed and its consumed | * messages are automatically recovered. For more information on session recovery, see Section | * 4.4.11 'Message Acknowledgment.'" | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999360#3999360 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999360

19 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Tests for JBoss MQ message counter functionality

by timfox

I have ported it anyway. I have made a few changes along the way. There was one biggie where the counters are updated as every message arrives at a destination. *slow*. I have changed this so instead the counter queries (samples) the queues every x milliseconds and updates itself appropriate - so it shouldn't be a bottleneck. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999357#3999357 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999357

19 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Failover analysis

by timfox

"ovidiu.feodorov(a)jboss.com" wrote : Keeping a single centralized valve per connection gives a single point of bottleneck. All threads invoking into any delegate will have to acquire/release the synchronization element of that valve. This will lead to a lot of contention. | | Distributing the load across different valve instances will relieve some of this pressure, with no apparent drawback. | I don't really agree with this. You would only get a lot of contention if the threads were all attempting to get the same write lock, but in the normal case they would be getting the read lock, and multiple read locks can obtained at any one time - this is kind of the whole point of read locks. There may be a very small synchronized region in actually executing the call to get the read lock but this is probably insignificant. If we can reduce the scope for deadlock and make the code simpler by using a single pair of locks I would prefer that solution. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999355#3999355 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999355

19 years, 3 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 January 2007