Strategy for default implementations

[Florian Huonder]

The question is how to handle default implementations within HERAS-AF.

There are some possibilities where each has its pros and cons.

• Do not configure default implementations: It's up to the user to configure all defaults
• Hard implementation of a default implementation: The default implementation is hard coded in the java code with new(). A variation from the default then can be configured trough the user (e.g. with spring)
• Provide a default Application Context (works only for users that use Spring): The default Application Context wires the application with all its defaults.

What's your opinion?

[Florian Huonder]

With default implementation I mean:

what should the default configuration of the framework be:

Example:
How does the PDP get its TargetMatcher.

• Do not preconfigure a target matcher
• Do something like targetMatcher = new HerasafDefaultTargetMatcher();
• Make a default Application Context: <bean id="pdp"><property = defaultTargetMatcher></bean>

[Stefan Oberholzer]

I think a combination of point 2 and point 3 would be the best solution.

This allows users to easily integrate HERAS-AF by giving them good support in how to change the default configuration.
I think it is the best solution to place the default configuration in an initialization prozedure or in case of primitive datatype directly attached to the attribte.

[Florian Huonder]

I am not really sure if it is advisable to choose combination.
IMHO it is not beneficial to do that case by case.

• Here a very clean documentation would be necessary (because there is no spring config that can act as documentation). Further it's not very handy for as well because we need spring for all configuration in the integration-tests etc.
• Here I see the drawback because the coupling between the components is increased when they depend no longer only on the interfaces.
• Here the drawback is that all users that do not use Spring are forced to bootstrap the whole application on their own. (as in point 1)

A suggestion:
We could provide a default application context configuration file that bootsraps the framework with all its defaults. If somebody needs an adaption, he/she can simply edit the application context provided or write a new one for his/her application.
Further a very detailed documentation is provided that shows the minimal needed configuration and how to extend.