I requested Spring / Spring Security, etc training at work, and the bosses want to hire someone who knows Spring to come work with us as a consultant so that we'll learn Spring from a real-world perspective instead of a training perspective.
I've been tasked with coming up with questions of various difficulty to ask potential hires in order to ascertain their Spring ability. The problem is that I don't fully understand Spring yet (hence the training request).
What questions would you ask someone to determine their Spring ability, and what level of knowledge would someone have to have of Spring to answer them? (I need 2 "easy" questions, 2 "medium" questions and 2 "hard" questions, specifically, but I'll take anything you guys have).
I suggest to hire someone who is a 'SpringSource Certified Spring Professional' if you can do that or at least someone who has completed the 'Core Spring' course.
As for the questions, there are some easy/medium sample questions (with answers) on the certificate page.
During the interview I would ask the candidate to explain some real-world situations where, how and why he/she has used Spring before.
Easy: Spring originally arose as a reaction to what technology? How does its philosophy compare?
Easy: Describe a situation where you improved a project with Spring? Which parts of Spring did you use?
Medium: Describe the facets of an application for which Spring supplies a solution. (looking for: dependency injection, transactions, distributed computing, etc)
Here an easy one : What is Dependency Injection ?
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am new to Spring and I want to clarify something about it. I developed an application for student management, for private institutes. It can record student details (address, phone number, enrolled courses, grade etc...), course details, payments from students, report generating module, details about lectures etc.,
However, I didn't use much of AOP to develop this app, except for rare cases like logging. But Spring AOP is a big part in Spring according to my knowledge. My question is, is AOP a big part of spring or am I missing the places where I should have used it (I am guessing I made newbie mistake of not using AOP much)? If so, can you clarify me where I should have used these concepts, so that I can learn from my mistake.
My view is that AOP is great if you are building a framework (like spring), as it allows the framework to implement cross cutting code that doesn't greatly impact the users of the framework, for example in spring:
#Transactional
This one line of code in a service class invokes significant transaction management functionality.
However, for normal web-apps (for example), custom aspects should be used sparingly because:
they are less readable
an advanced technique, so not all developers will be familiar with them
tooling not fully supported (eg checkstyle, PMD, findBugs dont work with aspects), see: Code Analysis Tools and Inter-Type-Declarations
I think I've actively used AOP in only a handful of projects over the years. In my work with Spring I use it rarely compared to most of the other Spring features. As such, I'm aware of it and what it can do, but I don't worry that I'm not ticking that particular box.
It's useful to understand what it is, and what it can do for you. However Spring is doing work for you already that leverages this, and you're likely to be using it already without knowing it! Being aware of AOP and how it works is the major issue here. As such, it sounds like you have this covered.
AOP is a big part in Spring according to my knowledge
Yes it is,
As you are already using AOP for logging, for better understanding of AOP read here on aop
Basically aop increased you modularity of application by separation of cross-cutting concerns.
such as it helped you lot at the time of transaction management logging etc.
AOP in spring is used:
To provide declarative enterprise services such as declarative transaction management
To allow users to implement custom aspects.
source
For my understanding you can use transaction management in your application. as you are maintaing the records of students, course, fee etc associated with students.
Spring AOP used to tracking entire activity of user in large business applications. More like logging using AOP we can identify user consumed classes and methods and if any error occurs in any method, developers or customer helpers can identify problem soon and can give solution soon than reading log files.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
JEE6 vs. Spring 3 stack
Let I’m going to develop a mission critical application which will be massively transaction based. I will do it with Java. Now I have to choose the technology. My application must be scalable, good performing, code must be maintainable and I want to get long term ROI. First thing, I’m going to choose framework. As a framework, spring comes at first in my mind. But I know there are more like EJB3 or anything. Now my question, what should I choice, EJB3 with JPA or spring framework with Hibernate. I know every technology have tradeoffs. Can anyone help me to make good choice? And one thing to make clear, I’m still learner.And I want to know advantage and disadvantage of EJB and spring framework too. Thanks
And I want to know advantage and disadvantage of EJB and spring
framework too
Both are light and POJO based, and you could get a good picture from similar threads. You might find that many of the pain-points that existed with EJB 2.x are no longer there.
'EJB' might simplify things for you
If your application would need distributed transactions started by remote clients
If your application is message-driven
Now my question, what should I choice, EJB3 with JPA or spring
framework with Hibernate.
Also look at adding CDI to the stack ( i.e EJB3.x + JPA + CDI ) and then compare with (Spring + Hibernate)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm working on development of a social web application using Java. I need to develop the frontend/GUI of my application for web browsers.
I'm wondering what is the better strategy to do frontend development, whether using frameworks like JSF 2.0 & like OR simply following MVC approach with servlets and JSPs ?
As I have heard JSF really makes the development simpler but also the learning curve is not too low, so is it worth learning JSF or I should prefer to directly proceed with servlets/JSPs ?
I'm new to web applications development using Java & I've almost completed writing the business logic for the application.
Please justify your answer on the basis of following parameters:
Performance & costs
Ease of Development & Time (considering the learning time as well)
Future Maintenance of code
Any other parameters you consider important
Update (07-09-2012):
I finally went with JSF-2.0 & have no regrets till date. Learning curve is not steep. It's easier & development is fast with component libraries like Primefaces. There are some costs as to state saving but those things can be handled intelligently. Community is big & things are well documented now. Hopefully, in near future Stateless JSF is also coming which will boost JSF with extra high performance.
For a hobby webapp, homebrewing some MVC framework is not bad. It's a nice learning exercise tour. However, it will bite you on the long term, for sure if you publish on the web and it becomes popular. Most of existing MVC frameworks are very well thought out. Most of the unforeseen caveats are taken into account. The sole framework API is well maintained and documented by a third party.
Also, whenever your webapp becomes popular and you need more developers to work on it to fulfill the enduser requirements/wishes, it's easier to find someone who's already familiar with an existing framework. With a homebrewed and possibly buggy MVC framework, you'll likely find less developers who are eager enough to dive into another learning curve before taking over the maintenance which they'll probably never reapply on their future jobs/projects.
This does not specifically apply on JSF, but on every other existing and popular MVC framework as well, such as Spring MVC. As to JSF in general, well, I've written a lot about it before here. Here are some good starting points to read the one and other about it:
JSF versus plain HTML/CSS/JS
JSF adoption and popularity
What are the disadvantages of JSF 2.0?
For modern web apps like yours, and if your responsibility is the UI, you really don't want any "abstraction layer" stand between you and your html/css/javascript. Don't use any "component" framework.
I have heard JSF really makes the development simpler
Did you hear that from real webapp developers who actually used JSF in real products? Or just JSF committee patting their own backs? Or some old timers' wishful thinking that they don't need to learn the darn javascript?
If you choose JSF, please report your experience back to us after you shoot yourself out of frustration.
It's better use some MVC framework.
You can use either component based framework:
JSF = mostly standard, but its hard to learn and a lot of people don't like itTapestry = quite big and probably good framework
Wicket, GWT - smaller component based frameworks, handy, powerful, smart, but I haven't used them yet
Or you can use request oriented framework.
Spring MVC, Struts 2 = They are very similar. Spring MVC have probably better documentation
Struts - I do NOT recommend this, when you can use Struts 2, or Spring MVC - you can trust me in this point
Each framework have its pro-and-con it depend on situation and your knowledge. I cannot give you single-valued answer.
Spring MVC is very easy to learn and if you have a simple web app and you want to save your time, its better than JSF.
However if your web app is not so simple, JSF beats Spring MVC by far. Its model is more complicated, but it is much better structured and it is widely supported, so that you don't have to reinvent the wheel again in most of the cases. Complex gui can done with JSF with less effort.
You might want to consider Tapestry 5 if you're exploring options. We've been happily using it for many years on a large project in the social media space. It's an easy to use MVC framework that's component based. We're able to develop rapidly with it, especially now that we've built up a lot of our building blocks.
Learning time is probably on par with ramping up on any new framework. I'd perhaps say it's less than JSF and more than Spring MVC, though it really depends on what you're already familiar with and how deeply you use things. I put together a very small project on github a while back to get started with Tapestry 5 quickly, if you're interested it's tapstack.
As for long term use of a Tapestry based application, it has served us well. Maintenance of the code has been much better than when were using JSP. It's very stable as well. We've served billions of page views through Tapestry without any major problems.
On the downside it is less common than some other web frameworks. It is definitely a little different too. We feel it's worth it though, and refreshing to work with. Ultimately it's going to depend on what you need and what you feel works best for you. Best of luck with your decision.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm a java developer, not seasoned, but I am familiar with most concepts reasonably well.
I recently built a website using Tomcat/JSP (~30 dynamic pages). I made the newbie mistake of including large sections of core logic in the JSP, using the rationalization that it's "just a simple project".
I learned the hard way. So I'm re-building the app now in google app engine using servlets and planning to use Velocity to implement it using a Model-View-Controller design pattern.
I'm also looking at Struts, but haven't used the framework before.
Can someone convince me why I should incorporate struts into this project? Is it really going to buy me a lot for a medium sized project of one or two people?
There is a clear cost in an extra learning curve with strut, will the benefits outweigh the costs? Or will the use of Velocity be enough to segregate the logic? Opinions?
I would look longer term than this project. As you saw, first time you use any technology is largely about making mistakes and learning from them. So this first project won't likely be a shining example of Struts usage once you're done.
Using Struts (and Tiles from what you indicate was a main concern: JSP copy and paste) will however be an excellent delve into "proper" MVC, i.e. it forces you to do things in a particularly structured way, and one which I happened to appreciate a lot, I was a big Struts fan.
That said, there are other options, e.g. Spring contains Spring MVC plus much much more. If you're going to invest in overcoming a learning curve, think about which framework will most benefit you overall in the medium term: which frameworks do employers in your area tend to look for, for example? At this point in time, I would go with Spring where I feel the momentum is but Struts is very good at what it does.
If you're going to learn a framework then I'd recommend Spring MVC over Struts. The learning curve isn't too steep and there are lots of Spring resources available on the internet.
Once you've got Spring in place you will find your application is much simpler to maintain and support. You'll also be able to add enhancements, like security, a lot easier.
First: don't let the name confuse you: Struts2 and Struts are very different frameworks.
Second: changing from JSP to Velocity can be a good or bad decisition, but that's not exactly the point. The point is to switch away from Model1 (rather ancient nomenclature, but still useful). That is, decoupling your view layer from your logic layer. (You can use JSP or Velocity for your view layer).
Furthermore, to decide your view layer is just a part of your architecture: you still must decide who will process the request and produce the data that will be sent to the view. The most basic option is to use plain servlets, but, again, it's better to use some framework. For this, there are a lot of frameworks in Java. The "action based" ones are a subset among them, perhaps the most simple to learn. Among them, the oldest is Struts; today the most used for new projects are (in no particular order) Struts2 , Spring MVC and Stripes - they are quite similar.
Learning to separate the logic is excellent. You can do that without using Velocity, Struts or any framework whatsoever, and you'll likely learn more about what it takes to do this separation if you try it with minimal help first.
Learning a framework (in fact multiple frameworks) is also worthwhile, but I wouldn't personally choose Struts as a first framework unless it's the one used by your employer or a prospective employer. If your employer is using Struts, I hope it's Struts 2, as Struts 1 is getting ancient.
The framework I like to work with the most is Wicket, but it's a radical shift from what you're currently looking at. SpringMVC is also definitely worth a look.
If your employer is already doing web development in Java using a framework, try to learn the framework that's actually in use, and ask your co-workers for help learning it.
Why you should learn Struts? My answer is: because employers often require knowledge of it, especially for maintaining of older projects. I didn't make any precise measurements, but I think that at my region JSF and Struts are used for web application development most often.
Struts is a quite old web framework, and it's quite clumsy to write modern AJAX GUIs with it, so there were created better frameworks. JSF is for me a bit less clumsy, but also has some problems. My favourite web frameworks are Vaadin and GWT, but I'm not suggesting anything for you - you should make the decision by yourself.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
We're trying to determine how to implement a simple plugin framework for a service we are implementing that allows different types of calculators to be "plugged-in".
After reading a number of posts about Java plugin frameworks, it seems like the most common options are:
OSGI
"Rolling your own" plugin framework
The Java Plugin Framework (JPF)
The Java Simple Plugin Framework (JSPF)
OSGI seems to be more than we need.
"Rolling your own" is ok but it would be nice to reuse a common library.
So we're down to the JPF and JSPF. JPF doesn't seem to be in active development anymore.
JSPF seems very simple and really all we need. However I haven't heard much about it. I've only seen one post on StackOverflow about it. Does anyone else have any experience with JSPF? Or any other comments on this design choice?
Update: There isn't necessarily a correct answer to this.. however we're going to go with Pavol's idea as we need just a really, really simple solution. Thanks EoH for the nice guide.
(Disclaimer: I am the author of JSPF, so better take my comment with a grain of salt ;-)
The main reason I started with the JSPF was because I had the same problem as you have now: I was looking for a simple solution to make my thesis-project 1) extensible and 2) give it a more or less clear code structure.
The reason why I haven't decided to use an existing framework was because most of them were so heavyweight to start with, that I got lost in reading documentation and was almost forgetting my original task. So, according to your statement
We're trying to determine how to
implement a simple plugin framework
for a service we are implementing that
allows different types of calculators
to be "plugged-in".
I'd think that you could give JSPF a shot and see how far you come within one or two hours.
However, the final decision also depends a bit on what exactly you want to achieve, and the specific circumstances.
I have heard positive results from a number of individuals who have been using it to structure their projects or load plugins in their projects. On the other hand, I also know of one person in our department who discarded it again because he didn't feel it was mixing well with his programming style.
So, to answer your question briefly (and surely in a biased way), I would use
OSGi for projects and teams
which are large and have many people working on it
that justify the overhead of setting up the infrastructure
in need of the specific services offered
JPF for projects and teams
of medium size (?, honestly I am not sure about the project / team size they are targeting)
which are in need of more structured facilities to organize their code, like XML configurations, detailed plugin lifecycle management, extensible plugins ...
JSPF for projects and teams
of small size, following an agile paradigm
that just need something that works out of the box, without the need of configurations or setup
willing to sacrifice some features for simplicity
I hope you find the plugin framework most suitable for your scenario. And, no matter what you try, I would be happy to hear about your results.
If you are planning to have just one (or only a few) not very complex 'extension points' than perhaps a well-defined SPI and a piece of configuration might be sufficient. No need to use a plugin framework.
By piece of configuration I mean some mechanism to find your plugins. For example something like META-INF/services/ or simply listing your plugins in a configuration file.
More details (upon request):
SPI = Service Provider Interface, an "implementer-side equivalent of an API". To learn more try searching for a difference between API and SPI. However in this context it is just a fancy term for an interface to be implemented by your plugins (i.e. defines the contract for your plugins).
A nice, short article "Creating a Service Provider Interface" by Ethan Nicholas describes how to create your own SPI in similar way as it is done in several part of the Java Platform itself.
META-INF/services/ can be seen as a more generalized approach to creating SPIs. More information can be found in the respective section of the JAR File Specification.
If you need a really simple solution, try jin-plugin. It is a minimalistic plugin framework for Java and PHP.