James,
At the danger that this has also been discussed before IMO the problem of recursive calls as I see is as follows (maybe I take it too serious as IMO Spring has sort of the same):
An interceptor is created by an intercept able Service (InterceptorFactory). The InterceptorFactory can be created again by an intercept able Service (ServiceImplementationFactory). The interceptor itself can use any intercept able service and each of this services can use another intercept able service.
So if you by mistake add the interceptor also to the InterceptorFactory or the ServiceImplementationFactory you have a chicken-egg problem (which I strongly guess will result in an Exception). But worse if you add the interceptor to any of the direct or indirect services unconditional used during the interception call (i.e. LoggingService) than you have an endless loop, because the interceptor on the used service calls the service again and by this way itself.
What make it worse are modules. If you take care it is well possible that your defined interceptor works until another module changes - than your definition can be broken. IMO you would need full integration tests for such a feature.
As said probably I take the problem to serious, Spring (at least) had the same, but in Spring it is easier to manage because there is not so much indirection and you fully control all beans. Hivemind is just more powerful than Spring that's why I like Hivemind more.
On Thu, 5 Aug 2004 12:07:19 -0700 (PDT), <[email protected]> wrote:
The following comment has been added to this issue:
Author: James Carman
Created: Thu, 5 Aug 2004 12:06 PM
Body:
I don't know if I understand how this feature causes any dangers. It's true that an interceptor could be called multiple times on the same thread during one service method invocation (a service you're calling uses another service which also has the same interceptor applied). I guess a service interceptor COULD be written to have some thread-specific state (using ThreadLocalStorage of course) and it might not manage that properly. However, that can arise if you do it by copy/paste also, no? I wouldn't say that this feature would CAUSE that problem, though.
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/HIVEMIND-39?page=comments#action_37074
--------------------------------------------------------------------- View the issue: http://issues.apache.org/jira/browse/HIVEMIND-39
Here is an overview of the issue: --------------------------------------------------------------------- Key: HIVEMIND-39 Summary: The ability to specify multiple interfaces of a service Type: Wish
Status: Open Priority: Minor
Project: HiveMind Components: framework Versions: 1.0
Assignee: Howard M. Lewis Ship Reporter: Zhengmao Hu
Created: Thu, 5 Aug 2004 7:24 AM Updated: Thu, 5 Aug 2004 12:06 PM
Description:
(Sorry, because sending email to [EMAIL PROTECTED] can not make me subscribe, so i post it here)
Currently, one service can only have one interface specifiled.
Inside ProxyBuilder.java, the proxy class built only implements this "major" interface. This behavior is coded as such:
public ProxyBuilder(String type, ServicePoint point) { ... _classFab.addInterface(_serviceInterface); ... }
public void addServiceMethods(String indirection) { ... Method[] methods = _serviceInterface.getMethods(); for (int i = 0; i < methods.length; i++) ... ... }
Because of this behavior, if there is a class:
class ServiceABImpl implements ServiceA, ServiceB
This class will be wrapped inside a proxy class, but the proxy class can only implement one interface, that makes the usage of this class/service inconvienent.
So, there is a wish, wish that more than one interfaces can be specified to one service.
--------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Christian Essl
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
