Hi,
I have a problem and wonder what is the best solution.
My application has an authentication service which is responsible for
realizing a single signon to different middleware systems. For each
middleware
there is a special Connector class that is realized as a sevice too.
No I have to tell the Authentication service which other services to use
as "authenticators". My first solution was to use <set-service> :
<service-point id="Authentication" interface="AuthenticationService">
<invoke-factory service-id="hivemind.BuilderFactory">
<construct class="AuthenticationServiceImpl" >
<set-service service-id="AuthenticatorA" property="nextAuthenticator"/>
<set-service service-id="AuthenticatorB" property="nextAuthenticator"/>
</construct>
</invoke-factory>
</service-point>
Actually "nextAuthenticator" is not really a property, since it adds the
authenticator to a list. Maybe one could add a "method" attribute to
set-service for such cases, where you want to add multiple services of the
same type (listeners for example) :
<set-service service-id="AuthenticatorA" method="addAuthenticator" />
But this doesn't solve the next problem: I want to add more authenticators
from different modules. Obviously I should use a configuration instead,
but it's not so clean as it should be:
<configuration-point id="Authenticators">
<schema>
<element name="authenticator">
<attribute name="service-id" required="true"/>
<conversion class="InstanceHolder" >
<map attribute="service-id" property="instance" translator="service" />
</conversion>
</element>
</schema>
</configuration-point>
What is bugging me here, is that I have to use the InstanceHolder class
which is just a wrapper around an object.
The method AuthenticationServiceImpl.setAuthenticators(List
authenticators) that is used for setting the configuration, receives a
list of InstanceHolders that contains instances of Authenticator. Kind of
ugly in my opinion.
Is there another solution that gets rid of the InstanceHolder class
(custom rule?) ?
Bye
Achim
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
|