configure application and services


As already mentioned at "first steps", the ApplicationContext is a XML-file that follows these rules:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns=""
Using a placeholder resolver, parts of the ApplciationContext could be place in the framework, without loosing any flexibility. So there exists a data-access-context.xml, which defines serveral classes for database access and the like. Additionally there exists security-context.xml, but you could consider it a an empty placeholder. Limiting access is already prepared at several places, but as I don't really have the need to use it, there's no much pressure to dedicate my human resources on that issues.

how it works

At application start all defined classes from ApplicationContext will be created. So they exists, but you can not reach that instances from application until the instances gets published. You can consider the instance from ApplicationContext like private properties of a java class. Only the startup helpers have direct access to all entries.

Define an instance

At ApplicationContext instances will be defined. The simplest variant of such a definition is:

<bean id="sysInfo" class="de.schwarzrot.system.SysInfo" />
which means, that each definition starts with a tag <bean. The mandatory parameters are "id" and "class".

Some classes don't have a default-constructor, which means, they need some parameters. Parameters could be specified like this:

<bean id="dataSourceManager" class="">
        <ref bean="dsConfig" />
Additionally this sample shows, how to reference an existing instance. With the tag <ref

howto set properties

After creating an instance, it might be necessary to set some properties. Therefor a tag <property exists.

<bean id="prefsEntityManager" class="">
    <property name="entityUtils"
               ref="entityUtils" />
    <property name="entityIntrospector>
        <ref="preferencesEntityIntrospector" />
    <property name="applicationName"
             value="${de/schwarzrot/app/config/SystemDefault/applicationName}" />
    <property name="schemaName"
             value="${de/schwarzrot/app/config/SystemDefault/dsSchema}" />
Furthermore you see the usage of placeholders. First two properties use different kinds of reference variants. Same can be used for specifying values.

Property of type List

Properties can also be set using list values:

<bean id="converterFactory" class="">
    <property name="converters">
            <ref bean="cnvDate" />
            <ref bean="cnvBoolean" />
            <ref bean="cnvInt" />
            <ref bean="cnvLong" />
            <ref bean="cnvByte" />
            <ref bean="cnvShort" />
            <ref bean="cnvFloat" />
            <ref bean="cnvDouble" />
            <ref bean="cnvColor" />
            <ref bean="cnvEnum" />
            <ref bean="cnvFile" />
            <ref bean="cnvString" />
            <ref bean="cnvEntity" />

Property of type Map

... same is true for Maps:

<bean id="appServices" class="">
    <property name="services">
       // IMPORTANT: don't change the keys,
       // change the bean definition above (if ever)
            <entry key="">
                <ref bean="transactionFactory" />
            <entry key="de.schwarzrot.ui.image.ImageFactory" value-ref="imageFactory" />
            <entry key="de.schwarzrot.ui.Desktop" value-ref="desktop" />
            <entry key=""
             value-ref="converterFactory" />
As a Map-entry consists of key and value and both can be specified as reference, another tag must be used. For the inlining of values or keys use the tags "value-ref" or "key-ref".

publish instances

The last passage already introduced the class, that is responsable for publishing instances from ApplicationContext: ApplicationServiceConfigurer.

All instances, that are added to the "services" map property will be registered to the ApplicationServiceProvider. Therefore the keys shall be absolute classnames of classes or interfaces, that are ancestors of the instance to publish.

That's the reason too, why you never should change an existing key from the services map. Other classes may rely on that entry! But of cause it is leagal to publish on instance using different keys ...