Validating RemoteServices Setup

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Validating RemoteServices Setup

Ramachandran K. Narayanan
Hello ECF-Dev,

I had followed the tutorial at

to make modifications to carry over an existing local OSGi setup to a Remote OSGi setup. But it doesn't look like the remote services changes are having an effect and I was wondering how I could validate the changes:

1) Based on the steps in the HelloHostApplication example:

// add ECF service property specifying container factory args
props.put(IDistributionConstants.SERVICE_EXPORTED_CONTAINER_FACTORY_ARGUMENTS,
              containerId);

I set containerId to "r-osgi://localhost:9280". But when I start this up, I don't see any service listening on port 9280 (using netstat). Is this expected or should I have to use port 9278?

When I try this directly in the examples code, I get an error on the consumer side as it seems to expect port 9278.

2) Also, why should localhost be specified in the containerId? After all, won't the Host Application always run on its "localhost" and would specifying a different host make sense?

3) On the Consumer side, the tutorial says:

getContainerFactory().createContainer(containerType);
helloServiceTracker = new ServiceTracker(bundleContext,createRemoteFilter(), this);
helloServiceTracker.open();

Note that the remote service can be accessed in a variety of ways...e.g. by using a ServiceTracker (as above), by using the BundleContext.getServiceReference methods, or injection via declarative services.

So instead of ServiceTracker, could I just do getServiceReference after the createContainer call? I tried it with the HelloHostApplication and Consumer examples using the (zeroconf, r-osgi) and (zookeeper, r-osgi) configurations (for both Host and Consumer) but it doesn't seem to work.

4) Is the createContainer call also necessary? I commented it out in the examples and didn't see any errors. I guess the example launch configurations are already creating a container and we still need it for more general cases.

Thanks for your help.

Regards,
Ramachandran


--
Ramachandran K. Narayanan
Software Engineer
RNET Technologies Inc.
240 W.Elmwood Drive, Suite 2010
Dayton, OH 45459-4248

_______________________________________________
ecf-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
Reply | Threaded
Open this post in threaded view
|

Re: Validating RemoteServices Setup

Scott Lewis-2
On 9/20/2016 1:23 PM, Ramachandran K. Narayanan wrote:
Hello ECF-Dev,

I had followed the tutorial at

to make modifications to carry over an existing local OSGi setup to a Remote OSGi setup. But it doesn't look like the remote services changes are having an effect and I was wondering how I could validate the changes:

1) Based on the steps in the HelloHostApplication example:

// add ECF service property specifying container factory args
props.put(IDistributionConstants.SERVICE_EXPORTED_CONTAINER_FACTORY_ARGUMENTS,
              containerId);

I set containerId to "r-osgi://localhost:9280". But when I start this up, I don't see any service listening on port 9280 (using netstat). Is this expected or should I have to use port 9278?

r-osgi is unique as a provider in that you have to also set a system property named  ch.ethz.iks.r_osgi.port

See here for information:  http://wiki.eclipse.org/R-OSGi_Properties

The reason this is so is because rosgi predates the OSGi RSA spec and it defined it's own default port (9278) independently from  any notion of the container id.  So it has to be set with *both* the system property and the id set to the same desired port number (in your case 9280).

Rather than
props.put(IDistributionConstants.SERVICE_EXPORTED_CONTAINER_FACTORY_ARGUMENTS,
              containerId);

I would suggest using the standard OSGi service properties:

// This property specifies that you want to export all the service interfaces for your service

props.put("service.exported.interfaces","*");
// This property specifies that you wish to use the ecf.r_osgi.peer provider
props.put("service.exported.configs", "ecf.r_osgi.peer");
// This sends the value r-osgi://localhost:9280 for the key 'id' to the ECF r_osgi container
props.put("ecf.r_osgi.peer.id","r-osgi://localhost:9280");

Notice that ecf.r_osgi.peer.id is just the config with '.id' on the end.   This is the RSA-standard way of sending config information (in this case the id) into the provider.   Since this was introduced with ECF supporting RSA 1.0, ECF has a non-standard way of doing the same thing (container factory arguments), but it's better to use the RSA-standard approach if possible.



