Getting back to my original question... is there any harm if I make the front servlet async-supported all the time, even though not all my application servlets support asynchronous mode?
Thank you! On Wed, Jul 15, 2015 at 4:55 PM, Rilak Kun <kunri...@gmail.com> wrote: > Thanks Chris for the suggestion, but since our application runs in > OSGi, we need a different mechanism for loading classes/plugins lazily > (and our servlet classes need to be loaded using OSGi class loader). > We are using Equinox servletbridge library, which defines a bridge > servlet I mentioned earlier, for delegating requests to our > application servlets, and doing the tedious job of setting the right > class loader and loading application plugins at the right time. > > In the long run, we should look into a different way of registering > our OSGi servlets which will allow us to control the async mode of > each servlet independently, but this is not a trivial task, so I am > trying to see if there are any possible workarounds meanwhile. > > Any additional feedback or pointers are welcome! > > Rilak > > On Wed, Jul 15, 2015 at 2:31 PM, Christopher Schultz > <ch...@christopherschultz.net> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> Rilak, >> >> On 7/14/15 11:06 PM, Rilak Kun wrote: >>> Our application is running in OSGi. Servlets are contributed via >>> Eclipse extension point, so they can be registered in different >>> plugins without changing the web.xml. >> >> When a servlet is registered, you can map it to a URL at the same time >> programmatically. Modifying web.xml is not necessary. >> >> - -chris >> -----BEGIN PGP SIGNATURE----- >> Comment: GPGTools - http://gpgtools.org >> >> iQIcBAEBCAAGBQJVptEoAAoJEBzwKT+lPKRYln4P/R/Z9dD8RqNo+HXVoNfoRwXe >> NU/XROl0gYsIvioGqfJvPrVQiS4gBWKD81/O2LGNeHBYGNqC5kUdYhtEKS52V1He >> 03H80TIkTB17b2Xv6zknoKjnsxUIBDYe3jn5DIfQvh20jVDr75jWTHKSYh4hGMqc >> LiQpxCotijltA0BDtHFgixH0FVaXQQumh9ylMN7LOMwLDul+8NPrbRrqAobWTs+t >> eS999tK4Uu++qQdXCUXysF9bESWtpkzXeAPuEPEgSQaFaxhVHZwSr74pgD2playt >> /ZKO0u397sMwSyI4uE96B5DlGu5cPNhHknTw7/VKuo4VfYcd4FmSzo9hCV4YRx0n >> qKUi/vnWOAXCvoy1/VCmyrIRttVYSuq29q/8sIRjapDNnszxRJsxy5i5jvHR7xgV >> /HdsPLKw7QbBxMd3jERpc2TWOaAwBq5/XqOXdc9zk6I936gQWZU+ayW49oYg9RL/ >> Ea+jZQsDdLypTCinry3p+5On9FPc9AUblUDhwSYyWrlGpHAyASNgjOiAJIxxEDej >> 2UcOWpfeO9ueJFQba9fyzBVfG+8p+qv8DhBMiBhSE9S8hYK47eVLtACea6aAv0Sb >> APbIg9K5z4LtIu/7M7xaDNHmOxkiqyzJLcBa5wIe461Dfstm20TXUhlHGmamABdk >> 0I5q6RuKTAc9FJa48EvX >> =Kap9 >> -----END PGP SIGNATURE----- >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
