typo in TUTORIAL

[Samael]

just a small issue. while updating to the new 6.1.0 release I was reading about RegistrationOption.DO_NOT_ADD_CONCRETE_TYPE_REGISTRATION changing to RegistrationOptions.doNotAddConcreteTypeRegistration . It states RegistrationOptions but it should just be RegistrationOption.

Thanks for the new version btw. I'm already making use of ApplicationContext to keep all my dependency stuff seperate from my code. Quick question though. Is it possible to use @Component with a method that takes args?

I'd like to do something like the following:

class PoodinisContext : ApplicationContext {
    public override void registerDependencies(shared(DependencyContainer) container) {
        auto properties = readProperties("./app.properties");
        configureDatabase(properties);
        container.register!(SomeDao, SomeDaoImpl);
        container.register!(ServiceLayer, ServiceLayerImpl);
        container.register!(SomeService, SomeServiceImpl);
    }

    @Component
    SessionFactory configureDatabase(string[string] properties) {
        ... ALL CODE HERE TO SETUP DB FROM PROPERTIES
        return new SessionFactoryImpl(schema, dialect, dataSource);
    }
}

or, if that's not doable, to at least use @Component with a method that takes args that should be in the container:

class PoodinisContext : ApplicationContext {
    public override void registerDependencies(shared(DependencyContainer) container) {
        container.register!(SomeDao, SomeDaoImpl);
        container.register!(ServiceLayer, ServiceLayerImpl);
    }

    @Component
    SomeService configureDatabase(SomeDao dao) {
        return new SomeServiceImpl(dao);
    }
}

[Mike Bierlee]

I will fix the typo, thanks for noticing.

In your first example you're already making a new instance of SessionFactoryImpl (by calling configureDatabase() in registerDependencies()), so you might as well register it as an existing instance at that point (instead of later on as Component):

auto sessionFactory = configureDatabase(properties);
container.register!(SessionFactory, SessionFactoryImpl).existingInstance(sessionFactory);

The second solution might be doable once I get around to implementing constructor injection. I will extend that to component construction as well then.

I've considered picking up Issue #4 at some point in time as well, so these constructions might not be necessary anymore then.

[Samael]

after turning my computer off I realised the second example was crazy - it'd been a long day.

If @Component can be used on a class, then the autowire will be fine:

@Component
class SomeServiceImpl : SomeService {

    @Autowire
    private SomeDao myDao;

    public this() {
        logDebug("Creating my service");
    }
}

doing #4 will be helpful for me. If time allows I'll have a go at implementing @Value

[Mike Bierlee]

Using @Component on a class will probably work once we have component-scanning

[Mike Bierlee]

To get back at your original examples, it is already possible to inject SomeDao because application contexts are autowired too:

class PoodinisContext : ApplicationContext {
    @Autowire
    private SomeDao doa;

    public override void registerDependencies(shared(DependencyContainer) container) {
        container.register!(SomeDao, SomeDaoImpl);
    }

    @Component
    SomeService configureDatabase() {
        return new SomeServiceImpl(dao);
    }
}

No need for injecting it through the factory-method's signature

[Samael]

nice, thanks for that