3

I have been tasked with doing some refactoring work on how we start up applications. Basically we have a bunch of console apps which were depending on the GUI application startup code, causing bogus dependencies which have kick-on effects for which libraries we need to ship, and which dependencies other modules need to declare.

So I have written a simple startup framework where I basically just throw a bunch of Runnable objects into a list and then run them in order - and it works.

But I was thinking - we already have PicoContainer in our project, so all these things that need to be run on startup could potentially be thrown into a PicoContainer, and if they implement Startable they will start...

But in some cases we want to specify the ordering between them. For example, I don't want any other component writing to the log before we write a header into the log indicating that the application is starting up. I know I can introduce ordering by introducing injection dependencies, but this feels like a hack in this case - I would need to add the log header writer as a dependency for every other component which might write to the log, which isn't great at all.

Nonetheless it seems like it would be nice to control the order of PicoContainer startup, so is there perhaps some other way?

Alternatively I could just keep it simple and stick to my list of Runnable. It does, after all, work.

Siguza
  • 21,155
  • 6
  • 52
  • 89
Hakanai
  • 12,010
  • 10
  • 62
  • 132

2 Answers2

2

You can't control default start/stop order, but surely you can have your own lifecycle ordered.

example:

1)make your interface MyStartable having methods init() and extending Comparable.

2)add container component MyStart initialized with list or array of MyStartable.

3)start MyStart manually or with standard start/stop lifecycle

4)in MyStart just sort the list/array according to natural order that you should override.

5)invoke init() on every MyStartable

I guess there's more "native" way to do this, through Lifecycle Managers, but need to explore the sources.

xeye
  • 1,250
  • 10
  • 15
0

How do your components currently write to the log? I would expect there to be a (picocontainer) dependency to the log, and then the constructor for that log would write the header. If the logging is not injected and totally bypasses PicoContainer, I wouldn't bring just the header part in, I would keep that seperate, like the rest of the logging.

beetstra
  • 7,942
  • 5
  • 40
  • 44
  • Actually, the component which writes the startup header to the logger is a separate component from the logger itself (single responsibility principle, and all that.) – Hakanai Nov 04 '10 at 09:03