Description of startup procedure

start procedure of a SR-JRC application

The start of an application with database access need lots of configuration, initialization, preparation, and pre reading of data ...
That's the same for nealy every applictaion, so it makes sense to cut off that grunt work and offer an easy to use interface.

As already mentioned at Configuration, the ApplicationContext is divided into several files. Two of them are part of the SR-JRC framework. The third is part of your application.

SR-JRC application can be separated into 3 types of applications:

modular desktop application: They use a contributed appstarter, that's part of the framework and that loads the application modules dynamically.
systemservices: are background tasks or automates, that run without any GUI
simple GUI-applications: are GUI applications like the java installer of VdrAssistant, that don't need or don't want to use desktop or dynamically loaded applications.

top

desktop application

After hiding the amount of configuration, initialization and preparations, the interface for desktop applications got quite simple.

The application needs to implements the interface MainEntry and use the desktop start helper like this (supposing your app is called SampleApp):

public static void main(String[] args) {
    List sArgs = new ArrayList(Arrays.asList(args));

    new DesktopApplicationLauncher(new SampleApp()
                                , new String[] {
                                  "de/schwarzrot/app/base/ctx/security-context.xml"
                                , "de/schwarzrot/app/base/ctx/data-access-context.xml"
                                , "de/schwarzrot/main/sampleapp/ctx/application-context.xml"
                                  }
                                , sArgs).start();
}

MainEntry is the interface used by DesktopApplicationLauncher to identify the application as desktop application. MainEntry takes a generics parameter, which specifies the configuration class of the application.

The configuration class is a java bean, that holds the application state, size and position and it will be stored for each user separately using java preferences.

Finally the application should get the chance to fake some commandline parameters. Therefor the commandline parameters will we packed into a List, which will be passed to the application startup helper.

When the startup helper has terminated the grunt work of initialization, it will pass control to the application by calling the run method. The desktop starter uses Swingthread for that issue. Sooner or later run method will lead to a call of JFrame.setVisible(true);

Click on the picture on the left to examine the startup procedure.

top

simple GUI application

If you use a SimpleApplicationLauncher instead of DesktopApplicationLauncher, no desktop will be created/initialized. The simple application launcher simply passes the control to MainEntry.run()

This kind of startup is used by the java installer of VdrAssistant, a wizard application without desktop or loadable applications.

top

Systemservice

The biggest part of application setup is identically to the start of a desktop application. Therefore both startup helpers share the same ancestor, AbstractApplicationLauncher. The differences are put into DesktopApplicationLauncher or this time ServerLauncher. A sample service like SampleService could use a main like this:

public static void main(String[] args) {
    List sArgs = new ArrayList(Arrays.asList(args));

    new ServiceLauncher(new SampleService()
                      , new String[] {
                        "de/schwarzrot/app/base/ctx/security-context.xml"
                      , "de/schwarzrot/app/base/ctx/data-access-context.xml"
                      , "de/schwarzrot/main/sampleservice/ctx/application-context.xml"
                        }
                      , sArgs).start();
}

Systemservices have different needs than desktop applications, therefor the service starter expects an implementation of Service, which is an extension of MainEntry.

The configuration class is a java bean again, but instead of storing parameters like size and position, it holds log configuration and the ip-address of the services host.

Opposed to desktop application startes start() method, which will never return, the service startup helper expects the service run() method to contain the execution of a single task processing, which shall be executed cyclically. So the service startup helper enters a work loop, that will repeatedly call the Service.run(). If the service expects small load, it can use the method isIdle(). When the service signals, that it is boring, the service startup helper will fell into sleep. The time to sleep can be configured by changing the serivce definition from database, i.e. by using the service-manager from desktop application, that is already part of SR-JRC frames.

Click on the picture on the left to examine the startup en details.

top