Hi Christian,

thank you so much for this work! I will go through it and try to match it with the current impl.

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.

I am also making use of the Servlet Whiteboard, which is why I publish the Servlet, and might not be desirable either.

I am in the process of pushing the integration tests, so we can be more confident when making refactors.


El 1/12/16 a las 10:36, Christian Schneider escribió:
I analyzed the Design of jax-rs whiteboard and how the trackers are interrelated. This is what I came up with:
Do you think this is correct? Would be happy about any hints or ideas how to improve this doc. I will also try to mive this to an apache system so we can all work on it.

One other finding:

I am not sure if the Bus handling is correct. ServicesRegistrator creates a Bus and a Servlet and publishes them as services. BusServiceTrackerCustomizer then picks up all Bus services and registers several trackers for each. I think this can be problematic if other bundles using CXF also publish Bus services.

What is the purpose of tracking the Bus as a service? I wonder if it would also work to just use the one Bus we create without the indirection of a tracker.


On 29.11.2016 12:05, Christian Schneider wrote:

I took some time to look into the jax-rs whiteboard code and noted some findings below.


  * The code is formatted with tabs. I propose to use spaces like in
    the other aries modules
  * In some java files there is a empty line between each line of
    code. I think empty lines should only be used for bigger blocks.
  * Some attribute defs are in the end of the class code. Will move
    them to the top
  * The line wrapping for parameters is different from the default.
    Generally I like the wrapping this way but the formatter is not
    configured for it so an autoformat would destroy this.
    So I propose to rather use the default formatting we have.

I just checked the aries coding conventions. Seems we have the rule of 4 Spaces instead of Tabs but not further rules. I think most of the code uses the eclipse defaults but we might want to provide a formatter to make it easier. Any opinions here?


  * The poms did not have the apache header. I already added it
  * The classes all have the author tag of Carlos. I propose we remove
    these as the author of each line is visible from git anyway and
    the author tag can be misleading if other people also edit the code
  * I get an error in each pom in eclipse at Manifest.write. Not sure
    what causes this but we should try to fix that
  * There is a project for log4j-configuration. I propose we use pax
    logging or logback instead of a fragment

Besides these there also might be some issues with concurrency. I will look into these in more detail.

Christian Schneider

Open Source Architect

Reply via email to