March 2009 - jboss-dev-forums - Jboss List Archives

[Design of JBoss jBPM] - A first look at the new participation model

by heiko.braun＠jboss.com

http://relative-order.blogspot.com/2009/03/jbpm-task-management-look-at.html View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222014#4222014 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222014

15 years, 9 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Server side thread leak?

by jesper.pedersen

Richard, the threads that identifies them self as "WorkManager" are from the JCA WorkManager thread pool. See | deploy/jca-jboss-beans.xml | The thread pool is backed by the implementation in the util project: | org.jboss.util.threadpool.BasicThreadPool | See http://www.jboss.org/community/docs/DOC-9324 for configuration options. The job of each thread is to execute a JCA Work instance - and then return to the pool. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221997#4221997 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4221997

15 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Recent changes to the TaskService API

by heiko.braun＠jboss.com

I did some changes to the TaskService interface: * Added query methods by participation, i.e. List findTasksByParticipation(String participation, UserRef user); * Use IdentityRef (UserRef, GroupRef) where appropriate, i.e. void assignTask(long taskDbid, UserRef user); * changed Participant to Participation, i.e. Participation.getType() = 'candidate' It looks a little cumbersome in the beginning, but the distinction between user and group references was necessary. I.e. assignTask(long taskDbid, UserRef user) now makes clear that task can only be assigned to users, not groups. The previous signature 'void assignTask(long taskDbid, String id)' didn't reveil that intention. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221993#4221993 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4221993

15 years, 9 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Server side thread leak?

by galder.zamarreno＠jboss.com

Re: https://jira.jboss.org/jira/browse/JBAS-6665 Ron/Richard, is this happening in clustered or non clustered tests? Or both? My thoughts: Unified invokers (read EJB2) do not work like the the EJB3 ones. The unified one caches client in the very 1st invocation and uses that all the time (versus create/connect/disconnect for every invocation). In the case of clustered unified invoker, every time a new locator is used, a new client is created and used. While the same locator is used invocation after invocation, the same client is used. When the locator changes, a new client is created and connected to. Not sure whether EJB2s should work exactly the same as EJB3s. In the case of non-clustered unified invoker, caching and reusing the same client all the time would probably yield better performance. When would we call disconnect in this case? Dunno right now. In the case of clustered invokers, I think disconnecting the current client before creating/connecting a new one would make sense as otherwise you're leaking clients (this probably needs a jira, FAO Brian thoughts?) Finally, why is the default value not to run the idle timeout task? For EJB2 non clustered beans, with current design, this idle timeout functionality should be enabled if we wanna leave it as it is. Actually, probably with clustered as well, (i.e. SFSBs that have first available lbp). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221979#4221979 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4221979

15 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Consumer max rate tests

by timfox

Ok, that's fine, as long as you're confident there are no nasty side effects such as messages building up in the client side buffer View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221899#4221899 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4221899

