aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Sierra Andrés <>
Subject Re: [jax-rs-whiteboard] First review
Date Thu, 01 Dec 2016 09:54:56 GMT
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.
> 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
>> Open Source Architect

View raw message