Is there a link to the code where the refernce implementation is being kept. I would love to take a look at it.
Thanks David On Thu, Nov 10, 2016 at 3:08 AM, Tim Ward <tim.w...@paremus.com> wrote: > I'll be there, and am happy to talk with you about it. These talks will > likely both be about the upcoming JAX-RS whiteboard specification from OSGi > Enterprise R7 - Liferay are building the reference implementation for it. > > Tim > > Sent from my iPhone > > On 10 Nov 2016, at 08:01, Bernd Eckenfels <e...@zusammenkunft.net> wrote: > > Hello, > > Just noticed at the modconf2016 in Darmstadt (literary event next Tuesday) > there is also a Workshop on this topic: > > https://web.liferay.com/de/web/events2016/modconf > > [ I will be at the conference as well, so maybe we can meet and greet? ] > > Modular Rest APIs using JAX-RS in OSGi (Workshop) > Ort: Lounge, Time: 11:30 - 13:20 > Carlos Sierra Andrés > Core Engineer, Liferay > Abstract: > Building great APIs is essential in an increasingly interconnected world. > In the workshop we will show how to build REST APIs using well known Java > standards while dealing with complexity in an incremental way using OSGi. > We will build a REST API from scratch that will be consumed from a client > application. Creating JAX-RS application in a modular way Incremental > resources and providers Adaptable URL generation Deploying in a OSGi > container We will also introduce the ongoing OSGi RFC-217 for standarizing > JAX-RS inside OSGi containers. > > > > Gruss > Bernd > -- > http://bernd.eckenfels.net > > > > > On Wed, Nov 9, 2016 at 6:36 PM +0100, "Christian Schneider" < > ch...@die-schneider.net> wrote: > > On 08.11.2016 19:59, Ancoron Luciferis wrote: >> > Hi Scott, >> > >> > first let me say thank you for taking the time to address my concerns >> > (sorry if they turned out as something other than just my personal >> > concerns). >> > >> > I think I have gone a little bit too far with my argumentation. >> > >> > My conceptional understanding of RS/RSA currently is that it looks like >> > a blueprint for creating heterogeneous service meshes or service grids. >> > Is that assumption actually true? >> RSA can be used to create service meshes and grids but it is not limited >> to that quite big use case. >> >> You can also scale very small and simply use it to export or import >> services. Exporting a service just means putting some properties on it. >> I just did an improvement for CXF DOSGi that allows to export services >> by just adding one property:https://issues.apache.org/jira/browse/DOSGI-251 >> The code also shows how to use ExportPolicy in practice. I think it >> could be very handy for applying company wide policies to services. For >> example you could add a logging intent to all services without touching >> any user bundles. >> >> On the import side you can use the Aries RSA config discovery together >> with CXF-DOSGi to simply import a REST or SOAP service from the outside >> world. The exporter of the service does not even have to use java. You >> just need a correct java interface with the JAXRS >> annotations.https://github.com/apache/aries-rsa/tree/master/discovery/config >> >> So I think RSA is also a very nice model to export and import services >> with any supported protocol. >> > So, my personal conclusion is that RS/RSA is about communicating with >> > services across nodes/processes. As a result, I would never imply that >> > any RS/RSA implementation must be able to expose my service via >> > JAX-RS/HTTP. As a further result, RS/RSA as a standard is not suitable >> > for the requirement of publishing a ReST endpoint using a JAX-RS >> > annotated service, although some implementations might be. >> > Don't get me wrong, I really am a standards-enthusiast and wherever >> > possible/suitable, I favor a standard over a specific implementation. >> > However, the scope of RS/RSA may include JAX-RS but cannot be relied on. >> > So, at least portability is questionable here as well (same for >> > osgi-jax-rs-connector). >> This is correct. As the standard does not cover the specifics of JAX-RS >> these specifics are not portable. >> On the other hand JAX-RS is standardized so the portability is quite >> good in practice. Even switching >> from the JAX-RS connector to CXF-DOSGi and back is a very small step. >> >> > In essence, I just wondered why multiple people advertised RS/RSA for >> > the simple job of exposing a JAX-RS-annotated service via HTTP, despite >> > the fact that simply CXF alone would be enough (which I'm using as well, >> > btw.), starting with the programmatic way as described in [1]. Putting >> > that in a DS-managed, configurable service and with a few tens of lines >> > I was good to go. Turned out some hundred for production-grade, though. ;) >> Using CXF programmatically is a good approach. It ties you to CXF but >> that is not that problematic. >> The programmatic way is easier to understand as it is more direct. It >> allows to learn a lot about how CXF works. >> >> For a bigger system I prefer RSA/CXF-DOSGi as it easily allows to apply >> central policies and the decoupling from CXF in your user code is also >> beneficial in this case. >> Basically the idea is that a business programmer can focus on the >> business code and keep the business code as clean from technological >> artifacts as possible. >> This is not completely possible with JAX-RS but at least you can often >> avoid to have a CXF dependency. For SOAP, tcp and fastbin transports the >> abstraction from the transport works very well as these are more RPC like. >> >> Ideally I try to only use specs and small APIs in business code. This >> makes the code much easier to test and maintain and also more portable. >> > Anyway, I think I might have missed how "simple" RS/RSA implementations >> > seem to be for the task of exposing a JAX-RS service via HTTP, so I'll >> > give some a try on one of my services. >> Yes that is something we have to advertise better. People have the >> impression that RSA is complicated but for small use cases it is really >> simple. >> >> If you also try the more advanced features I would be really happy about >> feedback of the current approach using intents and ideas for improvement. >> >> Christian >> >> >> -- >> Christian Schneiderhttp://www.liquid-reality.de >> >> Open Source Architecthttp://www.talend.com >> >> _______________________________________________ >> OSGi Developer Mail >> listosgi-...@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev >> >> _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev >
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
