December 2006 - jbossws-dev - Jboss List Archives

[Design of JBoss Web Services] - Re: Proposed new package structure

by jason.greene＠jboss.com

Lest look at the actual real problem, which is the need for a legacy jsr181 implementation. We could even have this legacy implementation in the trunk codebase if desired, but disabled. This can be achieved by simply having a metadata builder that exists in the branch that does not exist in trunk. If we want 1 codebase, all that is needed is to sync trunk with the jbossws-1.0 branch and whenever a change is made it is committed to trunk first, and then after committed to the 1.0 branch. The code bases would be virtually identical, and by merging in this order we guarantee that 1.0 specific stuff remains. The contract between what you call core, and what you call tools is NOT static, but rather changes significantly. In fact, it is a work in progress. For an example take a look at WSDLMetaData, this is by no means complete or fully accurate, and if we solidify this to some kind of API, we are only going to make things more difficult by having to guarantee backwards compatibility across any particular branch of core. I only see this effort as creating more work for us, and I don't see how it helps achieve any of the outstanding project goals. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991691#3991691 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991691

18 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Proposed new package structure

by thomas.diesler＠jboss.com

anonymous wrote : | Therefore if we did this we would surely end up maintaining multiple versions of binary dependencies which is just as much if not more work (since you would need branches for each subcomponent). | Only if the changes are not backward compatible, which they should be given that trunk is a superset in functionality. Looking at it from a different angle, there is no way we would be able to maintain the current largely divereged code base. Therefore it is a MUST that we consolidate. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991650#3991650 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991650

18 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Switching to JAX-WS 2.1

by heiko.braun＠jboss.com

The latest spec and API for JAX-WS include significant changes that we need to implement. I realized it when i was looking at the MTOM impl. for JAX-WS. I.e. there are new Binding URI's that indicate the use of MTOM: | Enable using @BindingType on the endpoint (SEI) implementation class | | * @BindingType(value=javax.xml.ws.SOAPBinding.SOAP11HTTP_MTOM_BINDING) will enable MTOM on the deployed endpoint for SOAP 1.1 binding | | Is there any reason to stick to the current version? I.e. with regard to CTS? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991631#3991631 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991631

18 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Proposed new package structure

by thomas.diesler＠jboss.com

Before we decide on implementation details, lets have a look at the current sittuation with respect to tools/metadata. Please step back a little and look at it from a consultants perspective whose only aim it is to make it better in the future - what happend in the past is not of interrest. | * jbossws-2.0.x is a functional superset of jbossws-1.2.x and jbossws-1.0.x. There is however a conflicting implementation with respect to how JSR181 endpoints are handled. | | * currently we have two (in the near future three) code bases | that are divergent to a degree where it becomes virtualy impossible to merge changes from branch to trunk and vice versa. Effectivly, team members spend days merging trivial functionality or don't do it at all (which is worse) | | * the tools code base in branch has virtually not been maintained for the largest part of the year it is also in a state where it is still difficult to maintain | | * the tools code base in trunk builds on the tools code base from branch, such that maintainability concerns apply likewise | | * there is no tools api that can be used from core and thirdparty | | | Therefore, I'll put some effort in | | | | * unify the metadata model accross branches | | * reuse a single tools code base accross branches | | * draft a tools api | | | | I see this as necessary prerequisity before I continue with CTS work and the foundation for 1.0.5, 1.2.0 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991630#3991630 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991630

18 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Proposed JAX-WS Docs

by sam.griffith＠jboss.com

Hello, The outline below is a basis for the docs for the JAX-WS 2.0 docs. I'd like to get input on what other documentation people would like to see. The initial docs will be for the January release and will have the most important information and we will add to it from there. So even if you don't see your suggestion in the initial cut, we will try and add it later. Thanks for the input. Sam Griffith Docs Team --------------------------------------------------------- JBoss JAX-WS 2.0 Doc Proposal - [ ] JAX-WS 2 Topics for Docs - [ ] Overview - [ ] JAXB - [ ] What roll does JAXB play in JAX-WS 2.0? - [ ] SOAP 1.2 - [ ] Description - [ ] WS Basic Profile 1.1 - [ ] Description - [ ] Annotations in JAX-WS 2.0 - [ ] Description This is the annotations that JAX-WS 2.0 defines. The annotations allow you to set the common configuration settings for client and server side development in common configurations. - [ ] Overview of - [ ] rpc/literal - [ ] document/literal/bare - [ ] document/literal/wrapped - [ ] JBoss Tools - [ ] Which tools do we provide - [ ] WSTOOL - [ ] Description - [ ] options - [ ] description - [ ] acceptable values - [ ] ??? - [ ] Which tools do we use from reference implementation - [ ] ???? - [ ] JSR 181 POJO Example - [ ] Description - [ ] Greeting App A variation of Hello World. - [ ] Important Annotations - [ ] Ant build file The standard Ant build file that you can build on for JAX-WS 2.0 web services you want to build. - [ ] Setting up Eclipse to work with JBossWS 2.0 - [ ] How to - [ ] Setting up NetBeans to work with JBossWS 2.0 - [ ] How to - [ ] JSR 181 EJB Example - [ ] Description - [ ] What's different than the POJO example? - [ ] New Annotations - [ ] Changes to Ant build file - [ ] MTOM Example - [ ] Description - [ ] How To - [ ] Annotaions? - [ ] WS-Security - [ ] Description - [ ] Alignment with JSR 183 - [ ] Annotations? - [ ] Authentication - [ ] What we support - [ ] How To - [ ] Encryption - [ ] What we support - [ ] How To - [ ] Authorization - [ ] What we support - [ ] Signatures - [ ] How To - [ ] Provider - [ ] ??? - [ ] Protocol vs. Logic Handler - [ ] ??? - [ ] WS-Addressing (Not sure on this one) - [ ] Description - [ ] How To - [ ] Annotations? - [ ] Async Web Services (Not sure on this one) - [ ] Description - [ ] How To - [ ] Client Programming Model - [ ] ie - @WebServiceRef - [ ] ??? - others... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991628#3991628 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991628

