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

Reply via email to