[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[ecf-dev] Re: Need further clarification on Distributed Event Admin
|
Hi Andrea,
Andrea Zoppello wrote:
Hi Scott,
When i'll finish my work, and had something working, i'll have no
problem to make my conclusion public
on ECF wiki or where you prefer, i'll be very happy to make my little
contribution to the community.
BTW there are ( probably for my fault ) a few things i've not solved yet.
I've developed a simple bundle following the code in the distributed
event admin application that try to understand in in "a group" an "ECF
Manager" is already registered.
Following your suggestion the method i write looks like:
protected boolean isThereEventAdminManager(){
IContainer[] containers =
getContainerManager().getAllContainers();
for ( int i=0; i< containers.length; i++){
ISharedObjectContainer soContainer =
(ISharedObjectContainer)
containers[i].getAdapter(ISharedObjectContainer.class);
if ((soContainer != null) && soContainer.isGroupManager())
return true;
}
return false;
}
BTW as i run two equinox instances ( 2 virtual machines ) this method
always return false because the Containers array is always empty also
if the other nodes has
already registered the event admin manager.
So at the moment i've not solved the problem of the "ECF
Manager/Client" creations.
Well, the above code does depend upon having the container creation code
(wherever it is in your application) be run first...so that the
container instances are present in the array returned from
getAllContainers(). I'm not sure why the container instances are not
present when the above code is run.
Maybe it's wrong but ( at least in the case of jms ) the problem of
having multiple "managers" is because the clientID is set on the JMS
Connection, because
the the client ID is set on JMS Connection, i've commented the line
that set the client id add i could successfully have more than one
equinox node running on the
same machine without problem.
Do you see any problem in not setting up the clientID on jms connection??
I think I would have to see what code change you are talking about to
say. Would you please open a bug for this and attach a patch with the
code change in question? And then I could take a look at it.
Regards the group management it seems before starting to write some
code i need to get in depth and understand ECF Shared Object API. A
suggestion
for documentation is to take the JGroup tutorial and try to achieve
the same with ECF....
Well, I'm not sure if I would refer to the necessary understanding of
the shared object API for group management as 'in depth'...but
nonetheless it is where the group management functions for reliable
group membership are exposed programmatically.
I think the shortest route to understanding is for you to examine
BaseSharedObject. The DistributedEventAdmin class extends
BaseSharedObject, and shared objects are:
1) Notified about group membership changes (asynchronously) via any/all
the IEventProcessors registered.
2) Have access to ISharedObjectContext, which gives methods for getting
at the current *local* group membership information.
I will try to create some further documentation for the shared object
API over the next few weeks, but my own schedule is very full right now.
Also, if you would like some contract/direct support for this project
please contact me at slewis at composent.com
Thanks,
Scott