Christian Raschka wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Why do you think, this breaks backwards compatibility?
Because the impression I got from reading the initial description was that you removed all of the DD classes in lieu of the JAXB Types. After looking in more detail at the patch, it looks like you've just duplicated the descriptor services so that they can use jaxb generated companions.
While this will help compatibility, I still don't think it's ideal. The descriptor services are intended to be interfaces which provide a clean facade for accessing the descriptors. Clients should not care which service implementation they are using, instead, they should simply utilize the interface methods to retrieve a generic model. Introducing a JAXB specific service negates this transparency.
- --- There is a problem with the castor classes: many types aren't similar to the portlet XMLSchema. E.g. in IconDD there are String smallIcon and String largeIcon. The xsd says, that this have to be PathType (which is an extend to String). The JAXB Codegeneration does it well.
Don't things like PathType simply provide xsd level validation over the format of the String? Looking at the PathType defined in the patch, it adds no members, methods, etc. . .which differentiate it from a String. In these cases, I see nothing wrong with using a String to encapsultate the data. What value does the PathType class provide?
That said, I'm sure there are arguments to be made about modifications to the DD (Descriptor) classes. By all means, we should make those modifications when possible, but simply throwing away an entire object model and forcing those using pluto to digest a totally new one seems extreme. If nothing else (not ideal, but will work), couldn't we provide decorations of the Type classes to adapt them to the DD model?
The other point is, that in the castor *DD classes there aren't all nesessary methods and fields.
But there's nothing preventing anyone from adding them. Right? In fact, several have just been added to the trunk due to jira tickets that were filed.
If we make an interface (e.g. Icon) to both support Castor and JAXB, we have to reimplement nearly all castor classes and the corresponding castor binding.
This is a simple model. I don't see a reason to introduce interfaces. There's not logic we'll want to provide different implementations of. This is simply an encapsulation of data we're talking about.
What is the best way, to solve this problem?
I won't claim to be a JAXB expert, so I'm not sure. My only comment would be that we should discuss this before introducing a brand new set of interfaces and associated model. Perhaps the best solution is to deprecate the old service and replace it with a new one, but I will still argue that it should be done in an implementation specific manner so that if someone wanted to utilize a different service implementation they could. Of course, the JAXBDescriptorService may be just a naming issue, but I tend to think it's a little more than that. . .
Thoughts? David
Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFyylg40Vb1Zesx0kRAjoqAJ9NNNlhgV8SjUOF4WwBxnDTnSIYZQCcDhaE lL4RcOkR6KoZICMh3/k3D50= =prAo -----END PGP SIGNATURE-----
