Does anyone have any input on this? Maybe I should forward this to the dev list?
Trying not to be (too) impatient, David ;) -- David Ward wrote: > I have (at least what I think) is an interesting problem/proposal... > > I am using xdoclet from cvs and apache axis (successor to Apache SOAP) > which comes bundles with JBoss 3.0. Apache axis can encode/decode many > java types nicely, but I'm having a problem with the valueobjects > created by xdoclet. > > Basically, the axis BeanSerializer/BeanDeserializer is (understandably) > strict about the objects it wants to work on. For every get, there must > be a set. Unfortunately, the valueobjects created by xdoclet have many > gets without sets. I'm referring specifically to the internal > Collections holding the valueobjects for ejb cmr's. > > So, I've come up with 4 options, and would like some input: > > 1) Write my own custom serializers/deserializers for every valueobject > that xdoclet creates for me. > PRO: No changes necessary to xdoclet. > CON: A lot duplicated effort since each valueobject is different > CON: Not very maintainable and defeats the purpose of xdoclet. > > 2) Do the above but with one serializer/deserializer that goes nuts with > reflection. > PRO: One serializer/deserializer to write and can be used for all > valueobjects. > CON: Very ugly. > CON: Very slow. > > 3) Change valueobject.xdt so it includes sets for all the gets. > PRO: Quick, easy change to xdoclet. > PRO: Can use AXIS' Bean(De)Serializer(s) out-of-the-box. > CON: The valueobject class author I'm guessing purposely didn't > provide sets for these methods since he'd rather one use addXXXValue(X); > this way he can control removing a valueobject from the updated > Collection when someone calls removeXXXValue(X). Still, I think this is > not horrible and is at the developer's own risk if they call that > method... (They should at least LOOK at what XDoclet generates, for > heaven's sake... ;) > > 4) Create a new ejbdoclet subtask that will generate custom AXIS > BeanSerializers/BeanDeserializers for every valueobject that gets created. > PRO: Doesn't break the (possible) contract that the original author > wanted to maintain inside valueobjects. > CON: A lot more work... (java, xdt, possbily new @tags to aggree on) > > I would prefer option 3, but would settle for option 4. Either way, I'm > willing to be the one to make the changes. > > How do others feel about this? > > Thanks, > David ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Stuff, things, and much much more. http://thinkgeek.com/sf _______________________________________________ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
