Could we change the <implementation> element to take a comma-separated list
of regular expressions for matching service-ids within the registry? That
might help this situation (and another one that we recently discussed
involving contributing an interceptor to multiple services)...
<implementation service-id="ServiceA, ServiceB">
<invoke-factory service-id="hivemind.BuilderFactory">
<construct class="com.myco.ServiceABImpl" />
</invoke-factory>
</implementation>
<implementation service-id="mymodule.*">
<interceptor service-id="SecurityInterceptor" />
</implementation>
I think this could be done without breaking current module definition files,
since nobody was using the regular expressions before anyway.
-----Original Message-----
From: [email protected]
[mailto:[EMAIL PROTECTED]
Sent: Thursday, August 05, 2004 1:35 PM
To: [email protected]
Subject: [jira] Commented: (HIVEMIND-39) The ability to specify multiple
interfaces of a service
The following comment has been added to this issue:
Author: Christian Essl
Created: Thu, 5 Aug 2004 10:34 AM
Body:
The aggregate interface certainly solves the issues. However I think it
comes with two problems:
First you have to add a conceptual unnecessary interface, which increases
complexity and second you bind two things together just because of the
current implementation, which decreases flexibility.
My suggestion would be that an implementation can map to more than one
service, where the service represents one interface.
This would also come handy for interceptors. I.e. if you have a
SecurityInterceptor you would probably have different requirements for
live-cycle and business methods. If the interceptor does not support
(interface or method based) filtering you are lost, if it (certainly) does
you have higher setup needs and probably less performance. (IMO the same
applies to other interceptors as well).
I think the current one to one mapping of service to implementations, breaks
a main reason interfaces exist in Java: That implementations (classes) can
represent different out of hierarchy types and where the user is shielded
from not only how (that could be done with abstract classes) but also where
the types are implemented.
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/HIVEMIND-39?page=comments#action_37063
---------------------------------------------------------------------
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 10:34 AM
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
