Develop Reference

Spring's ORM (hibernate) vs hibernate [closed]

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 7 years ago.
Improve this question
I have used hibernate in my java project where I have used Spring MVC.
I avoided SPRING HIBERNATE because it seemed that it was making my code very tightly coupled. Now, even if I move the app to struts, my service layer would work fine (because I have used the core hibernate , it is not the one that spring provides).
I would like some experienced developer to answer this:
What is the reason of using spring hibernate? I know it provides a number of features but there is a trade off as it really makes your code tightly coupled, you can't re-use the services any where else since they would work based on spring's hibernate api

Spring having 7 different modules each are independent you can use anyone of them or multiple
The core container
Spring context
Spring AOP
Spring DAO
Spring ORM
Spring Web module
Spring MVC framework
you want to know about the ORM integration believe me it doesn't make any tight coupling with your service layer
you can use strut mvc at the same time on service layer spring-orm + hibernate there is no tight coupling, more over spring is providing transaction mgt. hibernatetemplate support, you need not to take care of session and transaction mgt and of course easy integration and configuration.

According to my experience Spring-Hibernate provides:
A template to make 'easy' its configuration
The persistence engine can be used as a dependency, so you can change it whenever you want without modify JPA annotations in your model classes
It's supposed to be much more efficient managing XA transactions
And nothing else ...

well complex question, i could answer it with another question :
What is the reason of using hibernate? I know it provides a number of features but there is a trade off as it really makes your code tightly couple, you can't re-use the services any where else since they would work based on hibernate api.
Why not using direct JDBC and SQL ?
To be more productive on the question : choosing a framework always come with a trade off : being coupled with the framework.
So either the features provided by the framework be worth to pay the trade off or not.

Why do large companies prefer Spring over Java EE? [closed]

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 8 years ago.
Improve this question
While looking for the job, i have attended some job interviews at companies, that work at financial sphere. Every company uses Spring Framework as main framework for development. And almost everywhere I was told 'We need proved and stable technologies, that is why we use Spring.'
I would like to know, as I can't understand, why Spring is more popular and 'safer', than Java EE (for example, Spring MVC is used more, than JSF, while both provide almost the same functionality)?
How it is possible, that native Java EE functionalities are less stable, than third-libraries?

Some reasons:
Spring was already there: J2EE was ugly (no Dependency Injection, no conversion over configuration and lot of scares from EJB2, ouch). Java EE "stole" all good ideas from Spring, and it is in fact lighter and easier than previous versions. But now, everybody already uses Spring. It means a lot of production code, lot of well tested products and so on. In the end, why do people in UK/USA use English units? (There is a huge cost to change)
Spring is lighter: You do not need a heavy Java EE application server, you can deploy your application in a web container such as Tomcat.
Spring offers a ton of features which are not available as Java EE standards, such as Spring Batch or Spring Integration. You can use Spring features with Java EE standards, but it should be supposed Spring works better with Spring, shouldn't it?
Spring Aspect-oriented programming is more flexible and power that Java EE interceptors. You can use third-party AOP with Java EE but you can have this out-of-the-box from Spring.
Spring moves faster. Spring can release often and faster because it is no standard and only one vendor. So, it is not required JCP ballots, approvals, etc. The reaction to market requirements is much faster. Some current examples: cloud, mobile, social computing.
Ironically, I have "got" a lot ideas from:
http://www.kai-waehner.de/blog/2011/11/21/why-i-will-use-java-ee-jee-and-not-j2ee-instead-of-spring-in-new-enterprise-java-projects-in-2012/

While looking for the job, I have attended some job interviews at
companies, that work at financial sphere. Every company uses Spring
Framework as main framework for development. And almost everywhere I
was told 'We need proved and stable technologies, that is why we use
Spring.'
I work in financial domain since several years - so I can speak from my experience.
Many financial service providers I know had a major upgrade to their enterprise software stack at around 2006-2008, at a time when the disillusion about EJBs were at its peak after several unmaintainable and poorly written EJB projects. So in-order to upgrade their system and also to attract developers, they began to re-implement their stuffs in Spring and Hibernate, also it was a logical step for them to start new projects in the state of the art frameworks (which at that time were Spring, Hibernate and Wicket)
But since then financial crisis broke out and not many financial service companies think of investing that much money in new development unless it is very critical. Most do not care whether Java EE 6 or 7 was launched and some of the old arguments do not hold good anymore or so.
So they would like to believe that what they have is safer, faster etc (which may or may not be true)

One thing that makes Spring attractive to developers, especially at big organizations like financial companies, is that it lets them take more control over their middleware. With pure Java EE, developers are at the mercy of an operations group that has very different goals than they have. In many cases operations wants to avoid messing with anything that works, every upgrade is a chance for things to go wrong, and it's not like they're the ones who see the benefits from upgrades, so that makes their choices very conservative. That can mean developers get stuck with obsolete versions of an application server, and if a problem comes up the developers have to work with the vendor's technical support (so you have to convince the vendor you have a problem and reproduce it under the conditions they specify), then coordinate with operations to implement the fix (which of course means justifying your request to an organization with different priorities from you). Developers like to minimize this kind of thing whenever possible.
Having Spring in the application gives the developers more freedom to update more of their infrastructure on their own schedule.

