Re: [jax-rs-whiteboard] First review

[Raymond Auge]

Please note the OSGi api does not yet reflect the latest accepted RFC
changes.

- Ray

On Dec 1, 2016 3:08 PM, "Carlos Sierra Andrés" 
wrote:

> FYI... I already uploaded the spec classes.
>
> Bests.
>
> Carlos.
>
>
> El 1/12/16 a las 12:41, Raymond Auge escribió:
>
>> I can request doing that, but for the meantime, we need to get a cut of
>> the
>> API from the OSGi git repo.
>>
>> @Carlos, would you retrieve the latest API sources from the OSGi git repo
>> and import them into the API module?
>>
>> - Ray
>>
>> On Thu, Dec 1, 2016 at 11:12 AM, Christian Schneider <
>> ch...@die-schneider.net> wrote:
>>
>> Hi Ray,
>>>
>>> the new spec mentions the JaxRsContext. Is this already available in a
>>> spec api jar?
>>> Not sure if the OSGi alliance is consisdering this but it would be great
>>> to have the most current spec (in development) as a SNAPSHOT in maven.
>>>
>>> Christian
>>>
>>> On 01.12.2016 11:41, Raymond Auge wrote:
>>>
>>> Please consider the changes recently made and accepted to the
 jax-rs-whiteboard RFC [1] (look for the yellow change markers)

 - Ray

 [1]
 https://github.com/osgi/design/blob/master/rfcs/rfc0217/rfc-
 217-JAX-RS-Services.pdf


 --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> http://www.talend.com
>>>
>>>
>>>
>>

Re: [jax-rs-whiteboard] First review

[Carlos Sierra Andrés]

FYI... I already uploaded the spec classes.

Bests.

Carlos.


El 1/12/16 a las 12:41, Raymond Auge escribió:

I can request doing that, but for the meantime, we need to get a cut of the
API from the OSGi git repo.

@Carlos, would you retrieve the latest API sources from the OSGi git repo
and import them into the API module?

- Ray

On Thu, Dec 1, 2016 at 11:12 AM, Christian Schneider <
ch...@die-schneider.net> wrote:


Hi Ray,

the new spec mentions the JaxRsContext. Is this already available in a
spec api jar?
Not sure if the OSGi alliance is consisdering this but it would be great
to have the most current spec (in development) as a SNAPSHOT in maven.

Christian

On 01.12.2016 11:41, Raymond Auge wrote:


Please consider the changes recently made and accepted to the
jax-rs-whiteboard RFC [1] (look for the yellow change markers)

- Ray

[1]
https://github.com/osgi/design/blob/master/rfcs/rfc0217/rfc-
217-JAX-RS-Services.pdf



--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [jax-rs-whiteboard] First review

[Carlos Sierra Andrés]

yup... I guess I can do that...

Carlos.


El 1/12/16 a las 12:41, Raymond Auge escribió:

I can request doing that, but for the meantime, we need to get a cut of the
API from the OSGi git repo.

@Carlos, would you retrieve the latest API sources from the OSGi git repo
and import them into the API module?

- Ray

On Thu, Dec 1, 2016 at 11:12 AM, Christian Schneider <
ch...@die-schneider.net> wrote:


Hi Ray,

the new spec mentions the JaxRsContext. Is this already available in a
spec api jar?
Not sure if the OSGi alliance is consisdering this but it would be great
to have the most current spec (in development) as a SNAPSHOT in maven.

Christian

On 01.12.2016 11:41, Raymond Auge wrote:


Please consider the changes recently made and accepted to the
jax-rs-whiteboard RFC [1] (look for the yellow change markers)

- Ray

[1]
https://github.com/osgi/design/blob/master/rfcs/rfc0217/rfc-
217-JAX-RS-Services.pdf



--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [jax-rs-whiteboard] First review

[Raymond Auge]

I can request doing that, but for the meantime, we need to get a cut of the
API from the OSGi git repo.

@Carlos, would you retrieve the latest API sources from the OSGi git repo
and import them into the API module?

- Ray

On Thu, Dec 1, 2016 at 11:12 AM, Christian Schneider <
ch...@die-schneider.net> wrote:

