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
