Discussions

EJB design: When not to use Spring framework ?

  1. When not to use Spring framework ? (14 messages)

    Hi All, After reading all the features of Spring, i could see that it can be used at all layers and for all types of Application requirements. Now am interested in knowing when not to use Spring. When and Where it should not be used? Please give me some application requirements where it cannot be used or some components or frameworks with which it should not be used ..

    Threaded Messages (14)

  2. Re[ Go to top ]

    I think that Spring does nothing with clustered environment, you should do clustering manually if you use Spring without Java EE Server. Also, distributed transactions are not implemented in Spring itself; you can use them in Spring, but you should have an JTA implementation outside of Spring itself. IMHO, Spring is a suitable solution for small projects based on Java SE or simple servers like Tomcat.
  3. For very big projects too...[ Go to top ]

    IMHO, Spring is a suitable solution for small projects based on Java SE or simple servers like Tomcat.
    As the founder of the Spring project, I should declare my interest. But it's worth pointing out that one of the strengths of Spring is that it provides the same simple, productive, programming model, regardless of whether you are in an SE environment or a high-end EE environment. Spring performs extremely well in either case. And using Spring does not mean that you have to forgo any of the capabilities of your application server, such as distributed transaction management if you need it. As a case in point, virtually all interbank payments in the UK are processed by a Spring application running on WebLogic. It replaced a large mainframe deployment and significantly outperforms it. You can see the slides from Voca's presentation at the recent SpringOne conference here. This application handles 70m+ payment instructions per day, at up to several thousand per second, and is critical to one of the world's largest economies. The Spring-based solution dramatically outperforms previous attempts to port the project to J2EE technology. Other mission-critical complex applications running on Spring include the French Tax Office's online tax submission system--also a public reference. Spring runs on all web containers and application servers, as well as standalone applications and test environments. Rgds Rod
  4. Spring and Terracotta[ Go to top ]

    Hi, I am using Spring as far I can use it, and yes I also understood that clustering was only for the EJB stuff, not for Spring. But I found recently a product (it does not seems entirely commercial) that permit a Spring application clustering. http://terracottatech.com/terracotta_spring.shtml If Terracotta works well, I will not see a lot of reason not using Spring/Terracotta on a J2EE project... regards, Etienne
  5. Re: Spring and Terracotta[ Go to top ]

    I am using Spring as far I can use it, and yes I also understood that clustering was only for the EJB stuff, not for Spring.
    There is nothing in Spring that prevents you from using the clustering capabilities of a J2EE server, and, as mentioned, there are value added integrations with a number of clustering products.
  6. Re: When not to use Spring framework ?[ Go to top ]

    My experience with Spring is, that it is a big tool-box that offers a lot of features that you can use if you like or ignore if you don't need or like it. Thats the positive thing about it, that (most) features are clearly separated from each other. We, for example, do use Spring in our projects to benefit from it's Hibernate support, component container and some others, but do the frontend with jWic instead of the spring MVC. So my answer to your question is that you should not use it if there is simply no feature you could benefit from. :-)
  7. So my answer to your question is that you should not use it if there is simply no feature you could benefit from. :-)
    I agree. This is what the developers of Spring mean when they say it is "non-invasive". One of the cool things about Spring is that it does not force any real dependencies on the application framework classes. This not only eases the testing of applications but also enables selective use of Spring services. Nitin
  8. In my view, figuring out if your application can run on light weight container or more than light -heavy weight... How do we find : one way is to look at non functional requirements - performance, scalability, failover, backup, concurrent number of users..., cost,... once we do this analysis, it is very easy to judge if it is obviously light weight.... question is for the one which fall on the line...and where do you draw the line... well look for future requirements,... time to market functionality...etc., http://www.jroller.com/page/bhagvank/20050930 Bhagvan K http://www.jroller.com/page/bhagvank
  9. In my view, figuring out if your application can run on light weight container or more than light -heavy weight...

    How do we find : one way is to look at non functional requirements - performance, scalability, failover, backup, concurrent number of users..., cost,...

    once we do this analysis, it is very easy to judge if it is obviously light weight....
    That's probably true. EJB(heavy-weight) can be helpful if we need a truly distributed architecture. But even in that case, a lightweight containter like Spring can be helpful by reducing the complexity involved in accessing EJB. There may be other abstractions provided by the lightweight container, which can eliminate the need for service locators and singletons in the application, which may be beneficial in either case. I guess the true measure of whether we need a lightweight container, Spring in particular, is if we can benefit from any of the services offered by the container.
  10. Correction[ Go to top ]

    My experience with Spring is, that it is a big tool-box that offers a lot of features that you can use if you like or ignore if you don't need or like it.
    This is what I intended to quote in my previous message.
  11. Re: When not to use Spring framework ?[ Go to top ]

    After reading all the features of Spring, i could see that it can be used at all layers and for all types of Application requirements.
    That is a key goal of Spring. It runs in any environment, whether web container, app server, standalone application--even an applet. The container is very lightweight and has a modest footprint and negligible startup time--essentially, the time taken to instantiate the components it contains. So you should only use the Spring features relevant to your requirements, but the aim is that it delivers real benefit in a very wide range of scenarios, and that it is modular so that if you don't want particular features you don't incur any overhead.
  12. Re: When not to use Spring framework ?[ Go to top ]

    I think that a valid questions is 'when to use Spring framework', not 'when not to use it'. If you can see you can fulfill your requirements without adding additional complexity introduced by Spring (such as tons of XML files, dozens of additional libraries etc.) -- just don't use it. Only if you really need it -- because 'everyone uses it' or because your boss tells you to or for some other reason -- do it, but first think what you need, not what you don't need. This is the way to avoid introducing the unnecessary complexity and save a lot of time by spending it on your business problem, not architecture.
  13. Re: When not to use Spring framework ?[ Go to top ]

    If you can see you can fulfill your requirements without adding additional complexity introduced by Spring (such as tons of XML files, dozens of additional libraries etc.) -- just don't use it.
    Just to clear up a common misconception: The Spring core depends on just one additional library, not dozens. (Commons Logging.) The other libraries come into play only if you want to use one of the integrations Spring offers. The goal of these is simplifying your overall experience, so they can be expected to reduce rather than add complexity. Thus, for example, you don't need the iBATIS integration or Quartz integration or Hessian integration if you don't use those products.
  14. Velocity - Webwork + Spring + Hibernate[ Go to top ]

    Hello all, First: I'm new to spring. And I've used Webwork for about a year to develop web application for my site. Recently, we get a requirement develop a new web based application with separate into 3-tier architecture. To Webwork, I'm so confused because they are on thier way to merge to Struct. We have very bad experience with Struct (OMG, my bosses hate Struct) and Spring comes to me. We don't want to use EJBs because EJBs seem too haevy for our application for now. We have plan to apply EJBs in future. We want to use Hibernate to take advantage of it. We want to have our application 3-tier. So, I come to this solution: Velocity - Webwork + Spring + Hibernate. What do you think? Do you know any examples that I can ref to? Thanks alot. Thanh
  15. Can use Spring most of cases.[ Go to top ]

    Hi, I believe you can use Spring almost for any application. We are using Spring in applet too. That is when I begin to have this question. When Spring is used with the web container, we can load the Spring configuration file using ContextLoader configured in web.xml. However, I could not find a way to do it in applet environment. Right now, we are loading it manually with hard coded Spring configuration file name in the code, as follows ApplicationContext ctx = new ClassPathXmlApplicationContext("applicationContext.xml"); myService = (TemplatingService) ctx.getBean("templatingService"); I wonder if there is any more graceful way to do it. Thank you for your suggestion in advance. Brian Ko