Raw Servlet vs. Spring MVC [closed]

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 8 years ago.
Improve this question
What are the reasons you should build your web application with raw Java Servlets or by using Spring MVC (or any other frameworks)?
Are there exceptions when you should avoid Spring MVC, what are the advantages of doing it with Raw Servlets?

If you're building a really quick and dirty demo that you have no intention of extending later, spring can result in a lot of additional configuration issues (not really if you've done it before, but I always end up fighting with it one way or another), so that might be a time to consider just using plain old servlets. Generally though, anything beyond just a super fast and dirty demo, using some form of MVC framework is going to make life in the future a lot easier and is also in line with best practices. Spring makes things super easy, just have to spend some time on the front end configuring everything.
I should note, there's nothing you can do with java servlets that you can't do with Spring. The big difference is setup time.
Edit: It's worth noting that when I posted this answer, I was unaware of Spring Boot that is actually quite easy to get up an running using either an embedded web server or a more conventional web container. Here's a link to a quick start example: http://projects.spring.io/spring-boot/#quick-start

Servlet technology is used for more generic server side extension for request-response paradigm.
And Spring just uses it for the Web application over HTTP.
And some quote from here:http://www.reddit.com/r/java/comments/29f3ul/why_is_spring_mvc_better_than_servlets_jsp/
Servlets are based upon a low-level API for handling requests and
responses. Web frameworks like Spring MVC are designed to make
building web applications, which handle HTTP requests and responses,
easier. Most Java web frameworks, including Spring MVC, use servlets
behind the scenes.
You CAN use servlets to write a web application, but you'll have to
handle all of the details manually. You'll get very little help with
typical web stuff like validation, REST, request/response body for
JSON, form binding, etc. You will end up writing lot of utility code
to support your web application.
Web frameworks, on the other hand, are designed to make all of this
stuff simple. With Spring MVC, you aren't bothered with manually
handling the request and response even though you can still get access
to them if you need to. Want to return JSON in Spring MVC? Just add a
#ResponseBody annotation and Spring will append it. Want RESTful URLs?
Easy. Input validation? Piece of cake. Want to bind form data to an
object? Simple. With servlets, you'd have to do all of this stuff
manually.
Using raw servlets can be a good learning experience though. It really
helps to clarify how web frameworks make life easy for you!

I have developed projects both with raw servlet and web app framework.
Framework gives you everything, only you need to is to setup and config the env, coding is much more easier. The result is that you will know nothing about web dev.
However, code with raw api and servlet gives you chance to gain experience and be a programmer.

I don't use Spring a lot. But I don't see how would it have big impact on the performance. MVC's can help, but they can create a mess and extra work and frustration.
The old good way is good enough for most projects implemented by one programmer. MVC's could help when there are more than one developer.
I would use a plain servlet/jsp for most projects. If I need reusable components, I use wicket. Servlets goes with JSPs/freemarker/velocity or other template engine for presentation.
If you follow a naming pattern for your Servlets/JSP, I don't think you need Spring MVC.

I find that, with the addition of Spring version 3+, it becomes much more easier to bootstrap a Spring Web application with all the basics. The advantage of Spring MVC is that once you've bootstrapped the application context and the database connection, it becomes incredibly easy to create new controllers and it follows a much more logic architecture that newer developers may actually find easier as they get more familiar with it.
In fact, at my previous place of work, we were in the process of building a Java Servlet Web application, but we found that we had to create our own architecture or spine of the application and that is actually more work. Spring can take care of that which means that developers can get on with the actually application logic instead of worrying about the architecture too much.

Are there any examples/tutorials of using Spring 3.0 with Cassandra as a backend? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
As I had written in title, I am trying to learn Spring 3.0 (I already know Django, Pylons and few simpler MVC frameworks) and try to use Cassandra as a backend for my web application.
Are there any real world examples of doing this? Or maybe some tutorials? I know about the existence of documentation of both technologies, yet I am looking for something "faster" to read and get me rolling.

I'm the author of Hector https://github.com/rantav/hector, the leading java client for cassandra so I would encourage you to have a look at what it has to offer.
While I personally have not been using hector with spring, we did get a few contributions which added spring support. See for example https://github.com/rantav/hector/blob/master/core/src/test/resources/cassandra-context-test-v2.xml and https://github.com/rantav/hector/blob/master/core/src/test/resources/cassandra-context-test-v2-new.xml

