I'm partially leaning to re-implementation also. I have not had a chance to look at the code again, but I think it was a little bit tightly coupled to Rio's (service associations) features, instead of pure Jini. This was an accelerator for me at the time.
I'm very sure I could use the lessons learnt at the time to re-implement it in a couple of days of spare time, with the additional benefit of 4 years extra life experience :-) warm regards, Dawid On 07/09/2016 07:42, Peter wrote: > > > A few quick thoughts: > > 1. An existing implementation, even if hurriedly implemented is a good place > to start understanding the interop gap we're attempting to bridge. > 2. As Dennis has suggested, we may decide to implement from scratch, if > either the original implementation cannot be donated (for whatever reason) or > we learn from the implementation and want to make a second attempt to produce > something we're happy supporting long term. > 3. Exporting spring services sounds good too. > > Good to see people positively engaged. > > Thanks & Cheers, > > Peter. > > > Sent from my Samsung device. > > Include original message > ---- Original message ---- > From: Dennis Reedy <dennis.re...@gmail.com> > Sent: 06/09/2016 11:25:32 pm > To: dev@river.apache.org <dev@river.apache.org> > Subject: Re: Exporters for other RPC frameworks > > Hi Dawid, > > I remember chatting about this when you did the work, I think it would be > great if we could even do it from scratch as a side-project. As an aside, > we can also consider things like exporting Spring services as River > services: > > http://docs.spring.io/autorepo/docs/spring/3.2.x/spring-framework-reference/html/remoting.html > > > Somewhat different angle on this, but can illustrate that River is part of > s larger eco-system. > > Regards > > Dennis > > On Tue, Sep 6, 2016 at 8:48 AM, Dawid Loubser <da...@travellinck.com> wrote: > >> I'm going to have a chat to the client (I don't do that much work for >> them anymore). >> And I will have to dust off what I did, and probably generalise it - it >> was for very specific circumstances, developed in a hurry, but it's been >> running on a couple of services in production for 4 years, so the basics >> hold up :-) >> >> To be honest, I haven't looked at the work you guys have been doing on >> River 3 - but that would be a good starting point. >> >> What I did, was basically to write a service (which wraps a web >> container), which you could configure to look for other services >> (usually by type, but perhaps using other service properties as >> selection criteria). It would generate "smart" proxies (which track, and >> delegate calls to, a normal Jini service) and expose them as your choice >> of web service style (SOAP, REST) and manage them in the embedded web >> container. >> >> chat soon - >> Dawid >> >> >> On 06/09/2016 13:32, Bryan Thompson wrote: >> > +1 I see exposing Jini / River more broadly as key. >> > >> > Bryan >> > >> > On Tue, Sep 6, 2016 at 4:18 AM, Peter <j...@zeus.net.au> wrote: >> > >> >> Thanks Dawid, talk about surpassing expectations. >> >> >> >> That's great news if you're able to donate your webservices works to >> >> River, I agree, it will expose River to a potentially much wider >> audience >> >> with needs that River is presently unable to cater for, and may ignite >> >> greater interest as a result. >> >> >> >> Regards, >> >> >> >> Peter. >> >> >> >> Sent from my Samsung device. >> >> >> >> Include original message >> >> ---- Original message ---- >> >> From: Dawid Loubser <da...@travellinck.com> >> >> Sent: 06/09/2016 07:37:26 pm >> >> To: dev@river.apache.org >> >> Subject: Re: Exporters for other RPC frameworks >> >> >> >> In 2012, I wrote infrastructure to export Jini services (running in >> >> Dennis Reedy's Rio service provisioning infrastructure) as either >> >> SOAP/XML web services, or RESTful JSON services, or - uniquely I believe >> >> - both at the same time without having to write adaptors or different >> >> interfaces. >> >> >> >> I remember having to write some tricky smart-proxy generation code (I >> >> used ASM at the time) in order to end up with proxies which JAX-WS and >> >> JAX-RS would be happy to expose (in an embedded Grizzly web container) - >> >> and dealing smoothly with services coming, going, and moving. >> >> >> >> If anybody would be interested in my work in this space - even though I >> >> did it commercially, I believe the client will be open to me >> >> open-sourcing it. >> >> >> >> But basically, I think there is a strong need to expose Jini services >> >> "at the edges" to common protocols like SOAP or RESTful JSON/HTTP. I >> >> couldn't find anything, which is why I wrote my own. >> >> >> >> warm regards, >> >> Dawid Loubser >> >> >> >> >> >> On 06/09/2016 11:12, Peter Firmstone wrote: >> >>> Anyone interested in Exporters for other RPC Frameworks? >> >>> >> >>> If so which and why? >> >>> >> >>> Pete. >> >>> >> >>> Sent from my Samsung device. >> >>> >> >>> >> >> >> >> >> >> >> >> >> > > >