Community
Participate
Working Groups
Hi, Here my work on Spring support where you can found examples host and consumer examples of org.eclipse.ecf.examples.remoteservices.hello.* with Spring DM. Spring DM provides the capaibility to declare your OSGi services (publish/get). It's possible too declare your IContainer into Spring configuration by using the bundle "org.eclipse.ecf.springframework" which give you a Spring factory bean to declare IContainer into XML Spring configuration. I have attached the org.eclipse.ecf.springframework_100208.zip which contains 4 bundles : * org.eclipse.ecf.examples.remoteservices.hello.dm.config.log4j : log4j * org.eclipse.ecf.examples.remoteservices.hello.dm.consumer : hello consumer declared with Spring DM. * org.eclipse.ecf.examples.remoteservices.hello.dm.host : hello host declared with Spring DM. * org.eclipse.ecf.springframework : Spring support to declare IContainer with XML Spring configuration. * target-platform : simple eclipse project which contains Spring DM bundles Jars. this projet contains too my Target Platform exported ("Spring Target Platform.target"). When you will import the hello DM examples, bundles will not compile. Click on the "Spring Target Platform.target" and click on "Set Target Platform" link to use Target platform with Spring bundles. The hello host/consumer works ONLY with last version of ECF (I have used CVS source of ECF) and follow "OSGi 4.2 remote services spec". If you want test hello host/consumer with ECF SDK (which is 3.0.0), you have host/consumer bundles into ecf_3.0.0 folder. If you like my work, I would like update the ECF wiki to explain how use Spring DM (and my Spring support) with ECF. Could you tell me where I could post that into the wiki? Which title can I use it? "Spring support for ECF" is that ok? Hope that my work will please you. Regards Angelo
Created attachment 158438 [details] Zip for Spring support for ECF + Hello examples with Spring DM (without Spring JAR)
Created attachment 158439 [details] Spring DM Jar (1). Copy Jar of this Zip into target-platform of the ZIP org.eclipse.ecf.springframework_100208.zip
Created attachment 158440 [details] Spring DM Jar (2). Copy Jar of this Zip into target-platform of the ZIP org.eclipse.ecf.springframework_100208.zip
" Zip for Spring support for ECF + Hello examples with Spring DM (without Spring JAR)" doesn't contains Spring DM Jar because it was to big. So I have splitted Spring DM bundles into 2 ZIP ( Spring DM Jar (1). and Spring DM Jar (2)). Unzip it and copy Jar bundles into target-platform project before clicking on "Set As Target Platform".
Adding myself to this bug. Also changed to enhancement. Thanks Angelo for the work and contribution. It may take some time (because I'm quite occupied with ECF 3.2 release plus other things), but this contribution will certainly see the light of day. I beg for some patience, however, as there are lots of other things pressing right now.
I'm working on adding attachment 158438 [details] to the ECF incubation area. Assigning to myself.
Created attachment 158984 [details] Schema used into ECF Wiki for Spring support I have start to update the ECF wiki at http://wiki.eclipse.org/Using_Spring_with_ECF_Remote_Services where I explain how use ECF with Spring DM. I have attached to this bug the OppenOffice document which contains the 2 schema I have done for the wiki. Regards Angelo
Created attachment 159060 [details] Schema used into ECF Wiki for Spring support with Dependencies Screenshot
Assigning to Angelo Zerr, ECF contributor.
(In reply to comment #9) > Assigning to Angelo Zerr, ECF contributor. Just for everyone information... Angelo's contribution of a new Spring/ECF integration bundle (org.eclipse.ecf.springframework) has been committed to the ECF incubation area on the EF CVS here: host: dev.eclipse.org root: /cvsroot/rt path: org.eclipse.ecf/incubation/bundles/org.eclipse.ecf.springframework Additional work (i.e. changes, enhancements, etc) will be committed to this location. Since this bundle is dependent upon Spring, at some point in the future it may make sense to have it be moved/renamed...although it's possible that it could stay where it is. Too early to tell, I think, whether it makes sense as part of ECF, or as part of Virgo...for example.
Hi, I'm very interested in using this org.eclipse.ecf.springframework bundle. Can you give me some updates on the integration of this bundle? I have noticed that it haven't been integrated neither in the latest ECF distribution, nor in the Virgo release. Is this project still opened, and is there any short term plan? Thaks in advance for your answers. Regards, Lorie.
(In reply to comment #11) > Hi, > I'm very interested in using this org.eclipse.ecf.springframework bundle. > Can you give me some updates on the integration of this bundle? I have noticed > that it haven't been integrated neither in the latest ECF distribution, nor in > the Virgo release. Is this project still opened, and is there any short term > plan? > > Thaks in advance for your answers. > Regards, > Lorie. This integration was contributed by Angelo Zerr (the original bug reporter). It currently exists in the incubation part of ECF's git repo...i.e. here: http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/incubation/bundles This bundle depends upon Spring, and I do not know if Angelo has been tracking/making changes to it as modifications (e.g. package name changes) have been made to Virgo. It's possible, but Angelo will have to comment directly. I've not made any recent updates to this code. Angelo, could you comment about Lorie's questions? Since it depends upon Spring, we can't really move it out of incubation and include it in our releases until a) Virgo is out of incubation (which I think it is now), and b) it has some review and testing. Although I'm not certain of this, it might be the case that simplifications to ECF remote services *since* this contribution might make even some of this small codebase unnecessary (since it's no longer necessary to explicitly create an ECF container prior to remote service host registration).
Hi Scott, I have suggested to Lorie to build org.eclipse.ecf.springframework with PDE. I had not change the source of this project since my last patch. I had just modify helloword samples to use Spring 3 which give some cool feature like Spring EL (to get system properties to select container type value like Java Helloword Sample). But I have not fix problem with ECF connection when you declare the Host URL in the consumer. Regards Angelo (In reply to comment #12) > (In reply to comment #11) > > Hi, > > I'm very interested in using this org.eclipse.ecf.springframework bundle. > > Can you give me some updates on the integration of this bundle? I have noticed > > that it haven't been integrated neither in the latest ECF distribution, nor in > > the Virgo release. Is this project still opened, and is there any short term > > plan? > > > > Thaks in advance for your answers. > > Regards, > > Lorie. > > This integration was contributed by Angelo Zerr (the original bug reporter). > It currently exists in the incubation part of ECF's git repo...i.e. here: > > http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/incubation/bundles > > This bundle depends upon Spring, and I do not know if Angelo has been > tracking/making changes to it as modifications (e.g. package name changes) have > been made to Virgo. It's possible, but Angelo will have to comment directly. > I've not made any recent updates to this code. Angelo, could you comment about > Lorie's questions? > > Since it depends upon Spring, we can't really move it out of incubation and > include it in our releases until a) Virgo is out of incubation (which I think > it is now), and b) it has some review and testing. > > Although I'm not certain of this, it might be the case that simplifications to > ECF remote services *since* this contribution might make even some of this > small codebase unnecessary (since it's no longer necessary to explicitly create > an ECF container prior to remote service host registration).
(In reply to comment #13) > Hi Scott, > > I have suggested to Lorie to build org.eclipse.ecf.springframework with PDE. I > had not change the source of this project since my last patch. I had just > modify helloword samples to use Spring 3 which give some cool feature like > Spring EL (to get system properties to select container type value like Java > Helloword Sample). > > But I have not fix problem with ECF connection when you declare the Host URL in > the consumer. I don't understand what you mean here. Is this some problem with the ECF spring integration, or something more general? BTW...now that Virgo is out of incubation, we could move toward including this work in ECF 3.5...but there would need to be some additional work (that I can't commit to right now) to review, test, do associated releng, etc. If people would like this to happen then please let me know...I would like to see it happen, fwiw. Thanks. > > Regards Angelo > > (In reply to comment #12) > > (In reply to comment #11) > > > Hi, > > > I'm very interested in using this org.eclipse.ecf.springframework bundle. > > > Can you give me some updates on the integration of this bundle? I have noticed > > > that it haven't been integrated neither in the latest ECF distribution, nor in > > > the Virgo release. Is this project still opened, and is there any short term > > > plan? > > > > > > Thaks in advance for your answers. > > > Regards, > > > Lorie. > > > > This integration was contributed by Angelo Zerr (the original bug reporter). > > It currently exists in the incubation part of ECF's git repo...i.e. here: > > > > http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/incubation/bundles > > > > This bundle depends upon Spring, and I do not know if Angelo has been > > tracking/making changes to it as modifications (e.g. package name changes) have > > been made to Virgo. It's possible, but Angelo will have to comment directly. > > I've not made any recent updates to this code. Angelo, could you comment about > > Lorie's questions? > > > > Since it depends upon Spring, we can't really move it out of incubation and > > include it in our releases until a) Virgo is out of incubation (which I think > > it is now), and b) it has some review and testing. > > > > Although I'm not certain of this, it might be the case that simplifications to > > ECF remote services *since* this contribution might make even some of this > > small codebase unnecessary (since it's no longer necessary to explicitly create > > an ECF container prior to remote service host registration).
(In reply to comment #14) > (In reply to comment #13) > > Hi Scott, > > > > I have suggested to Lorie to build org.eclipse.ecf.springframework with PDE. I > > had not change the source of this project since my last patch. I had just > > modify helloword samples to use Spring 3 which give some cool feature like > > Spring EL (to get system properties to select container type value like Java > > Helloword Sample). > > > > But I have not fix problem with ECF connection when you declare the Host URL in > > the consumer. > > I don't understand what you mean here. Is this some problem with the ECF > spring integration, or something more general? Excuse me for my bad explanation (it's long time that I have not played wirh ECF). Do you remember the problem when Consumer wich declare the Host URL (declared with Spring) try to connect to Host wich is not started? The Spring Bean Consumer try to create an ECF container but it crash it because Host os not started. I have not found solution to manage this case. > > BTW...now that Virgo is out of incubation, we could move toward including this > work in ECF 3.5...but there would need to be some additional work (that I can't > commit to right now) to review, test, do associated releng, etc. If people > would like this to happen then please let me know...I would like to see it > happen, fwiw. It should be fantastic if my (little) contribution could be integrated to Virgo. Tell me if you need help for that. Regards Angelo > > Thanks. > > > > > > > > Regards Angelo > > > > (In reply to comment #12) > > > (In reply to comment #11) > > > > Hi, > > > > I'm very interested in using this org.eclipse.ecf.springframework bundle. > > > > Can you give me some updates on the integration of this bundle? I have noticed > > > > that it haven't been integrated neither in the latest ECF distribution, nor in > > > > the Virgo release. Is this project still opened, and is there any short term > > > > plan? > > > > > > > > Thaks in advance for your answers. > > > > Regards, > > > > Lorie. > > > > > > This integration was contributed by Angelo Zerr (the original bug reporter). > > > It currently exists in the incubation part of ECF's git repo...i.e. here: > > > > > > http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/incubation/bundles > > > > > > This bundle depends upon Spring, and I do not know if Angelo has been > > > tracking/making changes to it as modifications (e.g. package name changes) have > > > been made to Virgo. It's possible, but Angelo will have to comment directly. > > > I've not made any recent updates to this code. Angelo, could you comment about > > > Lorie's questions? > > > > > > Since it depends upon Spring, we can't really move it out of incubation and > > > include it in our releases until a) Virgo is out of incubation (which I think > > > it is now), and b) it has some review and testing. > > > > > > Although I'm not certain of this, it might be the case that simplifications to > > > ECF remote services *since* this contribution might make even some of this > > > small codebase unnecessary (since it's no longer necessary to explicitly create > > > an ECF container prior to remote service host registration).
Hi Angelo, (In reply to comment #15) <stuff deleted> > > I don't understand what you mean here. Is this some problem with the ECF > > spring integration, or something more general? > > Excuse me for my bad explanation (it's long time that I have not played wirh > ECF). Do you remember the problem when Consumer wich declare the Host URL > (declared with Spring) try to connect to Host wich is not started? Ah. I think the general solution to this would be to use the remote services discovery...so that you can avoid the timing issues you are having (it seems to me that starting the consumer and try to connect to the host...when the host has not yet started and the host service registered...can't possibly work...as it's essentially having a consumer try to access a service that doesn't exist yet). If discovery is used, the consumer doesn't try to connect until the remote service is explicitly discovered...which only happens *after* the host service is created and registered.
(In reply to comment #16) > Hi Angelo, > > (In reply to comment #15) > <stuff deleted> > > > I don't understand what you mean here. Is this some problem with the ECF > > > spring integration, or something more general? > > > > Excuse me for my bad explanation (it's long time that I have not played wirh > > ECF). Do you remember the problem when Consumer wich declare the Host URL > > (declared with Spring) try to connect to Host wich is not started? > > Ah. I think the general solution to this would be to use the remote services > discovery...so that you can avoid the timing issues you are having (it seems to > me that starting the consumer and try to connect to the host...when the host > has not yet started and the host service registered...can't possibly work...as > it's essentially having a consumer try to access a service that doesn't exist > yet). > > If discovery is used, the consumer doesn't try to connect until the remote > service is explicitly discovered...which only happens *after* the host service > is created and registered. Perhaps Spring support for ECF works well if we declare remote services discovery as a bean Spring? Or do you think I must do something to manage that? To simplify the problem I do that when URL is filled : ID targetID = idFactory.createStringID("ecftcp://localhost:3787/server"); IContainer conatiner = containerFactory.createContainer("ecf.generic.client"); container.connect(targetID , null); which fail when Host is not started : -------------------- org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.eclipse.ecf.springframework.ConsumerContainerFactoryBean#0' defined in URL [bundleentry://65.fwk16993205/META-INF/spring/module-context.xml]: Invocation of init method failed; nested exception is org.eclipse.ecf.core.ContainerConnectException: Exception during connection to ecftcp://localhost:3787/server .... -------------------- Which code I must do to use remote services discovery? Perhaps just declare remote services discovery as a Spring bean?
Dear Scott and Angelo, I have started the hello example bundles in a Virgo web server. It works fine. But the problem of the consumer crashing when the host is not started still remains. I would like to try modifying the org.eclipse.ecf.springframework project to use the the service discovery. I start having a look at org.eclipse.ecf.osgi.services and org.eclipse.ecf.discovery, but this is not clear for me how we can use it in the springframework bundle. Scott, do you have any idea how to start with this? Regards, Lorie
(In reply to comment #18) > Dear Scott and Angelo, > I have started the hello example bundles in a Virgo web server. It works fine. > But the problem of the consumer crashing when the host is not started still > remains. > I would like to try modifying the org.eclipse.ecf.springframework project to > use the the service discovery. I start having a look at > org.eclipse.ecf.osgi.services and org.eclipse.ecf.discovery, but this is not > clear for me how we can use it in the springframework bundle. Scott, do you > have any idea how to start with this? Sure. The ECF impl of OSGi 4.2 uses the ECF discovery API (org.eclipse.ecf.discovery) 'under the covers'. So if a discovery provider (i.e. impl of ECF discovery API) is present and functioning, then the OSGi 4.2 impl will use it. If you are using ECF's OSGi remote services impl, then the only thing you have to do is include/use a network discovery provider. The ones that we currently have are (zeroconf/jmdns, dnssd (new in 3.4), zookeeper, service locator protocol (slp), as well as static xml-file-based discovery). In the hello example source code are some product configurations that include discovery provider bundles...for example, for the consumer this is the product configurations that uses zeroconf (org.eclipse.ecf.provider.jmdns): /org.eclipse.ecf.examples.remoteservices.hello.consumer/products/Hello Service Consumer (zeroconf,generic).product If you look in these product configurations they list the bundles included...and you will see that they include the given discovery provider (i.e. o.e.e.provider.jmdns for the above). Once included, when the remote service is registered on the host the given discovery provider (in the above case zeroconf) is automatically used by ECF OSGi remote services to publish the remote service. Now one thing to keep in mind...these discovery systems do use the network to discovery remote services (zeroconf uses multicast IP), and so they are sensitive to network configuration (e.g. whether multicast is enabled on the lan where run, etc). Also, based upon what you have in mind for your remote service and Virgo server...you may not want the security implications of the various discovery providers (e.g. making a remote service available over lan or wan). There's *lots* more on discovery...Markus is the lead developer on discovery...although I've done a fair bit of work with it and was the original implementer of the discovery API (which has gone through quite a lot of positive maturation over the past few years). Wim Jongman is the committer that contributed the Zookeeper discovery provider implementation, and so also knows quite a lot about discovery. Also, several of us have presentations/slides/etc/wiki pages about discovery...and can point you to those resources. Also...you can use the static-xml-file-based discovery...which is just an xml file on the consumer that can be parsed, and used to discover remote services either programmatically...when a bundle is started, or upon user command. Further...it's quite possible (others have apparently done this), to implement your own discovery provider...if, for example, you already have a service to let consumers discover a remote service (e.g. a web server where remote services are registered). You also might want to ask on the ecf-dev mailing list about discovery...Markus will certainly respond. There are probably lots of resources that I'm not remembering right now.
Hi! I have been working on the hello remote example. @Angelo : I found a way to have the consumer starting when the host has not been created. You just need to use another container type for your host and consumer. I tried with r_osgi, and it seems to work. To do this, I simply changed the spring config file, to replace ecf.generic container type by r_osgi, and also remove the container id. In the consumer, the file is : <osgi:reference id="containerManager" interface="org.eclipse.ecf.core.IContainerManager" timeout="1000" /> <bean class="org.eclipse.ecf.springframework.ConsumerContainerFactoryBean"> <property name="containerManager" ref="containerManager" /> <property name="containerType" value="ecf.r_osgi.peer" /> </bean> <osgi:reference id="helloService" interface="org.eclipse.ecf.examples.remoteservices.hello.IHello"/> <bean id="helloClient" class="org.eclipse.ecf.examples.internal.remoteservices.hello.dm.consumer.HelloClientThread" init-method="start" destroy-method="interrupt"> <property name="hello" ref="helloService" /> </bean> And in the host : <osgi:reference id="containerManager" interface="org.eclipse.ecf.core.IContainerManager" timeout="1000" /> <bean class="org.eclipse.ecf.springframework.HostContainerFactoryBean"> <property name="containerManager" ref="containerManager" /> <property name="containerType" value="ecf.r_osgi.peer" /> </bean> <bean id="helloService" class="org.eclipse.ecf.examples.remoteservices.hello.impl.Hello" /> <osgi:service ref="helloService" interface="org.eclipse.ecf.examples.remoteservices.hello.IHello"> <osgi:service-properties> <entry key="service.exported.interfaces" value="*" /> <entry key="service.exported.configs" value="ecf.r_osgi.peer" /> </osgi:service-properties> </osgi:service> This example with the new spring bean config runs fine when the bundles are started on the same OSGi container, but for now, I don't manage to have remote discovery running. @Scott: is there special configuration that need to be setup when usgin r_osgi to indicate the IP address of the accessible remote hosts? In the meantime, I will try with another discovery protocol.
(In reply to comment #20) > Hi! > I have been working on the hello remote example. > @Angelo : I found a way to have the consumer starting when the host has not > been created. You just need to use another container type for your host and > consumer. I tried with r_osgi, and it seems to work. I don't really see how using the r_osgi provider would actually deal with this problem. As I understand it from previous postings, what appears to be happening is that the consumer container is created...and tries to immediately connect to the server/host...before that host has been created (and the remote service actually registered). This seems to me to be some timing issue...as spring's injection doesn't allow the specification of any ordering (?). That is, if the remote services host/server is started and the remote service registered *prior* to the consumer being started and attempting to connect, then all would be well. Given this is right (and it's possible I'm wrong about this interpretation), I don't really understand why the r-osgi provider would be any different...as no matter what provider is used, the host/server has to exist, be started, and have a remote service host be registered prior to the consumer connecting and trying to access that remote service. With r-osgi...is it possible that you are actually running these inside of Eclipse...and so are using the r-osgi host that's running inside of Eclipse? <stuff deleted> > @Scott: is there special configuration that need to be setup when usgin r_osgi > to indicate the IP address of the accessible remote hosts? I'm sorry you will have to ask the r-osgi experts...Jan Rellermeyer and Markus Kuppe. I don't immediately know the answer to this question.
To answer your question, Scott, the hello service is imported as "optional". In this case, using the ecf generic container, event with an optional service, the bundle start fails because the host (which IP address is known) hasn't started yet. But as the service being optional, this should not fail... And this is the case when using r_osgi... Hope this is a little clearer.. Thanks for your support. I will try to find the appropriate forum to ask my question about r_osgi configuration within ECF.
(In reply to comment #22) > To answer your question, Scott, the hello service is imported as "optional". In > this case, using the ecf generic container, event with an optional service, the > bundle start fails because the host (which IP address is known) hasn't started > yet. But as the service being optional, this should not fail... And this is the > case when using r_osgi... I suppose what may be happening is that the r-osgi provider bundle gets started when/before the consumer container is created...and since r-osgi opens/listens on a given default port upon bundle start the server is available. In general, I would say it's probably going to be better to find a way to have Spring order the injection so that 1) the remote service is registered (on host/server) 2) the consumer attempts to connect to/accesses the service Declarative services (DS) allows such dependencies to be expressed...e.g. so that service ordering dependencies like this can be handled. I was under the impression that Spring also had a way to do this with it's declarative injection...but I don't know what it is. > Hope this is a little clearer.. Thanks for your support. I will try to find the > appropriate forum to ask my question about r_osgi configuration within ECF. Ok. I'm happy to help further, but don't know all the necessary r-osgi specifics.
Created attachment 185926 [details] Exposing and retreiving OSGi services with ECF with minimal code modification Dear Angelo and Scott I finally got my project running with ECF support for remote services. I would like to have your feedbacks on the solution I implemented. See in the attached documents. Regards, Lorie.
(In reply to comment #24) > Created attachment 185926 [details] > Exposing and retreiving OSGi services with ECF with minimal code modification > > Dear Angelo and Scott > I finally got my project running with ECF support for remote services. > I would like to have your feedbacks on the solution I implemented. See in the > attached documents. > > Regards, > Lorie. Hi Lorie, This is great stuff! Thanks so much for your efforts here! I have a couple of questions for you: 1) Would you be willing to contribute the documentation for what you did to to a new wiki page off of http://wiki.eclipse.org/ECF ? Then as we document more how to use Spring and ECF remote services together we can point to it as one example of how to do so. 2) Have you considered trying the ECF implementation of OSGi remote services specification...along with Spring as well? The OSGi remote services impl *uses* the ECF remote services API in a way very similar to the usage in this code...and it might simplify things considerably (e.g. you could just have the proxy injected into your bean I believe). Also, we are approaching completion of work on the OSGi 4.2 remote services admin (rsa) specification, which is an extension to the remote services spec. See bug 324215. If you would like to discuss the use of the OSGi remote services/rsa work please let me know and we could discuss further. In any event...thanks much for the work and contribution of example. I'm sure that there are several folks that have an interest in combining ECF remote services and Spring/Virgo...and this along with other things should make it much easier. Again, thanks.
Hello Scott! Sorry for the late answer. Of course, I agree to contribute the document to ECF. Unfortunately, I have no time to go further into this right now. For sure, the sample I provided could be improved, at least by using Angelo's Spring support for ECF instead of hard-coding the containers etc... I hope I will have time to improve this soon. In the meantime, you can share the document I sent as a first-step sample. Let me know if I can be of any help. Regards, Lorie.
(In reply to comment #26) > Hello Scott! > Sorry for the late answer. Of course, I agree to contribute the document to > ECF. Unfortunately, I have no time to go further into this right now. For sure, > the sample I provided could be improved, at least by using Angelo's Spring > support for ECF instead of hard-coding the containers etc... I hope I will have > time to improve this soon. In the meantime, you can share the document I sent > as a first-step sample. Let me know if I can be of any help. > > Regards, > Lorie. Hi Lorie. Thanks for your answer. Do you have the document above in html form?...so that it could be easily added as a wiki page? I would like to persue the more general Spring/Virgo integration with OSGi remote services/remote services admin with you and others. Any further contributions would be appreciated...as there seem to be a number of people in the Spring/Virgo and ECF communties interested in this...as well, I'm nearing completion of the OSGi 4.2 remote service admin implmentation bug 324215
Created attachment 187007 [details] Exposing and retreiving OSGi services with ECF with minimal code modification [HTML]
I added a new attachement with an HTML version of the document. The formatting might not be ideal, but I guess you will have to modify it anyway to include it in the wiki... Hope this will suit.
Ping about the status of work on this enhancement. Is there any chance that the Spring + Hello remote services examples code and docs could make ECF 3.5 release? (scheduled for ~3/14/2011)? If not, I will reset the target milestone to 3.6 (June 2011). I am very interested in getting the fuctionality described by this bug into ECF as soon as is possible...particularly since with ECF 3.5 has introduced support for the OSGI Remote Services Admin specification...see bug 324215 Another consideration for the importance of this bug is that ECF remote services can run on Felix, and it would be great to show Felix+ECF Remote Services/impl of RSA + Spring-based application (that uses remote services/RSA).
Since we haven't heard anything from Angelo, I'm changing the target milestone on this enhancement to ECF 3.6. But I think that with the ECF Remote Service Admin (to be released as part of ECF 3.5), the integration of ECF Remote Service Admin and Spring should be nearly trivial. That is, I don't think it should even be necessary to use the approach exemplified by the attached code examples from Lorie Pisicchio (e.g. attachment 185926 [details] and attachment 187007 [details] )...as these use the ECF remote service API *directly*. I think that with ECF RSA, this direct/manual use of the ECF remote service API should be unnecessary (rather, one can use the OSGi remote service specification, along with the customization available from ECF's RSA implementation...to export and import an ECF remote service). In any event, I'm very anxious to see more work on the integration of Spring/Virgo and OSGi remote services with ECF's implementation, and so those on this bug please communicate directly with me (as well as each other) to help move this community effort forward.
(In reply to comment #31) > Since we haven't heard anything from Angelo, I'm changing the target milestone > on this enhancement to ECF 3.6. > > But I think that with the ECF Remote Service Admin (to be released as part of > ECF 3.5), the integration of ECF Remote Service Admin and Spring should be > nearly trivial. That is, I don't think it should even be necessary to use the > approach exemplified by the attached code examples from Lorie Pisicchio (e.g. > attachment 185926 [details] and attachment 187007 [details] )...as these use the ECF remote service > API *directly*. I think that with ECF RSA, this direct/manual use of the ECF > remote service API should be unnecessary (rather, one can use the OSGi remote > service specification, along with the customization available from ECF's RSA > implementation...to export and import an ECF remote service). > > In any event, I'm very anxious to see more work on the integration of > Spring/Virgo and OSGi remote services with ECF's implementation, and so those > on this bug please communicate directly with me (as well as each other) to help > move this community effort forward. Hi Scott, I'm really sorry, but time is my problem-( I whish that Spring support for ECF can be usefull but I have not time to study the new ECF features since I have developped this support. I don't know what I must code to resolve the problem with client started before server side. Anyway if you need help to understand my (very easy code), don't hesitate to contact me. Regards Angelo
(In reply to comment #32) <stuff deleted> > I'm really sorry, but time is my problem-( I whish that Spring support for ECF > can be usefull but I have not time to study the new ECF features since I have > developped this support. Hi Angelo. The new features is essentially a complete implementation of the OSGi 4.2 remote services admin specification. See bug 324215. Also see this wiki page http://wiki.eclipse.org/Remote_Services_Admin I'm working on this page today/as we speak so if you find it incomplete then just check back. > > I don't know what I must code to resolve the problem with client started before > server side. 1) I suspect that the best way to resolve this problem is to have the server and client containers be created lazily as they are needed...during the OSGi remote service export (server container created), followed by discovery, followed by import (client container created). This is the way things work in the remote services examples using both declarative services and java-based OSGI service registration. I don't really see why it couldn't be the same way for Spring-based services. 2) Alternatively, I expect that Spring should/does have some way to order the creation/use of Spring beans...as this case...and lots of others...there are ordering dependencies (i.e. a server has to be 'up' before a client can access it). I don't know what this is, however. >Anyway if you need help to understand my (very easy code), don't > hesitate to contact me. As I recall, it was/is using the ECF core API...for container creation...and the ECF remote services API (for exporting a remote service) directly...i.e. you were/are creating container instances and in the case of the server calling containerAdapter.registerRemoteService and in the case of the client calling container.connect (which fails if the server hasn't already started listening) and then getRemoteServiceReference. If this is right, then it should easily be possible to remove all of the ECF core and remote service code and just use the ECF Remote Services/RSA service properties to go through the remote service registration (service host), and the proxy lookup/creation (service consumer) all within the ECF RSA impl. If any of this doesn't make any sense, please let me know and I'll help further.
(In reply to comment #33) Hi Scott, Many thanks for your help. I have worked a little about Spring support and for your information I have improved hello DM Consumer sample to use Spring 3.0.0 and benefit with Spring EL. So now you can write : ------------------------------------------------ <entry key="service.exported.configs" value="#{systemProperties['containerType']}" /> ------------------------------------------------ instead of ------------------------------------------------ <entry key="service.exported.configs" value="ecf.generic.server" /> ------------------------------------------------ And manage several configuration container (several products) type by setting value in the JVM parameters (like Java Hello sample). I have too add declared listener LoggingHostDistributionListener, .. in the bean Spring to track and display ECF process like Java Hello sample. > 1) I suspect that the best way to resolve this problem is to have the server > and client containers be created lazily as they are needed... Jutst to clarify the thing, Spring support give you the capability to create ECF IContainer with Spring bean. For the Host side, Spring support IS NOT used (no need). For the Consumer side, you can NOT use Spring support and so IContainer is created with lazly mode (I think it's that you said below). With this configuration every thing works : start client BEFORE start server works well. The problem is when you wish customize the URL of your server in the client side. I have never find sample wich works with that. In java sample org.eclipse.ecf.examples.remoteservices.hello.consumer you have ----------------------------------------------------------- getContainerFactory().createContainer(containerType); ----------------------------------------------------------- Which is the same thing that lazly creation. My question is how set the server URL? I have added the HelloConsumerApplication code by calling IContainer#connect like this : ----------------------------------------------------------- IContainer container = getContainerFactory().createContainer(containerType); ID targetID = IDFactory.getDefault().createStringID("ecftcp://localhost:3787/server"); container.connect(targetID, null); ----------------------------------------------------------- And I have the problem when client is started before server. It's the same problem with Spring support. Perhaps it's forbidden to call the IContainer#connect with custom code (or manage a Thread which try several things)? I think we must take this sample to discuss (forget Spring for the moment) and give me the code I must write to to set URL server in client side (perhaps it's not a good ECF practice to set URL server in client side?). Thanks for your help. Regards Angelo > (In reply to comment #32) > <stuff deleted> > > I'm really sorry, but time is my problem-( I whish that Spring support for ECF > > can be usefull but I have not time to study the new ECF features since I have > > developped this support. > > Hi Angelo. The new features is essentially a complete implementation of the > OSGi 4.2 remote services admin specification. See bug 324215. Also see this > wiki page http://wiki.eclipse.org/Remote_Services_Admin > > I'm working on this page today/as we speak so if you find it incomplete then > just check back. > > > > > I don't know what I must code to resolve the problem with client started before > > server side. > > 1) I suspect that the best way to resolve this problem is to have the server > and client containers be created lazily as they are needed...during the OSGi > remote service export (server container created), followed by discovery, > followed by import (client container created). This is the way things work in > the remote services examples using both declarative services and java-based > OSGI service registration. I don't really see why it couldn't be the same way > for Spring-based services. > > 2) Alternatively, I expect that Spring should/does have some way to order the > creation/use of Spring beans...as this case...and lots of others...there are > ordering dependencies (i.e. a server has to be 'up' before a client can access > it). I don't know what this is, however. > > >Anyway if you need help to understand my (very easy code), don't > > hesitate to contact me. > > As I recall, it was/is using the ECF core API...for container creation...and > the ECF remote services API (for exporting a remote service) directly...i.e. > you were/are creating container instances and in the case of the server calling > containerAdapter.registerRemoteService and in the case of the client calling > container.connect (which fails if the server hasn't already started listening) > and then getRemoteServiceReference. If this is right, then it should easily be > possible to remove all of the ECF core and remote service code and just use the > ECF Remote Services/RSA service properties to go through the remote service > registration (service host), and the proxy lookup/creation (service consumer) > all within the ECF RSA impl. > > If any of this doesn't make any sense, please let me know and I'll help > further.
(In reply to comment #34) > (In reply to comment #33) > > Hi Scott, > > Many thanks for your help. > > I have worked a little about Spring support and for your information I have > improved hello DM Consumer sample to use Spring 3.0.0 and benefit with Spring > EL. So now you can write : > > ------------------------------------------------ > <entry key="service.exported.configs" > value="#{systemProperties['containerType']}" /> > ------------------------------------------------ > > instead of > > ------------------------------------------------ > <entry key="service.exported.configs" value="ecf.generic.server" /> > ------------------------------------------------ I guess you mean the 'host' side rather than 'consumer' side...right? > > And manage several configuration container (several products) type by setting > value in the JVM parameters (like Java Hello sample). > > I have too add declared listener LoggingHostDistributionListener, .. in the > bean Spring to track and display ECF process like Java Hello sample. One thing...the LoggingHostDistributionListener (and the whole listening api) is/has gone away in the ECF 3.5/remote service admin work. The reason for this is that the Remote Service Admin specification gives a standards notification/event mechanism...and so rather than have a non-standard one we just expose the RSA standard mechnanism. See http://wiki.eclipse.org/Remote_Services_Admin I'm still in the middle of adding to/working on this, so please be patient. > > > 1) I suspect that the best way to resolve this problem is to have the server > > and client containers be created lazily as they are needed... > > > Jutst to clarify the thing, Spring support give you the capability to create > ECF IContainer with Spring bean. For the Host side, Spring support IS NOT used > (no need). For the Consumer side, you can NOT use Spring support and so > IContainer is created with lazly mode (I think it's that you said below). > > With this configuration every thing works : start client BEFORE start server > works well. > > The problem is when you wish customize the URL of your server in the client > side. I have never find sample wich works with that. In java sample > org.eclipse.ecf.examples.remoteservices.hello.consumer you have > > ----------------------------------------------------------- > getContainerFactory().createContainer(containerType); > ----------------------------------------------------------- > > Which is the same thing that lazly creation. My question is how set the server > URL? I have added the HelloConsumerApplication code by calling > IContainer#connect like this : > > ----------------------------------------------------------- > IContainer container = getContainerFactory().createContainer(containerType); > ID targetID = > IDFactory.getDefault().createStringID("ecftcp://localhost:3787/server"); > container.connect(targetID, null); > ----------------------------------------------------------- > > And I have the problem when client is started before server. It's the same > problem with Spring support. Perhaps it's forbidden to call the > IContainer#connect with custom code (or manage a Thread which try several > things)? I think we must take this sample to discuss (forget Spring for the > moment) and give me the code I must write to to set URL server in client side > (perhaps it's not a good ECF practice to set URL server in client side?). With the recent ECF 3.5/RSA work, they way that the server URL is communicated to the client is via what's called an EndpointDescription. This is OSGi-specified meta-data about the host endpoint (including the server URL...also known as the EndpointDescription endpoint id). The OSGi specification defines a discovery mechanism for discovering EndpointDescriptions...this is what the OSGi RSA discovery mechanism does...discover endpoint descriptions. With ECF's implementation of the spec, this can/is done with any/all of the implementations of the ECF discovery API...e.g. zeroconf, slp, dnssd, zookeeper...any/all of these can be used to dynamically discover EndpointDescriptions over the network. I think that you could use one of the ECF network discovery protocols if you wish...and then the consumer would only discover EndpointDescriptions *after* they were published by the host...because that's the way that the network discovery protocols work (i.e. only when remote service hosts are registered do they publish EndpointDescriptions for discovery). In addition to the network discovery, the OSGi spec (see chap 122 here http://www.osgi.org/download/r4v42/r4.enterprise.pdf if you are interested in looking at the spec directly), defines (in section 122.8) an xml file format for discovering endpoint descriptions...called the Endpoint Description Extender Format (EDEF section 122.8). This is an xml-file format for discovering endpoint descriptions that are statically made available within a bundle (e.g. within your consumer)...i.e. *not* discovered over the network. Section 122.8 of the OSGI standard specifies the behavior here, and there is some documentation on ECF's implementation...along with a simple example...here: http://wiki.eclipse.org/File-based_Discovery_with_the_Endpoint_Description_Extender_Format Note that with the EDEF it's quite possible to still have timing problems between the consumer and the host...because unlike the network discovery case it's possible for the consumer to 'discover' the EDEF (this happens when the bundle that contains the EDEF xml file is started), and have this occur even if the host has not yet been started. This is because the EDEF-based discovery is based upon static information (the EDEF xml file), rather than a dynamic network discovery protocol. So in summary, I think there are two possibilities with the ECF 3.5/RSA work described above...wrt Spring integration 1) You use a network discovery protocol...like zookeeper, jmdns, etc to have the endpoint descriptions be dynamically discovered (making it unnecessary for you to explicitly call connect on the consumer side) 2) You use the EDEF file format on the consumer, and statically define the EndpointDescription for your host remote service. And then start the bundle that has the EDEF xml file in order to trigger the discovery (discovery based upon EDEF bundle start is specified in the OSGi spec as well). Does this make sense? I know the EDEF and other OSGi-specified parts are new, and so have to be understood...but I think overall it's better that ECF use/support all the relevant OSGi standards for network discovery, distribution, etc.
(In reply to comment #35) > (In reply to comment #34) > > (In reply to comment #33) > > > > Hi Scott, > > > > Many thanks for your help. > > > > I have worked a little about Spring support and for your information I have > > improved hello DM Consumer sample to use Spring 3.0.0 and benefit with Spring > > EL. So now you can write : > > > > ------------------------------------------------ > > <entry key="service.exported.configs" > > value="#{systemProperties['containerType']}" /> > > ------------------------------------------------ > > > > instead of > > > > ------------------------------------------------ > > <entry key="service.exported.configs" value="ecf.generic.server" /> > > ------------------------------------------------ > > > I guess you mean the 'host' side rather than 'consumer' side...right? Yes, sorry for my mistake. > > > > > And manage several configuration container (several products) type by setting > > value in the JVM parameters (like Java Hello sample). > > > > I have too add declared listener LoggingHostDistributionListener, .. in the > > bean Spring to track and display ECF process like Java Hello sample. > > One thing...the LoggingHostDistributionListener (and the whole listening api) > is/has gone away in the ECF 3.5/remote service admin work. The reason for this > is that the Remote Service Admin specification gives a standards > notification/event mechanism...and so rather than have a non-standard one we > just expose the RSA standard mechnanism. > > See http://wiki.eclipse.org/Remote_Services_Admin > > I'm still in the middle of adding to/working on this, so please be patient. > > > > > > 1) I suspect that the best way to resolve this problem is to have the server > > > and client containers be created lazily as they are needed... > > > > > > Jutst to clarify the thing, Spring support give you the capability to create > > ECF IContainer with Spring bean. For the Host side, Spring support IS NOT used > > (no need). For the Consumer side, you can NOT use Spring support and so > > IContainer is created with lazly mode (I think it's that you said below). > > > > With this configuration every thing works : start client BEFORE start server > > works well. > > > > The problem is when you wish customize the URL of your server in the client > > side. I have never find sample wich works with that. In java sample > > org.eclipse.ecf.examples.remoteservices.hello.consumer you have > > > > ----------------------------------------------------------- > > getContainerFactory().createContainer(containerType); > > ----------------------------------------------------------- > > > > Which is the same thing that lazly creation. My question is how set the server > > URL? I have added the HelloConsumerApplication code by calling > > IContainer#connect like this : > > > > ----------------------------------------------------------- > > IContainer container = getContainerFactory().createContainer(containerType); > > ID targetID = > > IDFactory.getDefault().createStringID("ecftcp://localhost:3787/server"); > > container.connect(targetID, null); > > ----------------------------------------------------------- > > > > And I have the problem when client is started before server. It's the same > > problem with Spring support. Perhaps it's forbidden to call the > > IContainer#connect with custom code (or manage a Thread which try several > > things)? I think we must take this sample to discuss (forget Spring for the > > moment) and give me the code I must write to to set URL server in client side > > (perhaps it's not a good ECF practice to set URL server in client side?). > > With the recent ECF 3.5/RSA work, they way that the server URL is communicated > to the client is via what's called an EndpointDescription. This is > OSGi-specified meta-data about the host endpoint (including the server > URL...also known as the EndpointDescription endpoint id). > > The OSGi specification defines a discovery mechanism for discovering > EndpointDescriptions...this is what the OSGi RSA discovery mechanism > does...discover endpoint descriptions. With ECF's implementation of the spec, > this can/is done with any/all of the implementations of the ECF discovery > API...e.g. zeroconf, slp, dnssd, zookeeper...any/all of these can be used to > dynamically discover EndpointDescriptions over the network. > > I think that you could use one of the ECF network discovery protocols if you > wish...and then the consumer would only discover EndpointDescriptions *after* > they were published by the host...because that's the way that the network > discovery protocols work (i.e. only when remote service hosts are registered do > they publish EndpointDescriptions for discovery). > > In addition to the network discovery, the OSGi spec (see chap 122 here > > http://www.osgi.org/download/r4v42/r4.enterprise.pdf > > if you are interested in looking at the spec directly), defines (in section > 122.8) an xml file format for discovering endpoint descriptions...called the > Endpoint Description Extender Format (EDEF section 122.8). This is an xml-file > format for discovering endpoint descriptions that are statically made available > within a bundle (e.g. within your consumer)...i.e. *not* discovered over the > network. Section 122.8 of the OSGI standard specifies the behavior here, and > there is some documentation on ECF's implementation...along with a simple > example...here: > > http://wiki.eclipse.org/File-based_Discovery_with_the_Endpoint_Description_Extender_Format > > Note that with the EDEF it's quite possible to still have timing problems > between the consumer and the host...because unlike the network discovery case > it's possible for the consumer to 'discover' the EDEF (this happens when the > bundle that contains the EDEF xml file is started), and have this occur even if > the host has not yet been started. This is because the EDEF-based discovery is > based upon static information (the EDEF xml file), rather than a dynamic > network discovery protocol. > > So in summary, I think there are two possibilities with the ECF 3.5/RSA work > described above...wrt Spring integration > > 1) You use a network discovery protocol...like zookeeper, jmdns, etc to have > the endpoint descriptions be dynamically discovered (making it unnecessary for > you to explicitly call connect on the consumer side) > > 2) You use the EDEF file format on the consumer, and statically define the > EndpointDescription for your host remote service. And then start the bundle > that has the EDEF xml file in order to trigger the discovery (discovery based > upon EDEF bundle start is specified in the OSGi spec as well). > > Does this make sense? I know the EDEF and other OSGi-specified parts are new, > and so have to be understood...but I think overall it's better that ECF > use/support all the relevant OSGi standards for network discovery, > distribution, etc. It seems that there is sense. But I'm very newbie with ECF and it seems that I must take a big time to test EDEF with Spring. Have you sample with Java code wich use EDEF? Perhaps I could use this sampel to adapt it with Spring.
(In reply to comment #36) > > It seems that there is sense. But I'm very newbie with ECF and it seems that I > must take a big time to test EDEF with Spring. Have you sample with Java code > wich use EDEF? Perhaps I could use this sampel to adapt it with Spring. There is an edef sample associated with the hello example here: http://wiki.eclipse.org/File-based_Discovery_with_the_Endpoint_Description_Extender_Format The way that it works is that (as specified by the OSGi spec), when the bundle that has the edef xml file (in the case of the example it's the org.eclipse.ecf.examples.remoteservices.hello.consumer.edef bundle) the Remote Service Admin implementation reads the xml file from the newly-started bundle, parses it, creates an EndpointDescription with the properties specified from the xml-file, and then treats it like it was just discovered over the network. So if you want to use this xml-file-based discovery, the thing to do is to create a bundle...with no java code at all if you wish...that has your xml file (of whatever name you wish), and has the manifest.mf entry...e.g. Remote-Service: generic_hello.xml (this is from the hello example edef bundle manifest...also here: http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/examples/bundles/org.eclipse.ecf.examples.remoteservices.hello.consumer.edef/META-INF/MANIFEST.MF Then, on your consumer you can trigger the discovery by simply starting the bundle that holds this xml. Now if the static discovery is not suitable for your use case, it's also possible to dynamically create/write this xml file from the host...and I've written an EndpointDescriptionWriter class to help do this. This would allow you, for example, to write the EndpointDescription that's created when your host exports your service. If you haven't already done so, to gain familiarity with this OSGi standard mechanism it might be useful for you to take a look at section 122.8 of the OSGi enterprise specification (see link in previous comment).
Resolving as fixed given existing work and change in ECF emphasis on OSGi Remote Services standard.
