May 2010 - jboss-dev-forums - Jboss List Archives

Re: [jboss-dev-forums] [jBPM Development] - JBPM-2537

by Maciej Swiderski

Maciej Swiderski [http://community.jboss.org/people/swiderski.maciej] replied to the discussion "JBPM-2537" To view the discussion, visit: http://community.jboss.org/message/541171#541171 -------------------------------------------------------------- Hi, patch uploaded to jira, please review it and let me know your comments. If it comes to committing I think Alejandro needs to approve it since it is a change of the API. So let's hope he can find some time to look into it as well. Cheers, Maciej -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/541171#541171] Start a new discussion in jBPM Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-dev-forums] [Management Development] - domain.xml work

by Jason Greene

Jason Greene [http://community.jboss.org/people/jason.greene%40jboss.com] replied to the discussion "domain.xml work" To view the discussion, visit: http://community.jboss.org/message/541168#541168 -------------------------------------------------------------- > David Lloyd wrote: > > The terms I suggest are: > * *Server Manager* (formerly *NodeAgent*) as the module which is responsible for coordinating with the *Domain Controller* to control the lifecycle of *Server* processes, the distribution of deployments from the *Domain Controller* to the *Server* instances, and the management of the *Installed Image* > * *Server Manager Process* as a JVM instance which runs the *Server Manager* exclusively > * Formalize Brian's *Installed Image* term as-is > * Formalize Brian's *Domain Controller* term as-is > I think server manager is a much better name, as we don't have a "node" construct in the topology. The more explicit definitions of domain controller and install image match my understanding of the discussions we had in Westford. So yeah I agree with all of these. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/541168#541168] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss XML Binding Development] - JBJPA-27 and setting PersistenceUnitMetaData reference to PersistenceMetaData

by Scott Marlow

Scott Marlow [http://community.jboss.org/people/smarlow%40redhat.com] replied to the discussion "JBJPA-27 and setting PersistenceUnitMetaData reference to PersistenceMetaData" To view the discussion, visit: http://community.jboss.org/message/541150#541150 -------------------------------------------------------------- I gave this a shot ( http://pastebin.com/erW3G8dp http://pastebin.com/erW3G8dp), seems to work well. I didn't bother implementing List.addAll() varients, but will if anyone feels I should? -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/541150#541150] Start a new discussion in JBoss XML Binding Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-dev-forums] [jBPM Development] - Insert user information for process instance

by Michael Wohlfart

Michael Wohlfart [http://community.jboss.org/people/mwohlf] replied to the discussion "Insert user information for process instance" To view the discussion, visit: http://community.jboss.org/message/541141#541141 -------------------------------------------------------------- Hi HuiSheng, > [...] The most easiest way to store the start of a process is extending the JBPM4_EXECUTION, we could add a starter column, or something like this. > [...] > I read the related forum posts and the JIRA about this, maybe i still miss the point here, but extending the JBPM4_EXECUTION table for this seems wrong to me. A much better approach imho would be to keep that information in a swimlane like it is done in JBPM3 ( see: http://docs.jboss.org/jbpm/v3/userguide/taskmanagement.html http://docs.jboss.org/jbpm/v3/userguide/taskmanagement.html section 11.7) ...and thanks for your great work on jBPM4 -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/541141#541141] Start a new discussion in jBPM Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-dev-forums] [Management Development] - domain.xml work

by David Lloyd

David Lloyd [http://community.jboss.org/people/david.lloyd%40jboss.com] replied to the discussion "domain.xml work" To view the discussion, visit: http://community.jboss.org/message/541118#541118 -------------------------------------------------------------- The terms I suggest are: * *Server Manager* (formerly *NodeAgent*) as the module which is responsible for coordinating with the *Domain Controller* to control the lifecycle of *Server* processes, the distribution of deployments from the *Domain Controller* to the *Server* instances, and the management of the *Installed Image* * *Server Manager Process* as a JVM instance which runs the *Server Manager* exclusively * Formalize Brian's *Installed Image* term as-is * Formalize Brian's *Domain Controller* term as-is -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/541118#541118] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-dev-forums] [jBPM Development] - JBPM-2537

by Sebastian Schneider

Sebastian Schneider [http://community.jboss.org/people/sebastian.s] replied to the discussion "JBPM-2537" To view the discussion, visit: http://community.jboss.org/message/541109#541109 -------------------------------------------------------------- Hi Huisheng Xu! I should have noticed that you've been talking about the outdated version of the patch. So nevermind. The great news are that we can go ahead and apply patchs having a solution for both issues. Sebastian -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/541109#541109] Start a new discussion in jBPM Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-dev-forums] [jBPM Development] - JBPM-2537

by Sebastian Schneider

Sebastian Schneider [http://community.jboss.org/people/sebastian.s] replied to the discussion "JBPM-2537" To view the discussion, visit: http://community.jboss.org/message/541108#541108 -------------------------------------------------------------- Hi Maciej! Thanks for taking the time to look deeper into the issue. I now recall the discussion I had with Ronald. He was not satisfied with the first solution because we have been changing an Interface and was afraid of breaking backwards compatibility. That was the reason he introduced a new Interface in his version of the patch. So it seems we can go ahead and apply the patch. Sebastian -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/541108#541108] Start a new discussion in jBPM Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss XML Binding Development] - JBJPA-27 and setting PersistenceUnitMetaData reference to PersistenceMetaData

by Scott Marlow

Scott Marlow [http://community.jboss.org/people/smarlow%40redhat.com] replied to the discussion "JBJPA-27 and setting PersistenceUnitMetaData reference to PersistenceMetaData" To view the discussion, visit: http://community.jboss.org/message/541073#541073 -------------------------------------------------------------- It is null. Stack trace is here http://pastebin.com/YQNhmY3T http://pastebin.com/YQNhmY3T This is using xb version 2.0.2.Beta1. Maven dependency tree is shown here with other version info http://pastebin.com/hwL3NmCC http://pastebin.com/hwL3NmCC -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/541073#541073] Start a new discussion in JBoss XML Binding Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-dev-forums] [JCA Development] - JcaXAResourceRecovery

by Jesper Pedersen

Jesper Pedersen [http://community.jboss.org/people/jesper.pedersen] replied to the discussion "JcaXAResourceRecovery" To view the discussion, visit: http://community.jboss.org/message/541069#541069 -------------------------------------------------------------- > I may be misunderstandin ghte model, but it seems that ManagedConnectionFactoryDeployment.getXAResources() creates a new connection on each call, which is good in that if the db crashes and recovers whilst the app servers stays up, the system will effectively reconnect rather than continuing to use a stale connection. However, as far as I can tell, it's never disposing those connections. Since the recovery system will make one pass every two minutes by default, it's going to leak pretty badly. The integration SPI does not allow for explicit disposal, so the best bet is probably to keep a handle on the last connection used and on each call to getXAResources either validate it (i.e. ping the db to make sure it's still there) and reuse it, or explicitly release it and get a new one. Fixed. Thanks. As to the explicit close case - I need to know when recovery have been done in order to cleanup and destroy the managed connection, and the JCA API doesn't have an SPI for that (yet). Maybe we could add recoveryBegin() and recoveryEnded() to our interface ? As to the validate case - I'll think about what we can do to best handle this case and commit something, if we aren't going with the idea above. > The XAResourceWrapperImpl usage appears to be applied only to XAResources used for recovery, not he ones used during normal transaction usage. It would be helpful to have the same wrapping applied to the XAResource handed out to the transaction manager during normal operation, as that would allow correlation in the logs between the tx run and the recovery. I'm guessing that's a fairly minor cutnpaste type fix - any chance of squeezing it in? Normal transaction usage is handled in the TxConnectionManager class, where the interface is used (if enabled). So we should be good in that case :) There is room for a lot of improvements both in the JCA spec and the JCA container to make life easier for our users - I'll keep this in mind for the new implementation. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/541069#541069] Start a new discussion in JCA Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 months

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss Web Services Development] - CXF jms integration

by Richard Opalka

Richard Opalka [http://community.jboss.org/people/richard.opalka%40jboss.com] replied to the discussion "CXF jms integration" To view the discussion, visit: http://community.jboss.org/message/541050#541050 -------------------------------------------------------------- Hi Jim, let me agree with Alessio. We really don't need to introduce another DD (jbossws-endpoints.xml namely). There are two reasons for that: * XML configuration duplicity (as Alessio properly said users can just provide jbossws-cxf.xml with all the configuration) * simplicity (our current SPI facade should be enough for you to do the job). What you're doing (providing jbossws-endpoints.xml) is just creating WS stack agnostic configuration. But our SPI is intended exactly for that purpose. Providing additional DD is the same thing like our SPI (just different XML-ized form of it). If you will follow my suggestions I wrote few days before you shoudn't face "real" problems. Another thing/issue is our SPI is not perfect (and we know that). We will improve/rewrite our SPI once we'll be done with all the highier priority tasks we have these days. > Jim Ma wrote: > I evaluated to make new SPI metadata to extend the current SPI Endpoint. But I did not find benifit from it, as our DeploymentAspects was intended to process the SPI HttpEndpoint. It can not be reused to process JMSEndpoint too. > Let me disagree. This is the way you had to go IMHO ;) We need these abstractions in our SPI: * Endpoint - ServletEndpoint -> url address - JMSEndpoint -> jms address * DA - ServletDA - JMSDA Our ASIL deployers will accept DA abstraction and will be able to distinguish between HTTP and JMS. In deployer, before specifying inputs/outputs, you should have code like this: // pseudocode ensuring proper deployers ordering if (DA instanceof ServletDA) { this.addInput(WebMetaData.class); ... } else if (DA instanceof JMSDA) { this.addInput(JMSMetaData.class); ... } Both HTTP and JMS endpoints should use the same deployers flow. Don't create another deployer flow just for JMS endpoints. but reuse our current architeture. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/541050#541050] Start a new discussion in JBoss Web Services Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 11 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 May 2010