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 > > >
