Do not use printStackTrace about update4j

[mordechaim]

DefaultBootstrap was not designed to be referenced in actual code. The goal was to allow to use this framework without having to design a bootstrap application, thus just focusing on the business app. In tandem with DefaultLauncher you don't even have to design the business app with the framework in mind, it will just launch a provided main class.

This being said, there's hardly any code catching those exceptions; it is rather designed to be run from the command line where you can pass commands to configure the bootstrap. Additionally, a failure to load the remote config, is not a fail; it falls back to the local config, so why throw anything?

What I do agree is that I haven't properly used a logging framework, so you can divert the output or control what to output. I'm busy now with the actual framework logic, maybe in the future.

If this doesn't fit your needs, you can design your own bootstrap, which basically is code that calls Configuration::update and Configuration::launch.

Calling UpdateHandler#failed(Throwable) would be actually another option.

Nope, the update handler is not loaded yet at that stage, it only get's loaded when update()is called.

[vinov]

First, maybe I should write what are we trying to achieve. The process must be as simple as possible for our users, it is unacceptable to make them run command line and watch the standard output. Users don't want to see command window at all, since they run GUI application which has its own window. I came to a conclution, we need something very similar to a webstart.

We build an executable (the app) that accepts one argument - file path or URL that points to the configuration on local disk, or web server. This executable is associated with the config file extension. User clicks on a webpage, downloads the config file and double clicks it aggain. This way associated application is run and it gets path to the config, like clicking jnlp file.

Now our app (starter) generates actual arguments for update4j --remote, --local and --syncLocal. How this is done is not important now.

Anyway, failure to load the remote config is a failure, at least if you run the application for the first time. And we need the user to know they should call administrator, and say that the server is not running (in the best case). I understand, you don't want to break current apps, but maybe update4j could load UpdateHandler earlier, or accept an argument like --throwExceptions.

I will try to use Configuration::update and Configuration::launch, thanks for the tip.

[mordechaim]

Now I understand you needs; DefaultBootstrap was not designed for this, and yes, best would be to design your own bootstrap.

[vinov]

There is actually lot of useful logic in DefaultBootstrap that I would need to copy. Maybe it would help, to make it more extensible, changing the private methods and fields to protected. Anyway I like the concept of framework and I still thing its perfectly usable for us, it just needs more entry points.

[mordechaim]

Make your changes and open a pull request. If it doesn't change the current behavior I will gladly merge it.

BTW there are breaking changes in the current codebase vs the released version, just be aware. There's a whole new dependency injection framework scheduled for release in the next few days.