You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Dirk Verbeeck <di...@pandora.be> on 2003/08/18 00:42:21 UTC
[Pool] Pool events
Hi all
I'm planning to implement pool events. This is already discussed on the
dev list before but never implemented.
Pool events would create a nice extention mechanism without having to
subclass.
A first use of these pool events would be logging for the dbcp component.
I will give a brief overview of what I'm planning to do so you can
comment on naming, etc.
PoolListener: 4 success events & 4 failure events, all using the same
PoolEvent object to store the event info.
The PoolEventSupport contains all the fire* methods.
These methods will be called from a wrapper class MonitoringObjectPool,
thus avoiding having to modify all pool implementations.
(for the keyed pool a DelegatingKeyedObjectPool & MonitoringKeyedObjectPool)
And finally a PoolAdapter as a base class for the actual PoolEventLogger.
Now, I'm not happy with the name of the PoolAdapter, maybe it should be
PoolEventAdapter and then PoolEventListener as well.
Comments?
Dirk
========================================================
public class PoolEvent extends EventObject {
public PoolEvent(ObjectPool source,Object key, Object pooledObject,
Throwable error) {...}
... }
public class PoolEventSupport {
public void fireObjectBorrowed(Object o) {...}
... }
public interface PoolListener extends EventListener {
// Success events
void objectBorrowed(PoolEvent event);
void objectReturned(PoolEvent event);
void objectAdded(PoolEvent event);
void objectInvalidated(PoolEvent event);
// Failure events
void objectBorrowFailed(PoolEvent event);
void objectReturnFailed(PoolEvent event);
void objectAddFailed(PoolEvent event);
void objectInvalidateFailed(PoolEvent event);
}
public class DelegatingObjectPool implements ObjectPool { ... }
public class MonitoringObjectPool extends DelegatingObjectPool {
public Object borrowObject() throws Exception {
try {
Object o = super.borrowObject();
eventSupport.fireObjectBorrowed(o);
return o;
}
catch (Exception ex) {
eventSupport.fireObjectBorrowFailed(null, ex);
throw ex;
}
}
public abstract class PoolAdapter implements PoolListener { ...}
public class PoolEventLogger extends PoolAdapter { ... }
Re: [Pool] Pool events
Posted by Dirk Verbeeck <di...@pandora.be>.
Hmm, you have a point there. I'll wait until the collection events are
ready and the see if its usable.
Dirk
Noel J. Bergman wrote:
>Dirk,
>
>
>
>>I'm planning to implement pool events. This is already discussed on the
>>dev list before but never implemented.
>>
>>
>
>I've been following the discussion related to NotifyingCollections. Any
>reason not to share constructs? Seems to me that a NotifyingCollection and
>a MonitoringObjectPool are similar in many ways, and there is likely to be
>common available code.
>
>
>
>>Pool events would create a nice extention mechanism without having to
>>subclass. A first use of these pool events would be logging for the
>>dbcp component.
>>
>>
>
>Absolutely. All references to System.out.println should be excised.
>
>
>
>>methods will be called from a wrapper class MonitoringObjectPool,
>>thus avoiding having to modify all pool implementations.
>>
>>
>
>I will argue that such an approach is likely to be insufficient.
>Internally, the pool code needs some limited callback mechanism if you are
>going to allow, for example, exceptions to be logged. I agree with the
>general approach; just pointing out where you may need to link core code and
>the MonitoringObjectPool.
>
>Method naming should follow the Java Beans specification.
>
> --- Noel
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [Pool] Pool events
Posted by Dirk Verbeeck <di...@pandora.be>.
Hmm, you have a point there. I'll wait until the collection events are
ready and the see if its usable.
Dirk
Noel J. Bergman wrote:
>Dirk,
>
>
>
>>I'm planning to implement pool events. This is already discussed on the
>>dev list before but never implemented.
>>
>>
>
>I've been following the discussion related to NotifyingCollections. Any
>reason not to share constructs? Seems to me that a NotifyingCollection and
>a MonitoringObjectPool are similar in many ways, and there is likely to be
>common available code.
>
>
>
>>Pool events would create a nice extention mechanism without having to
>>subclass. A first use of these pool events would be logging for the
>>dbcp component.
>>
>>
>
>Absolutely. All references to System.out.println should be excised.
>
>
>
>>methods will be called from a wrapper class MonitoringObjectPool,
>>thus avoiding having to modify all pool implementations.
>>
>>
>
>I will argue that such an approach is likely to be insufficient.
>Internally, the pool code needs some limited callback mechanism if you are
>going to allow, for example, exceptions to be logged. I agree with the
>general approach; just pointing out where you may need to link core code and
>the MonitoringObjectPool.
>
>Method naming should follow the Java Beans specification.
>
> --- Noel
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
>
>
RE: [Pool] Pool events
Posted by "Noel J. Bergman" <no...@devtech.com>.
Dirk,
> I'm planning to implement pool events. This is already discussed on the
> dev list before but never implemented.
I've been following the discussion related to NotifyingCollections. Any
reason not to share constructs? Seems to me that a NotifyingCollection and
a MonitoringObjectPool are similar in many ways, and there is likely to be
common available code.
> Pool events would create a nice extention mechanism without having to
> subclass. A first use of these pool events would be logging for the
> dbcp component.
Absolutely. All references to System.out.println should be excised.
> methods will be called from a wrapper class MonitoringObjectPool,
> thus avoiding having to modify all pool implementations.
I will argue that such an approach is likely to be insufficient.
Internally, the pool code needs some limited callback mechanism if you are
going to allow, for example, exceptions to be logged. I agree with the
general approach; just pointing out where you may need to link core code and
the MonitoringObjectPool.
Method naming should follow the Java Beans specification.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [Pool] Pool events
Posted by "Noel J. Bergman" <no...@devtech.com>.
Dirk,
> I'm planning to implement pool events. This is already discussed on the
> dev list before but never implemented.
I've been following the discussion related to NotifyingCollections. Any
reason not to share constructs? Seems to me that a NotifyingCollection and
a MonitoringObjectPool are similar in many ways, and there is likely to be
common available code.
> Pool events would create a nice extention mechanism without having to
> subclass. A first use of these pool events would be logging for the
> dbcp component.
Absolutely. All references to System.out.println should be excised.
> methods will be called from a wrapper class MonitoringObjectPool,
> thus avoiding having to modify all pool implementations.
I will argue that such an approach is likely to be insufficient.
Internally, the pool code needs some limited callback mechanism if you are
going to allow, for example, exceptions to be logged. I agree with the
general approach; just pointing out where you may need to link core code and
the MonitoringObjectPool.
Method naming should follow the Java Beans specification.
--- Noel