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

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

by scott.stark＠jboss.org

It depends on what the signature tests require. If they restrict what methods can show up in jaxws signatures, we can't have this in a certified release unless a challenge allows the updated api. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991694#3991694 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991694

17 years, 5 months

1
0
0 / 0

[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

17 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - JIRA issues for TODOs

by adrian＠jboss.org

I've gone through all the TODOs in the container module (except the VFS) and created JIRA issues for them. I also updated the source with the JIRA issue. There are some TODOs that are just reminders that some of the test utility methods need promoting to the AbstractTestCase class in the test module which I haven't updated. There is nothing major in these TODOs they are all mainly just tidyup. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991663#3991663 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991663

17 years, 5 months

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

17 years, 5 months

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

17 years, 5 months

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

17 years, 5 months

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

17 years, 5 months

1
0
0 / 0

[Design of JBossXB] - Re: Recent tests

by alex.loubyansky＠jboss.com

Just wanted to add, attributes of type xsd:ID are optional. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991626#3991626 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991626

17 years, 5 months

1
0
0 / 0

[Design of JBossXB] - Re: Recent tests

by alex.loubyansky＠jboss.com

For the 2), if all the attributes are optional then yes. And also if the complex type with simple content doesn't have a ClassMetaData associated with it (we have a testcase for this already). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991624#3991624 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991624

17 years, 5 months

1
0
0 / 0

[Design of JBossXB] - Re: Recent tests

by adrian＠jboss.org

I'd say for the simple types that if the complex type is just an extension of the simple types to add attributes and it can't find a binding then it should unmarshall as the simple type. Something like: 1) Real Complex type - error 2) Complex type extends simple - try to unmarshall as simple type if it can't find the model class 3) Plain simple type - as now Maybe you could add an option to the schema to enable the (2) processing for backwards compatibility? e.g. SchemaBinding.setUnmarshalSimpleComplexTypeAsSimpleTypeWhenNoMapping(true); Although, if the intention was really to map to a real type its going to be raised as an IllegalArgumentException on the setter anyway. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991604#3991604 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3991604

17 years, 5 months

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 2006