db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Armin Waibel" <armin.wai...@code-au-lait.de>
Subject Re: PersistenceBrokerAware lacks broker?
Date Fri, 04 Apr 2003 14:18:23 GMT
Hi,

as luck would have it I'm currently refactoring that
stuff a bit. Want to do a more common listener concept
based on java.util.EventObject as container for events.

I will integrate your proposal in the new PB event
handling.

One question, should we change the PersistenceBrokerAware
interface (we in rc2!) or should we declare this interface as
deprecated and add a new one (PersistenceAware) with the
changes suggested by Per-Olof?

regards,
Armin

>
> Hi comitters, all
> In my pursuit for getting db-manipulated attributes back into my
beans,
> I found out that
> the PersistenceBrokerAware interface does not supply a broker to
operate
> on.
> Given the the fact that I use the same mappings and beans to different
> connections,
> I can not use the factory default broker, since every bean does not
know
> which jcdAlias to use.
> Shouldn´t the methods in PersistenceBrokerAware supply a broker:
>
> public interface PersistenceBrokerAware
> {
>    public void beforeStore(PersistenceBroker broker) throws
> PersistenceBrokerException;
>    public void afterStore(PersistenceBroker broker) throws
> PersistenceBrokerException;
>    public void beforeDelete(PersistenceBroker broker) throws
> PersistenceBrokerException;
>    public void afterDelete(PersistenceBroker broker) throws
> PersistenceBrokerException;
>    public void afterLookup(PersistenceBroker broker) throws
> PersistenceBrokerException;
> }
>
> I  searched the source tree and found that the place
> PersistenceBrokerAware was mentioned in was:
> org.apache.ojb.broker.singlevm.PersistenceBrokerAbstractImpl, is this
> correct?
>
>
> My idea is to simply supply the broker calling the event-handler like
this:
>
> private void performCallBack(int eventId, PersistenceBrokerAware
> persistenceBrokerAware)
>    {
>        switch (eventId) {
>            case EVENT_BEFORE_STORE:
>                persistenceBrokerAware.beforeStore(this);
>                break;
>            case EVENT_AFTER_STORE:
>                persistenceBrokerAware.afterStore(this);
>                break;
>            case EVENT_BEFORE_DELETE:
>                persistenceBrokerAware.beforeDelete(this);
>                break;
>            case EVENT_AFTER_DELETE:
>                persistenceBrokerAware.afterDelete(this);
>                break;
>            case EVENT_AFTER_LOOKUP:
>                persistenceBrokerAware.afterLookup(this);
>                break;
>        }
>    }
>
> The questions that arise are:
> 1. Does this make sence?
> 2. If it doesn´t, is there possibly another smart way of doing this?
> 3. If it does, would a solution like this have impact on client-server
> mode (since PBAbstractImpl resiseds in singlevm-package)?
> 4. If I implement this, would this project be interested in
> incorporating the changes?
>
>
> PS.
> My ugly fix is add a jcdAlias attribute to my beans (and not map them)
,
> and iterate over them, setting the jcdAlias for this transaction
before
> every update.
> As you all see, I´m quite keen on response on a better solution than
> this. The ugly fix below is not very tempting...but I need to have
this
> working by Monday morning......
> DS.
>
> Regards,
> Per-Olof
>
>
>
>
>
> ---------------------------------------------------------------------
> 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