I agree, replacing the base class is a possible solution.
However, getting the classloader order correct is fragile as you are
relying on various sort orders and classloader behaviors. The order
is not the same on all platforms. eg OSX does name based sort, RedHat
enterprise does date sort. Classloaders are also hard to debug.... if
you are not certain what it going on.
I am concerned about the level of logic required, and that will make
things hard if the pojos need that logic. I don't have a perfect
solution. (anyone)
Ian
On 21 Apr 2008, at 18:31, Louis Ryan wrote:
Ian,
One possible workaround that we could quickly implement.
All POJO's extend a empty common base class (e.g. OpenSocialBase). You
implement your own OpenSocialBase in the same package which extends
CayenneDataObject and make sure it preceeds the Shindig one in your
classpath.
The real question is how much logic will need to reside in the
POJOs, data
validation etc... If its a lot and we are forced to go the
interface route
it will move into utility classes to allow you to make use of it
when you
implement the interfaces.
If the POJOs have almost no logic then interfaces are probably the
way to
go.
-Louis
On Sun, Apr 20, 2008 at 10:54 AM, Ian Boston <[EMAIL PROTECTED]> wrote:
If I use Cayenne to do the ORM, then it needs to have an
integration point
to the model its trying to implement. Cayenne uses class
extension... all
data objects must extend CayenneDataObject, so if the model is
interfaces I
can create pojos that work in the ORM and are usable in the
services. If
they are classes, I cant.
I could use the pojos, and copy into them from the orm, but that
would
increase the volume of objects going through the JVM GC cycles and
could
eliminate potential optimizations (lazy load, caching,
transactional caching
in the orm)
I could use another ORM that just uses Pojos, like hibernate, but
that can
be nasty since most of them generate really nasty SQL, and I have
some bad
experiences.
or I could use JDBC direct, but when I saw the size of the object, I
decided it would be quicker to use an ORM.
The reason for Cayenne, is it creates good quality SQL joins that
DBAs
dont go wild at.
If the service layer is almost pure interface, then the
implementor is not
bound and there is clean separation. (I am leaving all Enums in the
interface, just enough to stop it being a class).
I agree with you on the AbstractGadgetData, although I can cope
with that
one.
I could probably work with pojos and , but I think I would have to
resort
to GCLib.... which is nasty.
Ian
On 20 Apr 2008, at 18:15, Cassie wrote:
Well... interfaces seem a lot more complicated then just pojos. Why
would a
pojo need to be an interface to begin with?
As for the AbstractGadgetData thing we really really need to get
rid of
that
class, so that's a little bit of a separate issue. Ideally we
would just
use
a java->json->java library which takes in any java object, and
does not
require inheritance. What we have right now is a very good stop gap
solution.
So why do you need to change the default pojo implementation of a
pojo?
Can
you simply extend Person.java to do what you need? Any details would
greatly
help us all make a good design decision together.
Thanks.
- Cassie
On Sun, Apr 20, 2008 at 4:39 PM, Ian Boston <[EMAIL PROTECTED]> wrote:
I guess this is really a question for Cassie....
How receptive would you be to extracting interfaces from the model
area to
enable other implementation schemes.
eg
all the classes in org.apache.shindig.opensocial.model become
interfaces
the sample container provides an set of implementations bound to
the
interfaces.
AbstractGadgetData implements a GadgetData interface and that is
used
where
AbstractGadgetData is used.
I can provide a patch...
Ian
