Announcement Announcement Module
Collapse
No announcement yet.
init method in HttpServletBean set as final Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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
    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 :-)

    Comment


    • #3
      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:

      Comment

      Working...
      X