You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Howard M. Lewis Ship" <hl...@comcast.net> on 2003/10/09 14:46:20 UTC
[HiveMind] Initializable
Was thinking about this as well; currently, the instantiated service is passed as a parameter to the
initializeService() method.
I'm thinking of stripping this out.
It makes a kind of sense for the singleton and deferred service models ... in case they want to,
say, register with some other service and have the invocation go through the service methods
(including interceptors, such as logging).
However ... adding in the thread-related service models (threaded and pooled), I can't decide what
object they should get ... the service implementation or the proxy?
The more I thought about it, the more I thought the proxy was right; all connections between
services should go through the right proxies, or you run the risk of either (a) invoking a method on
a discarded threaded service impl or (b) invoking a method on a pooled service impl.
A service can simply use the BuilderFactory to assign its "serviceThis" to a property, if it wants
to hook itself to another service; it simply won't be hooking any particular instance of the service
that way. Otherwise, the service impl may want to hook a specific instance to the other serivce ...
in which case, it can pass "this".
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [HiveMind] Initializable
Posted by Christian Essl <ch...@yahoo.de>.
On Thu, 9 Oct 2003 13:45:32 -0400, Howard M. Lewis Ship
<hl...@comcast.net> wrote:
> I agree, which means nothing needs to be passed; if the core
> implementation needs to vend out the
> proxy, it can use the BuilderFactory to assign the proxy to a property.
> Perhaps another attribute
> of <contruct> to specify which property it should be assigned to.
>
I agree the property should be there. But is there a special reason you
want to remove it
form the Initializable. For me it was a cheap way to get the outher
representation (I did not
know this was not always the case).
>> Concerning Threaded model: I'd rather see if ServiceImplementations
>> which can be used for Threaded must implement a marker interface (as in
>> old Servlet-spec).
> I think that's an interesting idea; threaded core impls must implement a
> Threadable marker interface; pooled implementations must implement a
> Poolable interface.
>
Maybe we should even get stronger: service-interfaces must implement a
Threadable marker. There are also differences
in the usage. Especially if a Service holds state. (However I am not sure
about that. It is a question of the contract.)
> Hm. Marker interfaces as a precurser to JD 1.5 code attributes.
>
You are right marker interfaces are not nice if you see JD 1.5 on the
horizont. The question is wheter we want to wait with this until we don't
need JD 1.4 compliance anymore.
--
Christian Essl http://jucas.sourceforge.net
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [HiveMind] Initializable
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
>
> I would strongly encourage using the proxy. For my taste a
> Service should
> nearly never give out this. That's because in my mind a
> Service is not just
> the implementation but the implementation plus the Interceptors (and
> ServiceModel proxies) and the implementation does not know
> about the other.
> Think of an interceptor which never calls the actual Service
> but has some
> replacement etc.
I agree, which means nothing needs to be passed; if the core implementation needs to vend out the
proxy, it can use the BuilderFactory to assign the proxy to a property. Perhaps another attribute
of <contruct> to specify which property it should be assigned to.
>
> Concerning Threaded model: I'd rather see if
> ServiceImplementations which
> can be used for Threaded must implement a marker interface (as in old
> Servlet-spec). There are just too many implementation
> differences between
> the Singleton and the Threaded. HiveMind should than check that such
> Threaded marked ServiceImpl is never used as Singleton and
> vice-versa.
I think that's an interesting idea; threaded core impls must implement a Threadable marker
interface; pooled implementations must implement a Poolable interface.
Hm. Marker interfaces as a precurser to JD 1.5 code attributes.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [HiveMind] Initializable
Posted by Christian Essl <ch...@yahoo.de>.
I would strongly encourage using the proxy. For my taste a Service should
nearly never give out this. That's because in my mind a Service is not just
the implementation but the implementation plus the Interceptors (and
ServiceModel proxies) and the implementation does not know about the other.
Think of an interceptor which never calls the actual Service but has some
replacement etc.
Concerning Threaded model: I'd rather see if ServiceImplementations which
can be used for Threaded must implement a marker interface (as in old
Servlet-spec). There are just too many implementation differences between
the Singleton and the Threaded. HiveMind should than check that such
Threaded marked ServiceImpl is never used as Singleton and vice-versa.
On Thu, 9 Oct 2003 08:46:20 -0400, Howard M. Lewis Ship
<hl...@comcast.net> wrote:
> Was thinking about this as well; currently, the instantiated service is
> passed as a parameter to the
> initializeService() method.
>
> I'm thinking of stripping this out.
>
> It makes a kind of sense for the singleton and deferred service models
> ... in case they want to,
> say, register with some other service and have the invocation go through
> the service methods
> (including interceptors, such as logging).
>
> However ... adding in the thread-related service models (threaded and
> pooled), I can't decide what
> object they should get ... the service implementation or the proxy?
>
> The more I thought about it, the more I thought the proxy was right; all
> connections between
> services should go through the right proxies, or you run the risk of
> either (a) invoking a method on
> a discarded threaded service impl or (b) invoking a method on a pooled
> service impl.
>
> A service can simply use the BuilderFactory to assign its "serviceThis"
> to a property, if it wants
> to hook itself to another service; it simply won't be hooking any
> particular instance of the service
> that way. Otherwise, the service impl may want to hook a specific
> instance to the other serivce ...
> in which case, it can pass "this".
>
> --
> Howard M. Lewis Ship
> Creator, Tapestry: Java Web Components
> http://jakarta.apache.org/tapestry
> http://jakarta.apache.org/commons/sandbox/hivemind/
> http://javatapestry.blogspot.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
--
Christian Essl http://jucas.sourceforge.net
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org