You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a component that tries to lookup a reference to a bean from the registry - thus from ArC - as following:
@OverrideprotectedvoiddoInit() throwsException {
super.doInit();
if (this.vertx == null) {
Set<Vertx> instances = getCamelContext().getRegistry().findByType(Vertx.class);
if (instances.size() == 1) {
this.vertx = instances.iterator().next();
if (this.vertx != null) {
LOGGER.info("Found Vert.x instance in registry: {}", this.vertx);
}
}
}
}
and it turn out that ArC could find a bean of the given type but fails to resolve the reference so findByType returns a collection with a single element as expected but then the element is null.
This happens because the lookup method inside the came registry happens before the Vertx producer is properly initialized.
As initializing components from bean auto-discovered from registry is quite a common and powerful feature we need a better way to deal with dependencies, maybe we should not automatically populate the registry with components/languages/dataformat but we need to delegate this to the actual extension that can properly set-up dependencies on other extensions.
i.e. we can create {Component|DataFormat|Language}BuildItem and populate the registry from such items.
I have a component that tries to lookup a reference to a bean from the registry - thus from ArC - as following:
and it turn out that ArC could find a bean of the given type but fails to resolve the reference so
findByType
returns a collection with a single element as expected but then the element is null.This happens because the lookup method inside the came registry happens before the Vertx producer is properly initialized.
As initializing components from bean auto-discovered from registry is quite a common and powerful feature we need a better way to deal with dependencies, maybe we should not automatically populate the registry with components/languages/dataformat but we need to delegate this to the actual extension that can properly set-up dependencies on other extensions.
i.e. we can create {Component|DataFormat|Language}BuildItem and populate the registry from such items.
//cc @gnodet @davsclaus
The text was updated successfully, but these errors were encountered: