Re: contributing an interceptor to multiple services

6 Aug 2004 12:07:23 -0000

Yes you are absolutely right it is merely a shortcut to do something that you can do already. The shurtcut just makes it easier - unfortunately also to do it wrong.

Mabe it would help if additional to the inclusion expression an exclusion expression is provided on the <implementation> tag.

On Thu, 5 Aug 2004 19:53:07 -0400, James Carman <[EMAIL PROTECTED]> wrote:

Ok, I'm not so sure that would happen, but there's one way to find out. Can
you get HiveMind to do it currently? The proposed change shouldn't cause
this problem should it? The proposed change is merely a shortcut to do
something that you can already do in HiveMind. Correct?

-----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]

Reply via email to