[JBossWS] - Re: sending Soap message with timeout
by alessio.soldano＠jboss.com
The point here is SAAJ does not define an API for setting the timeout directly using the SOAPConnection. So you need to use some kind of proprietary stuff.
Forget about Axis, you can't use it with JBossWS. Take a look at the JBossWS-Native (I assume that's what you're using) org.jboss.ws.core.client.HTTPRemotingConnection that is used under the hood by org.jboss.ws.core.soap.SOAPConnectionImpl (which in turn is the JBossWS-Native impl of SOAPConnection).
HTTPRemotingConnection basically receives and endpoint object which can be an instance of EndpointInfo. That can contain a properties map including org.jboss.ws.timeout property. Setting that, you should be able to basically achieve what you get setting the same prop in the request context when performing a call through a ws port.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4243831#4243831
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4243831
17 years
[Microcontainer] - Re: Installing a context leads to resolve of other unrelated
by jaikiran
"alesj" wrote :
| Or how else are you gonna know what and when something can be moved?
|
Isn't that the job of the deployers (ex: BeanMetadataDeployer) to install (which internally will move it to various states) the specific context(s)?
"alesj" wrote :
| e.g. you might have some implicit dependencies
| * some bean sets some static flag, the other one inspects that as its dependency
| * we put something into JNDI, something else tries to pull that out
|
Shouldn't an implicit dependency be turned (by some piece of code) into an explicit dependency? For #1, the other bean is actually depending on the "some bean" for the static flag, so shouldn't this dependency be created explicitly? Same holds for #2
"alesj" wrote :
| Not to mention it would be too much + duplicated work to check for only those which might be affected by this new install / move.
| Whereas this is simple, but pretty much bullet proof concept.
Looking at what resolveContexts does:
1) Get "all" possible From and To states
2) Try to resolve "all" contexts for each of these From state to To state
3) #2 internally involves resolving dependencies of each of these contexts
4) Install any resolved contexts
Isn't this expensive (correct me if i am wrong) and is being done for every context being installed.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4243825#4243825
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4243825
17 years