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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]




-- -- Christian Essl http://jucas.sourceforge.net

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to