+1
I suspect there may be some servlets that were being used as a surrogate for a 
startup configuration component, which will need to be re-factored (eg activate 
or init doing something not related to the servlet function), but that will be 
a good thing. I am assuming that initialisation becomes lazy on all servlets... 
is that right ?
Ian

On 6 Apr 2010, at 20:18, Felix Meschberger wrote:

> Hi all,
> 
> IMHO we have an issue with Sling's access to Servlet registered as
> services and provided as Resources in the Resource tree for handling
> requests:
> 
>   * The Servlet services are eagerly accessed and initialized
>     by the Sling Engine.
>   * The Servlet services are eagerly accessed by the Servlet
>     Resolver bundle to register them as Resources.
>   * Initialization and use of the servlets is split between the
>     Sling Engine and Servlet Resolver.
> 
> I think we should change this as follows:
> 
>  * All Servlet service handling is concentrated in the Servlet
>    Resolver.
>  * Servlet services are accessed on-demand only. This works
>    because all information to register a servlet in the
>    resource tree is provided as service registration properties
> 
> This allows for the registration of Servlet services as service
> factories, e.g. by declaring the servlets as delayed compoents. This in
> turn enables us to optimize resource consumption:
> 
>  * Upon startup, the servlets need not be instantiated, only
>    the ServiceFactory needs to be registered.
>  * As a consequence class loaders creation might be delayed.
>  * Memory can be conserved by not creating objects which are
>    never used or not used often.
>  * Overall startup performance could be increased.
> 
> 
> WDYT ?
> 
> Regards
> Felix

Reply via email to