We have quite often the case that we would like to have a default implementation for a service, which should be overridable by the users of our framework. The possibility to achieve that by using the application/factory defaults is not very obvious and hides this semantic because it can also be used for many other things. Could we not add two attributes to the existing service point/implementation elements to support this? Such as: <service-point id=".." .. overridable="true"/> <implementation service-id=".." type="default"/> <implementation service-id=".." type="override"/> With: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> : not requiered, ( true | false ), default value = false [EMAIL PROTECTED]: not requiered, ( default | override ), default value = default [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> defines whether a service is overridable or not. Default behaviour is like it is today, which is not overridable. [EMAIL PROTECTED] defines whether the implementation is a default implementation or the overriden implementation. Default is �default�, so that the behaviour is as today. An �inlined� implementation is a final (not overridable) implementation if [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> is false. If [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> is true than the �inlined� implementation is a default (overridable) implementation. Possible conflicts (hivemind errors/warnings): [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> == false && [EMAIL PROTECTED] == override more ?
Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
