[
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
Scott
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;
}
@Override
5. public void run() {
6. while (true) {
7. try {
8. hello.hello("HelloClientthread");
9. System.out.println("IHello service called with HelloClientThread (Spring DM).");
Thread.sleep(1000);
} catch (Exception e) {
e.printStackTrace();
}
}
}
}
*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
Abhisek
*
* *
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.
Thanks,
Scott
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx <mailto:ecf-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/ecf-dev
------------------------------------------------------------------------
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev