Marcel,
Simply to make sure there's no confusion..
I agree that the possibility to override the default implementation is a
plus and I'm glad to see you're actively working on it.
Yet my original concern was the ability to give a (non-interface) class
(typically a superclass of the service to bind) as argument to the
setInterface() method.
In my example I was trying to express dependency on a ClassLoader, and
expected to be injected with an object implementing a subclass of
ClassLoader. My point was not to provide a default implementation for
this dependency.
Thanks again,
Arjun
Marcel Offermans wrote:
I'd be quite sad to have to abandon DependencyManager for this reason..
Does anyone know of a workaround, or a future release that would address
this issue?
I had some time yesterday evening so I added support for supplying your own
"default implementation" for a service dependency. If you do so, it will be
used instead of the null object. The new method (on a ServiceDependency) is
called setDefaultImplemenation(Object) and the argument can be either of
type class (which will lazily be instantiated by invoking the default
constructor) or an instance you already created.
I did not yet test this feature, but feel free to check out the latest
version and build and test it.
Greetings, Marcel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
