Folks Is it appropriate to have on going propaganda for various RSA implementations on the OSGi dev e-mail list? Cannot interest parties be forwarded to the appropriate Karaf & Eclipse community lists?
Or are we all using this list as a sales tool for product & services? Paremus have an extremely light-weight, low latency implementation of RSA that is secure by default - extremely simple to use - and Paremus have been driving many of the specs in this area. Im sure IBM also have high quality implementation and the Amdatu RI hasn’t been mentioned in this thread either... See what I mean... > On 10 Nov 2016, at 08:01, osgi-dev-requ...@mail.osgi.org wrote: > > Send osgi-dev mailing list submissions to > osgi-dev@mail.osgi.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.osgi.org/mailman/listinfo/osgi-dev > or, via email, send a message with subject or body 'help' to > osgi-dev-requ...@mail.osgi.org > > You can reach the person managing the list at > osgi-dev-ow...@mail.osgi.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of osgi-dev digest..." > > > Today's Topics: > > 1. Re: RS/RSA for exposing JAX-RS resources (Christian Schneider) > 2. Re: Enroute Rest (manoj.vrajam...@wipro.com) > 3. Re: RS/RSA for exposing JAX-RS resources (Bernd Eckenfels) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 9 Nov 2016 18:35:43 +0100 > From: Christian Schneider <ch...@die-schneider.net> > To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> > Subject: Re: [osgi-dev] RS/RSA for exposing JAX-RS resources > Message-ID: <dea2c70a-d860-7232-400f-02d9b5509...@die-schneider.net> > Content-Type: text/plain; charset=windows-1252; format=flowed > > 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 Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > > > > ------------------------------ > > Message: 2 > Date: Thu, 10 Nov 2016 05:17:34 +0000 > From: <manoj.vrajam...@wipro.com> > To: <osgi-dev@mail.osgi.org> > Subject: Re: [osgi-dev] Enroute Rest > Message-ID: > > <kl1pr03mb1576e8210cf9cb78cb296774ea...@kl1pr03mb1576.apcprd03.prod.outlook.com> > > Content-Type: text/plain; charset="us-ascii" > > * Do we have option to set HTTP Header set > Access-Control-Allow-Origin "*" on the Jetty side of Enroute (by any > chance?) !!! > > * Can we ignore CORS altogether. I tried many options from the > Firefox/Ubuntu side (both setting/ignoring) and still it fails... > > * I have a feeling that this needs some tweak on the server-side > (Enroute rest) ? Please correct/advise me.. > > From: osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org] > On Behalf Of Neil Bartlett > Sent: 09 November 2016 17:24 > To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> > Subject: Re: [osgi-dev] Enroute Rest > > > ** This mail has been sent from an external source ** > You can read about CORS here: > https://en.wikipedia.org/wiki/Cross-origin_resource_sharing > > Regards, > Neil > > > > On 9 Nov 2016, at 11:51, > <manoj.vrajam...@wipro.com<mailto:manoj.vrajam...@wipro.com>> > <manoj.vrajam...@wipro.com<mailto:manoj.vrajam...@wipro.com>> wrote: > > Hi All, > > I am trying to retrieve an http response (json string) from an osgi app > implementing enroute rest api. > > When i write a client html app and invoke the osgi app, it gets invoked and > returns the string. But I get a warning as below and I am unable to see the > text in my browser page. > > Cross-Origin Request Blocked: The Same Origin Policy disallows reading the > remote resource at http://127.0.0.1:8080/rest/execute/app/foo (Reason: CORS > header 'Access-Control-Allow-Origin' missing). > > Does this have anything to do with the http response header in the enroute > rest ? Would appreciate any quick solution/pointers.. > > Thanks, > Manoj > The information contained in this electronic message and any attachments to > this message are intended for the exclusive use of the addressee(s) and may > contain proprietary, confidential or privileged information. If you are not > the intended recipient, you should not disseminate, distribute or copy this > e-mail. Please notify the sender immediately and destroy all copies of this > message and any attachments. WARNING: Computer viruses can be transmitted via > email. The recipient should check this email and any attachments for the > presence of viruses. The company accepts no liability for any damage caused > by any virus transmitted by this email. www.wipro.com<http://www.wipro.com/> > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org<mailto:osgi-dev@mail.osgi.org> > https://mail.osgi.org/mailman/listinfo/osgi-dev > > The information contained in this electronic message and any attachments to > this message are intended for the exclusive use of the addressee(s) and may > contain proprietary, confidential or privileged information. If you are not > the intended recipient, you should not disseminate, distribute or copy this > e-mail. Please notify the sender immediately and destroy all copies of this > message and any attachments. WARNING: Computer viruses can be transmitted via > email. The recipient should check this email and any attachments for the > presence of viruses. The company accepts no liability for any damage caused > by any virus transmitted by this email. www.wipro.com > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://mail.osgi.org/pipermail/osgi-dev/attachments/20161110/3b99dbed/attachment-0001.html> > > ------------------------------ > > Message: 3 > Date: Thu, 10 Nov 2016 08:01:26 +0000 (UTC) > From: Bernd Eckenfels <e...@zusammenkunft.net> > To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> > Subject: Re: [osgi-dev] RS/RSA for exposing JAX-RS resources > Message-ID: > <57a008faa9e6e1e3.c3b32ea6-5ed5-4490-bb41-d9a6d0675...@mail.outlook.com> > > Content-Type: text/plain; charset="utf-8" > > 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:20Carlos Sierra Andr?sCore Engineer, LiferayAbstract: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 Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://mail.osgi.org/pipermail/osgi-dev/attachments/20161110/d55e0a70/attachment.html> > > ------------------------------ > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > > End of osgi-dev Digest, Vol 121, Issue 20 > ***************************************** _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
