From: Jody G. <jod...@gm...> - 2008-06-26 00:05:55
|
Adrian Custer wrote: > As you said, one can create DTO objects or use a home built parser framework. The annotations are in addition to, not in replacement of anything, merely another way to benefit from the same code. So JAXB could be written for Filter 1.2, a parser could do Filter 1.0, 1.1, 1.2 > and a DTO could do 1.0 and 1.1. > Well we do have the infrastructure to support multiple version of Filter; ie we can make a FilterFactory1_0 and a FilterFactory1_1 - so it is possible. Is it a good idea? It feels like the tail is wagging the dog. > Why? If you want to do Filter 1.0, you have code for that that works, correct? How is someone else doing 1.2 with a different method going to impact you? > As a library we want to tell a consistent story; parse your filter document like this. If the answer changes depending on which version of Filter it will look a bit nuts. Pros: People would like JAXB bindings; it is what they expect ... we could try and make the easy case easy. Cons: Even for the easy case Filter depends on GML and things quickly get hard ... can we still make it look easy? And for the really hard (ie dynamic case) there is no way JAXB can play (simple technical limitation). > No one is asking everyone to ditch the tool that works for them. And so far, I have not seen any example where the annotations break other > approaches. Martin wants to dive into glassfish and having *a* set of annotations for each module helps him work there. > I think that is just it; I want us to sort out parsing technology and adding one more to the mix only complicates matters. If you are proposing JAXB as ready for use it is time to clean out the others ... if we don't make a decision and continue with 4 parsing technologies as we have now then we need to maintain 4 parsing technologies - or sentence users to a nigh mare of testing because we did not have the will to make a decision and clean up the code. Cheers, Jody |