On 01.12.2016 10:54, Carlos Sierra Andrés wrote:
I propose we make this simpler for now and only introduce the tracking
of Bus as a service if there is a concrete need for it. WDYT?
Regarding the bus handling: in our original implementation we were not
limiting the publication of endpoints to only one. So basically the
administrator could establish several "endpoint publication contexts
(?)" to potentially publishing different applications with different
management on each. Maybe this no longer makes sense in the context of
this new impl. It it true that, if we keep the ability to have more
than one endpoint, we would need to mark the buses somehow so only the
interesting ones are tracked. This Buses could be created, for
instance, after configuration admin factories. Anyhow, as I said
before, this might no longer make sense in the context of this RI.
The servlet whiteboard is fine. The only downside is that it makes the
code a bit incompatible with old HttpService impls. In CXF we switched
to using the HttpService directly for the servlet transport but I think
for this new impl it should be fine to rely on the whiteboard spec.
I am also making use of the Servlet Whiteboard, which is why I publish
the Servlet, and might not be desirable either.
Open Source Architect