When I try this directly in the examples code, I get an error on the consumer side as it seems to expect port 9278.

Yes it will default to 9278 unless set by the ch.ethz.iks.r_osgi.port system property.


2) Also, why should localhost be specified in the containerId? After all, won't the Host Application always run on its "localhost" and would specifying a different host make sense?

3) On the Consumer side, the tutorial says:

getContainerFactory().createContainer(containerType);
helloServiceTracker = new ServiceTracker(bundleContext,createRemoteFilter(), this);
helloServiceTracker.open();

Note that the remote service can be accessed in a variety of ways...e.g. by using a ServiceTracker (as above), by using the BundleContext.getServiceReference methods, or injection via declarative services.

So instead of ServiceTracker, could I just do getServiceReference after the createContainer call?

Yes, although I would highly recommend using either a ServiceTracker or DS (preferably DS), as DS makes things much much simpler.

In the example code for the ServiceTracker, it also creates a filter via createRemoteFilter():

    private Filter createRemoteFilter() throws InvalidSyntaxException {
        return context.createFilter("(&("
                + org.osgi.framework.Constants.OBJECTCLASS + "="
                + IHello.class.getName() + ")(" + SERVICE_IMPORTED + "=*))");
    }

With DS, the filter is entirely unnecessary.  

My apologies...this tutorial should have been updated to emphasize using DS (and there are example projects in the repo that do this).

I tried it with the HelloHostApplication and Consumer examples using the (zeroconf, r-osgi) and (zookeeper, r-osgi) configurations (for both Host and Consumer) but it doesn't seem to work.

4) Is the createContainer call also necessary? I commented it out in the examples and didn't see any errors. I guess the example launch configurations are already creating a container and we still need it for more general cases.

You are right that it's not actually necessary any longer, but this is another old remnant of a pre-RSA....that I should remove.


Thanks for your help.

Sure.   If you can, please use DS both for local and remote services (both registration/export and import/injection).   It makes things oh so much easier.   There are examples and tutorials that do this...one here:  http://wiki.eclipse.org/Tutorial:_Building_your_first_OSGi_Remote_Service  and another example here:  https://github.com/ECF/enrouteEvalExampleRemoteService   that uses DS for both registration (host) and consumer.

I should have pointed this out to you previously.   My apologies about that, and that the old tutorials (IHello service) now unnecessary cruft that should be removed/cleaned up with RSA and DS both on the scene.

Scott



Regards,
Ramachandran


--
Ramachandran K. Narayanan
Software Engineer
RNET Technologies Inc.
240 W.Elmwood Drive, Suite 2010
Dayton, OH 45459-4248


_______________________________________________
ecf-dev mailing list
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
Reply | Threaded
Open this post in threaded view
|

Re: Validating RemoteServices Setup

Ramachandran K. Narayanan
Hello Scott,

Thank you for the detailed reply.

Actually, you had pointed out the DS services earlier, but I had been focused on the website tutorials. I will look at the DS tutorials more closely now, as you had outlined.

Thanks,
Ram

On Tue, Sep 20, 2016 at 11:28 PM Scott Lewis <[hidden email]> wrote:
On 9/20/2016 1:23 PM, Ramachandran K. Narayanan wrote:
Hello ECF-Dev,

I had followed the tutorial at

to make modifications to carry over an existing local OSGi setup to a Remote OSGi setup. But it doesn't look like the remote services changes are having an effect and I was wondering how I could validate the changes:

1) Based on the steps in the HelloHostApplication example:

// add ECF service property specifying container factory args
props.put(IDistributionConstants.SERVICE_EXPORTED_CONTAINER_FACTORY_ARGUMENTS,
              containerId);

I set containerId to "r-osgi://localhost:9280". But when I start this up, I don't see any service listening on port 9280 (using netstat). Is this expected or should I have to use port 9278?

r-osgi is unique as a provider in that you have to also set a system property named  ch.ethz.iks.r_osgi.port

See here for information:  http://wiki.eclipse.org/R-OSGi_Properties

