consider spring boot

[hohwille]

Spring boot can be used in several steps and levels. Currently we are only using it for dependency management.

Next step is to use it as dev tool and runtime to launch, test and debug the app in IDE. This is bringing a bigger shift in how things are configured. For that a first step would be to add config and starter classes to oasp4j modules but keep spring boot optional. After that we can migrate the sample app to spring boot and make it first choice.

Last step is to use spring boot also in production what is not suitable for most customers and operators today. However, this might also change.

For the actual work we should file smaller tickets and use this issue as a bracket for the overall coordination.

[tbialecki]

In which way it is not suitable ? 21 maj 2015 17:40 "Jörg Hohwiller" notifications@github.com napisał(a):

Spring boot can be used in several steps and levels. Currently we are only using it for dependency management.

Next step is to use it as dev tool and runtime to launch, test and debug the app in IDE. This is bringing a bigger shift in how things are configured. For that a first step would be to add config and starter classes to oasp4j modules but keep spring boot optional. After that we can migrate the sample app to spring boot and make it first choice.

Last step is to use spring boot also in production what is not suitable for most customers and operators today. However, this might also change.

For the actual work we should file smaller tickets and use this issue as a bracket for the overall coordination.

— Reply to this email directly or view it on GitHub.

[amarinso]

I think embracing Boot is coupling us too much to Spring. If we choose this path we may as well buy all the Spring bells and whistles like Spring Data...

I'm not against Spring but Java EE standards are becoming a valid alternative and I think we will see more customers going the standard way. If we deviate too much then little could be used for these engagements.

Going optional can also be a lot of effort to make it always compatible and I can not recommend it as the primary use case for OASP.

But... it surely is something we have to keep an eye on.

Maybe if it becomes a "de facto" standard as Spring is today it will be the preferred option.

Are you seeing it becoming "normal" on your customers? maybe we could move this into yammer to get more feedback.

[amarinso]

I've read the already ongoing conversation on yammer and I think it's similar to my comment.

For development it can be very beneficial if it reduces the code-run-debug cycle. Can you share your experience with it?

Maybe we can even integrate on the cycle some tools like JRebel (wich has free license for Open Source projects ) or other alternatives like HotswapAgent which I personally have no experience.

[hohwille]

@tbialecki

In which way it is not suitable ?

Many operating departments have standards and define how an application is deployed and operated. Most of them want to keep control over the container (e.g. tomcat or JEE app server) and keep responsibility for security updates. I am totally aware of all the arguments that e.g. there is in the end no reasonable difference between a security update of tomcat compared to a security update in hibernate. However, I am aware of reality and our daily business. Fact is that many enterprises will simply not allow you to do spring boot JAR launching in production. There is pretty much nothing we can do about it in such cases. And this is IMHO the typical case!

[hohwille]

If you are doing dev-ops and also hosting the app you develop in the cloud e.g. cloud-foundry then you are fully fine with 100% spring-boot approach. There is nothing against it and some pros for it such as you are testing the same way in dev as you are running in prod.

[hohwille]

Can you share your experience with it?

We have good experience with it in our pilot. It strictly supports "conventions over configuration". On the other side it can get a little bit magic and as a non hard-core developer you might loose grip on what is going on behind the scenes. This is what i am observing critical. In general I think that you need some time for the shift as things get slightly different and if you are master in spring classic you feel a little trapped in the first days. However in the end you will love it. There is so much pointless clutter that we can avoid with boot. E.g. in OASP we have to register all services in XML manually by name: https://github.com/oasp/oasp4j/blob/develop/oasp4j-samples/oasp4j-sample-core/src/main/resources/config/app/service/beans-service.xml#L44

With spring boot you can simple write a config that registers all services of your application automatically. This still allows you to integrate services from other modules or third-party without loosing control what is registered and what not.

[hohwille]

Maybe we can even integrate on the cycle some tools like JRebel or other alternatives

I already feel like heaven when I can avoid the ugly WTP and stop doing tomcat clean on every problem to ensure it is not WTP that got stuck. Just hit debug and run your app fast and reliable. Regular code hot-plugging already works. When it comes to bigger changes I am still used to restart. But if you change annotations and startup related behavior then no tool like JRebel can help. However, it is worth a try to see if it can boost even more!

[tbialecki]

Spring boot app can be deployed either as jar(with embedded tomcat) or as war app on any container/server.

2015-05-22 17:36 GMT+02:00 Jörg Hohwiller notifications@github.com:

Maybe we can even integrate on the cycle some tools like JRebel or other alternatives

I already feel like heaven when I can avoid the ugly WTP and stop doing tomcat clean on every problem to ensure it is not WTP that got stuck. Just hit debug and run your app fast and reliable. Regular code hot-plugging already works. When it comes to bigger changes I am still used to restart. But if you change annotations and startup related behavior then no tool like JRebel can help. However, it is worth a try to see if it can boost even more!

