I also tried once to run Wicket on Netty and started making abstractions for all Servlet APIs. But I dropped it exactly for the reason tetsuo noted - too big API breaks.
WicketFilter is a javax.servlet.Filter, so it is normal to be tied to Servlet APIs. Netty/Vert.x/... wont be able to use it anyway. They will have they own entry point. They have to create their own Response/Request impls... Some Wicket components use some javax.servlet.** classes directly, but this is something internal and wont change Wicket APIs. I'm going to fork this repo... On Fri, Jan 18, 2013 at 1:40 AM, tetsuo <[email protected]> wrote: > Isolating Servlet dependencies could potentially ease portlet support, too. > > It won't be an easy task, though. Some of the main classes of the > framework, like WicketFilter, are deeply coupled to the Servlet API. > > But I'm not sure if the benefits out-weight the cost of doing the changes > and probably breaking (once more) compatibility with older versions. > > > On Thu, Jan 17, 2013 at 8:53 PM, Michael Mosmann <[email protected]> > wrote: > > > What i want to know: Is there any chance, that this can succeed? This > will > > change wicket in many places, and i understand, that nobody will accept > > this as an wicket 6.x.y "improvment". Maybe this is the wrong direction, > > maybe the right thing to early, not the best thing we could do now... > > > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com <http://jweekend.com/>
