Hi Mark,
Removing stuff is always very difficult to version :-)
From the perspective of your service I think the right approach is to
version your media types. For example,
application/foo-v1
application/foo-v2
etc. Note that JAX-RS only uses the type and sub-type of the media
type for content negotiation, it does not take into account any
parameters on the media type.
Then you can add additional methods to your resource classes to
support the additional versions.
Once you have the media types it is possible if you wish to support
URI-based content negotiation if the client cannot send an accept
header.
JAX-RS has support for resolving JAXBContext for media type and Java
type. See the ContextResolver [1].
Thus you could do:
@Provider
@Produces("application/foo-v1")
public class Verson1ContextResolver implements
ContextResolver<JAXBContext> {
public JAXBContext getContext(java.lang.Class<?> type) {
...
}
}
I am not sure of the exact details of supporting two different
serializations from the same object. IMHO it seems, without
understanding too much about your use-case, easier to keep new and old
versions separate (different packages). That way you do not have to
work out backwards dependencies, plus think about the case when you
require 3 versions etc.
Paul.
[1]
https://jsr311.dev.java.net/nonav/releases/1.0/javax/ws/rs/ext/ContextResolver.html
On Feb 24, 2009, at 12:35 AM, Rabick, Mark A (MS) wrote:
> The project I'm working on is a small group and expect significant
> evolutionary changes to our software, primarily due to an evolving
> database schema. I originally annotated our existing Hibernate
> generated persistence objects (entity beans) with javax.xml.bind.*
> annotation (XmlRootElement, etc) and let JAXB and Jersey create the
> XML schema. We will have customers that will be using the current
> instance of our ReST resources that will not be able to easily
> migrate their software as we evolve. For example, if we remove a
> column from a database table, removing the attribute from our entity
> bean, and from the URI query string, new clients will be able to
> communicate with the newly generated schema but legacy clients will
> get errors in their query strings and my resources would get errors
> trying to parse the incoming xml. One solution we have looked at is
> to create multiple versions of our services:
>
> http://host:7001/app/v1/toy
>
> Would be the first instance and the URI would be mapped to
>
> - com.company.rest.resources.ToyV1Resource.java
>
> and return instances of com.company.persistence.Toy.java
>
> Here is the problem… Toy is an EJB3 entity bean created from
> Hibernate that is serviced by our EJB3 Stateless session beans. If
> I removed a column from the database, the client still wants access
> to the data so if I marked that class attribute (say String
> toyColor) as @XmlTransient, JAXB would exclude it from the generated
> schema but client 1 still is expecting the color attribute, even if
> it is meaningless in the new Schema.
>
> We'd like to create a new resource:
>
> - com.company.rest.resourcres.ToyV2Resource.java (http://host:7001/app/v2/toy
> )
>
> that is agnostic of the change and update the V1 resource to be
> aware of the change and for example, return the toyColor XML element
> or attribute as an empty string….
>
> Would an external JAXB configuration file be the way to go?
> Multiple JAXB configurations, one for each schema instance? It
> would seem that I would have to manually implement the JAXBContext
> using an custom JAX message body readers and writers…?
>
> In a nutshell, I'm looking for a way to support multiple schemas
> that bind to a single object, and support multiple versions of the
> schemas concurrently to support legacy ReST service users.
>
> --mark
>
> _______________________________________________
> Mark A. Rabick
> Software Engineer
> Northrop Grumman - C2 Systems (MS/C2SD/IIS)
> 3200 Samson Way
> Bellevue, NE 68123
> Ph: (402) 293-7091
> Em: mark.rabick_at_ngc.com
> Remember PFC Ross A. McGinnis...
> http://www.army.mil/medalofhonor/McGinnis/index.html
> ... MA2 Michael A. Monsoor, Lt. Michael P. Murphy, Cpl. Jason
> Dunham, SFC Paul Ray Smith and the rest...
> http://www.cmohs.org/recipients/most_recent.htm
>