[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[ecf-dev] Fwd: Re: Need further clarification on Distributed Event Admin
|
Hi Scott,
I confirm ( probably for my bad english ) that there was a
misunderstood between us on what i'm doing.
I'm definitely trying to use *two different virtual machine*, when i
speak about an "equinox node" i mean
each node has it's own process ant it's own virtual machine.
So in my case each equinox is starting the bundle that create and
configure the DistributedEventAdmin.
I'll open a bugzilla bug on ECF because my problems could simply be
solved by avoid to set the jms client ID
on jms connection.
The class i've modified is the
"org.eclipse.ecf.provider.jms.channel.AbstractJMSChannel" in the
"setupJMS method"
i've simply comment this line
//connection.setClientID(getLocalID().getName());
That solve the problem, btw i more elegant way could be to have a
configuration parameter/properties and let both
the case possible.
Andrea
Il 05/02/2010 16:15, Scott Lewis ha scritto:
Hi Andrea,
Andrea Zoppello wrote:
Hi Scott,
Thanks for the support and patience, btw i confirm that the code i've
post it's not working:
Here the code of the start method of my bundle:
<stuff deleted>
This code is supposed to create the container node if it's not
present, otherwise to create a client node and then to connect to it.
The createConfigureAndConnectContainer is the one from the
AbstractEventAdmin application in the DistributedEventAdmin examples.
I suppose the fisrt time ( in the first jvm ) in the first node the
container is created and io the second node the client is created
but the method that verify if there's a container node seems not
working.
It's because the container creation is done by the
createConfigureAndConnectContainer method...and this is only executed
*after* the call to isThereEventAdminManager...so your code in
isThereEventAdminManager always returns false.
I guess I don't understand what you are trying to do...because the
start method of any bundle is only going to be executed *once* (when
the bundle is started), meaning that if this is the only code that
creates container instances (via createConfigureAndConnectContainer)
that it will only ever create one container instance.
Perhaps I misunderstood what you are trying to do. I had thought that
you wanted to run more than one container instance (i.e. a client
and/or a manager...or more than one client) in a single *process*. If
you want to run things in separate processes...i.e. separate
vms...then the way to make sure that you have one manager and
everything else is a client is to control the launching of the various
processes (i.e. only start one manager, and start n clients).
Regards the shared object api, yeah i'll invest some time to look at
it, but i think in previous posts i've not explained very well my use
case, i don't want the *distributed event admin itself* to take care
of group changes.
Ok. You can/could also setup listeners on the container instance
itself...i.e. IContainer.addListener(IContainerListener), and this
listener will receive events of type IContainerConnectedEvent (join)
and IContainerDisconnectedEvent (leave). Also you can get the
ISharedObjectContainerAdapter from the IContainer...e.g.
ISharedObjectContainerAdapter adapter =
(ISharedObjectContainerAdapter)
container.getAdapter(ISharedObjectContainerAdapter.class)...and with
that get access to the current group membership information...e.g.
ID[] currentGroupMembers = adapter.getGroupMemberIDs();
In my architecture one equinox node ( probably the best object to
identify is the Spagicregistry ) are supposed to be notified about
coming, and leaving of other
equinox nodes and will use then use the distributed event admin to
synchronize their services list.
Ok, then access via the IContainerListener may be better/more
appropriate.
Scott
