Tag Info

Hot answers tagged

48

What does the Spring framework do? Should I use it? Why or why not? Spring is a framework that helps you to "wire" different components together. It is most useful in cases where you have a lot of components and you might decide to combine them in different ways, or wish to make it easy to swap out one component for another depending on different ...


37

First, what is dependency injection? Simple. You have a class, it has a private field (set to null) and you declare a public setter that provides the value for that field. In other words, the dependency of the class (the field) is being injected by an external class (via the setter). That's it. Nothing magical. Second, Spring can be used without XML (or ...


32

Since other posts here mention the upside, I'll mention the negative aspects of Spring. Even with these negatives, Spring is omnipresent in its niche, reliable, and works as advertised. So, on to the negatives: Enormous: I wouldn't like to put jars with 3000 classes into my little hobby project. There are some descriptions of it as slower than some other ...


13

First of all, your understanding of dependency injection is not fundamentally wrong, but quite different from what most people mean when they use the term. What you describe is a rather strange and unconventional way to achieve testability. I'd advise you to move away from it, as other developers will be rather puzzled by that kind of code. Dependency ...


11

The Maven file structure may help with this In essence the Spring configuration files (that can have any name by the way, not just the generic applicationContext.xml) are treated as classpath resources and filed under src/main/resources. During the build process, these are then copied into the WEB-INF/classes directory which is the normal place for these ...


11

For earlier versions of both the frameworks book authors were saying that if we keep configuration in xml files then it will be easier to maintain (due to decoupling) and just by changing the xml file we can re-configure the application. Back then annotations didn't exist. People hated the XML files, and Java got a horrible reputation because of them. ...


10

I would suggest doing neither. Trying to enforce a technical layering with a package structure leads to a lot of entanglement in your application. Not to mention the fact that we try so hard to hide everything behind a service interface and the first thing we do (mostly due to packaging) is make everything a 'public class'. This becomes painful when there ...


9

There are very few downsides to Spring I thought long and hard in order to find any serious downsides to using Spring, and I'm afraid I've failed. Spring is an excellent toolkit within the JEE/OSGi models. It provides a wide range of non-invasive templates that greatly simplify working with the often cumbersome supporting APIs provided by application ...


9

For why do you want to use Spring, You can read it on http://www.wrox.com/WileyCDA/Section/Why-Use-the-Spring-Framework-.id-130098.html In summary : J2EE applications tend to contain excessive amounts of "plumbing" code. Many code reviews repeatedly reveal a high proportion of code that doesn't do anything: JNDI lookup code, Transfer Objects, ...


9

At jClarity we've definitely followed this approach. We have a 'pure' HTML5 front end - AngularJS, HTML, CSS and a host of Javascript micro frameworks which is a separate project to the backend - vert.x with a variety of verticles coded in separate JVM languages as appropriate. The trick is to have a well defined messaging API between the two that is tested ...


9

Many of the Gang of Four Design Patterns are really just workarounds in Object Oriented languages for mechanisms that are already available in Functional languages. Consequently, the best languages for design patterns (from a productivity standpoint) are the ones that don't require them. If you don't need the pattern, then you don't have to spend any time ...


8

The EJB 3+ frameworks are actually pretty good as they came along with JPA as an answer for annotation configured Persistence frameworks, as well as CDI which allows for annotation configured dependency injection. You also add on top of that Weld. Spring on the other hand is just now catching up in the game with configuration through annotation. With that ...


8

An architecture is the the abstract design concept of an application. Basically, a structure of the moving parts and how they're connected. A framework is a pre-built general or special purpose architecture that's designed to be extended. If an architecture is the design of a structure, a framework is the architecture of a foundation. Frameworks are ...


8

In its broadest sense, a "transaction" is a group of actions that should be performed as if they were a single "bulk" action. The term is most often used in the context of databases, but it can be applied to many kinds of programs (particularly ones that implement a command pattern). When we're talking about databases, and often even if we aren't, we want ...


7

If you've got a good grasp of HTML, CSS, and JavaScript, you have a leg up on many people who end up doing web development. The concepts behind JSP are very similar to PHP. The quirks are different. A servlet is the name for a chunk of Java code that serves a request. That's it really. The whole original Struts framework was a single servlet. I would ...


