You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Ersin Er (JIRA)" <ji...@apache.org> on 2006/07/12 15:17:29 UTC
[jira] Created: (DIRSERVER-671) interceptor identifiers as service
names: type safity
interceptor identifiers as service names: type safity
-----------------------------------------------------
Key: DIRSERVER-671
URL: http://issues.apache.org/jira/browse/DIRSERVER-671
Project: Directory ApacheDS
Type: Improvement
Components: core
Reporter: Ersin Er
Priority: Trivial
We have several lookup bypass filters in interceptors. Those filters are formed by adding names of some interceptors literally to a collection. However this is not a type safe way and we loose the refactoring capabilities of the IDE also. What we need to do is to define a public final static field in each interceptor to hold its string identifier. So we can add that field to required bypass filters.
For instance the trigger service has a field lke this:
public class TriggerService extends BaseInterceptor
{
public static final String SERVICE_NAME = "triggerService";
...
And a bypass filter can be formed using that as follows:
...
Set c = new HashSet();
c.add( "authenticationService" );
c.add( "authorizationService" );
c.add( "defaultAuthorizationService" );
c.add( "schemaService" );
c.add( "subentryService" );
c.add( "operationalAttributeService" );
c.add( "eventService" );
c.add( TriggerService.SERVICE_NAME ); // <<<-----
USERLOOKUP_BYPASS = Collections.unmodifiableCollection( c );
...
BTW, we also have interceptors' names in the spring configuration but there does not seem to exist a good way to use it.
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (DIRSERVER-671) interceptor identifiers as service
names: type safity
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny resolved DIRSERVER-671.
-----------------------------------------
Resolution: Fixed
Assignee: Emmanuel Lecharny
Fixed. We are now using the XXXService.NAME constant everywhere in the code.
As a consequence, each service should define this NAME constant.
> interceptor identifiers as service names: type safity
> -----------------------------------------------------
>
> Key: DIRSERVER-671
> URL: https://issues.apache.org/jira/browse/DIRSERVER-671
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: core
> Reporter: Ersin Er
> Assigned To: Emmanuel Lecharny
> Priority: Trivial
> Fix For: 1.5.1
>
>
> We have several lookup bypass filters in interceptors. Those filters are formed by adding names of some interceptors literally to a collection. However this is not a type safe way and we loose the refactoring capabilities of the IDE also. What we need to do is to define a public final static field in each interceptor to hold its string identifier. So we can add that field to required bypass filters.
> For instance the trigger service has a field lke this:
> public class TriggerService extends BaseInterceptor
> {
> public static final String SERVICE_NAME = "triggerService";
> ...
> And a bypass filter can be formed using that as follows:
> ...
> Set c = new HashSet();
> c.add( "authenticationService" );
> c.add( "authorizationService" );
> c.add( "defaultAuthorizationService" );
> c.add( "schemaService" );
> c.add( "subentryService" );
> c.add( "operationalAttributeService" );
> c.add( "eventService" );
> c.add( TriggerService.SERVICE_NAME ); // <<<-----
> USERLOOKUP_BYPASS = Collections.unmodifiableCollection( c );
> ...
> BTW, we also have interceptors' names in the spring configuration but there does not seem to exist a good way to use it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRSERVER-671) interceptor identifiers as service
names: type safity
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny updated DIRSERVER-671:
----------------------------------------
Fix Version/s: 1.5.1
There is now a subproject (apacheds-constants) where we can declare all those constants. I agree with Ersin that declaring them straight in the code is not good.
We also have to think about a better way to allow new interceptors to be added (plugins ?)
> interceptor identifiers as service names: type safity
> -----------------------------------------------------
>
> Key: DIRSERVER-671
> URL: https://issues.apache.org/jira/browse/DIRSERVER-671
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: core
> Reporter: Ersin Er
> Priority: Trivial
> Fix For: 1.5.1
>
>
> We have several lookup bypass filters in interceptors. Those filters are formed by adding names of some interceptors literally to a collection. However this is not a type safe way and we loose the refactoring capabilities of the IDE also. What we need to do is to define a public final static field in each interceptor to hold its string identifier. So we can add that field to required bypass filters.
> For instance the trigger service has a field lke this:
> public class TriggerService extends BaseInterceptor
> {
> public static final String SERVICE_NAME = "triggerService";
> ...
> And a bypass filter can be formed using that as follows:
> ...
> Set c = new HashSet();
> c.add( "authenticationService" );
> c.add( "authorizationService" );
> c.add( "defaultAuthorizationService" );
> c.add( "schemaService" );
> c.add( "subentryService" );
> c.add( "operationalAttributeService" );
> c.add( "eventService" );
> c.add( TriggerService.SERVICE_NAME ); // <<<-----
> USERLOOKUP_BYPASS = Collections.unmodifiableCollection( c );
> ...
> BTW, we also have interceptors' names in the spring configuration but there does not seem to exist a good way to use it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRSERVER-671) interceptor identifiers as service
names: type safity
Posted by "Ersin Er (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ersin Er closed DIRSERVER-671.
------------------------------
> interceptor identifiers as service names: type safity
> -----------------------------------------------------
>
> Key: DIRSERVER-671
> URL: https://issues.apache.org/jira/browse/DIRSERVER-671
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: core
> Reporter: Ersin Er
> Assignee: Emmanuel Lecharny
> Priority: Trivial
> Fix For: 1.5.1
>
>
> We have several lookup bypass filters in interceptors. Those filters are formed by adding names of some interceptors literally to a collection. However this is not a type safe way and we loose the refactoring capabilities of the IDE also. What we need to do is to define a public final static field in each interceptor to hold its string identifier. So we can add that field to required bypass filters.
> For instance the trigger service has a field lke this:
> public class TriggerService extends BaseInterceptor
> {
> public static final String SERVICE_NAME = "triggerService";
> ...
> And a bypass filter can be formed using that as follows:
> ...
> Set c = new HashSet();
> c.add( "authenticationService" );
> c.add( "authorizationService" );
> c.add( "defaultAuthorizationService" );
> c.add( "schemaService" );
> c.add( "subentryService" );
> c.add( "operationalAttributeService" );
> c.add( "eventService" );
> c.add( TriggerService.SERVICE_NAME ); // <<<-----
> USERLOOKUP_BYPASS = Collections.unmodifiableCollection( c );
> ...
> BTW, we also have interceptors' names in the spring configuration but there does not seem to exist a good way to use it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.