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

[Design of JBoss jBPM] - Re: replace separate managers task list view with generic se

by david.lloyd＠jboss.com

There's also the question of whether a regular user should be allowed to see other users' tasks. If not, then even having the Actor ID column be visible and searchable is unnecessary for these users, and the column should not be visible. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999083#3999083 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999083

19 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: simplified task instance view

by david.lloyd＠jboss.com

"jeffdelong" wrote : I agree with Tom. I would also like to add that I don't like End Task for the name of the button. Even though the API is end, users would be more comforatable with "Complete", as it signifies that they have completed the task. As I commented before, "End Task" is not based on the API; it's just the name of the transition in the websale example. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999081#3999081 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999081

19 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: free choice of initial node

by david.lloyd＠jboss.com

I agree 100% View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999071#3999071 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999071

19 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: simplified process instance view

by david.lloyd＠jboss.com

"kukeltje" wrote : hmmmm won't this screen be cluttered with info? Well yes, but this is to me the classic webapp tradeoff: Either you get few complex screens, or many simple screens. It's a lose-lose situation. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999069#3999069 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999069

19 years, 3 months

1
0
0 / 0

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

by david.lloyd＠jboss.com

"jeffdelong" wrote : Having said this I again raise the concern about performance. Is the database schema and gui architecture able to handle these types of queries when there are 20,000 processInstances and 100,000 taskInstances in the db, and the query results in 2000 hits? In a word: Yes. :-) Well, subject to testing anyway. Well, at least for the two types of data you've mentioned (process instances and task instances). Process Definitions are a problem. If we had 100,000 processes each with 100 versions it would be slow (to get a list of the 100,000 processes, we can't use things like limit/offset because it's a grouping operation, meaning that the server would [in this contrived case] have to accumulate 10,000,000 rows before it could return even the first 10). I'd like to see this addressed at least for the new prototype as I've outlined in other posts. The other queries (in the GUI) are designed right now to impose a hard limit of 100 pages, under the rationale that more than 100 pages is not useful to the user and that they should reduce the search. This number is configurable as well. The advantage to this approach is that the database does not need to be hit to fetch each page, which avoids a race condition where the result set changes between pages causing rows to appear to vanish (where in actuality they have simply moved from the page you are on to a prior page). The disadvantage is that the search can result in a fairly good-sized chunk of data coming from the database (though in my actual experience it takes more than about 5k rows to start slowing things down; after all, we're only displaying one page at a time, and in most cases the real bandwidth bottleneck is between the web server and the end user, not between the web server and the database). At some point we should be able to add well-performing sorting to this model as well, assuming judicious use of indexes. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999068#3999068 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999068

19 years, 3 months

1
0
0 / 0

[Design of JBoss Wiki] - Re: wiki won't deploy in jboss-portal-2.4.1-bundled (SP1)

by szimano

AFAIK bundled version of portal doesn't have EJB3 included. Please install portal from JEMS installer 1.2.0.CR1 http://labs.jboss.com/portal/jemsinstaller/downloads Cheers, Tomek View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999067#3999067 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999067

19 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Component Proposal - Configurable Service Locator

by bill.burke＠jboss.com

anonymous wrote : From your point of view is what I am doing wrong or is it just another way to do the same things ? IMO, there is rarely a right/wrong way just better ways. For client configuration your way is better. The Java EE Client container can provide the same funtionality for you though in most cases (minus interceptors and XML reloading). The JBoss equivalent to Spring container is JBoss Microcontainer i fyou want to try that out. anonymous wrote : JNDI parameters are in XMLs, they can be changed easily. | Moving services from one EAR to another does not have impact on client source code but only on XMLs. Don't bash annotations. Using annotations are great for fast prototyping or generally providing default values for your injections. What I'm saying is that even if you use annotations, you can still override them in XML (web.xml, ejb-jar.xml, etc...) to provide the JNDI mappings you desire. The specifications also support partial XML deployment descriptors so it is real easy to override one env/ entry. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999064#3999064 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999064

19 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: user based process versioning ?

by david.lloyd＠jboss.com

In my opinion the new prototype would work like this: All process information is stored in the process definition archive (not in the database). The database has a row for the process, and a row for the specific version; this allows executions to link back to their owning process. These rows need not use system-maintained versioning, and in fact probably should not. A process definition archive contains the name and version of the process, as well as any associated information (process diagram, forms, etc). A variation on the standard file deployer is used to add a process definition to the container. A jBPM instance can execute any process that is currently deployed. An attempt to execute a process that is not deployed in the current container will result in an exception. Deploying processes in this way has several advantages: * We no longer have to deal with BLOBs, as we are not storing large chunks of binary data in the database. The process definition archives and their associated metadata are deployed much like any other javaee component. * We support two models of versioning. The first allows the user to deploy a new, independent version of their process by specifying a new version number, allowing the old version to continue to exist. The second allows the user to easily *replace* the definition of an existing version, in the case where they have (for example) a critical bug in their process definition and they want to get a quick fix out there, without having to execute a potentially complicated data update as well. * Table normalization. This should always be a goal in my opinion. We should never require grouping or distinct operations for a query of a simple domain object, as we do today for distinct process definitions. * Reusing standard javaee deployment mechanism. This is the standard way of performing a javaee deployment. By way of comparison, EJB authors do not deploy their code into the database; and they are used to the idea of doing a new file deployment for new versions of their applications. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999061#3999061 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999061

19 years, 3 months

1
0
0 / 0

[Design of JBoss Wiki] - wiki won't deploy in jboss-portal-2.4.1-bundled (SP1)

by shawdav1

Hi: Is jbosswiki-beta2-2.4-bin.tgz supposed to be compatible with jboss-portal-2.4.1-bundled (SP1)? It fails to deploy. I can post details if desired. Thanks David View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999060#3999060 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999060

19 years, 3 months

1
0
0 / 0

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

by clebert.suconic＠jboss.com

My comments regarding the WIKI page: >>2. Failure detected when sending a new invocation into the server For new connections, Remoting will mask any IOException as org.jboss.remoting.somewhere.CannotConnectException. >>3. Failure detected during an in-flight invocation On this case you get an IOException indeed. >> Failure Handling "Ovidiu on Wiki Page" wrote : If there are active threads traversing the valve at the moment when "close" command arrives, those threads must be interrupted and put to wait until the valve opens again There is no way to interrupt those threads, but on the event of a failure, all of the inflight invocations are going to fail at the same time, and all of them will capture the failure trying to close the valve at the same time. This scenario is already implemented on Clebert_Third_Failover Branch. The is a slightly differences on the way implemented: - I only have one valve, so there is no recursivety on closing the valve. - There is no need for the "command center" I guess, since a call on performFailover on ConnectionDelegate is already equivalent to "a failure has happened". View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999058#3999058 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999058

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