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

Expose SagaRepository and SagaManager as Spring Beans when using @Saga #303

Closed
abuijze opened this issue Mar 14, 2017 · 2 comments
Closed
Labels
Status: Won't Fix Use to signal that the issue is acknowledged, but it’s decided that the work will not be performed. Type: Enhancement Use to signal an issue enhances an already existing feature of the project.

Comments

@abuijze
Copy link
Member

abuijze commented Mar 14, 2017

When using Spring autoconfiguration to initialize components for an @Saga, the SagaRepository and SagaManager aren't accessible as Spring beans in the context.

@abuijze abuijze added the Type: Enhancement Use to signal an issue enhances an already existing feature of the project. label Mar 14, 2017
@abuijze abuijze added this to the Release 3.0.3 milestone Mar 14, 2017
@abuijze abuijze modified the milestones: Release 3.1, Release 3.0.3 Apr 5, 2017
@abuijze
Copy link
Member Author

abuijze commented Apr 5, 2017

Moved to 3.1, as this requires a redesign on how Axon uses autoconfiguration (internally).
Instead of using Axon Configuration API, it should use "regular" Spring Boot Autoconfiguration to configure beans part of Saga infrastructure.

@abuijze abuijze removed this from the Release 3.1 milestone Nov 23, 2017
@abuijze
Copy link
Member Author

abuijze commented Nov 23, 2017

Access of the autoconfigured components for Sagas are available through the SagaConfiguration instance, which is published as Configuration in the application context.
That bean can be autowired (using @Qualifier).

@abuijze abuijze closed this as completed Nov 23, 2017
@abuijze abuijze added Status: Won't Fix Use to signal that the issue is acknowledged, but it’s decided that the work will not be performed. Type: Enhancement Use to signal an issue enhances an already existing feature of the project. and removed Type: Enhancement Use to signal an issue enhances an already existing feature of the project. labels Nov 23, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Won't Fix Use to signal that the issue is acknowledged, but it’s decided that the work will not be performed. Type: Enhancement Use to signal an issue enhances an already existing feature of the project.
Projects
None yet
Development

No branches or pull requests

1 participant