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

Improved support for 'containerless' web application architectures [SPR-9888] #14521

Closed
spring-projects-issues opened this issue Oct 17, 2012 · 3 comments
Assignees
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) status: declined A suggestion or change that we don't feel we should currently apply type: enhancement A general enhancement

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Oct 17, 2012

Mike Youngstrom opened SPR-9888 and commented

As the enterprise development landscape grows more diverse the simpler the application framework the more likely developers are to adopt the framework. Developers with existing knowledge of previously common frameworks like the Servlet container are becoming more rare. Spring's dependence on frameworks and containers outside of Spring's component model increases the learning curve of new developers attempting to create and maintain spring web applications.

Traditionally Spring web applications have been embedded in a servlet container. This was useful in the past when the majority of enterprise applications ran in and depended on the servlet container for deployment and configuration. However, a servlet container comes with learning curve that we cannot assume new developers will have already overcome. The learning curve includes things such as:

  • web.xml and other Servlet oriented configuration concepts
  • .war directory structure
  • Container implementation specific items (e.g. ports, thread pools, etc.)
  • Complex Classloading hierarchies
  • Monitoring and management facilities configured outside of the application
  • Logging facilities
  • Configuration of application context roots
  • So forth

All of the above items are configured in inconsistent non-unified ways requiring a development team to learn these for the container their using in addition to Spring's own configuration model.

I think that Spring's web application architecture can be significantly simplified if it were to provided tools and a reference architecture that leveraged the Spring component and configuration model from top to bottom. Embedding and unifying the configuration of those common web container services within a Spring Container bootstrapped from a simple main() method.

Though there are many frameworks and platforms today that no longer require a container I think inspiration can be drawn most from DropWizard (http://dropwizard.codahale.com/).

Another project I've seen inspired by DropWizard but leveraging Spring is HalfPipe (https://github.com/32degrees/halfpipe). Though I don't think HalfPipe goes far enough. I think to truly provide simplification the entire architecture, wherever reasonable, must be embedded within the Spring container rather than without. Though it does have several other interesting ideas.

I believe that a Spring driven containerless web application architecture could provide benefits like:

  • Provide a single unified component model requiring no knowledge of the Servlet Component models.
  • Unified configuration of everything allowing developers to only have to learn one Spring configuration model for both component and app configuration.
  • Execution from a void main will simplify application startup and shutdown.
  • A much simpler pure java classloading hierarchy.
  • Simpler development tooling. Instead of needing a complex IDE to construct a war and deploy it to a dev container simply execute the applications Main class.

For such an architecture to be successful this architecture will also need new and simple ways to configure common Spring tools, such as Spring MVC and Spring Security, that have traditionally been configured through the servlet container.

To accomplish this simplification I don't think Spring would need to create a brand new http engine. It could simply utilize an embedded servlet container like Jetty. Though it would need to abstract away as much configuration as possible.

I think a reference app would also be unnecessary to set an example of how to structure, develop and configure such an application in a pure spring manner.


Sub-tasks:

Issue Links:

2 votes, 7 watchers

@spring-projects-issues
Copy link
Collaborator Author

Phil Webb commented

Rather than fix this as part of the core Spring Framework we have decided to start a new project called Spring Boot that addresses this and a number of other issues.

The GitHub project is at https://github.com/SpringSource/spring-boot and this blog post provides a general overview.

@spring-projects-issues
Copy link
Collaborator Author

Phil Webb commented

Mike Youngstrom, I would like to thank you for raising this issue with us at the last Spring One. This bug was the genesis of Spring Boot and I am only sorry that we couldn't make the project public earlier.

Cheers!

@spring-projects-issues
Copy link
Collaborator Author

Mike Youngstrom commented

Great! I'm excited to see how spring-boot looks.

Mike

@spring-projects-issues spring-projects-issues added status: declined A suggestion or change that we don't feel we should currently apply type: enhancement A general enhancement in: web Issues in web modules (web, webmvc, webflux, websocket) labels Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) status: declined A suggestion or change that we don't feel we should currently apply type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants