Hi Danushka, Is it possible to elaborate in more details what you are trying to achieve?
Thanks, Sorin On Fri, Aug 13, 2010 at 6:11 PM, Danushka Menikkumbura <[email protected]> wrote: > Hi Andrew, > > Thanks a lot for your quick reply. > > Why do you think what I have suggested is not the correct way to achieve > what I need?. I believe its the simplest approach to get it done. > > Thanks, > Danushka > > On Fri, Aug 13, 2010 at 6:46 PM, Andrew Kennedy < > [email protected]> wrote: > >> > Broker shutdown logic needs changing to run inside another process >> > ------------------------------------------------------------------ >> > >> > Key: QPID-2794 >> > URL: https://issues.apache.org/jira/browse/QPID-2794 >> > Project: Qpid >> > Issue Type: Bug >> > Components: Java Broker >> > Reporter: Danushka Menikkumbura >> > Attachments: QPID-2794.patch >> > >> > At the moment the broker shutdown terminates the JVM which is a problem >> when the broker runs inside another process. >> >> Danushka, Hi. >> >> I understand what you are trying to do here, but I don't think this is >> the way to go about it. I assume you want to start the broker inside >> an OSGi container, and not kill the container when it stops, right? >> Can I suggest the following refactoring of our broker startup classes >> as the way forward, instead? >> >> Main >> - move startup and shutdown methods to the Broker class, and build a >> BrokerOptions configuration from the command-line options here. if >> this class has to shut down the broker it started, it can safely call >> System.exit as well, after telling the instance to shut down. >> >> Broker >> - represents a broker instance that can be started and shut down >> (methods from Main originally) where the startup method should take a >> BrokerOptions configuration object. the instances would be created >> and methods called from Main, the BrokerActivator or possibly from a >> client wanting an in-vm broker. this class could also contain instance >> fields that represent ehther the broker is embedded and contain a copy >> of the OSGi context it is running >> >> BrokerOptions >> - the set of command-line options that are parsed out in the existing >> Main should be stored in a separate object, that can then be created >> independently for situations where broker startup does not happen on >> the command-line. >> >> BrokerActivator >> - OSGi activator that parses the configuration from a property file or >> similar to obtain a BrokerOptions and uses that to call startup on a >> Broker instance. similarly, when the Activator shuts down, it should >> shut the Broker instance down cleanly. this is distinct from the >> activator used by Felix when starting up our embedded container, and >> this is where you can set the flag that would indicate that the broker >> is embedded, so that the PluginManager knows not to start an OSGi >> container, but to use the existing OSGi context >> >> Hope this is useful, but it's just one way of doing things. >> >> Andrew. >> -- >> -- andrew d kennedy ? edinburgh : +44 7941 197 134 >> >> --------------------------------------------------------------------- >> Apache Qpid - AMQP Messaging Implementation >> Project: http://qpid.apache.org >> Use/Interact: mailto:[email protected] >> >> > -- Sorin S --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
