Oh, it throws the exception. The exception is thrown when trying to build the registry.
-----Original Message----- From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] Sent: Friday, August 06, 2004 9:38 AM To: [email protected] Subject: Re: contributing an interceptor to multiple services This is something that needs looking into, because the code is supposed to fail with an exception, rather than endlessly recurse. I even have a test for this, which is why I'm confused that it can happen! On Thu, 5 Aug 2004 21:53:10 -0400, James Carman <[EMAIL PROTECTED]> wrote: > Ok, I got it to do it. All you need to do is this (in your own module)... > > <implementation service-id="hivemind.BuilderFactory"> > <interceptor service-id="hivemind.LoggingInterceptor" /> > </implementation> > > This does cause a recursive problem. It fails when you try to build a > registry, though, so you won't get too far with that sort of configuration. > > > > -----Original Message----- > From: Christian Essl [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 05, 2004 4:32 PM > To: [email protected] > Subject: Re: contributing an interceptor to multiple services > > 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] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
