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

Reply via email to