If you are already familiar with MVC frameworks then you should be aware that which database/datastore you use in the backend shouldn't impact your MVC application as a whole, or how you structure things - it should only affect your data layer and how it retrieves data.
With Spring MVC, the accepted practice is that you represent your data model as a series of "domain model / classes", which are typically just POJOs to hold your data. "Domain" here means that it is related to your problem domain; so if you have an application which deals with customers ordering things you'd want to have a Customer class, an Order class, etc.
Each of the three layers of your MVC application - the controllers, the service/business logic layer, and the DAO layer interacts with these domain model classes. Since the DAO layer is responsible for retrieving or updating this data in the backend, this means it is the DAO layer which needs to know how to fetch your Customer or Order class from Cassandra, how to update certain Customer fields, etc.
So there is nothing special about how you would build your Spring MVC application itself when using Cassandra or any other "NoSQL" database. You'll just need to provide different implementations of your DAO classes which can communicate with Cassandra.
If you are asking if there are any pre-built Spring utilities that can access Cassandra (or Thrift) then the answer is no, at least as far as what's in Spring 3.0. But this should be pretty simple to write once you have the DAO interface set and all other layers of your application in place.

AFAIK there is no "public" tutorial or example covering Spring (3.0) in conjunction with Cassandra.
So maybe you could look into it :)
I would recommend to start looking at the "template" terminology in Spring (e.g JDBCTemplate and HibernateTemplate) and create something like a "CassandraTemplate".

I don't think there is any cassandra-spring library available. However, you could use Spring to instantiate and configure the bean that talks to Cassandra, and inject that into any other bean you have that requires persistence. That way you can let it benefit from Inversion Of Control and all the facilities the Spring ApplicationContext offers.
That way you can separate the code that is aware of the cassandra datastore from your business logic and use spring.
So, your component that talks to Cassandra will be of the [#Repository][1] stereotype, e.g. it is a Repository, just like a repository that talks, for instance to a JDBC datasource.

I am involved with a project using Spring with Cassandra called Easy Cassandra. A sample is provided here:
https://weblogs.java.net/blog/otaviojava/archive/2013/08/25/run-cassandra-spring-data

Spring vs EJB. Can Spring replace EJB? [closed]

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 8 years ago.
Improve this question
Since Spring is able to use transactions just like EJB. For me, Spring is able to replace the requirement of using EJB. Can anyone tell me what are the extra advantages of using EJB?

Spring was developed as an alternative to EJB right from its inception, so the answer is of course you can use Spring in place of EJBs.
If there's an "advantage" to using EJBs, I'd say that it would depend on the skills of your team. If you have no Spring expertise, and lots of EJB experience, then maybe sticking with EJB 3.0 is a good move.
App servers written to support the EJB standard can, in theory, be ported from one compliant Java EE app server to another. But that means staying away from any and all vendor-specific extensions that lock you in to one vendor.
Spring ports easily between app servers (e.g., WebLogic, Tomcat, JBOSS, etc.) because it doesn't depend on them.
However, you are locked into Spring.
Spring encourages good OO design practices (e.g., interfaces, layers, separation of concerns) that benefit any problem they touch, even if you decide to switch to Guice or another DI framework.
Update: This question and answer are five years old in 2014. It needs to be said that the world of programming and application development have changed a great deal in that time.
It's no longer just a choice between Java or C#, Spring or EJBs. With vert.x it's possible to eschew Java EE altogether. You can write highly scalable,
polyglot applications without an app server.
Update: It's Mar 2016 now. Spring Boot offers an even better way to write applications without Java EE app servers. You can create an executable JAR and run it on a JVM.
I wonder if Oracle will continue to support the Java EE spec. Web services have taken over for EJBs. The EJB solution is dead. (Just my opinion.)

First, let me say it clearly, I'm not saying you shouldn't use Spring but, because you are asking for some advantages, here are at least two of them:
EJB 3 is a standard while Spring is not (it's a de facto standard but that's not the same thing) and this won't change in the foreseeable future. Although you can use the Spring framework with any application server, Spring applications are locked into both Spring itself and the specific services you choose to integrate in Spring.
The Spring framework sits on top of the application servers and service libraries. Service integration code (e.g. data access templates) resides in the framework and is exposed to the application developers. In contrast, the EJB 3 framework is integrated into the application server and the service integration code is encapsulated behind an interface. EJB 3 vendors can thus optimize the performance and developer experience by working at the application server level. For example, they can tie the JPA engine closely to JTA transaction management. Another example is clustering support which is transparent to EJB 3 developers.
EJB 3 is not perfect though, it is still lacking some features (e.g. injection of non managed components like simple POJOs).

Pascal's points are valid. There are, however, the following in favour of Spring.
EJB specification is actually a bit loose, and therefore different behaviours can be observed with different application servers. This will not be true for the most cases, of course, but I've had such a problem for some "dark corners".
Spring has a lot of extra goodies, like spring-test, AOP, MVC, JSF integration, etc. EJB has some of those (interceptors, for example), but in my opinion they are not that much developed.
In conclusion, it depends mainly on your exact case.

Spring is meant to complement EJB, not to replace it. Spring is a layer on top of EJB. As we know, coding of EJB is done using API, which means we have to implement everything in APIs using the Spring framework. We can create boiler-plate code, then just take that plate, add some stuff to it, then everything's done. Internally Spring is connected with EJB -- Spring wouldn't exist without EJB.
The main advantage of using Spring is that there is no coupling at all between classes.