Servlet API doesnt enable it - the whole point of a tomcat integration. A custom web framework would be the alternativr but it is not the goal of OWB.
Le 11 févr. 2017 10:44, "Diego Urenia" <[email protected]> a écrit : > Hi Romain! > > Sorry, my question was not clear indeed. > > The tomcat module can still exist and be an option to people willing to use > the plugin to achieve this purpose. > > What I mean is that we could also have something tomcat plugin free where > we would still gain the ability to inject our beans inside our Servlets, > Filters, etc. (which is not the case nowadays AFAIK) and the reflection > thing was just an example on how to achieve this (replacing the > DefaultInstanceManager for OWB implementation) . I really haven't gotten > that deep in the alternative solution and that's why I am asking why OWB > went for the Tomcat plugin instead of going for a tomcat plugin free > approach or even support both. > > I want to understand because maybe there's a limitation that I could not > see at first. > > > > On Sat, Feb 11, 2017 at 9:44 AM, Romain Manni-Bucau <[email protected] > > > wrote: > > > Hi > > > > Not sure i get it, we need to be tomcat dependent in this module so what > > would be the gain to do reflection? > > > > > > Le 11 févr. 2017 09:37, "Diego Urenia" <[email protected]> a écrit : > > > > > Hello all! > > > > > > While playing with OWB and getting familiar with the codebase I found > out > > > that in order to inject beans in a Servlet we need to bootstrap our > > > application using the OWB Tomcat plugin, which makes our application > > > dependent of the plugin and impossible to deploy it in any other way. > > > > > > I would like to know, out of curiosity, if there's a strong motive to > > have > > > it implemented the way it was having other alternatives that would not > > make > > > us dependent of the plugin, such as using reflection to set the new > > > InstanceManager implemented by OWB. > > > > > > Best regards, > > > Diego Urenia > > > > > >
