On 10/13/11 4:30 PM, Alex Karasulu wrote:
I tried to play around the idea yesterday in the train, and I faced some
interesting challenges.
o First, many interecptors are doing calls to the chain again, but
with
a
restricted set of interceptors. For instance, in the
SchemaInterceptor,
we
go through the chain again when modifying the schema itself. In order
to
speedup the operation, we declare a BYPASS sets of interceptors (I'm
not
sure it's a good idea, but right now, this is how we proceed). At the
end,
this BYPASS set is declared this way :
private static final Collection<String> BYPASS;
static
{
Set<String> c = new HashSet<String>();
c.add( AuthenticationInterceptor.******class.getName() );
c.add( AciAuthorizationInterceptor.******class.getName() );
c.add( DefaultAuthorizationIntercepto******r.class.getName()
);
c.add( ExceptionInterceptor.class.******getName() );
c.add( SchemaInterceptor.class.******getName() );
BYPASS = Collections.******unmodifiableCollection( c );
}
As we can see, it creates a static dependency on interceptors. It
might
be
a better idea to use logical names instead of class names, and let the
OSGi
container retrieve the classes itself.
This is a good idea. How about going a little further and having a
set
of
interceptor chain re-entry constants or set of enum values like:
ReEntry.NO_AUTHENTICATION
ReEntry.NO_AUTHORIZATION
ReEntry.NO_ERROR_CHECKING
ReEntry.NO_SCHEMA_CHECKING
etc ...
This is like saying we do not need authentication, authorization,
additional
exception handling and checks or schema checking on re-entry instead of
having a direct list of interceptors to avoid.
That's a good idea.
One thing that might be problematic though is that we have no idea which
interceptors are going to be present in the chain, so we may be unable
to
tell the chain not to use the interceptors added on the fly (for
instance,
the logger interceptor).
Good point. Perhaps this is where we can have some kind of generic
property
that states whether or not by default on re-entry the interceptor should
be
included or excluded. There's a system default, say exclude by default
always. Then the interceptor might override this with some class property
like excludeOnReentry?
This way even though the IC does not know which interceptors are present
it
can react accordingly on reentry. So for this logger interceptor example
it
might have excludeOnReentry set to false in which case it will always be
included when present which makes send. We would not add the interceptor
if
we did not want to log reentrant invocations.
IMO, the best would be to declare sets of (I) we should go through, instead
of sets of (I) we should bypass. This way, we will be able to know what is
being executed, and we won't provide a way for users to pollute the internal
executions of operations (keep in mind that those internal operation are
themselves called by other operations).
We can also declare those sets in the configuration, for each operation, so
if we want to allow someone to modify the execution order, it's still
possible to do so. (it can be done later though).
Perhaps we should break this out and discuss this in a separate thread. The
reason historically for listing what you should not execute was a poor
attempt to decouple and well you just don't know what extra interceptors you
have.
I have some ideas here that I also want to think through as well then post.
Sure, create another thread.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
