March 2008 - jbossws-dev - Jboss List Archives

[Design of JBoss Web Services] - Re: Integration metro

by heiko.braun＠jboss.com

anonymous wrote : | Metro 3rd party thats not available through repo.jboss.com | Basically, we make sure that anything that is shared with the AS is provided through the repository. That requires identifying metro's thirdparty dependencies and and putting them into the repo. Anything else (Metro specific, mostly build artifacts) are pulled from the metro build. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136565#4136565 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136565

16 years, 10 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Integration metro

by thomas.diesler＠jboss.com

Yes, all of these jars are part of the metro build | <get src="${jboss.repository}/sun-jaxws/${sun-jaxws}/lib/FastInfoset.jar" dest="${thirdparty.dir}/FastInfoset.jar" usetimestamp="true" verbose="true"/> | <get src="${jboss.repository}/sun-jaxws/${sun-jaxws}/lib/http.jar" dest="${thirdparty.dir}/http.jar" usetimestamp="true" verbose="true"/> | <get src="${jboss.repository}/sun-jaxws/${sun-jaxws}/lib/jaxws-api.jar" dest="${thirdparty.dir}/jaxws-api.jar" usetimestamp="true" verbose="true"/> | <get src="${jboss.repository}/sun-jaxws/${sun-jaxws}/lib/jaxws-src.zip" dest="${thirdparty.dir}/jaxws-src.zip" usetimestamp="true" verbose="true"/> | <get src="${jboss.repository}/sun-jaxws/${sun-jaxws}/lib/jaxws-rt.jar" dest="${thirdparty.dir}/jaxws-rt.jar" usetimestamp="true" verbose="true"/> | <get src="${jboss.repository}/sun-jaxws/${sun-jaxws}/lib/jaxws-tools.jar" dest="${thirdparty.dir}/jaxws-tools.jar" usetimestamp="true" verbose="true"/> | <get src="${jboss.repository}/sun-jaxws/${sun-jaxws}/lib/jsr173_api.jar" dest="${thirdparty.dir}/jsr173_api.jar" usetimestamp="true" verbose="true"/> | <get src="${jboss.repository}/sun-jaxws/${sun-jaxws}/lib/jsr181-api.jar" dest="${thirdparty.dir}/jsr181-api.jar" usetimestamp="true" verbose="true"/> | <get src="${jboss.repository}/sun-jaxws/${sun-jaxws}/lib/jsr250-api.jar" dest="${thirdparty.dir}/jsr250-api.jar" usetimestamp="true" verbose="true"/> | <get src="${jboss.repository}/sun-jaxws/${sun-jaxws}/lib/mimepull.jar" dest="${thirdparty.dir}/mimepull.jar" usetimestamp="true" verbose="true"/> | <get src="${jboss.repository}/sun-jaxws/${sun-jaxws}/lib/saaj-api.jar" dest="${thirdparty.dir}/saaj-api.jar" usetimestamp="true" verbose="true"/> | <get src="${jboss.repository}/sun-jaxws/${sun-jaxws}/lib/saaj-impl.jar" dest="${thirdparty.dir}/saaj-impl.jar" usetimestamp="true" verbose="true"/> | <get src="${jboss.repository}/sun-jaxws/${sun-jaxws}/lib/sjsxp.jar" dest="${thirdparty.dir}/sjsxp.jar" usetimestamp="true" verbose="true"/> | <get src="${jboss.repository}/sun-jaxws/${sun-jaxws}/lib/stax-ex.jar" dest="${thirdparty.dir}/stax-ex.jar" usetimestamp="true" verbose="true"/> | <get src="${jboss.repository}/sun-jaxws/${sun-jaxws}/lib/streambuffer.jar" dest="${thirdparty.dir}/streambuffer.jar" usetimestamp="true" verbose="true"/> | Are they not? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136563#4136563 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136563

16 years, 10 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Integration metro

by richard.opalka＠jboss.com

I'm not sure if I understand you correctly. You don't like that we're mixing jars from METRO/trunk/thirdparty with METRO/glassfish-metro/output jars (something like generated thirdparty for GF), right? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136561#4136561 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136561

16 years, 10 months

1
0
0 / 0

[Design of JBoss Web Services] - Integration metro

by thomas.diesler＠jboss.com

This is related to http://jira.jboss.org/jira/browse/JBWS-1994 The metro-build-adapter.xml sais |  | | <fileset dir="${lib.runtime.dir}"> | <include name="jaxws-local-transport.jar"/> | <include name="stax-utils.jar"/> | <include name="txnannprocessor.jar"/> | <include name="wstx-asl-3.2.1.jar"/> | <include name="xmldsig.jar"/> | <include name="xws-security.jar"/> |  | <include name="resolver.jar"/> | </fileset> | Why do we have two sources to get thirdparty dependencies from? Should they not all be pulled from the glassfish metro build? It seems that the current build happily mixes metro dependencies from some previously released version and the current build. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136557#4136557 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136557

16 years, 10 months

1
0
0 / 0

Array test regression

by Thomas Diesler

