aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Ward <>
Subject Re: [jax-rs-whiteboard] current status
Date Wed, 14 Dec 2016 15:20:56 GMT
Hi Ray/Christian,

On 7 Dec 2016, at 17:54, Raymond Auge <<>>

Hey Christian, sorry for the late reply. See inline.

On Fri, Dec 2, 2016 at 8:01 AM, Christian Schneider <<>

I have updated the diagram to reflect the simpler bus creation. This looks
a lot simpler now.

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.


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.


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 :)

- Ray


Christian Schneider<>

Open Source Architect<>

*Raymond Augé* <>
Senior Software Architect *Liferay, Inc.* <<>>
Board Member & EEG Co-Chair, OSGi Alliance <<>>

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