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

Templates: Provide support for Spring Java Config #166

Open
tjuerge opened this issue Jan 3, 2015 · 10 comments
Open

Templates: Provide support for Spring Java Config #166

tjuerge opened this issue Jan 3, 2015 · 10 comments

Comments

@tjuerge
Copy link
Member

tjuerge commented Jan 3, 2015

Starting with version 3 Spring provides an alternative to XML for configuring the bean container - Java Config.

With Java Config the XML files are replaced by @Configuration annotated classes with @Bean annotated methods returning bean instances. This java-based approach has few advantages:

  • Fail-fast: Configuration errors are detected during compile-time.
  • Type-safe: It's java...
  • Refactoring support: It's java...
  • IDE support: It's java...
  • Debugging (break points): It's java...
  • Unit testing: It's java...
  • @Configuration annotated classes are automatically detected by component-scan (they are Spring managed beans as well)
@tjuerge
Copy link
Member Author

tjuerge commented Jan 3, 2015

The Spring Boot sample application #167 provides the reference for updating Sculptors templates.

@tjuerge tjuerge removed this from the 3.1.0 milestone Feb 20, 2015
@tjuerge tjuerge removed the 1 - Ready label Jan 9, 2016
@tavoda
Copy link
Member

tavoda commented Jun 7, 2017

Hello Torsten, I'm not big fun of Spring Java Configuration. XML configuration have one, for us huge advantage. You can override definition in more.xml. For example if you want override 'dataSource', you can define new one in more.xml and later definition win. I guess it's not possible with Java configuration.

@tjuerge
Copy link
Member Author

tjuerge commented Aug 10, 2019

@tavoda Pavel, I totally agree. Replacing the generation of XML config by Java config is no improvement. The advantages mentioned in the ticket's description are only valid for manually maintained configuration and not generated one.

So in 9ae41ff I updated the Spring Boot example #167 to use the generated XML configuration instead of manually maintained Java config classes.

But how about generating the corresponding wrapper configuration classes which import the XML configuration (BackendConfig and BackendTestConfig)?

@tavoda
Copy link
Member

tavoda commented Feb 13, 2021

Hello @tjuerge, i would like to finish release and cleanup issues. For this BackendConfig, do we have to generate it? It can be static with simple import for applicationContext.xml. Or do you have some idea for improvement?

@tjuerge
Copy link
Member Author

tjuerge commented Feb 14, 2021

For this BackendConfig, do we have to generate it?

Both classes from 9ae41ff are trivial and straight-forward to implement manually. They shouldn't be a deal breaker if not generated. But in the long run it would be convenient to generate them.

So let's postpone this ticket and finish the release :)

@tavoda
Copy link
Member

tavoda commented Feb 14, 2021

But they all look 'static'. I had before some SpringBoot integration requirements. Maybe we can create archetype for SpringBoot applications. Can we based it on springboot-example? Will it be useful than?

@tjuerge
Copy link
Member Author

tjuerge commented Feb 23, 2021

Maybe we can create archetype for SpringBoot applications. Can we based it on springboot-example? Will it be useful than?

Sure, it makes sense to provide an archetype which creates a Spring Boot app based on the springboot-example.

@tavoda
Copy link
Member

tavoda commented Feb 23, 2021 via email

@tjuerge
Copy link
Member Author

tjuerge commented Feb 24, 2021

Just one question, can you help me to create a RELEASE.

Sure. I'll check the head version with mvn -DdryRun=true release:prepare. Hopefully the release script is still working and my credentials are still valid - last release was back in 2015 :-)

@tavoda
Copy link
Member

tavoda commented Feb 24, 2021 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants