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

[Design of JBoss ESB] - Re: username, password & domain in Action for the soapClient

by tfennelly

"akfs" wrote : thanks, but I want to programatically add username, password and domain in the Action for the soap client. Is it possible And where do you want the username and password to come from? You could specify these in the Smooks config and have them applied through there. You really need to supply us with more info!! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4109954#4109954 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4109954

17 years

1
0
0 / 0

[Design of JBoss ESB] - Re: username, password & domain in Action for the soapClient

by akfs

The article discusses about basic authentication for HTTP Client, I want to do NTLM or digest Authentication in HTTP Client, or how can we put http headers View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4109947#4109947 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4109947

17 years

1
0
0 / 0

[Design of EJB 3.0] - Re: Annotation to metadata issues

by scott.stark＠jboss.org

"wolfc" wrote : | For now I would say a post-condition on metadata that these simple resource injections must have the correct mapped name. | Note that in the end the EJB container will still optimize an injection. So the code in ResourceHandler must stay. The only thing that can set the mapped name is the annotation creator if its not going to be a deployer. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4109946#4109946 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4109946

17 years

1
0
0 / 0

[Design of JBoss ESB] - Re: username, password & domain in Action for the soapClient

by akfs

thanks, but I want to programatically add username, password and domain in the Action for the soap client. Is it possible View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4109938#4109938 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4109938

17 years

1
0
0 / 0

[Design of JBoss ESB] - Re: username, password & domain in Action for the soapClient

by tfennelly

You can specify a Smooks transform. See the end of the SOAPClient wiki page. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4109933#4109933 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4109933

17 years

1
0
0 / 0

[Design of JBoss ESB] - username, password & domain in Action for the soapClient

by akfs

I want to know how can we add username, password and domain for accessing a webservice hosted by Sql server 2005. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4109927#4109927 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4109927

17 years

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBTHREE-1142 - Incomplete fix - Generic problem

by adrian＠jboss.org

"wolfc" wrote : | We then should resume the suspended tx. Oh bugrit, this will get complicated with the tidy up hack in there. What do we do if we have a suspended and a 'wrong' tx? Are you talking about | // Suspend any bad transaction - there is bug somewhere, but we will try to tidy things up | if (currentTx != null && currentTx.equals(transaction) == false) | { | log.warn("Current transaction " + currentTx + " is not the expected transaction."); | tm.suspend(); | tm.resume(transaction); | } | The log message should really be something like: | log.warn("SOMEBODY HAS PLAYING WITH THINGS THEY DON"T UNDERSTAND!"); | So there are more serious problems anyway. This has nothing to do with the endpoint's state so there is no need to invalidate it. A rollback exception when you attempt commit() is expected e.g. optimistic failure in the database, etc. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4109905#4109905 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4109905

17 years

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBTHREE-1142 - Incomplete fix - Generic problem

by wolfc

I was thinking about putting a TODO there. I don't want to disassociate when there is an error on rollback or commit. In that case we have bigger problems. The whole MessageInflowLocalProxy should be invalidated then. Hmm, except for heuristic exceptions. We then should resume the suspended tx. Oh bugrit, this will get complicated with the tidy up hack in there. What do we do if we have a suspended and a 'wrong' tx? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4109902#4109902 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4109902

17 years

1
0
0 / 0

[Design of POJO Server] - Re: Embbedded - broken - some fixes - still not working

by epbernard

Carlo, I think the URL you describe should be accepted by HEM (as it is a spec compliant root URL: chapter 6.2 of ejb3.0-persistente). I've opened a JIRA issue http://opensource.atlassian.com/projects/hibernate/browse/EJB-326 If you remember how it failed, please comment on the bug report. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4109887#4109887 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4109887

17 years

1
0
0 / 0

[Design of EJB 3.0] - EJBTHREE-1142 - Incomplete fix - Generic problem

by adrian＠jboss.org

I linked this issue to where it was originally reported http://jira.jboss.com/jira/browse/JBAS-4980 But the fix shows what is generally wrong with a lot of the EJB3 code (especially the deployment stuff). | | // Commit or rollback depending on the status | if (commit == false || transaction.getStatus() == Status.STATUS_MARKED_ROLLBACK) | { | if (trace) | log.trace("MessageEndpoint " + getProxyString(proxy) + " rollback"); | tm.rollback(); | } | else | { | if (trace) | log.trace("MessageEndpoint " + getProxyString(proxy) + " commit"); | tm.commit(); | } | | // We're done with the transaction | transaction = null; | So if tm.commit() throws an error, the transaction variable is not cleared meaning the problem is not fixed. The nulling of the transaction variable should be in the finally block further down: | finally | { | + transaction = null; | | // Resume any suspended transaction | if (currentTx != null) | { | try | { | tm.resume(currentTx); | } | catch (Throwable t) | { | log.warn("MessageEndpoint " + getProxyString(proxy) + " failed to resume old transaction " + currentTx); | | } | } | } | Basically, the code works great under normal circumstances but falls apart on any error. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4109874#4109874 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4109874

17 years

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 December 2007