15 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Outstanding JIRAs for next release of JBM 1.4 (1.4.0.SP3-CP0

by gaohoward

JBMESSAGING-1416 Provide complete message ordering Features pretty much done on branch if no more requests/feedback. Only need to merge to Branch_1_4. JBMESSAGING-1131 Add configuration for Remoting servlet transport Already done but taken back as it depends on JBoss Remoting 2.2.2.SP12 (will be released and go into next EAP). Need to put it back when SP12 is out. JBMESSAGING-1517 Malformed HTTP POST from Post Office management page in JMX Console This is not an JBM issue actually. It depends on https://jira.jboss.org/jira/browse/JBAS-6627. JBMESSAGING-1480 Specify Lock datarow on Sybase create tables Not fixed yet. It should be some configuration changes. Will fix it into next release. JBMESSAGING-1561 ConnectionFactoryCallbackHandler$CallbackConnectionListener should call disconnectTimeout(0) in connection failure handling Not fixed yet. Should be a very simple change. Will fix it into next release. JBMESSAGING-1491 add support for Ingres RDBMS to JBoss Messaging Not implemented yet. Need some effort to get it done. As it is not high priority, we can postpone it after the next release. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221888#4221888 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4221888

15 years, 9 months

1
0
0 / 0

[Design of JBoss Identity] - findRoleTypes(IdentitySearchControl[] controls) API discussi

by jeff.yuchang

In the RoleManager API, Collection findRoleTypes(IdentitySearchControl[] controls) throws IdentityException; If users pass a 'null' for this method, it will return all of RoleTypes, my question is that is it better that we have a method like: getAllRoleTypes() to return all of available role types, instead of passing a null parameter in the API level. The implementation could be resuing as what we have now, as at first sight, I was not sure how can I get all available role types. Thoughts? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221878#4221878 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4221878

15 years, 9 months

1
0
0 / 0

[Design of POJO Server] - Re: Explicit listing of Boot Classpath

by ALRubinger

"wolfc" wrote : It's the job of the classloader facilities to come up with something that makes service binding manager deployable. Yes. To be more clear on the target question: What's the correct approach - to stick with this explicit list, or put only stuff in $JBOSS_HOME/lib which can be used at boot? If it's the latter, I'll add lib scanning w/ a temporary excludes mechanism to jboss-bootstrap. S, ALR View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221842#4221842 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4221842

15 years, 9 months

1
0
0 / 0

[Design of POJO Server] - Re: Explicit listing of Boot Classpath

by wolfc

JBoss Bootstrap should only have these dependencies: [INFO] [dependency:tree] | [INFO] org.jboss.bootstrap:jboss-bootstrap:jar:1.0.0-SNAPSHOT | [INFO] +- org.jboss.logging:jboss-logging-log4j:jar:2.0.5.GA:test | [INFO] | \- apache-log4j:log4j:jar:1.2.14:test | [INFO] +- org.jboss.man:jboss-managed:jar:2.0.0.GA:compile | [INFO] | +- org.jboss.man:jboss-metatype:jar:2.0.0.GA:compile | [INFO] | | +- org.jboss:jboss-reflect:jar:2.0.1.GA:compile | [INFO] | | +- org.jboss.logging:jboss-logging-spi:jar:2.0.5.GA:compile | [INFO] | | \- org.jboss:jboss-common-core:jar:2.2.9.GA:compile | [INFO] | +- org.jboss:jboss-mdr:jar:2.0.1.GA:compile | [INFO] | \- sun-jaxb:jaxb-api:jar:2.1.4:compile | [INFO] +- org.jboss.microcontainer:jboss-kernel:jar:2.0.4.GA:compile | [INFO] | +- org.jboss.microcontainer:jboss-dependency:jar:2.0.4.GA:compile | [INFO] | \- org.jboss:jbossxb:jar:2.0.0.GA:compile | [INFO] | +- apache-xerces:xml-apis:jar:2.9.1:compile | [INFO] | +- apache-xerces:xercesImpl:jar:2.9.1:compile | [INFO] | +- wutka-dtdparser:dtdparser121:jar:1.2.1:compile | [INFO] | \- javax.activation:activation:jar:1.1.1:compile | [INFO] \- junit:junit:jar:4.5:test Maybe we can get rid of jboss-managed, I don't know. It's the job of the classloader facilities to come up with something that makes service binding manager deployable. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221832#4221832 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4221832

15 years, 9 months

1
0
0 / 0

[Design of POJO Server] - Re: Explicit listing of Boot Classpath

by ALRubinger

"ALRubinger" wrote : Probably the real issue is not a CNFE a this point, but the loading of some extra JAR is triggering some scanning/deployment prematurely. If this is the case, might be good to go to a "scan lib directory, but apply some explicit excludes" logic as a more maintainable interim solution. S, ALR View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221827#4221827 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4221827

15 years, 9 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 March 2009