Just joined to the list. I share the relevant part of the response to a
message I sent, just in case it's of general interest:
> - We find the need of comparing JAXB-generated objects for equality. One
> example could be to catch web services responses. We could use the
request
> as key and the response as value, but it's absolutely necessary to have a
> correct equals method. Looks like the compiler doesn't override the
equals
> method in the implementation classes it generates. It could be very
> interesting that it did. A possible equals definition could be:
marshaling
> each object would result in equivalent XML document fragments. And a
> possible implementation looks no much more complicated than recursively
> comparing for equality the object relevant attributes.
>
We simply didn't have time to implement this in 1.0, so if fell off the
table. I'm sure we will discuss the issue for the next version of the
specification. In the mean time, I think there might be some public
libraries (Apache?) that do reflection based comparisons of two objects,
but I suppose that could hurt performance. Marshalling to XML and
comparing
the result would be very inefficient for most (if not all) jaxb providers.
> - We need serializable JAXB-generated objects, to be able to pass them as
> RMI parameters and also to store them in an HttpSession. I know the
> possiblitity is included in the WSDP 1.1 implementation, but I wonder
about
> portability between different JAXB providers of an application which
relies
> in serializable generated objects. As long as I've been able to find
> nothing about serializability in the specification, I think it could be
> provider dependent. Is it right?
>
Exactly. The expert group decided not to pursue a "portable runtime"
system
in the first version of the spec. That means that the generated code is
tightly coupled with its JAXB provider. The implementation classes, that
is - all providers have to generate the same exact interfaces. If you use
provider A and develop a client app written to the schema derived
*interfaces*,
you should be able to move your client code to provider B as long as you
recompile the schema and generate their implementation code. Your client
code
shouldn't need any modifications. However, the second you enable any of a
particular vendor's extensions (ie generating serializable classes), you
are
throwing portability out the window. That's why the RI compiler runs in
"compatibility" mode by default - you have to explicitly enable our
extensions
with the "-extension" switch.
> - We are considering the possibility of caching JAXBContext objects, as
> long as generating them looks to be a costly operation. I've found
nothing
> in the specification which tells whether JAXBContext implementations
should
> be thread safe or not. Looks like the implementation is, but I don't know
> if other providers implementations could also be assumed to be.
>
I believe the next version of the spec/javadoc will address this and I
expect
that they will say that JAXBContext is thread safe and that Unmarshaller,
Marshaller, and Validator are not thread safe. You are correct that this
is
the case with the RI.
> - Simmilar question about marshallers (and unmarshallers). First of all I
> need to know about the possibility of recycling them to marshal (or
> unmarshal) more than one document. If it's possible, then I also need to
> know if they are thread safe or not. Looks like they aren't.
>
In the RI, they are not thread safe, but they can be reused.