7

You're right, Spring is inappropriate for the use case you listed. Spring is better used for managing external dependencies (like plugging a JDBC connection into a DAO) or configurations (like specifying which database type to use). In your example, if the bean type was liable to change, then you'd use an interface to specify the bean, and instantiate the ...


7

I don't think that article is implying that every method should should be logged that way, it's just saying when you're logging make sure you capture the context in which the log occurred. For example, if you have a log which says only "User cannot be found", if you're actually trying to understand the scenario which lead to that log then you probably need ...


6

Used to be we wrote simple, efficient, fast applications and web services using just core Java, Servlets and JSP, html and xml, JDBC API. It was good enough; JUnit was a good tool to test. We rested easy that our code worked. Hibernate came along to simplify SQL and enable true mapping of Database tables with Java objects, allowing hierarchical ...


6

You need to try to understand the software from an architectural perspective. That's going to be hard to do studying stack traces. I would start by laying out the classes in a UML diagram. Struts is an MVC framework, so the project is probably an MVC one. Find out what all of the frameworks are, and analyze your class layout to determine the role each ...


6

Well, the key here is familiarity. IMHO, the only way to achieve familiarity is by practice- use Spring, Hibernate, etc. and you will increase your knowledge about them. One of the strengths of the Java ecosystem is the great number of libraries/frameworks which come with great documentation- Spring's reference manual is excellent and reading it will teach ...


6

I would say that just by reading your analysis, you're saying there are alot of static methods and singletons. Static methods shouldn't be an issue by themselves, but if they're being used to proxy calls to the singleton objects, I would work on making those either rock solid, or replacing them with a more sane object model. Static methods are useful for ...


6

First of all, transaction management should be done on service layer, not on DAO layer as that would create a lot of performance overhead (to deal with appropriate transaction isolation level and propagation at each different method). Also, the scope of a unit of work comes from the service layer instead of the data access layer: imagine performing a ...


6

It should be in a Service Layer. public interface UserService { public void findByLogin(final String userName); } And in a Service implementation : public class UserServiceImpl implements UserService { @Inject private UserRepository userRepository; public User findByLogin(final String userName, final String password) { ...


6

Not at all. In my opinion, if used sparingly, it's actually one of the most useful patterns you'll find. It's an easy way to solve otherwise extremely difficult problems. Sure, every criticism is true, but to be honest, I'm willing to deal with a little bit of a bad pattern in an otherwise well designed application / framework that follows the other, better ...


5

You probably should have unit tests and integration tests. In the unit tests, you test for example your controllers/services in isolation. To achieve that, you may use for example a mocking framework such as Easymock or Mockito to cut the dependency to the database. Your integration tests should go the whole way, from your controllers/services right to the ...


5

I'd use Spring (or another DI system) between layers, direct instantiation within layers. So a class that creates a bean that leaves the scope of that class, to some (functionally) external system, possibly defined by that system or some communications layer, would be created through DI. Another bean created purely for internal use within the application ...


5

Spring aims to provide you a framework where there is "convention over configuration". However the reality is that Spring applications do need a certain amount of configuration. In the Spring 2.5.x and earlier versions, the common idiom was to provide this configuration via XML. With Spring 3.0+, the idiomatic way is to use annotations (something that Java ...


5

Anything you put into the Spring XML is static and compiled into the binary. If there is some information which can change, it is always a good idea to externalize it into a properties file. Spring can read the properties file and then use the values as inputs to its beans. You need to use a concept called the property placeholder to inject these ...


5

I think an important factor is who your service clients are. If your service layer is just an architectural boundary between layers in your own project, and the service client is within the same trust realm, then its ok to relax things, and let unchecked exceptions bubble out to the controller layer, or the service client. However, for public facing code; ...


4

one interesting thing that Martin Thompson mentions in this article is that spring can have a non-trivial impact on GC times: Keep call stacks reasonably small. Still more work to do here. If you are crazy enough to use Spring, then check out your call stacks to see what I mean! The garbage collector has to walk them finding reachable objects. -Martin ...



Only top voted, non community-wiki answers of a minimum length are eligible