Folks, we have regression with jaxrpc arrays http://jbws.dyndns.org:8180/hudson/job/Native-Core-AS-4.2.2/26/testReport/ Magesh, could this be related to http://fisheye.jboss.com/changelog/JBossWS/?cs=5933 cheers -thomas -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Thomas Diesler Web Service Lead JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx

16 years, 10 months

2
1
0 / 0

Interop endpoints down

by Thomas Diesler

Heiko, the interop endpoints are down http://jbossws.demo.jboss.com:8080/interop Could you please come up with a suggestion of how we can automatically verify that these are working? cheers -thomas -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Thomas Diesler Web Service Lead JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx

16 years, 10 months

1
0
0 / 0

Unfunctional TCK 5 Trunk

by Richard Opalka

Hi folks, The TCK 5 trunk is unfunctional at the moment (at least for unix platforms). Is there WIP on the TCK5 trunk or why this happen? It's not a blocker to me, because I worked around it locally. But I don't like unfunctional trunks :( The following is the error I was facing: *[/home/opalka][/home/opalka/tck/glassfish]>ant -f setup.xml setup Buildfile: setup.xml all: get.java.home: setup.init: check-java: get.java.home: setup.init: validate-java: [echo] Current Java Version 1.5.0_13 get.java.home: setup.init: do.copy.windows: do.copy.unix: **BUILD FAILED /home/opalka/tck/glassfish/setup.xml:132: The following error occurred while executing this line: /home/opalka/tck/glassfish/setup.xml:189: Warning: Could not find file /home/opalka/tck/glassfish/lib/install/templates/asenv.conf.template to copy. Total time: 1 second Richard

16 years, 10 months

2
2
0 / 0

Re: Web Service Stack for EAP 5

by Thomas Diesler

Hi Folks, We discussed this topic on Friday last week during our internal team workshop. As a result we came up with the idea of defining the set of required functionality for an enterprise ready web service stack and compare what we currently have in all three stacks. The result of this comparison would give us a clearer idea of how we want to move forward and how we distribute our available resources. http://jbws.dyndns.org/mediawiki/index.php?title=JBossWSSupportedStackCom... Native is the only certified stack, integration work for WS-TX pending, weak in the tools area. CXF has javaee5 certification pending, integration and documentation of extended functionality pending. Metro has javaee5 certification pending, integration and documentation of extended functionality pending. Metro is also considering their offer complete. My preferred strategy would be to gradually unlock more of the Metro/CXF functionality (maybe 20% of our time) and start the TCK effort for one of the stacks when/if we decide to replace our default stack. But instead of jumping to a conclusion, I would like to bounce this back to you for feedback. cheers -thomas Mark Little wrote: > I would have thought that JBossWS-native is the tier 1 because we know > we can support it now and then Metro and CXF as tier 2/3. Obviously > things may change in subsequent releases, as long as backward > compatibility isn't broken. > > Mark. > > > On 6 Mar 2008, at 22:16, Andrig T Miller wrote: > >> Mark and Thomas, >> >> Since we all are now on the same page about what version of our >> WS stack is in AS 5, the question now for EAP 5, is which web service >> stack, our own JBoss Native, CXF or Metro are we actually going to >> ship with EAP 5. Of course, whatever version it is needs to pass the >> Java EE 5 TCK, and not be missing anything we have supported from a >> feature perspective in previous EAP releases (4.2 and 4.3). The >> consensus, in the discussion so far, is that we also only want to ship >> one, and hence support one stack. >> >> Thoughts? >> >> Thanks. >> >> Andrig (Andy) Miller >> VP of Engineering >> JBoss, a division of Red Hat >> > > ---- > Mark Little > mlittle(a)redhat.com <mailto:mlittle@redhat.com> > > JBoss, a Division of Red Hat > Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod > Street, Windsor, Berkshire, SI4 1TE, United Kingdom. > Registered in UK and Wales under Company Registration No. 3798903 > Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons > (USA) and Brendan Lane (Ireland). > -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Thomas Diesler Web Service Lead JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx

16 years, 10 months

2
1
0 / 0

[Design of JBoss Web Services] - Re: RM Sender/Receiver as High Available (HA) Components

by richard.opalka＠jboss.com

"richard.opalka(a)jboss.com" wrote : Third identified problem is ESB integration with JBossWS. | This will be fixed in next JBossWS versions through SPI, see: http://jira.jboss.org/jira/browse/JBWS-2024 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135557#4135557 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135557

16 years, 10 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: RM Sender/Receiver as High Available (HA) Components

by richard.opalka＠jboss.com

"richard.opalka(a)jboss.com" wrote : Second identified problem is HA WS-RM in combination with WS-Security. | | WS-Security processing must be the last/first thing in client and endpoint | outgoing/incoming processing chain. | | HA WS-RM must reside on top of transport layer This will not be the problem anymore. WS-Security will be decoupled from handlers and will provide standard interface to handle WS-Security from other system components. On client side both WSRM-Handler and WS-Security handler will be moved to the transport layer. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135555#4135555 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135555

16 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-dev March 2008