[blueprint] Custom namespace handlers and registration of metadata

[blueprint] Custom namespace handlers and registration of metadata

I'm working on blueprint support for Apache Camel these days and came
across the following use case.
I have a custom namespace handler for camel which is able to create
camel routes. Those camel routes depends on camel components. What
I'm trying to do is use the OSGi registry to host those components and
leverage blueprint support for OSGi services, especially the grace
period. This means that the namespace handler would have to add a few
dependencies on the main bean, each of those dependencies being a
reference to a camel component from the OSGi registry.
So far so good.
Now the problem is that, given the way camel works, the required
components can only be found when the routes are created. I'd like to
keep this creation done when the camel context bean is created by the
blueprint container instead of having the custom namespace handler do
the instanciation and introspect the routes for components. This
should be doable using the BeanProcessor#afterInit() method. The
problem is, what should happen if we add additional metadata at this
stage ?
Currently, nothing is done, which means it may leave the blueprint
container in an inconsistent state. So we need to choose one way:
either registration of metadata using
ComponentDefinitionRegistry#registerComponentDefinition() can only be
done at parsing time or we want to allow it later at runtime. The
later is obvisouly much more complicated.
For this very use case, I could do without that by instanciating the
camel context at parsing time, introspect it, and add the needed
service references, so that's not a big deal, but i still think we
need to agree on this issue and enhance the code to either fully
support or reject that.

Hmm.. not too sure how you'd get to the ComponentDefintionRegistry during a
BeanProcessor before/after init call... the before/after calls do get passed
a reference to the current bean metadata though..

I'd figure that metadata passed to before/after init should be treated as
readonly.. since the metadata is accompanied by an instance of the bean
created from it, it would be strange to allow changes to it there. Although
we don't prevent that today either !

I'd guess the most likely way to do what you're describing would be to have
the NamespaceHandler save a reference to the CompDefReg into something it
registers as a BeanProcessor.. all feels a bit messy, and overall I think
I'd agree we probably dont want to be allowing modification of the registry
once we declare the parse phase complete. The comp def processor appears to
have to jump through some entertaining hoops to allow it's modifications to
take effect, and this would feel similar.

> I'm working on blueprint support for Apache Camel these days and came
> across the following use case.
> I have a custom namespace handler for camel which is able to create
> camel routes. Those camel routes depends on camel components. What
> I'm trying to do is use the OSGi registry to host those components and
> leverage blueprint support for OSGi services, especially the grace
> period. This means that the namespace handler would have to add a few
> dependencies on the main bean, each of those dependencies being a
> reference to a camel component from the OSGi registry.
> So far so good.
> Now the problem is that, given the way camel works, the required
> components can only be found when the routes are created. I'd like to
> keep this creation done when the camel context bean is created by the
> blueprint container instead of having the custom namespace handler do
> the instanciation and introspect the routes for components. This
> should be doable using the BeanProcessor#afterInit() method. The
> problem is, what should happen if we add additional metadata at this
> stage ?
> Currently, nothing is done, which means it may leave the blueprint
> container in an inconsistent state. So we need to choose one way:
> either registration of metadata using
> ComponentDefinitionRegistry#registerComponentDefinition() can only be
> done at parsing time or we want to allow it later at runtime. The
> later is obvisouly much more complicated.
> For this very use case, I could do without that by instanciating the
> camel context at parsing time, introspect it, and add the needed
> service references, so that's not a big deal, but i still think we
> need to agree on this issue and enhance the code to either fully
> support or reject that.
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/> ------------------------
> Open Source SOA
> http://fusesource.com>