Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initialization ordering #147

Closed
lburgazzoli opened this issue Aug 19, 2019 · 2 comments
Closed

Initialization ordering #147

lburgazzoli opened this issue Aug 19, 2019 · 2 comments
Labels
enhancement New feature or request
Milestone

Comments

@lburgazzoli
Copy link
Contributor

lburgazzoli commented Aug 19, 2019

I have a component that tries to lookup a reference to a bean from the registry - thus from ArC - as following:

@Override
protected void doInit() throws Exception {
    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.

//cc @gnodet @davsclaus

@lburgazzoli lburgazzoli added the enhancement New feature or request label Aug 19, 2019
@lburgazzoli lburgazzoli added this to the 1.0.0 milestone Aug 19, 2019
lburgazzoli added a commit to lburgazzoli/apache-camel-quarkus that referenced this issue Aug 19, 2019
lburgazzoli added a commit to lburgazzoli/apache-camel-quarkus that referenced this issue Aug 20, 2019
lburgazzoli added a commit that referenced this issue Aug 20, 2019
@lburgazzoli
Copy link
Contributor Author

With PR #148 I've added basic support for defining object to be bound to the camel context so you can do something like:

@Recorder
public class SupportRecorder {
    CamelRegistryBuildItem logComponent() {
        DefaultExchangeFormatter def = new DefaultExchangeFormatter();
        def.setShowAll(true);
        def.setMultiline(true);

        LogComponent component = new LogComponent();
        component.setExchangeFormatter(def);

        return new CamelRegistryBuildItem(
            "log",
            LogComponent.class,
            component
        );
    }
}
public class SupportBuildStep {
    @Record(ExecutionTime.STATIC_INIT)
    @BuildStep
    CamelRegistryBuildItem logComponent(SupportRecorder recorder) {
        return recorder.logComponent();
    }
}

And the pre-configured log component will be put in camel registry.

@lburgazzoli
Copy link
Contributor Author

Done in #148

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant