Ales replied.

"adrian@jboss.org" wrote:

It is the parameter type of the methods.

incallback is a HORRIBLE name for this. Please define something that is easier to understand. Thanks.

I agree. But I don't really care what it is called, I care what does.
Ales, maybe you can come up with a better name, e.g.
installCallback and uninstallCallback?

Just writing response myself. :-)
Yup I was thinking of something better, but everything looked too long.
Bill, any (short) suggestions?

This callback is just an IOC version of something you can do with OSGi
(or even the old JMX notifications).

In OSGi/JMX you can listen to services appearing and disappearing
and do work on them, e.g.

public void [un]registerNotification(Event event)
{
 if (event.getTarget() instanceof Deployer)
 [un]register();
}

All the [un]installCallback is doing is removing the need to write the notification
handling and wiring yourself.

Actually, it is slightly more complicated, because you can choose the event
to be a true dependency (i.e. there must be at least N deployers -most likely 1)
or optional (I don't care if there are no deployers, deploy me anyway)
through the cardinality.

Its probably easier to understand in its alternate form, i.e. as an injection
of a collection of all implementations of a specific type.

e.g. intead of, give me a DataSource

@Inject
public void setDataSource(DataSource ds);

it is give me all DataSources

@Inject
public void setDataSources(Collection<DataSource> all);