Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] [GSOC Project Idea]-Looking for a GSoc Project in ECF

Hi Salinda,

A couple of comments on your observations...that may be helpful for your proposal (please do get something into GSOC by 5/3 as Markus that your project can be considered).

See a couple of inline comments below.

On 4/30/2013 3:43 PM, Salinda Jayawardana wrote:
HI all

Sorry I couldn't give an update since I had my end semester exam till yesterday, Now I am going to work on this full time.

If I understand the requirements correctly, I should do following things

When User create a remote service using ECF SDK (without any framework or tools) approach as follows

    1) create a interface and include all the methods

    2)create a implementation for above interface

Yes...these are the first two steps.

    3) create a remote container

    4) register the service

Note one thing...although in ECF 3 can be done explicitly/programmatically, it is not strictly necessary to create a remote container.  That is, if 3 isn't done explicitly, when 4 is done (i.e. register the remote service with the OSGi service registry) in most use cases 3 can/will be done automatically by the ECF implementation of OSGi remote services.

I would tend to concentrate on the workflow that focuses on tooling support for creating OSGi remote services...e.g:

A) Create a service interface (which would possibly include annotations to specify the OSGi remote services meta-data...i.e. service properties)
B) Create implementation of service interface
C) Register the service with the OSGi service registry (this can be done in several ways...e.g. BundleContext.registerService, declarative services, others)...along with the service properties required by the OSGi remote service specification that will result in it being exported by one or more of the ECF config types (aka container types)).

With the current impl of he ECF remote service admin, doing C will result in what you describe as 3 above.  Further, with ECF's implementation of RSA this process of creating a remote container during/as part of export is customizable. main comment is that the tooling around remote services is conceptually simpler than the 4 steps you initially outlined...i.e. declare service interface, impl service, register service.  Does that makes sense?  If not let me know and we will discuss further.

If some one want to add some asynchronous method ,that above interface should extends using "IAsyncRemoteServiceProxy" class.

[Scott]  One approach that I was taking with the initial annotation work was that it was/is possible to create an Eclipse 'annotation processor' that when an annotation was added to a service interface (i.e. via Eclipse editor), another service interface could be automatically generated (and the generated service interface class would extend IAsyncRemoteServiceProxy).  I'm not sure this is the best way to go, but it is one idea I had around supporting asynchronous remote services.

According to my understanding, I am going to introduce annotations which can be used inside in the service interface to expose methods as remote service both blocking and non-blocking way ,


     public interface ICal {

     public int add(int num1, int num2);//just adding two digits

     public int sub(int num1, int num2);

     public float complexCal(int val); // do a complex calculation which take long time


 In the runtime , I will scan this interface and identify those annotations using java reflections, after that Register the services  by looking the annotations

For the @Remote annotation, I would agree with your assertion above...that remote services would be registered.  However, as I described way to go would be to process the @AsyncRemote annotation (or whatever it ends up being called) at *editing time*, and have it create a new async service interface...with methods that return IFuture or have IRemoteService.  This *could* be done at compile time (using Eclipse annotation processing tool...which supports extensible annotation processing in Eclipse).

Finally this services will be testing using the test framework for that also we can introduce a new annotation, to identify which methods should be tested using the framework

Is this the correct approach ? please advice me 

In general...yes.   Here's some of the thinking that remains to be done (and at least some of this can/could make a great gsoc project, IMHO):

1) What annotations should exist?
2) Should the annotations be processed/used at editing time (Eclipse apt), at runtime (reflection)?
3) How/whether these new annotations interoperate with the OSGi R5 standard annotations...e.g. @Component for declarative service components?
4) Are there annotations (and/or other tooling) for remote services could be considered for standardization (OSGi)?



Thanks and Regards


On Wed, Apr 24, 2013 at 12:23 AM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
Hi Salinda,

Your plan sounds good Salinda.   We will await your gsoc proposal.  

Assuming your gsoc proposal is accepted, and you go ahead with this project focusing on remote service annotations (e.g. for creation/definition of remote services, for creation of async remote services, and for testing remote services), I would like to be included in the project in some manner...e.g. I could be a mentor for this project...or a co-mentor.  Improving ease/usability of creating ECF remote services is obviously an area that I think is important for the project and I want to see moved forward.