18 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Proposed new package structure

by heiko.braun＠jboss.com

Here are my 2 cents: - What's the difference between org.jboss.ws.common.metadata and org.jboss.ws.core.metadata? - I would rename 'extras' to 'extensions' - As a general approach i would recommend to use *.jaxrpc *.jaxws subpackages. I.e. there would be *.xop.jaxrpc and *.xop.jaxws - As a consequence of the above, we should have org.jboss.ws.core.j2ee.jaxrpc and org.jboss.ws.core.j2ee.jaxws View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991586#3991586 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991586

18 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Proposed new package structure

by jason.greene＠jboss.com

Are you referring to using the same tools and common binary across branches? I don't think we should go this route because tools changes often impact metadata, tools, and common/core. Therefore if we did this we would surely end up maintaining multiple versions of binary dependencies which is just as much if not more work (since you would need branches for each subcomponent). The only diversion that I think is necessary for 4.2 is a couple of configuration lines for remoting. IMO as long as this is true, I think it would be better just to add code that detects which version of remoting, and then configures appropriately across all versions. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991526#3991526 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991526

18 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Proposed new package structure

by thomas.diesler＠jboss.com

Folks, the current package structure is becomming a little clutterd. I propose the following change to top level packages | org.jboss.ws.common | org.jboss.ws.common.api | org.jboss.ws.common.metadata | | org.jboss.ws.core | org.jboss.ws.core.jaxrpc | org.jboss.ws.core.jaxws | | org.jboss.ws.extras | org.jboss.ws.extras.addressing | org.jboss.ws.extras.eventing | org.jboss.ws.extras.policy | org.jboss.ws.extras.security | org.jboss.ws.extras.xop | | org.jboss.ws.integration | org.jboss.ws.integration.jboss40 | org.jboss.ws.integration.jboss50 | org.jboss.ws.integration.tomcat | | org.jboss.ws.tools | Further refactoring would be necessary such that * core only has a dependency on common, so has tools. * core does not have a dependency on tools. When this is done, we move common and tools in their respective modules that then can be reused accross branches. Shortly we will have a third branch to maintain jbossws-1.2, wich is targeted for jboss-4.2.x. This can only be done efficiently if the code bases do not divert more than necessary. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991503#3991503 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991503

18 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: JSR-181 Annotation Based UDDI Registration

by jgilbert

All the code I created to do this is available at: http://taylor.cvs.sourceforge.net/taylor/taylor/taylor-juddi/ View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991094#3991094 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991094

18 years, 1 month

1
0
0 / 0

Re: WS embedded in tomcat

by Thomas Diesler

yes, web service endpoints are supported in standalone tomcat. http://labs.jboss.com/portal/jbossws/user-guide/en/html/installation.html... -thomas On Mon, 2006-12-04 at 19:11 +0100, Julien Viet wrote: > actually I mean the fact that you can specify a WS as a servlet class > name (instead of a servlet) and replace that name at load time by a > proper servlet class implementation. > > On Dec 4, 2006, at 6:40 PM, Thomas Diesler wrote: > > > Do you mean web service client references like this > > > > <service-ref> > > > > ? > > > > This is supported in JBoss embedded Tomcat. With standalone Tomcat > > we do > > not bind service refs to JNDI. > > > > cheers > > -thomas > > > > > > > > > > On Fri, 2006-12-01 at 16:36 +0100, Julien Viet wrote: > >> Hi Thomas, > >> > >> do you support the declaration of WS in the web.xml file in the > >> Tomcat environment ? > >> > >> Julien Viet > >> JBoss Portal Project Lead > >> Red Hat Inc. > >> > >> > >> > > -- > > xxxxxxxxxxxxxxxxxxxxxxxxxxxx > > Thomas Diesler > > Web Service Lead > > JBoss, a division of Red Hat > > xxxxxxxxxxxxxxxxxxxxxxxxxxxx > > > > Julien Viet > JBoss Portal Project Lead > Red Hat Inc. > > > -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Thomas Diesler Web Service Lead JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx

18 years, 1 month

2
1
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-dev December 2006