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
Oh, it's good to be a geek.
http://thinkgeek.com/sf
_______________________________________________
Xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user