Send ecf-dev mailing list submissions to
ecf-dev@xxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
or, via email, send a message with subject or body 'help' to
ecf-dev-request@xxxxxxxxxxx
You can reach the person managing the list at
ecf-dev-owner@xxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ecf-dev digest..."
Today's Topics:
1. Re: tutorial idea: OSGi remote services for existing services
(Scott Lewis)
2. Re: tutorial idea: OSGi remote services for existing services
(Keimel, Christoph)
3. Re: tutorial idea: OSGi remote services for existing services
(Wim Jongman)
4. Re: tutorial idea: OSGi remote services for existing services
(Scott Lewis)
----------------------------------------------------------------------
Message: 1
Date: Mon, 08 Dec 2014 13:05:52 -0800
From: Scott Lewis <slewis@xxxxxxxxxxxxx>
To: ecf-dev@xxxxxxxxxxx
Subject: Re: [ecf-dev] tutorial idea: OSGi remote services for
existing services
Message-ID: <548612B0.4090705@xxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi Folks,
To go along with the example client code for the Geonames Timezone
service [1], I've started a tutorial that details/documents how this
example was created [2].
The tutorial is not finished yet (e.g. running the example consumer),
but that's a good time for review and feedback :). Please review and
provide feedback if you can. My intention is to finish this tutorial
prior to release of ECF 3.9.2 on December 22nd.
Thanks,
Scott
[1] https://github.com/ECF/Geonames
[2]
https://wiki.eclipse.org/Tutorial:_ECF_Remote_Services_for_Accessing_Existing_REST_Services
On 12/5/2014 11:10 AM, Scott Lewis wrote:
Hi Folks,
I've been working on the example code for this tutorial, and the
latest is available on github [1].
As I said below, I found a small bug in the rest client code that had
to be addressed [2] and I've since fixed this bug, and added a couple
of 'builder' classes to simplify the construction of the association
between the RSA-constructed remote service proxy and the REST request
creation, execution, and response handling.
The upshot is that I would like to propose that we have another
maintenance release before the end of 2014 to pick up these fixes and
small additions, so that when I finish the tutorial ECF Remote
Services impl will fully support it.
Any objections to maintenance release (3.9.2) this month? I was
thinking perhaps Dec 22nd to make an early Christmas gift. :)
Thanks,
Scott
On 11/27/2014 3:11 PM, Scott Lewis wrote:
I've created a new github repo for the Geonames Timezone example I've
been working on. The bundles so far are (in bundles directory):
1. org.geonames.timezone - declares the Geonames timezone API as an
OSGi service interface called ITimezoneService
2. org.eclipse.ecf.provider.geonames.timezone.client - An ECF Remote
Services provider using the ECF Rest API and JSON parser to make the
REST call and process the server's JSON response.
I've also begun the creation of two consumer bundles to test the
above provider
3. org.eclipse.ecf.geonames.timezone.consumer - A very simple
consumer which finds (via ServiceTracker) ITimezoneService proxies
and then calls the ITimezoneService.getTimezone/2 method on the added
proxy.
4. org.eclipse.ecf.geonames.timezone.consumer.edef = A very simple
EDEF bundle, containing the EDEF to discover the Geonames timezone
service, with RSA then creating the ITimezoneService proxy.
Over the next week, I'm going to write a short tutorial that shows
particularly the code in org.geonames.timezone (remote service API)
and org.eclipse.ecf.provider.geonames.timezone.client (REST Client
Remote Services ECF provider)
In testing this code unfortunately I discovered an oversight bug in
the RestClientService class from the changeover from httpclient 3.3
to 4.X. See [2] for details. To get this new example to work, this
fix has to be in place in the runtime, meaning that we will need to
produce 3.9.2 release for people to be able to successfully run the
timezone example themselves. We can discuss the timing of 3.9.2
creation and release relative to other things that committers and
contributors are currently working on.
If people have comments about any of this, would like to
help/contribute on this example, or would like to suggest specific
things to focus on for the wiki tutorial, please say so here, produce
a pull request, or contact me directly to coordinate on the tutorial.
Thanks,
Scott
[1] https://github.com/ECF/Geonames
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=453484
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
------------------------------
Message: 2
Date: Tue, 9 Dec 2014 09:18:19 +0000
From: "Keimel, Christoph" <c.keimel@xxxxxxx>
To: "Eclipse Communication Framework (ECF) developer mailing list."
<ecf-dev@xxxxxxxxxxx>
Subject: Re: [ecf-dev] tutorial idea: OSGi remote services for
existing services
Message-ID:
<8FF6D5A0093A1041873F086CCB503A2D4E7CAC6B@xxxxxxxxxxxxx.local>
Content-Type: text/plain; charset="iso-8859-1"
Hi Scott
Thanks for working on a tutorial on this subject! It reads very well and understandable. There are some questions I asked myself while reading. Maybe this could also be interesting for others?
Quote:
"2. Serialize the parameters passed to the getTimezone method (i.e. 'lat' and 'lng') and add them as URL request parameters, resulting in the URL: http://api.geonames.org/timezoneJSON?lat=<lat param value>&lng=<lng param value>&username=<username default value>"
Questions:
1. How does ECF know which parameters of the function getTimezone correspond to the parameters of the REST service? Is the relation itself built in the order in which the parameters where defined?
2. Would it be possible to overload getTimezone and also have a version supplying the username?
3. Would it be possible to overload getTimezone adding some other parameter unrelated to the REST request, which should be cached to be reused by the responseDeserializer?
4. How does ECF know how to serialize the parameters of the function getTimezone for the request URL? Is this customizable?
Smile
Christoph
-----Urspr?ngliche Nachricht-----
Von: ecf-dev-bounces@xxxxxxxxxxx [mailto:ecf-dev-bounces@xxxxxxxxxxx] Im Auftrag von Scott Lewis
Gesendet: Montag, 8. Dezember 2014 22:06
An: ecf-dev@xxxxxxxxxxx
Betreff: Re: [ecf-dev] tutorial idea: OSGi remote services for existing services
Hi Folks,
To go along with the example client code for the Geonames Timezone service [1], I've started a tutorial that details/documents how this example was created [2].
The tutorial is not finished yet (e.g. running the example consumer), but that's a good time for review and feedback :). Please review and provide feedback if you can. My intention is to finish this tutorial prior to release of ECF 3.9.2 on December 22nd.
Thanks,
Scott
[1] https://github.com/ECF/Geonames
[2]
https://wiki.eclipse.org/Tutorial:_ECF_Remote_Services_for_Accessing_Existing_REST_Services
On 12/5/2014 11:10 AM, Scott Lewis wrote:
Hi Folks,
I've been working on the example code for this tutorial, and the
latest is available on github [1].
As I said below, I found a small bug in the rest client code that had
to be addressed [2] and I've since fixed this bug, and added a couple
of 'builder' classes to simplify the construction of the association
between the RSA-constructed remote service proxy and the REST request
creation, execution, and response handling.
The upshot is that I would like to propose that we have another
maintenance release before the end of 2014 to pick up these fixes and
small additions, so that when I finish the tutorial ECF Remote
Services impl will fully support it.
Any objections to maintenance release (3.9.2) this month? I was
thinking perhaps Dec 22nd to make an early Christmas gift. :)
Thanks,
Scott
On 11/27/2014 3:11 PM, Scott Lewis wrote:
I've created a new github repo for the Geonames Timezone example I've
been working on. The bundles so far are (in bundles directory):
1. org.geonames.timezone - declares the Geonames timezone API as an
OSGi service interface called ITimezoneService 2.
org.eclipse.ecf.provider.geonames.timezone.client - An ECF Remote
Services provider using the ECF Rest API and JSON parser to make the
REST call and process the server's JSON response.
I've also begun the creation of two consumer bundles to test the
above provider
3. org.eclipse.ecf.geonames.timezone.consumer - A very simple
consumer which finds (via ServiceTracker) ITimezoneService proxies
and then calls the ITimezoneService.getTimezone/2 method on the added
proxy.
4. org.eclipse.ecf.geonames.timezone.consumer.edef = A very simple
EDEF bundle, containing the EDEF to discover the Geonames timezone
service, with RSA then creating the ITimezoneService proxy.
Over the next week, I'm going to write a short tutorial that shows
particularly the code in org.geonames.timezone (remote service API)
and org.eclipse.ecf.provider.geonames.timezone.client (REST Client
Remote Services ECF provider)
In testing this code unfortunately I discovered an oversight bug in
the RestClientService class from the changeover from httpclient 3.3
to 4.X. See [2] for details. To get this new example to work, this
fix has to be in place in the runtime, meaning that we will need to
produce 3.9.2 release for people to be able to successfully run the
timezone example themselves. We can discuss the timing of 3.9.2
creation and release relative to other things that committers and
contributors are currently working on.
If people have comments about any of this, would like to
help/contribute on this example, or would like to suggest specific
things to focus on for the wiki tutorial, please say so here, produce
a pull request, or contact me directly to coordinate on the tutorial.
Thanks,
Scott
[1] https://github.com/ECF/Geonames
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=453484
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/ecf-dev
------------------------------
Message: 3
Date: Tue, 9 Dec 2014 11:16:51 +0100
From: Wim Jongman <wim.jongman@xxxxxxxxx>
To: "Eclipse Communication Framework (ECF) developer mailing list."
<ecf-dev@xxxxxxxxxxx>
Subject: Re: [ecf-dev] tutorial idea: OSGi remote services for
existing services
Message-ID:
<CAOuK-P9YOMcXDAPdbBigeGZq+EkE+nQmBGJdigFn=MUD36fN_A@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
Looks good Scott. Very clean explanation in the beginning of the tut.
However, I am not clear one one thing. You say
"There are many situations, however, where it would be desirable to expose
an *existing* (e.g. web-based REST) service as a Remote Service"
When you say expose, do you mean creating an OSGi service that talks to the
REST server as some kind of proxy?
Cheers,
Wim
On Mon, Dec 8, 2014 at 10:05 PM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
Hi Folks,
To go along with the example client code for the Geonames Timezone service
[1], I've started a tutorial that details/documents how this example was
created [2].
The tutorial is not finished yet (e.g. running the example consumer), but
that's a good time for review and feedback :). Please review and provide
feedback if you can. My intention is to finish this tutorial prior to
release of ECF 3.9.2 on December 22nd.
Thanks,
Scott
[1] https://github.com/ECF/Geonames
[2] https://wiki.eclipse.org/Tutorial:_ECF_Remote_Services_
for_Accessing_Existing_REST_Services
On 12/5/2014 11:10 AM, Scott Lewis wrote:
Hi Folks,
I've been working on the example code for this tutorial, and the latest
is available on github [1].
As I said below, I found a small bug in the rest client code that had to
be addressed [2] and I've since fixed this bug, and added a couple of
'builder' classes to simplify the construction of the association between
the RSA-constructed remote service proxy and the REST request creation,
execution, and response handling.
The upshot is that I would like to propose that we have another
maintenance release before the end of 2014 to pick up these fixes and small
additions, so that when I finish the tutorial ECF Remote Services impl will
fully support it.
Any objections to maintenance release (3.9.2) this month? I was thinking
perhaps Dec 22nd to make an early Christmas gift. :)
Thanks,
Scott
On 11/27/2014 3:11 PM, Scott Lewis wrote:
I've created a new github repo for the Geonames Timezone example I've
been working on. The bundles so far are (in bundles directory):
1. org.geonames.timezone - declares the Geonames timezone API as an
OSGi service interface called ITimezoneService
2. org.eclipse.ecf.provider.geonames.timezone.client - An ECF Remote
Services provider using the ECF Rest API and JSON parser to make the REST
call and process the server's JSON response.
I've also begun the creation of two consumer bundles to test the above
provider
3. org.eclipse.ecf.geonames.timezone.consumer - A very simple consumer
which finds (via ServiceTracker) ITimezoneService proxies and then calls
the ITimezoneService.getTimezone/2 method on the added proxy.
4. org.eclipse.ecf.geonames.timezone.consumer.edef = A very simple EDEF
bundle, containing the EDEF to discover the Geonames timezone service, with
RSA then creating the ITimezoneService proxy.
Over the next week, I'm going to write a short tutorial that shows
particularly the code in org.geonames.timezone (remote service API) and
org.eclipse.ecf.provider.geonames.timezone.client (REST Client Remote
Services ECF provider)
In testing this code unfortunately I discovered an oversight bug in the
RestClientService class from the changeover from httpclient 3.3 to 4.X.
See [2] for details. To get this new example to work, this fix has to be
in place in the runtime, meaning that we will need to produce 3.9.2 release
for people to be able to successfully run the timezone example themselves.
We can discuss the timing of 3.9.2 creation and release relative to other
things that committers and contributors are currently working on.
If people have comments about any of this, would like to help/contribute
on this example, or would like to suggest specific things to focus on for
the wiki tutorial, please say so here, produce a pull request, or contact
me directly to coordinate on the tutorial.
Thanks,
Scott
[1] https://github.com/ECF/Geonames
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=453484
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/ecf-dev/attachments/20141209/ab0ffcdd/attachment.html>
------------------------------
Message: 4
Date: Tue, 09 Dec 2014 06:10:15 -0800
From: Scott Lewis <slewis@xxxxxxxxxxxxx>
To: ecf-dev@xxxxxxxxxxx
Subject: Re: [ecf-dev] tutorial idea: OSGi remote services for
existing services
Message-ID: <548702C7.5060503@xxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 12/9/2014 1:18 AM, Keimel, Christoph wrote:
Hi Scott
Thanks for working on a tutorial on this subject! It reads very well and understandable. There are some questions I asked myself while reading. Maybe this could also be interesting for others?
Quote:
"2. Serialize the parameters passed to the getTimezone method (i.e. 'lat' and 'lng') and add them as URL request parameters, resulting in the URL: http://api.geonames.org/timezoneJSON?lat=<lat param value>&lng=<lng param value>&username=<username default value>"
Questions:
1. How does ECF know which parameters of the function getTimezone correspond to the parameters of the REST service? Is the relation itself built in the order in which the parameters where defined?
Yes, it's the order.
2. Would it be possible to overload getTimezone and also have a version supplying the username?
Yes.
3. Would it be possible to overload getTimezone adding some other parameter unrelated to the REST request, which should be cached to be reused by the responseDeserializer?
Yes.
4. How does ECF know how to serialize the parameters of the function getTimezone for the request URL? Is this customizable?
Yes, it's customizable by calling
AbstractClientContainer.setParameterSerializer(IRemoteCallParameterSerializer
serializer). The default is set to an instance of
StringParameterSerializer, which is what is used in the example code to
serialize the Doubles in the proxy call to Strings in the request.
In general much of the behavior of creating a request URL, processing
and serializing parameters, making the http request, deserializing the
response, etc. can be customized via setting new default instances
and/or overriding methods on either the Container or the
RestRemoteService instance. I've tried to anticipate and allow as
much extension as I could. There are probably use cases that could be
handled more gracefully, but I suppose that's what new API is for. :)
Scott
------------------------------
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
End of ecf-dev Digest, Vol 113, Issue 3
***************************************