On 05/12/2013 8:49 PM, Mason Taube wrote:
> On Dec 5, 2013, at 4:37 PM, cowwoc <cowwoc_at_bbs.darktech.org
> <mailto:cowwoc_at_bbs.darktech.org>> wrote:
>
>> What prevents you from creating the same binding at runtime? Surely
>> if hk2-locator can locate this relationship at build-time, you can do
>> the same at runtime.
>
> We don’t always know at runtime. When an OSGi bundle is installed into
> GlassFish, the descriptor present in that bundle gets parsed and the
> HK2 bindings are created on the fly (with no classloading happening
> from the new bundle). As an example, this could be a new asadmin
> command (all asadmin commands implement a common contract) whose
> bundle gets copied to a running server’s module directory. The new
> command is now available since a call to
> ServiceLocator.getAllServices(Command.class) now includes this
> dynamically discovered service and the server can invoke on it. The
> cli framework doesn’t know anything about the specific commands (or
> what they are) it invokes on behalf of the user.
I'm a little confused. I was talking exclusively of replacing the need
to use inhabitant generator to translate @Service annotations to HK2
bindings. It sounds to me like you're talking about converting OSGI
bundles to HK2 bindings. How are the two related?
Gili