WRT your communications...what you are doing is absolutely fine.   Given that we are a distributed, all-volunteer team, IMHO it's very important to communicate publicly (on this list, via bugzilla, on wiki) as *often as possible*.  If there is one piece of advice I would give to all gsoc projects/students (and in fact all ECF contributors) it would be:  communicate with the committers and community as much as possible...both about status (i.e. what you are up to/planning), as well as the state of the code, what the problems are, where/with what you are encountering difficulties, etc.   In other words:  when in doubt (or even not in doubt)...communicate with the community.  It's very unlikely that you will get complaints...from me at least...that you are communicating too much :).

Thanks...good luck with your gsoc proposal.  


On 4/23/2013 10:38 AM, Salinda Jayawardana wrote:
Hi Scott

Thanks for all the information, those are very useful to me , I have already started work on the annotation stuff related to bug #309732 So I am looking forwards to work on following stuff for the GSOC

1) Define and Implement annotations for 
    a) Creating remote services (e.g. @RemoteService)
    b) Creating Async remote services (e.g. @AsyncService) [A].  This is work that I had started with bug 309732
    c) Doing remote services testing (this was started/done for a previous GSOC project [B], and could be moved forward/extended/completed)

I will give an important update on above bug very soon.

This is first time i am communicating in a mailing list but i am really enjoying this I am looking forwards to work with ECF , If i am doing something wrong(when communicating) please advice me 


On Mon, Apr 22, 2013 at 11:01 PM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
Hi Salinda,

On 4/21/2013 6:02 AM, Salinda Jayawardana wrote:
Hi Markus 

I am really interested in OSGI remote service stuff in ECF also I have good understanding OSGI ,Java and eclipse plugin development. 

As you mention, I went through the ECF issues in Bugzilla and selected[1] since i have good idea about java annotation processing stuff, So will try my best to provide a patch for this enhancement
I would like to know any feedback or idea regarding this ?

I think this is a good idea.  Actually...IMHO there is a lot of room for work in a general category of what I would call:  'tooling for remote services'.   What do I mean by 'tooling for remote services''s some brainstorming about possible tooling for remote services:

1) Define and Implement annotations for
    a) Creating remote services (e.g. @RemoteService)
    b) Creating Async remote services (e.g. @AsyncService) [A].  This is work that I had started with bug 309732
    c) Doing remote services testing (this was started/done for a previous GSOC project [B], and could be moved forward/extended/completed)

2) Tooling (e.g. Eclipse Views) for Debugging Remote Services
    a) Example:  View(s) that shows remote services (host and consumer) from registry...along with ECF meta-data/properties
    b) Example:  Enhancing the discovery UI to specifically support/display OSGi remote service discovery debugging

3) PDE templates of OSGi remote services
    a) As part of 3.6.0 I added a PDE template for creating a remote service (host and consumer) via the PDE project wizard.  This template is in this project:
    b) There is a lot more that could be done here...i.e. more examples/templates...e.g. with specific discovery/distribution providers, etc.

I think any of these areas would be great for a GSOC project on ECF remote services.   I don't think you would want to work on more than one of these areas any one of them can/could be quite a lot of work.  

As project lead, my goal here is that whatever is started here as part of a GSOC project eventually be incorporated and distributed as part of I prefer that any work that is started be followed through on seriously...hopefully continuing after GSOC is over.   BTW, that is ECF's model for mentoring GSOC projects...after GSOC completes, that the work be continued forward...hopefully by the original student becoming an ECF committer and completing the work all the way to deployment (e.g. including full integration, testing, releng, etc).  We've had great success with that approach, and several existing ECF committers started by doing GSOC projects.

Hopefully these comments are useful Salinda...and hopefully you (and perhaps others) will decide to propose something of interest to you for a GSOC project.   I look forward to working with you.




On Sun, Apr 21, 2013 at 4:15 PM, Markus Alexander Kuppe <> wrote:
On 04/21/2013 09:05 AM, Salinda Jayawardana wrote:
> I would like to know is this a important and valuable idea ? or is
> there any thing else, more important idea in ECF?

Hi Salinda,

first of all, it's not such much a question what's important for ECF,
but what your interests are. If you are more into other aspects of ECF
(telephony, collaborative editing, newsreader, ...) you should pick
this area instead. There is plenty of work. ;)

> Could you please give some assistance to contribute  ECF in this
> year GSOC

Generally we favor students who have shown the ability to work in a
distributed open source project. E.g. fixing one of ECF's simpler bugs
marked with "helpwanted" in Bugzilla is a good way to demonstrate this.
Afterwards you want to work on your official application that will be
ranked by all GSoC mentors.

ecf-dev mailing list

ecf-dev mailing list

ecf-dev mailing list

ecf-dev mailing list

ecf-dev mailing list

ecf-dev mailing list

Back to the top