I've inherited an incomplete but small web project (Java EE 5, running on WebSphere 7).
The project consists mostly of JSPs that are accessed directly via their URL, and most JSPs look up their own reference to the EJBs (services) they need. Also, there's a Servlet for every form that gets submitted by the HTML code in the JSPs.
Architecturally speaking, is there anything wrong with this?
I was thinking it would be better to have an MVC design. I don't want to convert everything to JSF because I don't want to convert all the HTML and embedded Java scriptlets into JSF tags and managed beans.
I don't really want to use Struts or Spring MVC because they're not part of the Java EE 5 toolkit that comes out of the box with WebSphere, and I don't want to add additional complexity with the additional libs and config files.
I was thinking about building my own little MVC with a "ControllerServlet" that accepts a command and dynamically build and execute the command object, and redirect to the JSP view.
But I ask myself again, is there anything "wrong" with JSPs that post to Servlets? It's actually kind of elegant in its simplicity.
What do you think?
Any suggestions are GREATLY appreciated! Rob
You're asking a rather subjective/localized question. But ala.
There's technically nothing wrong with individual JSPs that submit to individual servlets. The only real problem is when the servlets turn out to contain duplicated code for quite common tasks like collecting request parameters, converting/validating them, setting bean properties, invoking actions, performing navigation. That is not DRY and is what a MVC framework with a single front controller and a well definied lifecycle is supposed to solve.
Or, if the servlet's tasks are actually well refactored with homegrown code to perform those common tasks, then this is in turn not very maintainable as no one else than the original developer knows the ins and outs of this custom framework. So it's hard to find anyone else willing to maintain this webapp without learning another framework again which the new developer wouldn't likely to see in other future webapps. That is why companies usually adopt an existing and well-developed MVC framework like JSF, Spring MVC, Stripes, Struts, etc.
Related
I'm a newbie to struts1 and I was wondering if an application built on struts1 can be changed some how to make it independent of struts. If at all i want to change, what are the changes that I'll need to perform?
I know that I have to convert the struts tags to html tags. Is this the only change that i need to perform or there are more?
You could start by using the JSTL instead of most of the logic and bean tags. Other than that, your application will be dependant on Struts, and there's no way around it, other than
not using any of what the framework offers, but then why use Struts in the first place
build some kind of super framework which use Struts behind the scene, but could be migrated to another underlying MVC framework. But you'll probably lose more time creating and migrating the framework than it takes to build the whole app using Struts and migrate the app to another framework.
Struts1 is obsolete anyway, and shouldn't be used for new projects. Prefer more modern frameworks such as Stripes or Spring MVC.
I'm coming to SpringMVC from the world of PHP, precisely I was working with Symfony for several years.
For your information, in Symfony, there are plugins and bundles that are created by other developers so that you could use them in your project. When I come to Spring, I don't find these notions or may be I've missed something !?.
For example, I'm looking for a component that does the registration and login form, which I think that must be done many times already, and I don't want to reinvent the wheels certainly.
So, my question is, I wonder if in Spring, are there possibilities to have and how to use reusable components?
Authentication is directly supported by the Java EE spec. You don't even need any particular framework for that. Every web container supports it out of the box. If you want some additional functionalities (like remember-me, etc.), loot at spring-security.
I am looking for a good tutorial on migrating from struts to spring. I have multiple struts actions that I would like to refactor into spring components.
Here's one (assuming you're talking about Struts 1, although you don't specify).
Not sure how helpful it will be; depending on how clean the original Struts code was it could be relatively straight-forward, or brutal.
In my experience the bulk of the work lies in the JSPs, not the actions themselves, particularly if the S1 code made extensive use of the Struts tags. The actions themselves are easier to deal with because of strong IDE support.
I know the title may seem like apples & oranges, but hear me out... :)
I'm building the architecture of an MVC app and considering what to use for the core of the controller / services. This stack will also serve as a RESTful API which will be equally as important as the UI.
I'm narrowing down my stack to be built with either Grails or JAX-RS (at this point I've ruled out other options and am not super interested in expanding this list). Either way I'll be using Groovy, and my model and views will be virtually unaffected by this choice, so that further levels some of the differences between the two. Here are the pros/cons that I've been pondering and was wondering if anyone had any other inputs or caveat experiences.
Grails
I am not going to use a ton of the built-in Grails features (GSP/SiteMesh, Hibernate, nearly all plugins), so I'm concerned that Grails might be a bit heavy for my purposes
I'm concerned that I won't have enough control over my ability to handle the REST API since it is very view-centric
I've seen inconsistencies in the quality of plugins to the point where I'm not sure I consider them much of a 'pro'
I love the convention-over-configuration & edit-and-refresh, to the point where I'd probably want to wire up something similar if I go with JAX-RS
I like the grails command line for everything it streamlines, but I'm concerned that it might get in my way since I'm not using as much of the stack
I like the scaffolding but since I'm not using Hibernate or GSP/SiteMesh it might not mesh well
JAX-RS
JAX-RS is made for REST. This will make my RESTful API really a snap to implement as I have complete control
Groovy is an important part of what makes Grails shine, so I'll benefit from that even in JAX-RS
I love how JAX-RS doesn't automatically pull in a bunch of other things so I can have more control of what components are in/out
unfortunately since it doesn't pull in everything else anything that I end up needing will require more work, whereas Grails might have a plugin
the grails command line and scaffolding will be missed; perhaps Maven can fill some gaps
It seems like the capabilities of each for creating actions and routing are pretty similar (although the implementation styles are different). In fact there are other SO questions wish touch upon this so I'm not too concerned.
I wrote a small REST service prototype in several frameworks last year (namely Grails, Play!, Spring MVC, Jersey, Restlet). My feeling about Grails in this concern was that although Grails supports REST style architecture, it isn't really made for it. I don't want to get religious here, so if you only want to map resources to URLs and HTTP verbs your fine, but if you want to dig deeper into REST with tight control over return codes, location headers, etc. you might still be able to do it with Grails, but it is probably better supported in a pure REST framework.
Grails also comes with a lot of dependencies, which might not be a problem if you're starting on a green field, but can cause problems when you have to integrate it with existing legacy components or frameworks.
From the two used REST frameworks, I liked Jersey more, as it just worked in my case and the documentation was good (although a bit focused on Maven and Netbeans).
Yeah, it does seem heavy to build on a MVC framework when you're not going to use the model or the view. While the autowiring and simplified configuration is super nice, Grails would still be providing a lot of extra stuff that you don't need.
I'd personally take the lighter approach and leave Grails out, using any standalone libraries or writing custom code which provide the features that you do want. There's a number of container projects listed on the Groovy site, perhaps Spring or one of the alternatives would add some value to your architecture.
Scenario: A fairly mature project uses Struts2 and Spring and Hibernate. I say mature because it has been going on a for a while and there are many struts actions written already.
Suppose we wanted to remove Struts2 from the project and instead depend entirely on Spring MVC without rewriting the entire project.
Is this something that should even be considered?
Are there any migration guides out there?
Has anyone done this before and would like to warn me against it?
If it ain't broke, don't fix it. You have very likely better things to do than a migration that won't add any value to the product (and will certainly introduce some bugs). If I were the business, I would never buy such a migration (with close to zero benefits).
I have to ask: What advantages do you see with Spring MVC that aren't being fulfilled by Struts 2?
If there's not at least a handful of "smoking hot" features, or the amount of time saved is more than enough to overcome the time taken for the migration in the first place then it's probably best to stick with what you have.
You can do it slowly. Struts is a MVC framework. The rest of your application (business and data tiers) are classes which can be invoked by action classes. Struts is a plugin based architecture and it is easy for you to define a plugin in struts configuration file.
Take a look at this link. This may help.
With Struts2 security vulnerabilities being exposed and reported often, this task takes on more importance.