aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raymond Auge <raymond.a...@liferay.com>
Subject Re: [jax-rs-whiteboard] current status
Date Wed, 07 Dec 2016 17:54:43 GMT
Hey Christian, sorry for the late reply. See inline.

On Fri, Dec 2, 2016 at 8:01 AM, Christian Schneider <chris@die-schneider.net
> wrote:

> I have updated the diagram to reflect the simpler bus creation. This looks
> a lot simpler now.
>
> http://www.liquid-reality.de/x/EoACAQ
>
> From my side the code looks quite good now. Of course we need to reflect
> the new spec changes.
>
> From the spec side I wonder about two things.
>
> 1.
>
> Why do we need osgi.jaxrs.resource.base and osgi.jaxrs.application.base ?
> Couldn't we use the same property name for both? After all they are both
> meant to define a base address on top of what @Path annotations define
>

We discussed this very thing in the EG and agreed to use a single property.
We're just waiting for Tim Ward to commit the agreed changes.


>
> 2.
>
> I am not sure about the practical usage of the whiteboard patterns for
> resources, filters and providers. The problem is that this way you never
> can be sure when an Application is complete. So currently the code destroys
> and recreates the application endpoints for each change.


Tim also addressed this and we do think the whiteboard pattern here is
still very useful.

Besides causing a lot of unrest in the system this also makes endpoints
> available for a certain time that are incomplete and might even pose a
> security risk.
>

I think Tim could probably explain this best.


>
> For most cases I think Application and JAXRsContext should provide all you
> need to add filters, providers and resources in a safe way.
>
> I see the need for some cases where you want to add functionality
> decoupled from the applications / resources but this must be defined in a
> safe way that avoids invalid endpoints available to the outside world. I
> wonder if a pattern like in RSA intents would be better for this. We could
> allow to define a list of named intents at service as well as system level
> that can be implemented by filters, providers and resources. The actual
> endpoints would then only start when all intents are satisfied.
>

I think once the latest updates are public we should revisit your concerns
to see if we've addressed them well enough.

Let's be patient however since the holiday season is upon us and I know
that even without it Tim is very busy. I'm eagerly waiting for his changes
as well :)

Sincerely,
- Ray


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


-- 
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message