Le vendredi 6 janvier 2012 à 20:42, Sergey Beryozkin a écrit :
> Hi, > > <snip/> > > > > > Also it might be possible to use this transformation feature on the > > > > > target > > > > > endpoint to match the Java API. However it does seem to work only on > > > > > the > > > > > XML not on other content such as JSON which is common which JAX-RS > > > > > services. > > > > > > > > > > > > > > > > > Works when a default Jettison-based provider is used too > > > > Could it work with other providers (Jackson especially, but Gson too). > > Those providers may offer something else, I checked the source of the > jaxrs Jackson provider, might be possible, > > Benson, do you know by any chance how easy it is to provide a custom > org.codehaus.jackson.map.ObjectMapper, which will wrap the input stream > in the CXF specific custom XMLStreamReader and delegate to the default > Jackson JAXB-aware mapper ? > May be we may ship such a mapper if it were possible > > This would be interesting because these Jackson and Gson are really performant (GSon is way better than it was). Jackson offer some interesting annotations, while not standard they bring nice features. Gson has less features but it bring versioning annotations. And we still have to see what will emerge from JSR 353. > > > > > In all the things I read here and there, it seems all the techniques > > > > > about > > > > > versioning avoids to handle this on the Java side be it possible, > > > > > limited, > > > > > or experimental at best. > > > > > > > > > > For example, what would you do if you need to expose two different > > > > > versions, with difference in object/property names, in some value (ex: > > > > > splitting old value to indicate different sub-cases), etc. > > > > > In a previous mission we were using EJB-JARs and WARs, this way we > > > > > could > > > > > use different objects with the same qualified name (due to the JEE > > > > > classloader architecture), services were exposed with a version > > > > > number in > > > > > the URI (.../ws/5_0/quote) and in the JNDI name (.../ejb/5_0/quote), > > > > > and of > > > > > course one WSDL per services (no versioning on this front). While > > > > > clean, > > > > > this approach is also pretty heavyweight to maintain and is limited to > > > > > people that use JEE and EJB-JARs or people that can work in multi > > > > > classloader environment. > > > > > > > > > > The annotation approach seems more code centric and probably easier > > > > > for > > > > > people that don't follow the contract first approach. But you need to > > > > > deal > > > > > with annotating your code then. > > > > > But if you share your API artefact with your partners (or your > > > > > colleagues) > > > > > so they don't have to generate code from the WSDL or from the WADL, > > > > > you > > > > > will expose fields object that belong to the upper version or the > > > > > lower > > > > > version. > > > > > > > > > > > > > > > > > Sorry, I'm not sure I understand. I think that as far as the web > > > > services are concerned, the versioning& extensibility is to do with > > > > updating the way the consumers of the service use this service at the > > > > moment, so the way the implementation code is managed is kind of > > > > orthogonal to it... > > > > > > > > > > > > > Yeah, I'm not limiting the discussion of versionning to pure a pure > > endpoint / serialzed data discussion. > > IMHO, the way implementation is made is also part of it this discussion in > > the sense of what would be the best practices, is there any emerging > > /patterns/ regarding versionning on the implementation's side. > > > > Basically those are the two options that are right now in my head about > > implementing verisonning …in the java code part. > > In JEE you could craft the following architecture : > > [EJB-JAR v2] -> [EJB-JAR core] > > [EJB-JAR v3] ---------^ > > > > You see in this model that having multiple EJB-JAR allows isolation and > > modularity, the versionned EJB-JARs act as facades with adapters. JEE would > > then allow to expose EJBs as web services or resources. > > While in a WAR only application, you have one class loader, no isolation > > so you could make it explicit in the qualified names > > and / or you can make use of annotations to help versionning support in > > your model > > > > > > > > > > > > And whatever the case you will probably need to make the link between the > > implementation and the contracts such as the WSDL or the WADL. So this why > > I'm going further than only about how a client consumes the service or the > > resource. > > > > Am I clearer ? > I think so, I was not quite right anyway to suggest that the server-side > issues are out of scope for the web-services versioning... > > Right now I do not participate or follow what happens or what happened in the expert groups for JAX-RS / JAX-WS or other specs, but this would be interesting to bring "versioning support" discussion on these JSRs. Anyway as said, this is quite an open minded discussion, no real implementation behind yet, though someday me and others will mind versioning in their application. Regards, -- Brice Dutheil > Cheers, Sergey > > > > > > > Anyway thanks for the informations :) > > > > > > -- > > Brice > > > > > > > > Cheers, Sergey > > > >
