Hi Christian,
thank you so much for this work! I will go through it and try to match
it with the current impl.
Advertising
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.
Carlos.
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:
http://liquid-reality.de/display/liquid/Design+Aries+JAX-RS-whiteboard
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.
Christian
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.
Formatting:
* 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?
Other:
* 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
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
