Hi,
On Sat, Feb 8, 2014 at 1:58 PM, Tobias Bocanegra <[email protected]> wrote:
> ok, then what we need it the pendant to the OSGi service registry, [...]
s/the pendant/a dependency/? I'm not sure I understood this correctly.
> I.e. a mechanism where I can lookup any service.
This sounds like an XY problem, i.e. you're proposing a solution
without describing the problem you're trying to solve.
You mentioned a LoginModule implementation. Why would it need to look
up "any" service? Wouldn't a dependency to a specific service be
enough/better?
> thats what I mean, add the whiteboard from 'Oak.class' to the
> constructor to ContentRepositoryImpl.
You mean "new ContentRepositoryImpl(..., whiteboard, ...);"? Yes, we
can do that. Though as mentioned above I'd like to understand why we
need to do that instead of passing the whiteboard (or better, a more
specific dependency) directly to whatever component that needs it.
> The problem at hand is, that users can provide a service that is used
> in one of the login modules. so eventually we need to pass the osgi
> whiteboard into the login module. which is easy. but otoh, in the
> non-osgi case, a unique whiteboard instance should be passed. which is
> not so easy.
I don't see the problem:
Whiteboard whiteboard = ...;
new Oak(...)
.with(whiteboard)
.with(new SomeComponent(whiteboard))
....;
Or perhaps I'm missing something here?
> one workaround idea I tested in [0] by introducing "WhiteboardAware"
> interface (better name welcome). when such a instance is added to the
> Oak instance via a with() method, it oak will push the whiteboard to
> it.
Right, we can of course do that, but IMHO the above constructor
argument pattern seems much simpler.
BR,
Jukka Zitting
