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] > >
