Actually I believe the prototype of the reference implementation is currently here https://github.com/csierra/osgi-jaxrs-extracted <https://github.com/csierra/osgi-jaxrs-extracted> but it will be moved into Apache Aries at some point soon. It’s nice to know that Amdatu is planning to offer a competing implementation though - it always makes for a better spec! :)
Tim > On 10 Nov 2016, at 11:51, Bram Pouwelse <b...@pouwelse.com> wrote: > > https://bitbucket.org/amdatu/amdatu-remoteservices > <https://bitbucket.org/amdatu/amdatu-remoteservices> > > On Thu, Nov 10, 2016 at 12:50 PM David Daniel <david.daniel.1...@gmail.com > <mailto:david.daniel.1...@gmail.com>> wrote: > 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 > <mailto: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 > <mailto: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 >> <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 <http://bernd.eckenfels.net/> >> >> >> >> On Wed, Nov 9, 2016 at 6:36 PM +0100, "Christian Schneider" >> <ch...@die-schneider.net <mailto: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 >> <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 >> <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 Schneider >> http://www.liquid-reality.de <http://www.liquid-reality.de/> >> >> Open Source Architect >> http://www.talend.com <http://www.talend.com/> >> >> _______________________________________________ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> <https://mail.osgi.org/mailman/listinfo/osgi-dev> >> _______________________________________________ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> <https://mail.osgi.org/mailman/listinfo/osgi-dev> > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> > https://mail.osgi.org/mailman/listinfo/osgi-dev > <https://mail.osgi.org/mailman/listinfo/osgi-dev> > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> > https://mail.osgi.org/mailman/listinfo/osgi-dev > <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
