Skip to main content
[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 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:


    private static final String ECF_MANAGER_CONTAINER_TYPE =
"ecf.jms.activemq.tcp.manager";
    public static final String ECF_MANAGER_CONTAINER_ID =
"tcp://localhost:61616/exampleTopic";

    private static final String DEFAULT_CONTAINER_TYPE =
"ecf.jms.activemq.tcp.client";
@Override
public void start(BundleContext context) throws Exception {
        // Get BundleContext
        bundleContext =context;

        containerId = ECF_MANAGER_CONTAINER_ID;
        containerId =
System.getProperty(SpagicConstants.DISTRIBUTED_EVENT_ADMIN_TOPIC_URL);
        containerType = ECF_MANAGER_CONTAINER_TYPE;



        // Create event admin impl
        eventAdminImpl = new DistributedEventAdmin(bundleContext);

        if (isThereEventAdminManager()){
            containerId = null;
            containerType = DEFAULT_CONTAINER_TYPE;
            targetId = ECF_MANAGER_CONTAINER_ID;
            if
(System.getProperty(SpagicConstants.DISTRIBUTED_EVENT_ADMIN_TOPIC_URL)
!= null){
                targetId =
System.getProperty(SpagicConstants.DISTRIBUTED_EVENT_ADMIN_TOPIC_URL);
            }
            topic = DEFAULT_TOPIC;
        }else{
            containerId = ECF_MANAGER_CONTAINER_ID;
            containerType = ECF_MANAGER_CONTAINER_TYPE;
            if
(System.getProperty(SpagicConstants.DISTRIBUTED_EVENT_ADMIN_TOPIC_URL)
!= null){
                containerId =
System.getProperty(SpagicConstants.DISTRIBUTED_EVENT_ADMIN_TOPIC_URL);
            }


        }
        // Create, configure, and connect container
        createConfigureAndConnectContainer();

        // start event admin
        eventAdminImpl.start();
        // register as EventAdmin service instance
        Properties props = new Properties();
        props.put(EventConstants.EVENT_TOPIC, topic);
        props.put(SpagicConstants.EVENT_ADMIN_TYPE,
SpagicConstants.DISTRIBUTED_EVENT_ADMIN_TYPE);

        eventAdminRegistration = context.registerService(
                "org.osgi.service.event.EventAdmin", eventAdminImpl,
props);

    }

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.

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.

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.

Andrea


Il 05/02/2010 15:38, Scott Lewis ha scritto:

 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

Back to the top