[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] ECF3.2 using Spring

Hi Abhisek,

This seems to me to likely be some issue with how/when a given bundle is started. Given that you are using Spring DM to manage the runtime (along with the newly minted 'Spring-ECF remote services bridge' work), I think this may be very well some interaction with how Spring DM is/is not starting things...particularly on the consumer.

So, I have a couple of suggestions and observations about how to proceed.

1) Could you try the hello world examples without Spring DM? (i.e. just use the product configurations that are present in the consumer and/or host projects/ directory?). Since I'm not personally an expert in Spring DM, and wasn't the author of the code on the 'Using Spring with ECF...' page, I'm not at all certain what Spring is doing upon startup.

2) *Since ECF 3.2 release* we have changed the consumer/proxy container creation policy as per this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=303979. Given the 'Using Spring with ECF...' code was written *prior* to this change, the Spring-ECF bridge code may not be completely up to date. I have to get in direct contact with the author of that code to find out if the Spring-ECF bridge can be simplified. I believe it probably *can* be simplified, as it should no longer be even necessary for any container to be created in advance of the remote service registration (host) and/or the discovery (consumer). So I believe that the Spring-ECF work can/could be significantly simplified, but like I said I need to interact with the original author of that work before I can say for sure.

Does this make sense? I will try to reconnect with the Spring-ECF bridge author and see if we can update both the code and the documentation around that as quickly as possible (hopefully before Helios). Like I said, I suspect that the Spring-ECF integration will get significantly *easier and simpler* now that bug 303979 has been addressed, but we have some work to do on both the Spring-ECF bridge code, and the documentation...and since the Spring/ECF work is currently in incubation we haven't completed that work yet.

Actually, if you/Abhisek would like, I would encourage you to connect with and work directly with the Spring-ECF bridge author (Angelo Zerr...see this mailing list posting: http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg03316.html)...to update the Spring-ECF bridge, and to test/use various remote services scenarios with Spring. *Also*, some of the Spring DM work is in the process of being contributed to the new Gemini and Virgo projects at the Eclipse Foundation, and it would be *very good* to have the ECF remote services bridge updated and ready to go


abhisek saikia wrote:

Hi Scott
I just tested a simple hello word sample from http://wiki.eclipse.org/Using_Spring_with_ECF_Remote_Services
i tried from spring as well as plain java code.

i have 3 osgi bundles

1.hello-interface (contains interface org.eclipse.ecf.examples.remoteservices.hello.IHello)
2.hello-consumer(containing "client ecf generic container" creation code and hello service call from a thread )
3.hello-provider (containing "server ecf generic container" creation code and implementation of IHello)

i have 2 standalone osgi running ,where one osgi(i named it as client osgi) is running bundle 1 and 2 .Another osgi(i named it as server osgi) is running bundle 1 and 3

*Failure Scenario: *start client osgi.  then start server osgi.

After this for the following code which is running in consumer bundle is failing at line number 8.this could never be able to connect to server osgi to perform the remote call

1.public class HelloClientThread extends Thread {
2. private IHello hello;
3. public void setHello(
IHello hello) {
4. this.hello = hello;
5. public void run() {
6. while (true) {
7. try {
8. hello.hello("HelloClientthread");
9. System.out.println("IHello service called with HelloClientThread (Spring DM).");
} catch (Exception e) {

*Success scenario :*

start the server osgi.then start the client osgi

above remote call is successful.

then stop the hello-provider bundle from the server osgi console.using command "stop [bundle no]"

still the service call from consumer bundle is successful

---this scenario was failing for r-osgi

*Failure Scenario:* *

start the server osgi.then start the client osgi.remote hello call is successful.After that restart server osgi.hello call from consumer bundle stats failing .(its throwing Connection exception)

I currently dont have the setup with me for which i am not able to paste the logs.Sorry for my previous brief details

Thanks and Regards


* * *

On Mon, May 10, 2010 at 8:58 PM, Scott Lewis <slewis@xxxxxxxxxxxxx <mailto:slewis@xxxxxxxxxxxxx>> wrote:

    Hi Abhisek,

    abhisek saikia wrote:

        Hi Scott
          Today i tried with ECF generic server.But i found it not
        much flexible

        For the following scenarios its failing

        1.client start first and server start next.client remote calls
        to servers are failing

To diagnose this, you are going to have to describe what exactly you are doing and what is happening. For example...some questions: How are the calls failing? Are exceptions being thrown? If so, please attach them and/or open bug reports...as unless we can somehow reproduce these difficulties we have no way to identify what's wrong...because what you are seeing doesn't correspond to what we are seeing with the existing examples and tests.

    What you are describing could be due to a number of
    things...including your local network environment, your
    client/server environments, your specific OSGi framework
    environment (e.g. something with Spring), when/how you are making
    the remote calls, the version of ECF, or other things that are
    unique to your use case or situation.

    I would prefer to take one use case at a time...i.e. pick a
    specific use case, try it out...if it doesn't work then try to
    characterize the environment, the use case, and failure conditions
    (e.g. exceptions) with as much detail as possible...and we'll try
    to jointly come to a solution.



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


ecf-dev mailing list