April 2008 - jbossws-dev - Jboss List Archives

[Design of JBoss Web Services] - Re: jbossws-common vs. jbossws-framework

by heiko.braun＠jboss.com

anonymous wrote : | yada yada | common is 'common'. framework is an implementation of the SPI. You can live without the later by providing your own, but you cannot live without common. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142702#4142702 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142702

16 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: jbossws-common vs. jbossws-framework

by richard.opalka＠jboss.com

I don't know the background of decision to keep separate common and framework code bases. However it doesn't make a sence to me :( For me both framework and common are both common. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142590#4142590 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142590

16 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - jbossws-common vs. jbossws-framework

by thomas.diesler＠jboss.com

Folks, please remind me why we have jbossws-common *and* jbossws-framework. Apart from: "yada yada ... academic .. yada yada" - that I have probably come up with myself. Is there any real use to maintain the jbossws-common code base separately? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142565#4142565 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142565

16 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Web Service Transactions Implementation: Configuring WS

by adinn

. . . and the answer is? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142468#4142468 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142468

16 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Web Service Transactions Implementation: Configuring WS

by mark.little＠jboss.com

I can answer for WS-Addressing since I'm a co-author. Can't answer for JAX-WS. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142452#4142452 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142452

16 years, 1 month

1
0
0 / 0

Running the jbossws testsuite against cxf-2.0.5

by Thomas Diesler

Hi Folks, we (jboss) are in the process of migration our jbossws-native tests to a common testsuite that will run against all supported stacks. http://jbws.dyndns.org/mediawiki/index.php?title=JBossWSSupportedStackCom... We expect to see a number of failures with the respective stacks for which I plan to create individual jira issues. All failing tests will get listed in our exclude file and hance will make it into the next jbossws-cxf release notes. Over the course of the next few releases we can then work to reduce these failures if needed. cheers -thomas -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Thomas Diesler Web Service Lead JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx

16 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBossWS 2.1 embedded?

by heiko.braun＠jboss.com

The SPI 3.0 will bring embedded functionality View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142348#4142348 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142348

16 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Web Service Transactions Implementation: Configuring WS Addr

by adinn

Well, the good news is that I've just successfully converted my Web Service Transactions (WSCOOR/WSAT/WSBA 1.1) implementation over JaxWS which was running on Glassfish to run successfully on JBossWS native 3.0.1/AS 5.0.0.B4. So, thank you for delivering this latest release. There's not really any corresponding bad news but the port from Glassfish has thrown up an interesting issue regarding the combined use of WS AddressingProperties and W3CEndpointReference instances. The WS-T protocols require use of both these datatypes for the following reasons. WSCOOR services hand out endpoints to clients to provide access to related services; endpoints are configured with reference parameters which are automatically attached to service requests to identify the transaction context. The asynchronous messaging protocol requires clients and services to configure WSAddr MessageIds and validate WS-Addr RelatesTo properties in order to tie together certain sequences of messages. Services also need to specify the WSAddr Action associated with a request. So, at various points where a service request is performed the client needs to obtain a port from its endpoint and then configure the MessageIdand Action properties to be used for the resulting communication. Here is a typical bit of code which does this job: | . . . | CompletionInitiatorService service = getCompletionInitiatorService(); | CompletionInitiatorPortType port = service.getPort(endpointReference, CompletionInitiatorPortType.class); | BindingProvider bindingProvider = (BindingProvider)port; | List<Handler> customHandlerChain = new ArrayList<Handler>(); | | /* | * we have to add the JaxWS WSAddressingClientHandler because we cannot specify the WSAddressing feature | */ | customHandlerChain.add(new WSAddressingClientHandler()); | bindingProvider.getBinding().setHandlerChain(customHandlerChain); | Map<String, Object> requestContext = bindingProvider.getRequestContext(); | AddressingProperties requestProperties = (AddressingProperties)requestContext.get(JAXWSAConstants.CLIENT_ADDRESSING_PROPERTIES_OUTBOUND); | // overlay supplied addressing properties on request properties | AddressingHelper.installCallerProperties(addressingProperties, requestProperties); | // we should not need to do this but currently JBossWS does not pick up the value in the addressing properties | requestContext.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, requestProperties.getTo().getURI().toString()); | return port; | Ignore the hand cranking of the WS Addressing handler and endpoint address property -- they are stop-gaps until the WSAddressing Feature is fully functional. Now, this works because I know that the call to getPort installs an AddressingProperties instance on the port under the outbound client addressing properties property of the request context. This instance is configured with the To address embedded in the W3CEndpointReference. It's ReferenceParameters field has also been initialised using the reference parameters embedded in the W3CEndpointReference. The call to AddressingHelper.installCallerProperties adds the Action and MessageId. It overlays non-null fields found in the supplied AddressingProperties instance, addressingProperties, onto requestProperties, the instance obtained from the port. Now, in the Glassfish implementation there was no client addressing properties instance on the request context, So, I had to install my own addressing properties in order to supply the MessageId and Action. This caused a problem because there was no To field specified in AddressingProperties (it's embedded in the opaque W3CEndpointReference so only the Glassfish implementation can get at it). Glassfish actually makes the address available using the endpoint address property -- the call to getPort installs this on the requestContext via the endpoint address property. It also somehow managed to install the reference parameters into the message but they were not available via the requestContext as far as I could see. So, I had to fetch the address from the requestContext and install it in my addressing properties before installing them i.e. | . . . | CompletionInitiatorService service = getCompletionInitiatorService(); | CompletionInitiatorPortType port = service.getPort(endpointReference, CompletionInitiatorPortType.class); | BindingProvider bindingProvider = (BindingProvider)port; | List<Handler> customHandlerChain = new ArrayList<Handler>(); | | /* | * we have to add the JaxWS WSAddressingClientHandler because we cannot specify the WSAddressing feature | */ | customHandlerChain.add(new WSAddressingClientHandler()); | bindingProvider.getBinding().setHandlerChain(customHandlerChain); | Map<String, Object> requestContext = bindingProvider.getRequestContext(); | String address = (String)requestContext.get(BindingProvider.ENDPOINT_ADDRESS_PROPERTY); | try { | addressingProperties.setTo(builder.newURI(address)); | } catch (URISyntaxException use) { | // TODO -- log unexpected error here | } | requestContext.put(JAXWSAConstants.CLIENT_ADDRESSING_PROPERTIES, addressingProperties); | return port; | So, my question is how can I guarantee that this merging of the client and endpoint addressing properties will be performed correctly. I am obviously concerned about what happens with JBossWS-Metro/CXF and would hope that I can rely upon the first code example above working on these ports. If not then we need to establish some way of making this work. Also, it would be nice to know if there is supposed to be some sort of standard way of doing this. In the absence of any such standard I would be interested to know whether and how far this requirement was considered when defining the WS Addr and JaxWS specs and when implementing this for JBossWS. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142302#4142302 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142302

16 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Hudson file permissions

by richard.opalka＠jboss.com

Then I would go this way. There will be no need to rewrite hudson scripts and play with file permissions and deal with deep directory structures (time consuming issue) ;) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142011#4142011 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142011

16 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Hudson file permissions

by thomas.diesler＠jboss.com

yeah, I was thinking about a dedicated user as well. Then again | > su -l | > su whoever | will probably do the same View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142008#4142008 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142008

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

jbossws-dev April 2008