November 2008 - jboss-dev-forums - Jboss List Archives

[Design of JBoss ESB] - Re: ServiceInvoker / deliver in new transaction

by Kevin.Conner＠jboss.com

If you want to use deliverySync, and are not in a position to rearchitect the request using async messaging (see http://www.jboss.org/community/docs/DOC-9105 for an example), then the best solution is to execute the deliverSync within a method using @NotSupported. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193016#4193016 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193016

16 years, 1 month

1
0
0 / 0

[Design of JBoss ESB] - Re: ServiceInvoker / deliver in new transaction

by mark.little＠jboss.com

Hi Bernd. We've had a few people (not many) ask about this in the past. Yes it could be supported, but the whole philosophy behind ESB is SOA which is about loose coupling. The synchronous request-response pattern that we are used to in other areas is not the default one that we would encourage. There are quite a few papers and articles on the Web about how and why one-way interactions are more appropriate. In that situation, a single global transaction does not work and something like JMS transacted sessions, or compensation transactions (e.g., WS-BA) is better. However, there are still some cases where a single transaction that encapsulates the sending of the request and all work done by that request (including possible any other onward calls the initial receiver may make) is needed. It's just not something that we support at the moment. But I'm sure it will come eventually (e.g., through the eventually support of WS-AT or JTS). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193013#4193013 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193013

16 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: Allow unlocking Token without knowing the lock owner

by tom.baeyens＠jboss.com

the execution is also locked when sleeping. you are probably mixing with acquisition of jobs before they get executed. that is something else to make sure that a job is only executed once in a clustered env. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193011#4193011 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193011

16 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Re-deploying not-deployed deployment after adding new De

by adrian＠jboss.org

"alesj" wrote : | I'll add a JIRA. | When should we target this? 2.0.1 or 2.2.0? | Its a feature request, it gets done when it gets done. anonymous wrote : btw: is there a JIRA for your isDeployed todo? No, have we even decided how to do it? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193010#4193010 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193010

16 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: jpdl 3.3.GA / Why isn't the jar provided?

by tom.baeyens＠jboss.com

the suite got replaced by the installer. but i agree with you that we should have done a better job of producing exactly the same runtime installation as the suite produced before. regards, tom. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193009#4193009 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193009

16 years, 1 month

1
0
0 / 0

[Design of JBoss ESB] - ServiceInvoker / deliver in new transaction

by camunda

Hi. I have an issue with the ServiceInvoker: When you want to use deliverSync in a transactional context (let's say in a EJB3-SLSB) and you use JMS as provider, this will not work correctly. Since the JMS message will be delivered in the transaction of the SLSB the ESB cannot start work before the transaction commits. But in deliverSync we wait for an answer (which cannot come). If I need a deliverSync within transactional context, my only possibility is to use deliverAsync in an own transaction and then wait for an answer, like this: | try { | // if we get an exception in the next method this transaction is rolled back as well | callDeliverSyncInOwnTransaction(); | // now the ServiceInvoker succeeded, so the service is called correctly | Message m = waitForAnswer(); | // do something with answer | } | catch (TimeoutException ex) { | // OK, now we need some clever code to handle this situation! | // message sent but the answer timed out and will come sometime in future | } | This behavior isn't really supported by the ServiceInvoker out of the box, or did I miss something? I would need to implement that callDeliverSyncInOwnTransaction myself (maybe I could use a SLSB method with @RequiresNew, or without using EJB I could suspend the transaction, create a new one, send and commit and resume the old one via the TransactionManager directly) and the waitForAnswer. Would be cool if the ESB supports this pattern out of the box, or what do you think? Since the deliverSync is quite powerfull, but more or less useless in JTA/JMS environment. Cheers Bernd P.S: Sorry if this is the wrong forum, wasn't sure about using User or Developer Forum, please move it accordingly if you think it is wrong... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193008#4193008 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193008

16 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-6105; Improve start-up time

by dimitris＠jboss.org

See also https://www.jboss.org/community/docs/DOC-13178 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193006#4193006 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193006

16 years, 1 month

1
0
0 / 0

[Design of JBoss Profiler] - Re: Web app fails to start - managed beans missing no-argume

by rhills

"jesper.pedersen" wrote : A quick follow-up -- look into the CombinedFrameInfo class in the client package which maybe what you are looking for. | | Or create a class hierarchy like ThreadInfoManagedBean -> ThreadInfo -> FrameInfo -- where the last two are from shared and be used in the web ui since they implements Serializable. ThreadInfoManagedBean is a managed bean with a non-arg constructor and defined in faces-config.xml | | Hope this gives you an idea... It does thanks. As it happens, ThreadInfo is only used in xhtml as a class to hold row data (from treeThreadBean.allThreads where treeThreadBean is a legitimate managed bean. Hence I don't believe I'll need to create a managed bean for ThreadInfo, I can simply remove it from faces-config.xml. From my brief look into the faces-config.xml file it appears that a number of classes have been defined in there as managed beans that shouldn't have been (eg ThreadInfo, Snapshot, FrameInfo, AllocationInfo and others, none of which are referenced anywhere in the .xhtml as managed beans). I'll investigate each one and remove as necessary. If a bean is needed, I'll abstract one into the .web package as discussed. Cheers, Rob Hills Waikiki, Western Australia View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193002#4193002 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193002

16 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Re-deploying not-deployed deployment after adding new De

by alesj

"adrian(a)jboss.org" wrote : I didn't have time to do this logic when I wrote the deployers | but I remember putting some FIXMEs in the original version of the code. This is the only FIXME in Deployers. | // FIXME add method change logging levels to AbstractTestCase | Logger.getLogger(FileSystemContext.class).setLevel(Level.INFO); | I guess I removed them in my re-factoring frenzy. :-) I'll add a JIRA. When should we target this? 2.0.1 or 2.2.0? btw: is there a JIRA for your isDeployed todo? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4192992#4192992 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4192992

16 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Re-deploying not-deployed deployment after adding new De

by alesj

"adrian(a)jboss.org" wrote : Well the real solution is to determine whether the new deployer applies | to ANY of the existing deployments and unwind them back to where | the new deployer has appeared. | | Deployers disappearing would be pretty much the same | since you've got to allow the removed deployer to unwind whatever processing | it did to the deployment. | I guess this is doable based on attachments? e.g. adding some | boolean isApplied(DeployementUnit unit); | where we would in most cases be able to generically determine if we need unwind/rewind. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4192990#4192990 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4192990

16 years, 1 month

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 November 2008