I keep on studing Spring, and find Spring environment comparison as a very obscure topic. It's very difficult (IMHO) to find something intelligible on the topic.
I've got a vague understanding of the intention of each of Spring environment (mentioned below), but can't grasp the difference between them. I mean, I understand that EJB environment is destined for integration with EJB framework. But has it got some extra-bonuses compared to Standalone? What bonuses? So my questions are:
Can you provide me a brief comparison of "extra-bonuses" (means additional functional abbilities except of integration with the framework) of each environment?
Can you explain me what is JUnit environment and for it's destined?
Environment types:
Standalone
Web
JUnit
EJB
The only difference between these is how you wish to deploy/run your application.
Standalone
Run your Java application via a "main" method.
Web
Deploy your application to a Java web container such as Tomcat, as a .war file.
JUnit
Run a JUnit test.
EJB
Access EJBs from your application, which will have been deployed through one of 1-3.
The difference between these environments has nothing to do with Spring. Spring is just a framework, which makes some aspects of an application easier to write.
For instance, in a web environment, Spring provides annotations which make it easy to expose methods in your classes as MVC controller methods, REST or SOAP endpoints. These are obviously things which are commonly needed in web applications.
In a JUnit test, the Spring-Test libraries enable you to wire up a Spring context into your test so that you can test how those components have been wired together. Whether you intend to deploy as a standalone or web application, you should be testing your components with JUnit, or another test framework as part of your build process.
With respect to EJBs, if you also have EJB components (not Spring) deployed, then Spring provides helpers which let you reduce the amount of code involved in locating/invoking them.
Related
I have created a rest application using spring-boot 2.0.3. From an other maven module (in a different multi module pom), I have an integration test that tests that data sent to the running rest application is processed.
Is it possible to run this spring-boot application programatically? I cannot use the simple #SpringBootTest-annotation as the spring-boot application is not in the same maven multi module.
I would recommend using mockito to mock a request to your rest endpoint with some data, and testing that your other application tries to send the correct data to the endpoint.
This way both applications are tested independently and do not have dependencies at each other. This provides the benefit of being able to substitute one of these applications with another if necessary. Also it provides a good separation. This is important because when you (or someone else) wants to use your REST application they do not use your other application so it is very important that the REST application is tested with static data written in your tests and is not dependent on the output of another application. Since REST applications are meant to be independent.
However, when you do want to test it this way you could try to include your other application in the classpath.
The thing is "loose coupling". It is technical possible, but not recommended. The build itself has numerous tests using where mocking with Mockito is essential.
An integration test module, ala cucumber.io, should be created which will cover the functionality of the running module.
This is the main-point of the accepted answer.
I have a Java desktop application which uses spring framework and I need to replace the Swing UI with a web front end. I understand that I will need to adapt many things to make things work with the MVC architecture.
My concrete question is the following:
Will my application now have to run entirely in the application server?
I would appreciate if anyone could point me to some documentation that goes through a similar process.
Thanks!
Technically yes, but Spring Boot makes it trivial to set up an embedded servlet container and package your entire application as a runnable jar. This is how we're deploying our applications to production; the only thing we need is a JRE on the server VM, and java -jar takes care of all of it.
I recommend using Maven with the Spring Boot plugin (there's also a Gradle plugin) with the repackage goal, and using the lightweight Undertow servlet engine instead of the default Tomcat.
We are currently developing a web application for college and we would like some advice from a more experienced developer.
We have a backend using Hibernate to operate on a MySQL database. Another project is the web UI that uses the API delivered by the backend (registering user, fetching data associated with certain profiles etc.). We use the JSF framework (RichFaces) for the UI. Everything is built using Maven.
The technology we can't decide on is for the communication between UI and logic modules. The first option is to use ApacheCXF to provide SOAP webservices that UI can be a client of. The second option is to use EJBs to invoke backend methods from the UI module.
What approach is more widely-used? As far as we read on the Web, using EJB is faster than SOAP webservices. On the other hand, we don't have any experience with EJBs using Tomcat (we would prefer using Tomcat since it seems to be a cheaper option, however we don't know what we would have to do in order to use EJBs with Tomcat). Additionally, working with webservices since the beginning will allow us to add support for different platforms (for example, Android).
Another aspect which we are discussing is about how should the application be deployed. The alternatives we have considered right now are:
Deploy it as a single WAR project (which would solve the problem we have about communicating the UI with the backend of our application).
Deploy two WAR projects in the same server using webservices for communication between the projects. (We have a prototype using this approach deployed on a Tomcat server)
Deploy a WAR project and EJB project.
Deploy an EAR project which would contain the references to the WAR and EJB projects. (We have a prototype using this approach deployed on a Glassfish server)
The project right now is starting, so we will only be handling a couple hundreds of users right now. However, if the project succeeds we would need to deal with a couple million of users.
Any advice would be appreciated. Thanks.
Edit: So any advice about how the project should be deployed? Is it necessary to use EAR? Is there any advantage if we deploy the project as an EAR module?
Edit 2: We found the advice we needed on this thread: Deploying java applications (Tomcat/Glassfish)
First things first. I would avoid using Web Services if there's no need for it. If you feel that you might need to call this system from external programs and platforms, then go for it. Even then, I would only use the web service interface for external integration, and still have an internal EJB implementation.
EJBs are awesome for enterprise applications. I would highly recommend that you look into that. They provide support for EJB Pooling, Transactions, Aspect oriented programming, Security, Stateful sessions, Java Messaging, JNDI etc. And you can inject them directly inside a Managed Bean (JSF). You said that you will eventually handle millions of users, so I assume that you will want your application to run as fast as possible, I don't think SOAP web services will be a good fit. Remember that SOAP web services encode messages as text, so if your application will be sending binary files etc, then you'll suffer significant performance issues.
As far as deployment goes I would go with an EAR, or a WAR for the JSF and and EAR backend. you can use Injection to pull the classes you need, even remotely, from multiple web applications and other EAR apps.
I'm not sure why you say Tomcat is Cheaper. Glassfish open source edition is a fully functioning JavaEE6 Server and its free. JBoss is also JavaEE compliant and is free. both of them are used in lots of production environments. I find glassfish to be much more user friendly, and would recommend it to EJB noobs :)
I also started with Tomcat, but now I don't use it at all. why use the servlet container only, when you can have the whole shabang? hope this helps.
we use ApacheCXF at work and its has SOAP and Restful. Reliable and relatively easy to setup. I am not sure why you want to use glassfish maybe it's preference but you can implement your projects in eclipse too. It's really that is up to you and your team and the requirements and skill sets your team may have to build and support, that a side CXF webservice+apache + eclipse with maybe two war files would be a good path.
I wouldn't use web services in this case. You can use managed beans as controllers.
Put the logic into EJBs, views into rich faces and control the flow using managed beans.
If you use maven you can generate a project with the structure of EAR (war for web module and jar for ejbs). I don't remember the name of an archetype but you can find it easily.
I have an existing Java application (Spring based) that currently does NOT have a web interface, nor does it run in a web container. It packages up nicely with a start program and just works.
What I need to do is add an administrative web interface for some administrative type things, retrieving real time metrics, and perhaps some graphs to give the users a warm fuzzy feeling knowing that everything is working. As we are a Spring shop, and some of our web applications already use Spring MVC it only makes sense to us, however, I'm not happy with the suggestions I've had from our internal Spring folks on how I should procede.
What would be the ideal way to bolt on this web interface?
Convert my application to a web application and have a web container launch the application. I not too keen on this approach is the web tier is really secondary to the primary application.
Create a separate project that packages as a war, embed Jetty in my existing app and have it load the war. I think I can use the context loader listener to make the root context of my application the parent to the web application spring context. This would involve breaking up my Maven project into 2 projects I believe. I can't use an existing web technology for communication between the web tier and the primary application as my primary application is not web enabled.
Embed Jetty and put the Spring MVC stuff directly in my app. While I've done this approach before, it does involve some ugliness - for instance exploding the JSP tag libs into my jar.
Any thoughts on some clean separation here?
Also of note, my current jar contains some utility applications which some shell scripts launch. Going a pure WAR route would make this not so easy, since I can't juse point java at my war file and choose a class to execute.
Thanks.
If it's true that web is just a minor addition the application, migrating it to WAR and deploying in servlet container might be an overkill. Embedding web server/servlet container looks much simpler, although it doesn't have to be Jetty or Tomcat. You can use web server built into JDK or write one on top of netty or even raw sockets. But that's a hell to maintain.
Yet another solution to springs to mymind when reading:
web interface for some administrative type things, retrieving real time metrics, and perhaps some graphs
Maybe you don't need an interface, but monitoring infrastructure instead? Check out JMX (Spring has great support for JMX) - and write a second web application that simply connects to your standalone Java app via JMX and displays the metrics in fancy way. Another approach is to expose JMX via Jolokia, which translates JMX to REST services.
This approach has several advantages:
monitoring API is universal, and you get it for free
you don't have to use web client, monitoring application is completely decoupled,
finally changes to your original application are minimal. Check out this proof of concept: 1, 2.
It really depends on the structure of your existing Java/Spring app and how much of an API it provides. I've done something similar to this and I approached it by creating a separate Spring MVC project and then specified the existing Java app as a JAR dependency.
This is easy with Maven (or Ivy, etc) and provides nice decoupling. The trick is to be able to write service classes in the Spring MVC app which then access data via your dependent Spring app via a simple DAO class. That's why I stated at the beginning, that it depends on the structure of your original Java app. It has to be able to provide an API for data access that you can then plug your DAO (impl) into.
If this is not easily done, then the next option I'd suggest is simply converting your Spring app to a Spring MVC app. I've worked on another app where we did this. Using Maven, its possible to specify that the build can create either a war file or a jar file (or both). So it can be deployed as either a webapp (via war) or a normal app (via jar). Yes, the jar version has a bit of bloat but its a worthwhile compromise.
The question of embedding Jetty or using Tomcat via a war file is a completely separate issue that has its pros and cons. It shouldn't affect the approach you take in architecting the web app in the first place.
I need to start developing applications using the Spring framework, and am wondering what tools I need to download to have me up and running.
On the SpringSource website I am seeing all these applications to download and I am wondering, do I really need all this? And what versions should I use, especially for Spring Framework?
Spring Framework
SpringSource dm Server Samples
Spring Security
Spring Web Flow
Spring Web Services
Spring Dynamic Modules
Spring Integration
Spring Batch
Spring.NET
Spring JavaConfig
Spring LDAP
Spring Extensions
Spring IDE
Spring BlazeDS Integration
SpringSource Bundlor
Spring ROO
What other applications do I need to download (eg. Struts, Glassfish, Apache, etc.)?
This depends on what you want to use Spring for. Typically that's Web applications. If so you only need two things:
Spring framework (with minimal dependencies); and
A servlet container (eg Tomcat) or a full-blown application server (eg Glassfish, JBoss).
Everything else is optional. I believe the only required dependency is Apache Commons logging. Depending on what features you use, you may well need more.
If so, here is a [tutorial][1] that creates a barebones Spring MVC project. There are countless others around for that and other topics.
It's entirely possible to use Spring in, say, a Swing application in which case you obviously don't need a servlet container.
All you need from SpringSource is the Spring Framework.
Spring 3.0 is on the way, but for now, use 2.5.6.SEC01, the current production release.
You can get started with a simple servlet container (ie: Tomcat) rather than a full blown application server (eg: JBoss, Glassfish).
The Spring Framework comes bundled with jars for web development - ie: spring-web and spring-webmvc.
See #117535 for a simple example of using Spring MVC.
It mainly dependent on what you need Spring for. Each and every piece of Spring can, actually, be used in separation from the rest. You may use it only for IOC, in this case you don't need, for example, MVC and Servlets, etc...
The easiest way to start is to dowload the main package from http://www.springsource.com/download/community?project=Spring%20Framework
You can use Spring from any IDE
The best way is to use Maven with your project. Basically all you have to do is edit your pom.xml file and tell it that you want to use Spring. Then when you compile your code, Maven will go out and automatically download the Spring libraries you need from their public repository.
Here's an example:
http://pookey.co.uk/blog/archives/63-Getting-started-with-Maven-and-Spring.html