Results 1 to 3 of 3

Thread: init method in HttpServletBean set as final

  1. #1
    Join Date
    May 2005
    Location
    Kaprun, Austria
    Posts
    10

    Default init method in HttpServletBean set as final

    Hi

    I am having problems using the DispatcherServlet with the fact that the init method in HttpServletBean is set to final, and the initServletBean in FrameworkServlet is also set to final.

    My problem stems from the fact that the app server I am using, Sybase EAServer, has a bug, whereby if an init method in a servlet takes more than 60s to complete, EAServer jumps in and starts initialising the next servlet in the <load-on-startup> sequence :evil:. This means that my DispatcherServlets are starting before the ContextLoaderServlet is ready to service them, causing all sorts of errors.

    Sybase's suggested workaround was to synchronise the init methods of my servlets (an ugly but effective sledgehammer :roll: ). My approach was to subclass ContextLoaderServlet and DispatcherServlet and override the init method with:

    Code:
        public void init&#40;&#41; throws ServletException &#123;
            synchronized &#40;ServletInitLock.class&#41; &#123;
                super.init&#40;&#41;;
            &#125;
        &#125;
    But this does not work on the DispatcherServlet as all the init methods are final. Putting aside my dislike for making any method final unless overriding it will lead directly to a reversal in the laws of physics and ultimately the complete extinction of all life on earth, I was wondering why the spring code makes so many methods final, making customisation of some behaviour very difficult? (I have run into similar difficulties in other areas of the code)

  2. #2
    Join Date
    Aug 2004
    Location
    San Mateo, CA
    Posts
    1,265

    Default

    Such methods are made final so as not to allow overriding that could corrupt state by preventing the framework completing the steps it needs to complete. E.g. the usage where an overridden method invokes super.sameMethod is very error-prone. What if the caller forgets to make that call? Or makes it at the wrong point?

    Best to report that issue in JIRA and we'll consider it. It might also be good to raise a bug report with Sybase :-)
    Rod Johnson - GM, SpringSource Division, VMware
    http://www.springsource.com
    Spring From the Source

  3. #3
    Join Date
    May 2005
    Location
    Kaprun, Austria
    Posts
    10

    Default

    Thanks for the response. Posting a bug report with Sybase was the first thing I did, as it is all their fault after all! :twisted:

    I just wanted to have a winge, because I reckon if I want to break your implementation, I should have the right to, and any consequences of so doing are my own fault for playing where I shouldn't! :x

    :wink:

Similar Threads

  1. Order of Bean definitions matters?
    By cfuser in forum Container
    Replies: 2
    Last Post: Oct 21st, 2005, 10:29 AM
  2. Spring container fails with no exception
    By naor in forum Container
    Replies: 9
    Last Post: Oct 1st, 2005, 03:39 PM
  3. EHCaching Hibernate
    By dencamel in forum Data
    Replies: 3
    Last Post: Sep 6th, 2005, 09:03 PM
  4. PerformanceMonitorInterceptor
    By tnist in forum AOP
    Replies: 3
    Last Post: Aug 24th, 2005, 01:39 PM
  5. Stack Overflow
    By rayho222 in forum Container
    Replies: 6
    Last Post: May 17th, 2005, 03:42 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •