I configured my servlet to load automatically on start and it is working in the traditonal WebSphere, however when I deploy my application in WLP, my servlet no longer loads automatically.
I found that the Liberty documentation below mentions that WLP default delays the servlet load until it receives a requestion regardless of what is set for load-on-start in the web.xml file. To override this behavior, you must add <webContainer deferServletLoad="false"/> to the WLP server configuration file server.xml, see link :
Adding the option enables my servlet to start automatically in WLP again. I would like to confirm my interpretation of Delay servlet for WLP described in the link above that I can only either automatically start all or non but nothing in between? And that there isn't a way to specify auto start for certain serlvet and not all?
I understand the reason for deplaying the servlet load in WLP is for optimization, but would it defeat the optimization purpose when enabled because it applies to all serlvets in that WLP server? Would it be better to include the original behavior as an option. With this said,serlvet load options will be :
- delay serlvet load (current WLP default behavior)
- dont deploy servlet load (<webContainer deferServletLoad="false"/>)
- obey web.xml setting for load-on-start option which load servlet for all setting with non-negative number and delay for other.
NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
This topic has been locked.
6 replies Latest Post - 2013-03-08T21:57:09Z by SystemAdmin
Pinned topic Deplay Servlet load on WebSphere Liberty Profile
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
bergmark 110000GUM942 PostsACCEPTED ANSWER
Re: Deplay Servlet load on WebSphere Liberty Profile2013-03-07T18:31:36Z in response to SystemAdminThe default deferServletLoad=true effectively prevents the entire web app from initializing until the first request comes in that matches its context root.
I believe the following combinations are all valid and should result in different behavior:
1) deferServletLoad=true, no load-on-start for a servlet
- web app will init upon first request to the context-root, servlet will init upon first request to that servlet
2) deferServletLoad=false, no load-on-start for a servlet
- web app will init immediately, servlet will init upon first request to that servlet
3) deferServletLoad=false, load-on-start positive for a servlet
- web app will init immediately, servlet will init immediately when the app inits
4) deferServletLoad=true, load-on-start positive for a servlet
- web app will init upon first request to the context-root, servlet will init as soon as the web-app inits (request doesn't have to match the servlet)
Re: Deplay Servlet load on WebSphere Liberty Profile2013-03-07T20:32:57Z in response to bergmarkThank you for your quick response.
#3 and #4 applied to my environment because I set the load-on-start for my servlet to a non-negative number (I tried both 0 and 1). #3 is the only one that work in Liberty .
#4 did not work however it works in Traditional WebSphere.
For #4, I even tried to explicitly set the <webContainer deferServletLoad="true"/> and the load-on-start (tried with 0 and 1) and the servlet doesn't load on start.
Is it a bug then?
Re: Deplay Servlet load on WebSphere Liberty Profile2013-03-07T20:58:35Z in response to SystemAdminHello,
Option 4 will still only cause the servlet to load when the web app initializes, which is on first request to the context-root, not on start of the server. If that doesn't happen then it is a bug.
We are looking into options to make this behavior more granular (as you suggest). You can vote for the RFE or add additional comments about what you'd like here: http://ltsgnd001k.sby.ibm.com/developerworks/rfe/execute?use_case=viewChangeRequest&CR_ID=23179
Regards, Alex Mulholland.
Re: Deplay Servlet load on WebSphere Liberty Profile2013-03-08T14:41:53Z in response to SystemAdminHi Alex,
For option 4, it behaves as you described, meaning I have to manually initiate a first request to the context root for the servlet to load. This means the load-on-start setting in web.xml is ignored when it is set to a non-negative value. In Traditional WAS, when this load-on-start is set to a non-negative value, the servlet is loaded and initialized when the server starts.
We currently leaverage the load-on-start setting to load one of our servlet automatically (without initiate the first request to the context root)on server startup/application startup to handle some initialization. This'd been working in the TWAS however it is not working on WLP unless we configure <webContainer deferServletLoad="false"/> . This option would enable all the servlets to load on server start instead of enable only the specified one.
I just want to confirm that currently there isn't a way to configure individual serlvet to load on startup in WebSphere Liberty Profile. If this is the case then I will take your suggestion and add comment to the RFE you included in your reponse.
Re: Deplay Servlet load on WebSphere Liberty Profile2013-03-08T14:51:57Z in response to SystemAdminHi An,
Yes I can confirm that you need to add that configuration to get the servlet to load at server start, and I'm sorry this is causing you a problem. Please add your details/vote to that RFE. I would also encourage you to look at the 'product extension' function in the Liberty 8.5.next beta, which allows you to add your own features to a server. This may provide a more appropriate way to have functions that need to run at server start and to perform initialization for the whole system (for example) rather that having to contain that 'system' function in an application as you do today.
Re: Deplay Servlet load on WebSphere Liberty Profile2013-03-08T21:57:09Z in response to SystemAdminHi Alex,
Yes, We are currently creating user feature for other uses and the initialization being done in one of our OSGi bundle was considered. It is a matter of time.
I also submitted my vote and comments for this in the RFE.
Thank you for your quick response.