You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Christian Essl <ch...@yahoo.de> on 2003/09/18 16:08:57 UTC
Re: [HiveMind] TSS
> HiveMind's take on the DAO factory: Define a DAO interface and supply
several implementations (for
> different databases or environments) in a configuration point. Have a
service factory create a
> service implementation that delegates to a particular implementation,
i.e.
>
> client code --> wrapper service --> actual service
>
> The wrapper service is created at runtime. Client code only sees the
wrapper service, never has to
> even know that a dynamic selection takes place. Wrapper service is
constructed at runtime using a
> service impl factory ... look at how EJBFactory is implemented to
understand this.
>
I think that's realy needed. However I have a (stupid) question. If you
have a DAO interface and you have implementations of this interface why do
you need an extra (dynamicly created wrapper-service)? Why can't you just
use (or return in a ServiceFactory) the actual service which implements the
interface any way?
> Service that creates C#-style delegates for use in Swing apps. You
feed
in: object, name of public
> method (of object), listener interface type ... it spits out delegate
object that implements the
> interface and invokes the public method (possibly, passing the event
in).
Optional: if listener
> interface defines multiple methods, you decide which to connect.
>
Do you mean a Service which returns something like java.beans.EventHandler?
What's about a central Event Service. I mean a Service where (all) Services
can register themself with the event-type and the source service(id) they
are interested in and the firing Service just imforms the central event
Service when an event should be fired. The interface would look like this:
public interface CentralEventService {
public void register(Object listener, Class listenerInterface,String
source_serviceId);
public void unregister(Object listener,Class listenerInterface,String
source_serviceId);
public void fireEvent(String source_serviceId,Class listener,
EventAction action);
}
public interface EventAction{
public void fire(Object listener);
}
The CentralEventService keeps all the listeners and when asked to fire
provides the EventAction whith the listeners to fire the Event. This would
certainly be a bit slower, but it would free the service of managing their
own listeners and thus provide some further decoupling. If ie a Service is
never actually used it is not just activated to register a listener. If a
threaded service fires Events and a Singleton-Service has to listen
currently it has to make sure to register with each instance. In case of a
central EventService this would not be needed. You could also add some
additions to such a Service. Ie you could make Event-groups or you are
interested only in events on the current thread etc.
Re: [HiveMind] Question about basic LiveCycle support
Posted by Johan Lindquist <jo...@kawoo.co.uk>.
Good point - I first though about the services possibly registring
themselves with the event notifier you described earlier, but this allows
complete decoupling ...
On Thu, 18 Sep 2003 16:17:33 +0200, Christian Essl
<ch...@yahoo.de> wrote:
> As I see there are quite some wanted Services which all need at least a
> from of destroy:
> - Database access (generally Resources)
> - Caches
> - Pooles
>
> As I see HiveMind does currently not support this. So I want to ask is
> there any plan to support something like this?
>
> Maybe in the mean-time we could agree on a 'standard' interface, which
> such Services have to implement so that the user knows that she has to
> 'destroy' the Service manually. The interface would than later (when
> LiveCycle is supported?) also be used by HiveMind - so that such Service
> won't have to change.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
you too?
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [HiveMind] Question about basic LiveCycle support
Posted by Johan Lindquist <jo...@kawoo.co.uk>.
Good point - I first though about the services possibly registring
themselves with the event notifier you described earlier, but this allows
complete decoupling ...
On Thu, 18 Sep 2003 16:17:33 +0200, Christian Essl
<ch...@yahoo.de> wrote:
> As I see there are quite some wanted Services which all need at least a
> from of destroy:
> - Database access (generally Resources)
> - Caches
> - Pooles
>
> As I see HiveMind does currently not support this. So I want to ask is
> there any plan to support something like this?
>
> Maybe in the mean-time we could agree on a 'standard' interface, which
> such Services have to implement so that the user knows that she has to
> 'destroy' the Service manually. The interface would than later (when
> LiveCycle is supported?) also be used by HiveMind - so that such Service
> won't have to change.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
you too?
[HiveMind] Question about basic LiveCycle support
Posted by Christian Essl <ch...@yahoo.de>.
As I see there are quite some wanted Services which all need at least a
from of destroy:
- Database access (generally Resources)
- Caches
- Pooles
As I see HiveMind does currently not support this. So I want to ask is
there any plan to support something like this?
Maybe in the mean-time we could agree on a 'standard' interface, which such
Services have to implement so that the user knows that she has to 'destroy'
the Service manually. The interface would than later (when LiveCycle is
supported?) also be used by HiveMind - so that such Service won't have to
change.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[HiveMind] Question about basic LiveCycle support
Posted by Christian Essl <ch...@yahoo.de>.
As I see there are quite some wanted Services which all need at least a
from of destroy:
- Database access (generally Resources)
- Caches
- Pooles
As I see HiveMind does currently not support this. So I want to ask is
there any plan to support something like this?
Maybe in the mean-time we could agree on a 'standard' interface, which such
Services have to implement so that the user knows that she has to 'destroy'
the Service manually. The interface would than later (when LiveCycle is
supported?) also be used by HiveMind - so that such Service won't have to
change.