> Hi Ray,
>
> the new spec mentions the JaxRsContext. Is this already available in a
> spec api jar?
> Not sure if the OSGi alliance is consisdering this but it would be great
> to have the most current spec (in development) as a SNAPSHOT in maven.
>
> Christian
>
> On 01.12.2016 11:41, Raymond Auge wrote:
>
>> Please consider the changes recently made and accepted to the
>> jax-rs-whiteboard RFC [1] (look for the yellow change markers)
>>
>> - Ray
>>
>> [1]
>> https://github.com/osgi/design/blob/master/rfcs/rfc0217/rfc-
>> 217-JAX-RS-Services.pdf
>>
>>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>


-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)

Re: [jax-rs-whiteboard] First review

[Christian Schneider]

Hi Ray,

the new spec mentions the JaxRsContext. Is this already available in a 
spec api jar?
Not sure if the OSGi alliance is consisdering this but it would be great 
to have the most current spec (in development) as a SNAPSHOT in maven.


Christian

On 01.12.2016 11:41, Raymond Auge wrote:

Please consider the changes recently made and accepted to the
jax-rs-whiteboard RFC [1] (look for the yellow change markers)

- Ray

[1]
https://github.com/osgi/design/blob/master/rfcs/rfc0217/rfc-217-JAX-RS-Services.pdf



--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [jax-rs-whiteboard] First review

[Carlos Sierra Andrés]

Cool!...

thx Ray.

Carlos.


El 1/12/16 a las 11:41, Raymond Auge escribió:

Please consider the changes recently made and accepted to the
jax-rs-whiteboard RFC [1] (look for the yellow change markers)

- Ray

[1]
https://github.com/osgi/design/blob/master/rfcs/rfc0217/rfc-217-JAX-RS-Services.pdf

On Dec 1, 2016 10:12 AM, "Christian Schneider" 
wrote:


On 01.12.2016 10:54, Carlos Sierra Andrés wrote:


Hi Christian,

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 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?


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


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.

Christian

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [jax-rs-whiteboard] First review

[Raymond Auge]

Please consider the changes recently made and accepted to the
jax-rs-whiteboard RFC [1] (look for the yellow change markers)

- Ray

[1]
https://github.com/osgi/design/blob/master/rfcs/rfc0217/rfc-217-JAX-RS-Services.pdf

On Dec 1, 2016 10:12 AM, "Christian Schneider" 
wrote:

> On 01.12.2016 10:54, Carlos Sierra Andrés wrote:
>
>> Hi Christian,
>>
>> 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 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?
>
>>
>> I am also making use of the Servlet Whiteboard, which is why I publish
>> the Servlet, and might not be desirable either.
>>
> 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.
>
> Christian
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>

Re: [jax-rs-whiteboard] First review

[Christian Schneider]

On 01.12.2016 10:54, Carlos Sierra Andrés wrote:

Hi Christian,

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 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?


I am also making use of the Servlet Whiteboard, which is why I publish 
the Servlet, and might not be desirable either.
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.


Christian

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [jax-rs-whiteboard] First review

[Carlos Sierra Andrés]

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.


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

Re: [jax-rs-whiteboard] First review

[Christian Schneider]

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



--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [jax-rs-whiteboard] First review

[Christian Schneider]

Hi Carlos,

thanks for the changes. I also did some more refactorings in the code to 
improve readabiltiy.


About the conventions. We currently only have this which is a little sparse:
http://aries.apache.org/development/guidelines.html

So I think the standard eclipse formatter should at least satisfy the 
two rules. The rules do not mention the formatter. So we can of course 
use a different one but I guess using the default might be easiest.


Christian

On 29.11.2016 18:05, Carlos Sierra Andrés wrote:

Hi again,

for the moment I have changed tabs for spaces and removed the author 
tag in the classes.


For the rest I understood there exist some coding conventions or 
formatter?


Best.

Carlos.




--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [jax-rs-whiteboard] First review

[Carlos Sierra Andrés]

Hi again,

for the moment I have changed tabs for spaces and removed the author tag 
in the classes.


For the rest I understood there exist some coding conventions or formatter?

Best.

Carlos.


El 29/11/16 a las 12:05, Christian Schneider escribió:
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

Re: [jax-rs-whiteboard] First review

[Carlos Sierra Andrés]

Hi Christian,

thanks for looking into this. For me it's fine to use whichever 
conventions are appropiate. I just commited the source with the 
conventions we had in our code.


where is the formatter you mention and how can it be used?

I can adapt the sources to the conventions it enforces.

Regarding the author comment... sure, let's remove it... it is also part 
of the conventions we had in the previous work.


Please let me know if you find any concurrency issues.

Bests.

Carlos.

El 29/11/16 a las 12:05, Christian Schneider escribió:
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