— Reply to this email directly or view it on GitHub https://github.com/oasp/oasp4j/issues/232#issuecomment-104693391.

[hohwille]

To me this is not a question whether to integrate/adapt spring boot but more when and how.

• Shall we introduce spring boot by adding an additional application template?
• Or shall we simply drop further support/improvements for spring classic then?
• IMHO we should migrate the sample to spring boot then and have no spring classic sample to avoid maintenance overhead.

I would propose this feature for oasp4j version 2.0.0 and schedule for Q1 2016. WDYT?

[amarinso]

We have to think which is the default deployment option for our clients.

If the typical war/ear is still the common for our clients I think we should stick with this because otherwise we are not providing an accelerator/help for the engagements.

Also consider a future line of pure Java EE deployment (OASP4JEE). Going the boot path may be too radical to maintain coherence on the projects.

But as an alternative for easing development I'm all in.

[hohwille]

Default deployment is WAR (or EAR). We also do that based on spring boot and it works fine. Still we have the better tooling, faster testing, etc. If you want you can also run the WAR standalone with java -jar my.war but you can also paste it into the webapps folder of your container.

[hohwille]

Only in engagements where we also operate the system or where DevOps is an option then providing JAR instead of WAR is a regular option.

[hohwille]

I am doing a review of oasp4j-spring-boot and we are planing to integrate this on this main repo very soon. So far I am planning to:

• remove ServletInitializer (besides the wrong package this class is not required, we define mainClass in POM. Would be great if someone can shed light into this. Git does not seem to be capable of telling me the original history before the file has been moved/renamed).
• remove server.context-path=/oasp4j-sample-server from config/application.properties. The whole story about spring-boot is that we can now configure such things as desired. I never wanted to name this oasp4j-sample-server in the URL what is just a dumb technical name but with pure servlet technology this was tricky to solve. Now the URL path is just restaurant and developers should simply get used to the new name and the old strange name shall die out.

[hohwille]

I also discovered that the archectype has a bug:

• io.oasp.gastronomy.restaurant.SpringBootApp is not replaced with a variable. I will fix this easily.

[hohwille]

All done. What is IMHO still open is what I wrote as task in #363: We should make the core module to be a regular JAR project (without spring-boot) and have the spring boot stuff in the server module. I am also confused how the batch module does work. A dependency on a bootified JAR does IMHO not make real sense. Also we do not want to have our batch to depend on tomcat and all the servlet and web stuff. Further currently the batch code is also in the core module causing it to inherit all the batch dependencies. That is IMHO all a very bad design and should be changed. As I am not familiar with the batch code, I assume I need assistance to fix this.

[hohwille]

from config/application.properties:

logging.level.org.springframework.web=DEBUG logging.level.org.hibernate=ERROR

If we want to have this, we should change this in oasp4j-test/src/main/resources/logback.xml instead of overriding this here.

[hohwille]

Who is doing anonymous commits in OASP?

Revision: e2ddfe4ae43fcebead39d959e8b0e0ac6a62b2b3 Author: Your Name you@example.com Date: 15.01.2016 12:34:50 Message: added ChunkLoggingListener and

JobLauncherWithAdditionalRestartCapabilities to module oasp4j-batch

AFAIK github does not connect its authentication with git commit history when pushing changes. So in such case we can never figure out who did this. Please all let us avoid such things in the future or we will end in a mess!

[hohwille]

We urgently have to establish clear naming-conventions for flyway. In my project we introduced a folder for each release such as src/main/resources/db/migration/releases/1.0/V0001__Create_Schema.sql. This is a recommended best practice that we should also introduce into OASP. It makes it a lot easier to maintain the SQLs and to see what can still be changed during development and what is frozen forever. If I got it right we introduced a convention to have all SQLs in src/test/resources/TESTCASE/setup/db and also number them starting with 9000 (V900x) while some are V99xx. To me this looks like a first idea that is not yet an established best practice. I also think it would be better to follow typical flyway conventions and have them in src/test/resources/db/test/TESTCASE/. Then the default package namespace would also not be as polluted and flyway stuff would stay closer together. For the numbering we should have some discussions and the most important thing is that we in the end have a documentation in our wiki that describes these best practices and fits to the code.

[hohwille]

Besides my comments I have no further concerns (of course there are warnings left and still own conventions are not followed such as CORSFilter needs to be renamed CorsFilter but that is sugar). Thanks to all contributors that made this become reality. I will open a PR for the boot repo. IMHO we can fix the remaining issues (esp. core/batch/server dependencies stuff) after the merge to this repo.

[amarinso]

Regarding CORSFilter, there is a PR on the oasp-forge repository to remove and substitute it with the functionality already provided by Spring.

[hohwille]

We have more than considered spring-boot. We migrated to it and suggest it now. This issue is therefore done.