The reason this is so is because rosgi predates the OSGi RSA spec and it defined it's own default port (9278) independently from  any notion of the container id.  So it has to be set with *both* the system property and the id set to the same desired port number (in your case 9280).

Rather than
props.put(IDistributionConstants.SERVICE_EXPORTED_CONTAINER_FACTORY_ARGUMENTS,
              containerId);

I would suggest using the standard OSGi service properties:

// This property specifies that you want to export all the service interfaces for your service

props.put("service.exported.interfaces","*");
// This property specifies that you wish to use the ecf.r_osgi.peer provider
props.put("service.exported.configs", "ecf.r_osgi.peer");
// This sends the value r-osgi://localhost:9280 for the key 'id' to the ECF r_osgi container
props.put("ecf.r_osgi.peer.id","r-osgi://localhost:9280");

Notice that ecf.r_osgi.peer.id is just the config with '.id' on the end.   This is the RSA-standard way of sending config information (in this case the id) into the provider.   Since this was introduced with ECF supporting RSA 1.0, ECF has a non-standard way of doing the same thing (container factory arguments), but it's better to use the RSA-standard approach if possible.



When I try this directly in the examples code, I get an error on the consumer side as it seems to expect port 9278.

Yes it will default to 9278 unless set by the ch.ethz.iks.r_osgi.port system property.



2) Also, why should localhost be specified in the containerId? After all, won't the Host Application always run on its "localhost" and would specifying a different host make sense?

3) On the Consumer side, the tutorial says:

getContainerFactory().createContainer(containerType);
helloServiceTracker = new ServiceTracker(bundleContext,createRemoteFilter(), this);
helloServiceTracker.open();

Note that the remote service can be accessed in a variety of ways...e.g. by using a ServiceTracker (as above), by using the BundleContext.getServiceReference methods, or injection via declarative services.

So instead of ServiceTracker, could I just do getServiceReference after the createContainer call?

Yes, although I would highly recommend using either a ServiceTracker or DS (preferably DS), as DS makes things much much simpler.

In the example code for the ServiceTracker, it also creates a filter via createRemoteFilter():

    private Filter createRemoteFilter() throws InvalidSyntaxException {
        return context.createFilter("(&("
                + org.osgi.framework.Constants.OBJECTCLASS + "="
                + IHello.class.getName() + ")(" + SERVICE_IMPORTED + "=*))");
    }

With DS, the filter is entirely unnecessary.  

My apologies...this tutorial should have been updated to emphasize using DS (and there are example projects in the repo that do this).


I tried it with the HelloHostApplication and Consumer examples using the (zeroconf, r-osgi) and (zookeeper, r-osgi) configurations (for both Host and Consumer) but it doesn't seem to work.

4) Is the createContainer call also necessary? I commented it out in the examples and didn't see any errors. I guess the example launch configurations are already creating a container and we still need it for more general cases.

You are right that it's not actually necessary any longer, but this is another old remnant of a pre-RSA....that I should remove.


Thanks for your help.

Sure.   If you can, please use DS both for local and remote services (both registration/export and import/injection).   It makes things oh so much easier.   There are examples and tutorials that do this...one here:  http://wiki.eclipse.org/Tutorial:_Building_your_first_OSGi_Remote_Service  and another example here:  https://github.com/ECF/enrouteEvalExampleRemoteService   that uses DS for both registration (host) and consumer.

I should have pointed this out to you previously.   My apologies about that, and that the old tutorials (IHello service) now unnecessary cruft that should be removed/cleaned up with RSA and DS both on the scene.

Scott



Regards,
Ramachandran


--
Ramachandran K. Narayanan
Software Engineer
RNET Technologies Inc.
240 W.Elmwood Drive, Suite 2010
Dayton, OH 45459-4248


_______________________________________________
ecf-dev mailing list
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
--
Ramachandran K. Narayanan
Software Engineer
RNET Technologies Inc.
240 W.Elmwood Drive, Suite 2010
Dayton, OH 45459-4248

_______________________________________________
ecf-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev