Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] My first steap with ECF with Restlet

Hi Scott,

Many thank's for your answer. I will study that.

Regards Angelo

2012/6/10 Scott Lewis <slewis@xxxxxxxxxxxxx>
Hi Angelo,


On 6/10/2012 8:34 AM, Angelo zerr wrote:
Hi Scott,

<stuff deleted>

I have setted breakpoints in the method which add the service in the HelloConsumerApplication, but it is never called-(
So my problem comes from "a) Creates a local proxy for the remote service", and I'm searching where is the code which computes the base URL of the Rest server to consume it (on other words http://localhost:8080/hello ).

There are two things that immediately come to mind as possibly being wrong in your environment

1) Before running the consumer, did you start/run this (server) launch config?

/org.eclipse.ecf.examples.remoteservice.restlet.hello.host/Restlet RSA Server.launch

This launch config starts the Restlet server, and registers/exports the hello remote service.  As part of exporting the remote service, it *also* publishes the remote service's EndpointDescription via the zeroconf/jmdns lan-based discovery, which on my lan/system then discovers the remote service on the consumer (again via zeroconf/jmsdns lan-based discovery).

2) It's not impossible that zeroconf is not going to work on your lan...as on some lans it is intentionally disabled (usually to prevent usage of iTunes :).  If that's the case then you will possibly have to use some other discovery mechanism (e.g. file-based discovery, zookeeper, slp, dnssd, or one of your own choosing/creation.

<stuff deleted>


If you can read my articles it should be cool, because you will see what I want to do. But as I know you have not time, I will try to explain here what I want to do. I think my services to expose with remoting is a little complex but I have done that with success with cxf dosgi and I would like study if it's possible with ecf restlet. Here my UserService :

---------------------------------------------------------
public interface UserService {
   Page<User> findAll(Pageable pageable);
}
---------------------------------------------------------

This service is complex because :

1) It uses complex type in the method parameter (Pageable) and result method (Page)
2) Page and Pageable are interfaces and not Pojo.
3) Page and Pageable belongs to "Spring Data" framework, so you cannot modify it (to add some annotations or extend some classes).

As long as the actual implementation types (i.e. PageImpl or PageableImpl...or whatever you call them) are

1) Serializable
2) Available in an *exported package*

Then there's not difficulty with either OSGi remote services, or with ECF's implementation, of using complex types in the signature of the remote methods.



I must study restlet to see if it's possible. With JAX-RS+JAXB it's possible.

Since Restlet is an implementation of the JAX-RS spec, I expect that it is possible.  Because I'm not an expert on Restlet, however, I can't describe how to do it with Restlet.  I do know that Restlet has a pluggable architecture for...e.g....adding extensions to support different kinds of serialization/marshalling formats...e.g. json, xml, others, etc.



My goal is to have several configuration with my eclipser cp application:

1) Fat client: this confuguration means that rcp client consumes directly the implementation of the UserService retrieved from the OSGi registry services. As you can see here this implementation needs not to extend ServerResource (very shame to add in this config reslet bundles)

2) Client/Server: this config means that rcp client consumes the rest client which consumes the rest server (here the impl of Userviceisnot hosted with rcp but in other OSGi container (server side)

So for 1), I would like avoid extending ServerResource in my impl off UserService.

I still don't really understand why extending ServerResource is a problem (for either 1 or 2).  Actually, I don't really see...for either 1 or 2...why ServerResource is even an issue...aren't both 1 and 2 the client/consumer side?  It's only the host/server side that actually needs ServerResource (for Restlet).



With CXF DOSGi you must just annotate the Uservice interface and that's all.As it's annotations you can import jax-rs packages in the Services API bundles and set it as optionnal.
So for Fat client config, you need NOT add jax-rs bundle.

Like I said, I'm not a Restlet expert, but it seems to me likely that Restlet also probably supports the standardized (Jax-rs) annotation specification.



Here a list of features that remoting must support (supported by cxf dosgi with jax-rs) :

1) more transparent like use only annotations (avoid developping some other classes).
2) support complex object in the param of the sevice (not only String but pojo).
3) support interface(eg: Page, Pageable) in the param of service.
4) configure the baseURL of the server  on client side (eg: you deploy the host side in a server A and B, you can configure the base URL of server A to use it)

As I understand Restlet, it's a JAX-RS compliant implementation...which means to me that it it probably supports exactly the same annotations as any other JAX-RS implementation.   If that's true, I don't see any technical reason why these features couldn't be supported with ECF + Restlet.



I think it should be very cool if ecf support JAX-RS (with cxf, jersey, etc?).

That would be great.  And I can tell you that everything about ECF's structure (e.g. it's remote services API and provider architecture) makes this straightforward.  By way of comparison, consider...for example...using cxf with some other distribution provider...e.g. r-OSGi underneath.  As I understand it' this sort of substitution would not be possible.

But, of course, implementing a new remote service provider (based upon cxf, or jersey, or whatever)...although doable...and quite well supported (e.g. there's a lot of the existing implementations that can/could be reused for the creation of some other provider)...will take some additional technical work[1].  I would welcome such contributions...but cannot commit to doing it myself...without some visible means of support or sponsorship.


>Hope you will understand my need.

I believe I do.   Hope this helps.

Scott

[1] As an example of what's necessary to create a new remote service provider...see the code in org.eclipse.ecf.provider.restlet project.



_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev


Back to the top