Home

News: The Java EE Container Redeploy & Restart Report

  1. The Java EE Container Redeploy & Restart Report (25 messages)

    The Java EE Container Redeploy & Restart Report comes from a survey conducted over the summer, with over 1100 Java EE developer respondents. It analyzes time spent on the Redeploy and Restart process, and compares the following containers: GlassFish, Jetty, Tomcat, WebSphere and WebLogic. Among other results, this report shows that Java EE developers are spending 3 to 7 work weeks a year on redeploys and restarts, depending on their container of choice. http://www.zeroturnaround.com/blog/java-ee-container-redeploy-restart-turnaround-report/

    Threaded Messages (25)

  2. WC Eend[ Go to top ]

    In Holland we have a slogun "Wij van Wc-eend adviseren Wc-eend". Essentially meaning that one should always watch out with advice from a company that benefits from that advice.
  3. Re: WC Eend[ Go to top ]

    Peter, are you publicly accusing me in tampering with the data? Cause I made sure to make both the raw data and my calculations to be available (look for the link to Excel files in the post). The only thing I stripped were the emails, for obvious reasons.
  4. Re: WC Eend[ Go to top ]

    Hi Jevgeni, of course I'm not accusing you of tampering with data. But I always watch out with vendor provided information that claims that their product will solve a lot of problems. Perhaps it is my distrust on sales guys and marketing :) I wish you good luck with your product.
  5. Re: WC Eend[ Go to top ]

    Hi Jevgeni, of course I'm not accusing you of tampering with data. But I always watch out with vendor provided information that claims that their product will solve a lot of problems. Perhaps it is my distrust on sales guys and marketing :)
    Well, I take engineering ethics seriously and would never let our marketing guys do anything like that. It's aggravating that such bad practices are almost a standard in the industry, that's why we go to great length to be as transparent as possible.
  6. Re: WC Eend[ Go to top ]

    In Holland we have a slogun "Wij van Wc-eend adviseren Wc-eend". Essentially meaning that one should always watch out with advice from a company that benefits from that advice.
    We of WC-duck advise you WC-duck! Classic one! :) It's a double edged sword though... in order to sell your own product, you do have to point out the weaknesses in products you're competing with, or in this case you are supplementing. Are SSD vendors allowed to publish reports about the slowness of traditional hard drives and the advantages of SSDs? Probably... Was Rod right to bash J2EE? Maybe... Is Rod right to bash Java EE and advise us to use Spring? Not so sure, the WC-duck argument seems to more applicable there. It's a thin line though...
  7. LOL @ Peter (nt)[ Go to top ]

    no text
  8. 1) Edit your Java files (even with a simple text editor). 2) Refresh your browser. Gain the happiness (even if something went wrong thanks to perfect error pages). 3) Go to 1.
  9. In my experience[ Go to top ]

    The problem is mostly on the The way most people develop for containers is to take the path of least resistance and more coffee breaks: * Make a code change * Build the whole thing, often from scratch (ant|mvn clean package) * Copy to the deployment directory * Restart the application server * Manually test said change Better tooling will automate of this and eliminate unnecessary steps like restarting the server. This is all good. But I think the bigger issue is getting people to unit test their changes using plain Java. For JSF, you're using something like JBoss Seam's testing framework, or for EJB you're using something like JBoss's Embedded EJB container. (I'm guessing there's other tools out there as well from other vendors.) What you should be using your application server for is solving application server configuration issues and packaging mistakes, not actually business logic testing your application. But it's good to see that Java Rebel is capitalizing on laziness, since this is readily in abundance.
  10. Re: In my experience[ Go to top ]

    If you ask me the problem is that this report assumes that during the redeploy the developer is effectively doing nothing which sadly might be the case for the vast majority that are not very productive but for those of us with more experience and/or better practices this time is used productively like thinking about what one is actually doing with the design and code. I also think this report is encouraging developers to not think just act and in a very inefficient manner by redeploying on ever little change rather than batching work together and fixing bugs before they even occur. We need to discourage less deployments and more thinking and analysis. This view is probably strange for the most part but then I have never used a debugger. William
  11. Re: In my experience[ Go to top ]

    There's only so much unit testing you can do at the UI level without getting bogged down by writing too many tests. Plus, the only real test to see that a page renders correctly is to have it served to and rendered on your browser.
  12. Why not use Apache Tomcat and be productive instead of using big massive J2EE app servers like WAS, WLS, JBOSS?.
  13. Why not use Apache Tomcat and be productive instead of using big massive J2EE app servers like WAS, WLS, JBOSS?.
    Maybe because a lot of people actually put things like EJB3, JPA, JTA, JMS and JSF to good use? Are you seriously going to develop anything larger than a few pages on a bare bone Apache Tomcat? (and no, a Tomcat with added libraries for Spring, Struts and Hibernate is not bare bone and is as massive or even more massive than Jboss AS) Can you imagine the horror of putting everything in JSP pages and using nothing but JDBC? Sorry pal, but you clearly live in the past...
  14. Maybe because a lot of people actually put things like EJB3, JPA, JTA, JMS and JSF to good use?
    You dont need App servers to use JSF, JPA or JTA.
    You can check my blog at: http://www.jroller.com/seam The big/complex J2EE server are the reason that freshers (and almost all ecommerce websites) - flock to the easier .Net(which though sucks in maintainence/security ). The only reason you should prefer professional app server is due to support , clustering(though it works fine with tomcat/jboss) and of course JMS(in high load).

  15. The only reason you should prefer professional
    app server is due to support , clustering(though it works fine with tomcat/jboss) and of course JMS(in high load).
    We recently release MuleSoft Tcat Server ( www.mulesoft.com), which is an enterprise Tomcat Server with enterprise class support. There are other vendors who do this as well. The point is that no one has to choose Jboss or WLS or WAS purely for support reasons, there are several companies that do a very good job of supporting Apache Tomcat. For clustering Tomcat, you have tons of choices, same with JMS. Why pay the penalty of EJB and all that other legacy stuff?.

  16. The only reason you should prefer professional
    app server is due to support , clustering(though it works fine with tomcat/jboss) and of course JMS(in high load).


    We recently release MuleSoft Tcat Server ( www.mulesoft.com), which is an enterprise Tomcat Server with enterprise class support. There are other vendors who do this as well.

    The point is that no one has to choose Jboss or WLS or WAS purely for support reasons, there are several companies that do a very good job of supporting Apache Tomcat.

    For clustering Tomcat, you have tons of choices, same with JMS. Why pay the penalty of EJB and all that other legacy stuff?.
    EJB 3 is not legacy. The post talks about Java EE, not sure why you are confused. Tomcat has its place, but to claim that Tomcat can be the be all and end all smacks of arrogance, ignorance and poor experience!
  17. We recently release MuleSoft Tcat Server ( www.mulesoft.com), which is an enterprise Tomcat Server with enterprise class support.
    vs
    The days of using massive, complex App Servers like Jboss, WLS, WAS is over.
    Seems like a clear case of "We of WC-duck advise you WC-duck".
  18. We recently release MuleSoft Tcat Server ( www.mulesoft.com), which is an enterprise Tomcat Server with enterprise class support.


    vs

    The days of using massive, complex App Servers like Jboss, WLS, WAS is over.


    Seems like a clear case of "We of WC-duck advise you WC-duck".
    Its more like "We of WC-duck advice you stick with ducks than bring blue whales to your pond" :) There are other companies that provide support for Apache Tomcat too. The point is that there are options (http://wiki.apache.org/tomcat/SupportAndTraining) to get support for Tomcat, you don't need to take on the complexity of JBoss, WLS or WAS, /s/GlassFish/Oracle AS/g just for support reasons.
  19. The point is that there are options (http://wiki.apache.org/tomcat/SupportAndTraining) to get support for Tomcat, you don't need to take on the complexity of JBoss, WLS or WAS, /s/GlassFish/Oracle AS/g just for support reasons.
    The point is that there are options (JBoss Enterprise Services) to get support for Jboss AS, you don't need to take on the complexity of Tomcat combined with some home brew stack just for support reasons. But give it up Sateesh. I mean seriously, you are a Tomcat support vendor for Christ's sake. Do you seriously think I'm going to believe you on your word when you bring us the lie that one can't be productive with Jboss, and that moving away from Jboss to Tomcat is the best decision we can make? Seems to me such decision is only good for one person, and that's you yourself. I'm sorry, but if I would ever need support for Tomcat, you would really be on the bottom of my list.
  20. We just switched to Jetty in development. Test and production is running with WebLogic (customers choice). We use JSF/MyFaces, Spring, Hibernate. Configuration with Jetty is just adding libraries into classpath and then: new Server(8080).start(); We don't need JavaRebel, plugins or anything other tools to debug or to make changes dynamically to server (which actually starts in 1,5 seconds). Just change Java class or jsp in Eclipse and hit refresh on browser. Setting up Jetty classpath is actually easier than configuring traditional app server (at least in our case). The productivity boost is huge, changes happen just like with php.
  21. @Tomi Have you also set up session serialization/deserialization so that after restart you have not lost state (login, navigating to the page that you were working on)?
  22. SOA[ Go to top ]

    As far as I understood the survey is just about web development and web containers. I totally agree that for web development Tomcat is just fine. I'm on a SOA landscape and there's simply no other way than redeploy to launch the new components/services/etc... hot deploy comes handy but a few shutdowns and restarts every now and then are needed. When the server's restarting I generally do some refactoring on the code or put down some unit test. Going back to web development: UI changes are generally solved using exploded WEB-INF structures on the developer's box which doesn't need the restart other than for config files or libraries. Most of the IDEs (IntelliJ, for instance) allow instant preview for the look & feel of the pages. This -in my opinion- is what requires the majority of the redeploy, cosmetic and make up.
  23. The big/complex J2EE server are the reason
    that freshers (and almost all ecommerce websites) - flock to the easier .Net
    Strange, I'm not seeing this. We have a number of eCommerce customers on .NET, but the overwhelming majority of the big brands are on Java EE, and the small ones are mostly on PHP or similar. Peace, Cameron Purdy | Oracle Coherence http://coherence.oracle.com/


  24. Maybe because a lot of people actually put things like EJB3, JPA, JTA, JMS and JSF to good use?

    Are you seriously going to develop anything larger than a few pages on a bare bone Apache Tomcat? (and no, a Tomcat with added libraries for Spring, Struts and Hibernate is not bare bone and is as massive or even more massive than Jboss AS)

    Can you imagine the horror of putting everything in JSP pages and using nothing but JDBC? Sorry pal, but you clearly live in the past...
    Survey after survey show increasing adoption of Apache Tomcat and it is easy to use exactly what you need. I can understand someone using a J2EE app server due to legacy reasons, but if you have the ability to change, moving to Tomcat is the best decision one can make today. The days of using massive, complex App Servers like Jboss, WLS, WAS is over.
  25. Importance of Turn-Around-Time[ Go to top ]

    IMO the turn-around-time (code, compile, deploy and test) in the development process is a very important thing if you or your team want to be productive. If you have to prototype or if you need to build user interface, you need to see the result directly and without any long running deployment thing. Just "ctrl-s" and "reload your browser". I wrote my experience using Weblogic FastSwap technology in my blog: http://lofidewanto.blogspot.com/2009/09/one-day-in-your-life.html I would like to see other developer's experiences in such technlogies like FastSwap and JavaRebel (JRebel). Cheers, Dr. Jawa.
  26. Another alternative[ Go to top ]

    The costs of slow turnaround time are also in the lost concentration from having to context switch between tasks while waiting for your redeploy to complete, and the risk of taking short cuts (such as bunching up changes and redeploying less often) in order to work more efficiently. As the report makes clear, turnaround time is a big part of the problem with large applications. The other part in my view is being able to structure applications so that you can deploy the bits you need in the right combinations. An alternative which can solve both problems is a dynamic module framework like Impala. Phil Zoio http://www.impalaframework.org