Re: WebappLoader vs WebappClassLoader
Hi Could someone tell me what is the purpose of having WebappLoader and WebappClassLoader in Tomcat? WebappLoader is the Tomcat object that a user can configure that represents the class loader. It remains the same across web application stop/start. WebappClassLoader is the actual class loader. Every time the web application is started, a new instance is created and used. As I understand WebappClassLoader is per web application and WebAppLoader for tomcat server instance. Am I wrong? Yes. Thanks for the quick explanation. So it means WebappClassLoader and WebAppLoader both are per web application. In tomcat 7 we were able to add repository to the class loader using WebAppClassLoader.addRepository() This is replaced in favor of the new resource implementation. Check this [1] and this [2]. Thanks for quick response. I will look into them :) Best Regards 2015-04-21 12:02 GMT+05:30 Violeta Georgieva violet...@apache.org: Hi, 2015-04-21 6:42 GMT+03:00 Thusitha Thilina Dayaratne thusithathil...@gmail.com: Hi, Could someone tell me what is the purpose of having WebappLoader and WebappClassLoader in Tomcat? WebappLoader is the Tomcat object that a user can configure that represents the class loader. It remains the same across web application stop/start. WebappClassLoader is the actual class loader. Every time the web application is started, a new instance is created and used. As I understand WebappClassLoader is per web application and WebAppLoader for tomcat server instance. Am I wrong? Yes. Thanks for the quick explanation. So it means WebappClassLoader and WebAppLoader both are per web application. In tomcat 7 we were able to add repository to the class loader using WebAppClassLoader.addRepository() This is replaced in favor of the new resource implementation. Check this [1] and this [2]. Regards, Violeta [1] http://tomcat.apache.org/migration-8.html#Web_application_resources [2] http://tomcat.apache.org/tomcat-8.0-doc/config/resources.html So in Tomcat 8 if we wanna add repositories to the classloader we should done that trough the WebAppLoader not with WebAppClassLoader? Please correct me if I'm wrong. Thanks Best Regards 2015-04-21 1:51 GMT+05:30 Mark Thomas ma...@apache.org: On 20/04/2015 14:22, Thusitha Thilina Dayaratne wrote: Hi, Could someone tell me what is the purpose of having WebappLoader and WebappClassLoader in Tomcat? WebappLoader is the Tomcat object that a user can configure that represents the class loader. It remains the same across web application stop/start. WebappClassLoader is the actual class loader. Every time the web application is started, a new instance is created and used. As I understand WebappClassLoader is per web application and WebAppLoader for tomcat server instance. Am I wrong? Yes. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- --
Re: WebappLoader vs WebappClassLoader
Hi, 2015-04-21 6:42 GMT+03:00 Thusitha Thilina Dayaratne thusithathil...@gmail.com: Hi, Could someone tell me what is the purpose of having WebappLoader and WebappClassLoader in Tomcat? WebappLoader is the Tomcat object that a user can configure that represents the class loader. It remains the same across web application stop/start. WebappClassLoader is the actual class loader. Every time the web application is started, a new instance is created and used. As I understand WebappClassLoader is per web application and WebAppLoader for tomcat server instance. Am I wrong? Yes. Thanks for the quick explanation. So it means WebappClassLoader and WebAppLoader both are per web application. In tomcat 7 we were able to add repository to the class loader using WebAppClassLoader.addRepository() This is replaced in favor of the new resource implementation. Check this [1] and this [2]. Regards, Violeta [1] http://tomcat.apache.org/migration-8.html#Web_application_resources [2] http://tomcat.apache.org/tomcat-8.0-doc/config/resources.html So in Tomcat 8 if we wanna add repositories to the classloader we should done that trough the WebAppLoader not with WebAppClassLoader? Please correct me if I'm wrong. Thanks Best Regards 2015-04-21 1:51 GMT+05:30 Mark Thomas ma...@apache.org: On 20/04/2015 14:22, Thusitha Thilina Dayaratne wrote: Hi, Could someone tell me what is the purpose of having WebappLoader and WebappClassLoader in Tomcat? WebappLoader is the Tomcat object that a user can configure that represents the class loader. It remains the same across web application stop/start. WebappClassLoader is the actual class loader. Every time the web application is started, a new instance is created and used. As I understand WebappClassLoader is per web application and WebAppLoader for tomcat server instance. Am I wrong? Yes. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --
Help with overriding default cookie name
Hello, I'm trying to override the default cookie name (JSESSIONID) for one of my Tomcat7 instances. I put the following in $catalina_home/conf/context.xml: Context sessionCookieName=MyCookie However, after restarting Tomcat, the setting isn't being applied; the cookie always remains as JSESSIONID rather than MyCookie. My environment is: tomcat 7.0.39, java 1.7.0_79, kubuntu 14.10. Can anyone shed some light on how/where $catalina_home/conf/context.xml is loaded? Or any ideas, suggestions, etc are appreciated. Cheers, Brian Jones Programmer/Analyst Information Technology Services Support Services Building, Suite 4300 Western University (519) 661-2111 x86969 bjone...@uwo.ca - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: File descriptors peaks with latest stable build of Tomcat 7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 4/21/15 10:56 AM, André Warnier wrote: Thomas Boniface wrote: The file descriptor peak show up in our monitoring application. We have some charts showing the number of file descriptors owned by the tomcat process (ls /proc/$(pgrep -u tomcat7)/fd/ | wc -l). The calatalina.out log shows errors, the most frequent being a java.io.IOException: Broken pipe. [..] A broken pipe, from the server perspective while sending a response to the client, is a rather usual thing. It usually means that the (human) client got tired of waiting for a response, and clicked somewhere else in the browser (maybe a cancel button; maybe he closed the window; etc..). In this case, though, the client is nginx and not a human at a browser. If the browser severs the connection to nginx, I'm not sure what nginx does with the connection to Tomcat. I would expect that it either cleans it up nicely (e.g. drains the bytes from the connection, then closes), or just drops the connection to the back-end Tomcat (which might be more efficient if Tomcat is expected to send relatively large responses). I don't know how nginx works when acting as a proxy. Does it use HTTP keep-alive and process many requests through a single connection (possibly not all from the same end user), or does it make and close many connections? If it makes and closes many connections, Tomcat won't hang up the phone unless some kind of timeout occurs. Thomas, I'd advise you to do the following: 1. Check the nginx configuration. Specifically, the keep-alive and timeout associated with the proxy configuration. 2. Make sure that Tomcat's timeouts are appropriate for those matching settings in nginx. It's common for users to misconfigure httpd+Tomcat by settings different timeouts on either side of the connection, and the result is many broken pipe or similar errors on the Tomcat side. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVNpjcAAoJEBzwKT+lPKRYEI0P/A9EtvOwGtfBcnQLEDWt/CSW MPDCHKd4M4TmAvzBqdnJgiSp94cSSmXj46h4xaQViHbg+SrODoJenm4SyEV0b3qb Rx7HwvtsVs0DglTVNGv+ELpDKmeSvzQ0hlEG7dC/AIDDAu7d5ibGBoDxVX8znVRO CGbZll2YWO+oBypdd7EBR70xVXUZryEWyb2E9F6au1yk0XnLEW0RHG4kbycponbc JiUny+z1kAPODK8ZlpLv+6FJ6kdwwMDj+3SxSalETf32dU+FAYTDCf6rCC5bciRv xUctskJQdGuIP/vYyTtIb4xSV3o58HQgqxvaTPciBgr0WOkoQ9+mrcHYGYanzmXd 0FtArB+KtuDFlCfQvt6bhgNX1mvAYQUkk0nZqY4NfabFtq0TSEzUNrxLsvBrvq4m smYImnaZgkCJMwuQeiZO8jNo5WAP24CC/8oP1OilqEf58wKf0v6iwcxGBC5Z+bjD LcfY+SGsEbBToiSwkpOmk+ZJhdqgUnmJ4oGwfeE+fm74h+8GjGuETvYkncmoBxfz Hn7eSELM/dr/NJVFtGsJg6W3zGlsxGKlTflDRteF9RNaeYRd7RrER6zNdVEFkRCw PXYMmpRbdiZddVBUP0qOJSx/9PJytLBmS6wPjZDkRIVUNOGvV4/K3p9pAupJW1Sn bcDLfLdKqkAVcR9o0LIy =GQ5+ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Help with overriding default cookie name
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Brian, On 4/21/15 1:14 PM, Brian Jones wrote: I'm trying to override the default cookie name (JSESSIONID) for one of my Tomcat7 instances. I put the following in $catalina_home/conf/context.xml: Context sessionCookieName=MyCookie That will change the session cookie name for all applications deployed on the server, and not just one web application. Is that what you wanted ? However, after restarting Tomcat, the setting isn't being applied; the cookie always remains as JSESSIONID rather than MyCookie. My environment is: tomcat 7.0.39, java 1.7.0_79, kubuntu 14.10. Can anyone shed some light on how/where $catalina_home/conf/context.xml is loaded? Or any ideas, suggestions, etc are appreciated. I would have expected what you did to work. Do you have a separate CATALINA_BASE as well as a CATALINA_HOME? If so, the CATALINA_BASE/conf/context.xml will *completely override* the one in CATALINA_HOME/conf/context.xml. It would probably be better to set the configuration in your web application's META-INF/context.xml file. Give that a try and see if it gives you the desired effect. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVNppOAAoJEBzwKT+lPKRYo+oP/1E4/xSTSBGjjVC7rZ9LEaQB d70saLAAZPVsR6MFo+v9qdBwaGrN6YYibHUlvgnADtaucuMEmCB9QQzlWeJcvHo5 IAiMDL1bUAr61iNYKgPn/XASUQUNKZ2ZHemWzsMhRF7dJDFylt1aIJk4Igeeyg96 TZ9cEONHdZYMfguH3A5jNkTDbL0YlTvGlDxR9S3qJ1fpTzQJ9Y4xwKwNh/SdxBuE VPR0dBrbFEPPnxF33v9gXKroPELWQgc/648qz119WNWNy5+x8SWe2MfcE7XTTPTD BJjj8UzxY17gWRs+s+OQydBM5xv8+UNm1oR21mjRglLiyQG5lLe9eeRi5JgoHM3I lQXmQX8bJdqBQN0VfxkWt9NxZAE+8XuYIwEYKQXCnfDYgkbL6N6ph5VV/RU7iL12 aJcoo7QtSTtVGmsB64HBJEt88v/WXnOIQ92ckfYtfgyefSWF7wqsVaAks6I5qUV9 5jjSYGzv2jl2AEhHiUv5vHTRo85z0Eq7DI1qtqLTFFNoaaNyYpvUlIfRgzWz0+AR 8/+zO7gPwOyhqUB+rVHehA3nIb9IsiXNUABw2gdcNwvziX1F1RfLbTUq9uTKfUNa G6cllAqoTZi/LUtn2HHK2oGh/HWYOpHM0VOlMmQ9m1mSgVTpJF1vF0Qto3WlGOEp FRZRlGreI9G5QfXUvS0X =/g1r -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: WebappLoader vs WebappClassLoader
Hi,
Could someone tell me what is the purpose of having WebappLoader and
WebappClassLoader in Tomcat?
WebappLoader is the Tomcat object that a user can configure that
represents the class loader. It remains the same across web application
stop/start.
WebappClassLoader is the actual class loader. Every time the web
application is started, a new instance is created and used.
As I understand WebappClassLoader is per web application and
WebAppLoader
for
tomcat server instance. Am I wrong?
Yes.
Thanks for the quick explanation.
So it means WebappClassLoader and WebAppLoader both are per web
application.
In tomcat 7 we were able to add repository to the class loader using
WebAppClassLoader.addRepository()
This is replaced in favor of the new resource implementation.
Check this [1] and this [2].
Previous Implementation was
@Override
protected void startInternal() throws LifecycleException {
..
for (String repository :
webappClassloadingContext.getProvidedRepositories()) {
addRepository(repository);
}
super.startInternal();
..
}
Now I tried to add the required repositories as follows now
@Override
protected void startInternal() throws LifecycleException {
..
if(webappClassloadingContext.getProvidedRepositories().length 0){
File dir = new
File(webappClassloadingContext.getProvidedRepositories()[0]);
WebResourceRoot resources = getContext().getResources();
resources.addJarResources(new DirResourceSet(resources,
/WEB-INF/lib, dir.getAbsolutePath(), getContext().getPath()));
getContext().setResources(resources);
}
super.startInternal();
..
}
But I'm getting
org.apache.catalina.LifecycleException: Failed to start component
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/jaxrs_basic]]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:725)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:701)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:717)
at
org.wso2.carbon.tomcat.internal.CarbonTomcat.addWebApp(CarbonTomcat.java:344)
at
org.wso2.carbon.tomcat.internal.CarbonTomcat.addWebApp(CarbonTomcat.java:189)
at
org.wso2.carbon.webapp.mgt.TomcatGenericWebappsDeployer.handleWebappDeployment(TomcatGenericWebappsDeployer.java:258)
at
org.wso2.carbon.webapp.mgt.TomcatGenericWebappsDeployer.handleWarWebappDeployment(TomcatGenericWebappsDeployer.java:207)
at
org.wso2.carbon.webapp.mgt.TomcatGenericWebappsDeployer.handleHotDeployment(TomcatGenericWebappsDeployer.java:174)
at
org.wso2.carbon.webapp.mgt.TomcatGenericWebappsDeployer.deploy(TomcatGenericWebappsDeployer.java:139)
at
org.wso2.carbon.webapp.mgt.AbstractWebappDeployer.deployThisWebApp(AbstractWebappDeployer.java:204)
at
org.wso2.carbon.webapp.mgt.AbstractWebappDeployer.deploy(AbstractWebappDeployer.java:111)
at
org.wso2.carbon.webapp.deployer.WebappDeployer.deploy(WebappDeployer.java:42)
at
org.apache.axis2.deployment.repository.util.DeploymentFileData.deploy(DeploymentFileData.java:136)
at
org.apache.axis2.deployment.DeploymentEngine.doDeploy(DeploymentEngine.java:807)
at
org.apache.axis2.deployment.repository.util.WSInfoList.update(WSInfoList.java:144)
at
org.apache.axis2.deployment.RepositoryListener.update(RepositoryListener.java:377)
at
org.apache.axis2.deployment.RepositoryListener.checkServices(RepositoryListener.java:254)
at
org.apache.axis2.deployment.DeploymentEngine.loadServices(DeploymentEngine.java:135)
at
org.wso2.carbon.core.CarbonAxisConfigurator.deployServices(CarbonAxisConfigurator.java:567)
at
org.wso2.carbon.core.internal.DeploymentServerStartupObserver.completingServerStartup(DeploymentServerStartupObserver.java:51)
at
org.wso2.carbon.core.internal.CarbonCoreServiceComponent.notifyBefore(CarbonCoreServiceComponent.java:235)
at
org.wso2.carbon.core.internal.StartupFinalizerServiceComponent.completeInitialization(StartupFinalizerServiceComponent.java:185)
at
org.wso2.carbon.core.internal.StartupFinalizerServiceComponent.serviceChanged(StartupFinalizerServiceComponent.java:288)
at
org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:107)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:861)
at
org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
at
org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
at
org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:819)
at
org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:771)
at
Re: File descriptors peaks with latest stable build of Tomcat 7
I guess I get what you mean. Do you know if the same kind of explanation applies to these ? Apr 20, 2015 12:11:05 AM org.apache.coyote.AbstractProcessor setErrorState INFO: An error occurred in processing while on a non-container thread. The connection will be closed immediately java.nio.channels.AsynchronousCloseException at java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:205) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:496) at org.apache.tomcat.util.net.NioChannel.write(NioChannel.java:128) at org.apache.tomcat.util.net.NioBlockingSelector.write(NioBlockingSelector.java:101) at org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.java:174) at org.apache.coyote.http11.InternalNioOutputBuffer.writeToSocket(InternalNioOutputBuffer.java:163) at org.apache.coyote.http11.InternalNioOutputBuffer.flushBuffer(InternalNioOutputBuffer.java:242) at org.apache.coyote.http11.InternalNioOutputBuffer.endRequest(InternalNioOutputBuffer.java:121) at org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:762) at org.apache.coyote.Response.action(Response.java:174) at org.apache.coyote.Response.finish(Response.java:274) at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:319) at org.apache.catalina.connector.CoyoteWriter.close(CoyoteWriter.java:112) at networkComm.commands.HttpCommand.sendResponse(HttpCommand.java:224) at com.stickyadstv.adex.AuctioneerResponseWriter.respondToClient(AuctioneerResponseWriter.java:322) at com.stickyadstv.adex.BidSerializationListener.checkSerializationIsComplete(BidSerializationListener.java:70) at com.stickyadstv.adex.BidSerializationListener.completed(BidSerializationListener.java:53) at com.stickyadstv.adex.bidder.marketplace.MarketPlaceBidSerializationWriter.respondToClient(MarketPlaceBidSerializationWriter.java:92) at com.stickyadstv.adex.BidSerializationListener.checkSerializationIsComplete(BidSerializationListener.java:70) at com.stickyadstv.adex.BidSerializationListener.completed(BidSerializationListener.java:53) at com.stickyadstv.adex.BidSerializationListener.completed(BidSerializationListener.java:24) at org.apache.http.concurrent.BasicFuture.completed(BasicFuture.java:115) at com.stickyadstv.adex.bidder.internal.InternalBid.serializeAsVAST(InternalBid.java:56) at com.stickyadstv.adex.bidder.marketplace.MarketPlaceBid.serializeAsVAST(MarketPlaceBid.java:151) at com.stickyadstv.adex.AuctioneerResponseWriter.completed(AuctioneerResponseWriter.java:120) at com.stickyadstv.adex.Auctioneer.bangTheGavel(Auctioneer.java:521) at com.stickyadstv.adex.Auctioneer.close(Auctioneer.java:236) at com.stickyadstv.adex.Auctioneer.checkCompletion(Auctioneer.java:195) at com.stickyadstv.adex.Auctioneer.registerBuyerPlatformResponses(Auctioneer.java:178) at com.stickyadstv.adex.bidder.openrtb.OpenRTBBuyerRequest.flagAllAsNotParticipating(OpenRTBBuyerRequest.java:428) at com.stickyadstv.adex.bidder.openrtb.OpenRTBBuyerRequest.setBidResponse(OpenRTBBuyerRequest.java:139) at com.stickyadstv.adex.bidder.openrtb.OpenRTBBidRequestAsyncListener.completed(OpenRTBBidRequestAsyncListener.java:27) at com.stickyadstv.adex.bidder.openrtb.OpenRTBBidRequestAsyncListener.completed(OpenRTBBidRequestAsyncListener.java:12) at org.apache.http.concurrent.BasicFuture.completed(BasicFuture.java:115) at org.apache.http.impl.nio.client.DefaultClientExchangeHandlerImpl.responseCompleted(DefaultClientExchangeHandlerImpl.java:173) at org.apache.http.nio.protocol.HttpAsyncRequestExecutor.processResponse(HttpAsyncRequestExecutor.java:355) at org.apache.http.nio.protocol.HttpAsyncRequestExecutor.responseReceived(HttpAsyncRequestExecutor.java:230) at org.apache.http.impl.nio.client.LoggingAsyncRequestExecutor.responseReceived(LoggingAsyncRequestExecutor.java:112) at org.apache.http.impl.nio.DefaultNHttpClientConnection.consumeInput(DefaultNHttpClientConnection.java:254) at org.apache.http.impl.nio.client.InternalIODispatch.onInputReady(InternalIODispatch.java:73) at org.apache.http.impl.nio.client.InternalIODispatch.onInputReady(InternalIODispatch.java:37) at org.apache.http.impl.nio.reactor.AbstractIODispatch.inputReady(AbstractIODispatch.java:113) at org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:159) at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:338) at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:316) at org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:277) at
Re: File descriptors peaks with latest stable build of Tomcat 7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Thomas, On 4/20/15 8:11 AM, Thomas Boniface wrote: I have tried to find help regarding an issue we experience with our platform leading to random file descriptor peaks. This happens more often on heavy load but can also happen on low traffic periods. Our application is using servlet 3.0 async features and an async connector. We noticed that a lot of issues regarding asynchronous feature were fixed between our production version and the last stable build. We decided to give it a try to see if it improves things or at least give clues on what can cause the issue; Unfortunately it did neither. The file descriptor peaks and application blocking happens frequently with this version when it only happens rarely on previous version (tomcat7 7.0.28-4). Tomcat is behind an nginx server. The tomcat connector used is configured as follows: We use an Nio connector: Connector port=8080 protocol=org.apache.coyote. http11.Http11NioProtocol selectorTimeout=1000 maxThreads=200 maxHttpHeaderSize=16384 address=127.0.0.1 redirectPort=8443/ The default maxConnections is 1, so nginx can open that many connections before Tomcat starts to refuse them. How are you observing the file descriptor peak? Are you getting errors ? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVNlhgAAoJEBzwKT+lPKRYMWIQAKWiP7T8HkZq0L9SmqmZr3rv DrlWBVXBq21M3/e0P3MNEnKp73SbZtq82i6Ib58cjBi6DMQQJTGisdb1WUqNkxWL f0J0fizl5wwDho9FJzxHzR/uV3Nm67Bx7QzvroEEyAmE/wRXdFFOlq/rSdKWfVDC jlBE5Seo+AQiURCONEZ9CYHPwm50yeSy9JzGuH1VXcfUTl0NVXS63vOjLp8XeJKO 68jT6CuY5uzjvv6ZXeES73zvcthkCbF1/Si1KSVshQ/+aXAFDJDuXLLx0D7PWNV7 N6jxVeHOoTdogYtfVyuOhQ4Xu6d9d9NddKC1ycMBeRfJP/5zG3YXHAbDdwWP8Sc7 ip9Md6Y+KA089bRhQ92+6kWqWqtxx1Rg1lhRPkY9nOFc5kEFFsWT8NIEIVWtaN80 zcanU29juMtJK/+Ov/vwyHljTxOikl2So3l19K2bBaCa1pDQ+NeKRQq4KISLlfjB 05w88zu7uS8gYbf+uiw/TMZte1skT8tR3AD1Ye5XRV22zz+yKy6Z7nAdGg/bvIug 8ngVWAQ7mxWt6QAtLRMFS4nw+xBNNNRyMYzvFEkZ6d6Wr67SnQXxRKqAIf8nhZ3h tqAnU0iXlhrdQCcVsMq/iv9lMgHo2x1NBNfeClkIz3XDvgVDJBbHNAr49WmlC5/H 3xUS2AOTCIJNuK+W1CTm =i7t2 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: File descriptors peaks with latest stable build of Tomcat 7
The file descriptor peak show up in our monitoring application. We have some charts showing the number of file descriptors owned by the tomcat process (ls /proc/$(pgrep -u tomcat7)/fd/ | wc -l). The calatalina.out log shows errors, the most frequent being a java.io.IOException: Broken pipe. Apr 20, 2015 12:11:02 AM org.apache.coyote.AbstractProcessor setErrorState INFO: An error occurred in processing while on a non-container thread. The connection will be closed immediately java.io.IOException: Broken pipe at sun.nio.ch.FileDispatcherImpl.write0(Native Method) at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) at sun.nio.ch.IOUtil.write(IOUtil.java:65) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487) at org.apache.tomcat.util.net.NioChannel.write(NioChannel.java:128) at org.apache.tomcat.util.net.NioBlockingSelector.write(NioBlockingSelector.java:101) at org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.java:174) at org.apache.coyote.http11.InternalNioOutputBuffer.writeToSocket(InternalNioOutputBuffer.java:163) at org.apache.coyote.http11.InternalNioOutputBuffer.flushBuffer(InternalNioOutputBuffer.java:242) at org.apache.coyote.http11.InternalNioOutputBuffer.flush(InternalNioOutputBuffer.java:94) at org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:801) at org.apache.coyote.Response.action(Response.java:172) at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:363) at org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:331) at org.apache.catalina.connector.CoyoteWriter.flush(CoyoteWriter.java:98) at networkComm.commands.HttpCommand.sendResponse(HttpCommand.java:223) at com.stickyadstv.adex.AuctioneerResponseWriter.respondToClient(AuctioneerResponseWriter.java:322) at com.stickyadstv.adex.BidSerializationListener.checkSerializationIsComplete(BidSerializationListener.java:70) at com.stickyadstv.adex.BidSerializationListener.completed(BidSerializationListener.java:53) at com.stickyadstv.adex.BidSerializationListener.completed(BidSerializationListener.java:24) at org.apache.http.concurrent.BasicFuture.completed(BasicFuture.java:115) at com.stickyadstv.adex.bidder.openrtb.OpenRTBBid.serializeAdm(OpenRTBBid.java:158) at com.stickyadstv.adex.bidder.openrtb.OpenRTBBid$AdmReceived.completed(OpenRTBBid.java:310) at com.stickyadstv.adex.bidder.openrtb.OpenRTBBid$AdmReceived.completed(OpenRTBBid.java:254) at org.apache.http.concurrent.BasicFuture.completed(BasicFuture.java:115) at org.apache.http.impl.nio.client.DefaultClientExchangeHandlerImpl.responseCompleted(DefaultClientExchangeHandlerImpl.java:173) at org.apache.http.nio.protocol.HttpAsyncRequestExecutor.processResponse(HttpAsyncRequestExecutor.java:355) at org.apache.http.nio.protocol.HttpAsyncRequestExecutor.inputReady(HttpAsyncRequestExecutor.java:242) at org.apache.http.impl.nio.client.LoggingAsyncRequestExecutor.inputReady(LoggingAsyncRequestExecutor.java:87) at org.apache.http.impl.nio.DefaultNHttpClientConnection.consumeInput(DefaultNHttpClientConnection.java:264) at org.apache.http.impl.nio.client.InternalIODispatch.onInputReady(InternalIODispatch.java:73) at org.apache.http.impl.nio.client.InternalIODispatch.onInputReady(InternalIODispatch.java:37) at org.apache.http.impl.nio.reactor.AbstractIODispatch.inputReady(AbstractIODispatch.java:113) at org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:159) at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:338) at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:316) at org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:277) at org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:105) at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:584) at java.lang.Thread.run(Thread.java:745) Here a count made on Exception: 304 java.io.InvalidClassException: com.stickyadstv.web.commands.request.RequestData; incompatible types for field time 6477 java.io.IOException: Broken pipe 1 java.io.IOException: Connection reset by peer 3 java.lang.NullPointerException 821 java.nio.channels.AsynchronousCloseException 12 java.nio.channels.ClosedChannelException 1 - locked 0xa503aa38 (a java.lang.NumberFormatException) 21 org.apache.catalina.connector.CoyoteAdapter$RecycleRequiredException I have uploaded a portion of the catalina log during the test I made:
Re: File descriptors peaks with latest stable build of Tomcat 7
Thomas Boniface wrote: The file descriptor peak show up in our monitoring application. We have some charts showing the number of file descriptors owned by the tomcat process (ls /proc/$(pgrep -u tomcat7)/fd/ | wc -l). The calatalina.out log shows errors, the most frequent being a java.io.IOException: Broken pipe. [..] A broken pipe, from the server perspective while sending a response to the client, is a rather usual thing. It usually means that the (human) client got tired of waiting for a response, and clicked somewhere else in the browser (maybe a cancel button; maybe he closed the window; etc..). The browser would then immediately close the connection with the server, and when the server eventually tries to write anything else to that connection, the broken pipe exception would be the result. With the numbers you quoted previously regarding the number of simultaneous client sessions, it doesn't look extraordinary that this would happen regularly. Maybe the thing to investigate here is whether your server is really so slow in answering clients, that a significant portion of them do get tired of waiting and get an irresistible urge to click elsewhere.. Apart from the human client, browsers themselves have a built-in timeout for waiting for a server response, and will themselves give up after a while. That is on the order of 4-5 minutes after sending the request and not receiving anything from the server in response. Some applications are such that they can sometimes take more than that to be able to send a response. In such cases, to avoid the browser timeout (and connection close), there are tricks to use, to send intermediate kind of wait message to the browser, so that it does not hang up. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Help with overriding default cookie name
Chris, thanks for getting back to me! I'm trying to override the default cookie name (JSESSIONID) for one of my Tomcat7 instances. I put the following in $catalina_home/conf/context.xml: Context sessionCookieName=MyCookie That will change the session cookie name for all applications deployed on the server, and not just one web application. Is that what you wanted ? Yes, this is what I'm after. I'm working on an enterprise application which is comprised of over 70 webapps all working together. I need to change it for everything, as they all obey a single cookie. However, after restarting Tomcat, the setting isn't being applied; the cookie always remains as JSESSIONID rather than MyCookie. My environment is: tomcat 7.0.39, java 1.7.0_79, kubuntu 14.10. Can anyone shed some light on how/where $catalina_home/conf/context.xml is loaded? Or any ideas, suggestions, etc are appreciated. I would have expected what you did to work. Do you have a separate CATALINA_BASE as well as a CATALINA_HOME? If so, the CATALINA_BASE/conf/context.xml will *completely override* the one in CATALINA_HOME/conf/context.xml. I don't believe so, output from ./shutdown.sh: Using CATALINA_BASE: /opt/apache-tomcat-7.0.39 Using CATALINA_OWL: /opt/apache-tomcat-7.0.39 Using CATALINA_TMPDIR: /opt/apache-tomcat-7.0.39/temp Using JRE_HOME:/usr/lib/jvm/java-7-openjdk-amd64 Using CLASSPATH: /opt/apache-tomcat-7.0.39/bin/bootstrap.jar:/opt/apache-tomcat-7.0.39/bin/tomcat-juli.jar It would probably be better to set the configuration in your web application's META-INF/context.xml file. Give that a try and see if it gives you the desired effect. The problem with doing this, is that as the application is open source, modifying each subtool's context.xml would fork me from the community. The only reason I'm trying to accomplish this, is because I have two versions of the application running in two different Tomcats; one is the community version, one is my institution's localized/modifyied version. I need to be able to run both simultaneously for comparison purposes. However, because both Tomcats/applications are using the same JSESSIONID as the cookie name, if I start a session on one Tomcat, it invalidates the session on the other. Anything else you can think of? Do you perhaps know how/where Tomcat is loading up the $catalina_home/conf/context.xml file? If that is known, I can perhaps modify (hack) it to point explicitly to the context.xml file that I have the sessionCookieName set. Thanks again, Brian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache Tomcat jk connector 400 bad request
hi there, Another bit of information I wanted to add. The apache error log is peppered with the following line : OpenSSL : I/O error, 5 bytes expected to read on BIO#... Warm Regards Razi A. Ansari From: Razi Sent: Tuesday, April 21, 2015 8:37 AM To: users@tomcat.apache.org Subject: Apache Tomcat jk connector 400 bad request Hi there, I would like to explain my scenario, perhaps this has been answered on this forum. A bunch of random Ajax requests from the browser (IE9) end up with a 400 error code on the apache webserver and the the browser hangs for 5 minutes. Httpwatch shows the error code as ERROR_INTERNET_CONNECTION_RESET and then immediately afterwards IE fires the same request again, which shows up with a time taken of 5 minutes and error code as ERROR_HTTP_INVALID_SERVER_RESPONSE. The browser recovers after 5 minutes. Further investigation on the webserver and appserver logs reveals the following:: a.. The request comes from the browser and hits the webserver and then forwards to the appserver instantly. b.. The mod_jk log for the request shows that there is time duration of 5 minutes spent in the ajp_read_fully_server::jk_ajp_common.c(1399): enter. After 5 minutes I get the next line as follows ajp_read_fully_server::jk_ajp_common.c(1432): exit. Then in the next line i see the following ajp_send_request::jk_ajp_common.c(1766) worker 11 browser stop sending data, no need to recover. Later it shows unrecoverable 400, request failed. c.. The forensic.log show the content length as a nonzero value. d.. The applcation server log hangs in the org.apache.coyote.ajp.AjpProcessor.read method for 5 mintues and the continues the execution. The thread dump also confirms this. The questions I have are:: a.. Is this a problem with IE only because of the keepalive timeout and the apache webserver keepalive time(current value is set to 5seconds) out which is not in sync. b.. Is this a problem with the appserver not able to process requests that are bad/incomplete. c.. Should I increase the Apache webserver timeout value to 60s or more , will this have any performance impact. Kindly advise on the scenario. Many thanks for reading through. Current setup: Apache 2.2.24 Mod_jk 1.2.37 Redhat Linux VM JBoss EAP 6.1.0 JSF 2.1, Richfaces 3.3.4 Warm Regards Razi A. Ansari
Re: File descriptors peaks with latest stable build of Tomcat 7
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 4/21/15 10:56 AM, André Warnier wrote: Thomas Boniface wrote: The file descriptor peak show up in our monitoring application. We have some charts showing the number of file descriptors owned by the tomcat process (ls /proc/$(pgrep -u tomcat7)/fd/ | wc -l). The calatalina.out log shows errors, the most frequent being a java.io.IOException: Broken pipe. [..] A broken pipe, from the server perspective while sending a response to the client, is a rather usual thing. It usually means that the (human) client got tired of waiting for a response, and clicked somewhere else in the browser (maybe a cancel button; maybe he closed the window; etc..). In this case, though, the client is nginx and not a human at a browser. If the browser severs the connection to nginx, I'm not sure what nginx does with the connection to Tomcat. Nginx has no way to know that the client dropped the connection (the client-receiving part of it), until Nginx tries to send some data (presumably coming from Tomcat) to the client browser and finds no listener anymore. When that is the case, presumably Nginx closes its own receiving part connected to Tomcat, which propagates the error to Tomcat. (Buffering of all kinds neglected here). I would expect that it either cleans it up nicely (e.g. drains the bytes from the connection, then closes), or just drops the connection to the back-end Tomcat (which might be more efficient if Tomcat is expected to send relatively large responses). I don't know how nginx works when acting as a proxy. Does it use HTTP keep-alive and process many requests through a single connection (possibly not all from the same end user), or does it make and close many connections? I don't know how Nginx works precisely, but it must have all kinds of settings to tune such behaviours in function of the circumstances. If the back-end Tomcat application works under a Windows NTLM-like authentication mechanism e.g., then using different connections for the same client (or vice-versa, sharing some connections between different clients) would play havoc with said AAA mechanism, which is connection-oriented. This seems to say that Nginx, by default, buffers the entire back-end server response before starting to send it to the client : http://nginx.com/resources/admin-guide/reverse-proxy/ But it also says that this can be tuned, and even disabled. It also hints at the fact that even if the client specifies keep-alive with Nginx, nginx itself, when dealing with the back-end server, disables the keep-alive (Connection: close). This probably makes sense, in a scenario where the client may think that all responses come from the same back-end server, but Nginx in the middle distributes the requests to several back-end servers. It would make no sense in that case to use keep-alive with the back-end servers, which may only ever see one request each from that client. If it makes and closes many connections, Tomcat won't hang up the phone unless some kind of timeout occurs. Thomas, I'd advise you to do the following: 1. Check the nginx configuration. Specifically, the keep-alive and timeout associated with the proxy configuration. 2. Make sure that Tomcat's timeouts are appropriate for those matching settings in nginx. It's common for users to misconfigure httpd+Tomcat by settings different timeouts on either side of the connection, and the result is many broken pipe or similar errors on the Tomcat side. I'll +1 all that in any case. The OP has a complex setup, where we are not even sure that the various connections in various states are even related directly to Tomcat or not. Graphically, we have this : client -- TCP -- nginx -- TCP -- Tomcat -- webapp -- TCP -- external servers The output of netstat shows all the connections and their state, at the OS level. Even assuming that nginx runs on a separate host, that still leaves the possibility that most of the connections in CLOSE_WAIT state for example, would be connections between the webapps and external servers, having not much to do with Tomcat per se. But of course they use fd's and resources, just like the others. And for lsof, they would appear as belonging to the Tomcat process. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cluster - Session replication error: Unable to apply diff
Fixed at r1675020. 2015-04-20 16:18 GMT+09:00 Keiichi Fujino kfuj...@apache.org: This NPE has been caused by that apply the diff data to a ReplicatedMapEntry that has not set a MapOwner. Usually, ReplicatedMapEntry always has to have the MapOwner. I think this is probably a bug. Please open Bugzilla entry. I will scrutinize the code. 2015-04-20 15:04 GMT+09:00 Keiichi Fujino kfuj...@apache.org: Hi Are there other error or exception in your log? Please show us your cluster configuration in your server.xml. e.g. - What is mapSendOptions? - Which Interceptor do you use? 2015-04-15 3:55 GMT+09:00 Théo Chamley theo...@mley.fr: Hello, I have a working Tomcat 8.0.15 cluster with 3 members with the BackupManager as session manager. The session replication is mostly working except in a few cases. In those cases, I get the following error: 09-Apr-2015 12:16:58.369 SEVERE [Tribes-Task-Receiver-6] org.apache.catalina.tribes.tipis.AbstractReplicatedMap.messageReceived Unable to apply diff to key:3B286B4C7CA060163A00988969D21923 java.lang.NullPointerException at org.apache.catalina.ha.session.DeltaSession.applyDiff(DeltaSession.java:164) at org.apache.catalina.tribes.tipis.AbstractReplicatedMap.messageReceived(AbstractReplicatedMap.java:664) at org.apache.catalina.tribes.group.GroupChannel.messageReceived(GroupChannel.java:293) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81) at org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.messageReceived(TcpFailureDetector.java:112) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81) at org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor.messageReceived(ThroughputInterceptor.java:89) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81) at org.apache.catalina.tribes.group.ChannelCoordinator.messageReceived(ChannelCoordinator.java:260) at org.apache.catalina.tribes.transport.ReceiverBase.messageDataReceived(ReceiverBase.java:240) at org.apache.catalina.tribes.transport.nio.NioReplicationTask.drainChannel(NioReplicationTask.java:206) at org.apache.catalina.tribes.transport.nio.NioReplicationTask.run(NioReplicationTask.java:97) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) I was able to replicate the problem with a scenario in the application, but I was not able to understand the underlying problem. This happens when the user is making a very specific request and this request arrives on a Tomcat where his session is not stored, forcing the Tomcat to fetch the session elsewhere. The 3 tomcats are on the same network with a very low network latency. Does anybody has some advice on how to debug this problem? For now, I got around it with sticky sessions on mod_jk, but I find this very unsatisfactory. Thank you in advance for your help, //Théo -- Keiichi.Fujino -- Keiichi.Fujino -- Keiichi.Fujino
Re: [Tomcat8] What happened to WebappLoader.addRepository()?
On 21/04/2015 05:59, Thusitha Thilina Dayaratne wrote:
Hi,
Try addURL().
Sorry for the inconvenience.
As I understand addURL() method is defined in WebAppClassLoaderBase. So
should I obtain the WebAppClassLoaderBase using getClassLoader() method
and
use reflections to call the addURL() method?
No need for reflection. Cast to URLClassloader.
Note the cast *should* always work but if someone is using a strange
custom class loader it will fail. Note that Tomcat 7 required the class
loader to be an instance of WebappClassLoader.
Thanks for quick explanation Mark.
But still addURL() method is defined as protected. So it is not possible
to call that method by casting right?
This is my implementation with Tomcat 7
public class CarbonWebappLoader extends WebappLoader {
@Override
protected void startInternal() throws LifecycleException {
WebappClassloadingContext webappClassloadingContext;
try {
webappClassloadingContext =
ClassloadingContextBuilder.buildClassloadingContext(getWebappFilePath());
} catch (Exception e) {
throw new LifecycleException(e.getMessage(), e);
}
for (String repository :
webappClassloadingContext.getProvidedRepositories()) {
addRepository(repository);
}
super.startInternal();
//Adding the WebappClassloadingContext to the WebappClassloader
((CarbonWebappClassLoader)
getClassLoader()).setWebappCC(webappClassloadingContext);
}
In Tomcat 8 don't have addRepository() in the WebAppLoader. Suggestion was
to use addURL() method.
But that can be access through WebAppClassLoader. So I must get the
classloader using getClassLoader() and use reflections to call addURL
method.
That would be really costly operation since it will get call for each and
every application.
Is there a better approach than that? Or Should I move this logic to
somewhere else?
It is worth considering other options. E.g.
a) Use the WebResources to map the JARs into WEB-INF/lib
b) Cache the method object so reflection calls are faster.
c) Ignore the performance issue since it only occurs on application start
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [Tomcat8] What happened to WebappLoader.addRepository()?
Hi,
On 21/04/2015 05:59, Thusitha Thilina Dayaratne wrote:
Hi,
Try addURL().
Sorry for the inconvenience.
As I understand addURL() method is defined in WebAppClassLoaderBase. So
should I obtain the WebAppClassLoaderBase using getClassLoader() method
and
use reflections to call the addURL() method?
No need for reflection. Cast to URLClassloader.
Note the cast *should* always work but if someone is using a strange
custom class loader it will fail. Note that Tomcat 7 required the class
loader to be an instance of WebappClassLoader.
Thanks for quick explanation Mark.
But still addURL() method is defined as protected. So it is not possible
to call that method by casting right?
This is my implementation with Tomcat 7
public class CarbonWebappLoader extends WebappLoader {
@Override
protected void startInternal() throws LifecycleException {
WebappClassloadingContext webappClassloadingContext;
try {
webappClassloadingContext =
ClassloadingContextBuilder.buildClassloadingContext(getWebappFilePath());
} catch (Exception e) {
throw new LifecycleException(e.getMessage(), e);
}
for (String repository :
webappClassloadingContext.getProvidedRepositories()) {
addRepository(repository);
}
super.startInternal();
//Adding the WebappClassloadingContext to the WebappClassloader
((CarbonWebappClassLoader)
getClassLoader()).setWebappCC(webappClassloadingContext);
}
In Tomcat 8 don't have addRepository() in the WebAppLoader. Suggestion was
to use addURL() method.
But that can be access through WebAppClassLoader. So I must get the
classloader using getClassLoader() and use reflections to call addURL
method.
That would be really costly operation since it will get call for each and
every application.
Is there a better approach than that? Or Should I move this logic to
somewhere else?
Thanks for the response.
It is worth considering other options. E.g.
a) Use the WebResources to map the JARs into WEB-INF/lib
I've tried to do so as follows.
File dir = new File(webappClassloadingContext.getProvidedRepositories()[0]);
WebResourceRoot resources = getContext().getResources();
resources.addJarResources(new DirResourceSet(resources, /WEB-INF/lib,
dir.getAbsolutePath(), getContext().getPath()));
getContext().setResources(resources);
But then I get IllegalStateException
org.apache.catalina.LifecycleException: Failed to start component
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/jaxrs_basic]]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
Mail Thread -
http://mail-archives.apache.org/mod_mbox/tomcat-users/201504.mbox/%3CCANVncXDD7h49OztF=6a3u=+MR7=_wkdssjyvqh98kios8zq...@mail.gmail.com%3E
What did I do wrong here?
b) Cache the method object so reflection calls are faster.
c) Ignore the performance issue since it only occurs on application start
I was able to fix that by overriding the addURL method and use that to add
repositories.
Thanks
Best Regards
2015-04-21 16:43 GMT+05:30 Mark Thomas ma...@apache.org:
On 21/04/2015 05:59, Thusitha Thilina Dayaratne wrote:
Hi,
Try addURL().
Sorry for the inconvenience.
As I understand addURL() method is defined in WebAppClassLoaderBase. So
should I obtain the WebAppClassLoaderBase using getClassLoader() method
and
use reflections to call the addURL() method?
No need for reflection. Cast to URLClassloader.
Note the cast *should* always work but if someone is using a strange
custom class loader it will fail. Note that Tomcat 7 required the class
loader to be an instance of WebappClassLoader.
Thanks for quick explanation Mark.
But still addURL() method is defined as protected. So it is not possible
to call that method by casting right?
This is my implementation with Tomcat 7
public class CarbonWebappLoader extends WebappLoader {
@Override
protected void startInternal() throws LifecycleException {
WebappClassloadingContext webappClassloadingContext;
try {
webappClassloadingContext =
ClassloadingContextBuilder.buildClassloadingContext(getWebappFilePath());
} catch (Exception e) {
throw new LifecycleException(e.getMessage(), e);
}
for (String repository :
webappClassloadingContext.getProvidedRepositories()) {
addRepository(repository);
}
super.startInternal();
//Adding the WebappClassloadingContext to the WebappClassloader
((CarbonWebappClassLoader)
getClassLoader()).setWebappCC(webappClassloadingContext);
}
In Tomcat 8 don't have addRepository() in the WebAppLoader. Suggestion
was
to use addURL() method.
But that can be access through WebAppClassLoader. So I must get the
classloader using getClassLoader() and use reflections to call addURL
method.
That would be really costly operation since it will get call for each and
every application.
Is there a better approach than that? Or Should I move this logic to
somewhere else?
It is worth considering other options. E.g.
a) Use the WebResources
