You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Christian Schneider <ch...@die-schneider.net> on 2016/12/02 13:01:52 UTC
[jax-rs-whiteboard] current status
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
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.
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.
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.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [jax-rs-whiteboard] current status
Posted by Timothy Ward <ti...@apache.org>.
Hi Ray/Christian,
On 7 Dec 2016, at 17:54, Raymond Auge <ra...@liferay.com>> wrote:
Hey Christian, sorry for the late reply. See inline.
On Fri, Dec 2, 2016 at 8:01 AM, Christian Schneider <ch...@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.
Christian - do you also see the same problems with the Http Whiteboard? It follows the same model with the same restrictions
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.
This is exactly the reason that resources can “require” a particular context, just as they can in the Http Whiteboard
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.
This proposal is just a different syntax for what is already proposed. The current proposal uses the same model as the Http Service Whiteboard. If you want to propose a different implementation then you would:
a) Need to justify making it different from the Http Whiteboard specification, with which there are strong parallels.
b) Need to propose the solution through the OSGi Alliance process so that it could be included in a specification. The validity of IP transfer from an Open Source mailing list is murky at best.
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<http://www.liquid-reality.de/>
Open Source Architect
http://www.talend.com<http://www.talend.com/>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com<http://www.liferay.com/>>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org<http://osgi.org/>> (@OSGiAlliance)
Re: [jax-rs-whiteboard] current status
Posted by Raymond Auge <ra...@liferay.com>.
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)