Felix Meschberger wrote: > If we are at it, why not go bit further down the road: > > ComponentException > We keep that one extending the ServletException, to indicate Component > based exceptions, but we change all signatures to throw ServletException > where currently ComponentException is thrown. > +1
> ComponentFilter/ComponentFilterChain > These are actually more or less duplicates of the Serlvet API Filter and > FilterChain interfaces. We could drop these interfaces and just support > plain old Servlet Filters. +1 (see below) > > Component > The init, service and destroy methods are actually really the same (with > some minor signature differences) as the Serlvet interface methods. We > could have Component extend Servlet and just add the new methods - most > prominently the getId() method. +1 (see below) > This of course brings me to another question: the init and destroy > methods of the Servlet, Filter, Component and ComponentFilter interfaces > are used to implement lifecycle support. In OSGi we do not actually this > because we either have a BundleActivator which starts and stops these to > register them as services or we have them declared using Declarative > Services which has activate and deactivate (other solutions might be > IPojo or DependencyManager). So why not have simple interfaces like: > > ComponentFilter with a single doFilter(request, response, > filterChain) > Component with a single service(request, response) > > objects and - already in the API - stipulate there is some environment > support for lifecycle and configuration management, which need not be > reflected in the API. > Hmm, there is a certain advantage of using well known interfaces like Servlet and Filter. On the other hand, I agree that methods like init and destroy do not make that much sense in an OSGi world. I assume that Sling could call init and destroy when a service has been started or shutdown, so this shouldn't be much of problem. I think, if we can call these methods automatically, we should use Servlet and Filter - if we can't lets use our own interfaces. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
