db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Morris <josh.mor...@unitt.org>
Subject Patch: Why no plugable IndirectionHandler?
Date Thu, 30 Oct 2003 20:16:46 GMT
I submitted the patch we are using into scarab (id=OJB4), as well as a
description containing this email. I have a client that uses the
ojb-client.jar file, whic contains about 12 classes (mostly exception
classes and interfaces), and a server (TOMCAT) that is running the OJB
API. I can serve classes to my client and resolve proxied references and
collections without a problem (that I've noticed anyways). It has not
been thru a full test cycle, nor are we using it with odmg. Sooooo...be
nice...its oly dev code ;). Please let me know if I misunderstood the
intent of any of the classes I modified. There are most certainly
refactorings/cleanups that could be performed to the changes, but I was
attempting to introduce as few changes as possible. 

Changes made:
1) Identity instances are now constructed using a Factory, never
directly. This allowed all broker references to be removed as they were
only used for construction.
2) VirtualProxy & CollectionProxy are no longer directly constructed,
they are using the ProxyHelper class as a factory. All broker references
were removed, as this behaviour is now performed by the
SubjectMaterializer (explained further down).
3) ManageableCollection was seperated into two interfaces:
ManageableCollection and RemovalAwareManageableCollection (all
associated behaviours were modified to be aware of distinction). The
RemovalAwareManageableCollection contains the PersistenceBroker aware
functionality.
4) There is a new interface SubjectMaterializer whose implementation
class is configurable in OJB.properties. This class performs the
getRealSubject() behaviors that were previously owned by the
IndirectionHandler, and the loadSize() and loadData() of the
CollectionProxy classes.
5) There is a QueryProxy class that acts as a delegate to the Query
instance used in Collection materialization. If serialized, it will hold
reference to a byte stream containing the underlying Query. If that
query is requested via the getter, it will be deserialized. If it is
never serialized, everything behaves the same as today.
6) Need to specify the default collection proxy as
CollectionNonRemovalAwareProxy in the OJB.properties if the serialized
to non-OJB aware VM behaviour is desired.
7) Rather than provide a custom implementation of IndirectionHandler,
one would provide a custom implementation of SubjectMaterializer. The
config entry in OJB.properties is: subjectMaterializerImplementation

Caveats/Concerns:
1) RemovalAwareCollection is no longer the default class used,
ManageableVector is. Don't know how that affects ODMG. It appears to
behave perfectly in PB API.
2) I have not run the OJB unittests on this patch, only our app which
exercises most of the PB API. 

Josh Morris
-- 
Quidquid latine dictum sit, altum viditur.
        [Whatever is said in Latin sounds profound.]

On Tue, 2003-10-28 at 02:11, Thomas Mahler wrote:
> Hi Andrew,
> 
> 
> Clute, Andrew wrote:
> > In my quest to implement proxies and realize the ramification of using them
> > with EJB's, I have investigated what the IndirectionHandler does. I see that
> > it is really a back-reference to read through the same OJB configuration and
> > instantiate the object when necessary. Pretty slick.
> > 
> > However, that doesn't work well when the client class has no idea about the
> > existence of OJB.
> > 
> > It looks to me like IndirectionHandler is a one of many specific
> > implementations that could be used as the InvocationHandler for proxies.
> > Another possible IndirectionHandler could be to call an EJB that will
> > retrieve  that object.
> > 
> > Is there a specific reason why the IndirectionHandler is not a configurable
> > property in the OJB.properties file?
> 
> No, the only reason is that nobody requested it before!
> My ideas for remote objects was always to have a complete 
> PersistenceBroker stub on the client (maybe based on our 
> PersistenceBroker EJB).
> 
> But this will work only if the client side is aware of OJB API.
> 
> If we want to support programming models where remote clients are not 
> aware of OJB API, your soultion is the best choice!
> 
> 
> > 
> > If not, and it is just an over sight, I would suggest a refactoring (which I
> > would be happy to perform) to allow for pluggable IndirectionHandlers to
> > facilitate easier proxy handling for disparate n-tier applications.
> 
> 
> If you write such a patch I'll review it and integrate it in our codebase!
> 
> thanks for sharing this good idea,
> Thomas
> 
> > -Andrew
> > 
> > 
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> > For additional commands, e-mail: ojb-dev-help@db.apache.org
> > 
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message