On Aug 7, 2006, at 12:05 PM, Michael Victorov wrote:
> Currently I implemented big hierarchy of serializers/deserializers to
> provide mostly all of query and sync capabilities. Code at
> https://svn.objectstyle.org/repos/soc/trunk/cayenne-ropwsdl/.
It would be nice to review and commit this code to the master SVN at
Apache. I know Kevin mentioned that he is busy and can't dedicate
needed time to that. If any other committers can help with this (and
also Eclipse plugin project), please speak up.
I don't have bandwidth for a thorough review of this project, so my
comments are based only on Michael's description.
> Questions:
>
> 1. It seems like most of Cayenne classes can not be serialized or
> deserialized without accessing their private fields through
> reflection. I placed "//TODO" at places in cayenne-axis project where
> private fields are accessed.
That's ok - serializing private fields is a fairly acceptable
practice (although I'd think that most of them are at least protected).
> To avoid cyclic blocking dependences in deserialization process I need
> to provide initial deserialized value at the early stage of
> deserialization. Most of Cayenne classes constructors need child
> objects to be deserialized to invoke. And in many cases these child
> objects need parent object to be created before. To make
> deserialization work I povided constructors of many objects with fake
> values and then replaced these values with deserialized correct ones
> (using reflection).
>
> So it works. But it's wrong. Some comments - what can I do with it?
When dealing with Hessian serialization, I usually created a private
noarg constructor. If it is missing for some classes, please submit a
patch via Jira - I will apply it.
> 2. My web service can work without client business logic classes on
> serverside. But I need different .map.xml files on server and client.
> On serverside all entities must be assigned to CayenneDataObject class
> instead of actual business logic classes.
>
> Maybe I can write an ant task to convert xml files provided by
> modeller. Is it ok?
Ideally this needs to be addressed as a patch to Cayenne. Cayenne
should provide this functionality out of the box.
> 3. Client classes must be subclasses of
> org.apache.cayenne.remote.axis.ClientCayenneDataObject.
>
> It copies implementation of CayenneDataObject with some changes:
>
> It uses getObjectContext() instead of getDataContext() in methods
> addToManyTarget(), removeToManyTarget(), setToOneTarget(). So these
> methods still work when provided context is not DataContext.
>
> It seems like such use of getObjectContext() instead of
> getDataContext() can
> be implemented in main cayenne distribution. Or am I wrong?
>
> Also there is a method named validateForSave() which will not work
> without local DataContext...
I suggest subclassing org.apache.cayenne.PersistentObject - it is
more lightweight and doesn't have all those methods (CayenneContext
supports it already)
> 4. It would be better to remove .driver.xml file (with db info) from
> client side. But I need working local configuration on client side to
> map entities to classes and do validateForSave() (etc...). Is there
> some crorrect way to make configuration work (maybe partly) without
> .driver.xml class?
Per my comment on #2, I hope we can still get the mapping from the
server and avoid this proble all together. Then on the client you can
create a mapping of abstract entity name (e.g. "Artist") to a client
class name (e.g. "my.special.Artist") - this can be a hashmap loaded
from properties or something. Then you can merge it with the
EntityResolver obtained from the server.
Andrus
This archive was generated by hypermail 2.0.0 : Tue Aug 08 2006 - 12:13:58 EDT