Re: [eclipse-pmc] API request: Align Http Registry Extensions more close

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

+1

Simon Kaegi/Ottawa/IBM@IBMCA
Sent by: eclipse-pmc-bounces@xxxxxxxxxxx

03/16/2007 01:54 PM

Please respond to
eclipse-pmc@xxxxxxxxxxx

To	eclipse-pmc@xxxxxxxxxxx
cc
Subject	[eclipse-pmc] API request: Align Http Registry Extensions more closely with OSGi Http Service

The extension points in org.eclipse.equinox.http.registry are meant to
enable declarative use of the HttpService. The extension points were
recently reviewed and require a few changes to better mimic the typical
coding patterns when using a ServiceTracker with the HttpService.  In
particualr we want to add support for filtering content based on service
properties and more controlled inter-bundle resource access. We also want
to reduce the scope of some of the built in HttpContext aggregation
capabilities introduced earlier in 3.3 as they can result in complex timing
situations for resource access.

GOALS/BENEFITS:
- aligned more closely with the Http Service
- simpler API

CORRESPONDING BUG:
Design a filtering mechanism to decide against which service instance a
servlet is registered
      https://bugs.eclipse.org/bugs/show_bug.cgi?id=158168
Consider adding "bundle" to set of httpcontext params.
      https://bugs.eclipse.org/bugs/show_bug.cgi?id=163586
HttpContexts extension-point should use "id" instead of "name"
      https://bugs.eclipse.org/bugs/show_bug.cgi?id=177652

RISKS:
Small. These changes add new elements and attributes to the extension point
schema. The shifting from "name" to "id" is backwards
compatible for
typical use where httpcontext and servlet/resource definitions are in the
same bundle. Where the httpcontext and resource/servlet definitions are
in
separate bundles the "name" should be updated to a fully qualified
"id".
HttpContext aggregation involving multiple httpcontext extensions is no
longer supported directly however the httpcontext extension will now
support multiple resource mappings so the resource aggregation use-case
can
be migated to easily. Other uses of aggregation will require creation of
a
custom HttpContext as we're unwilling to commit to having this behaviour
as
API. It should be added that in practice aggregation use is very rare.

PERFORMANCE IMPACTS:
- No impact

_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-pmc