Grzegorz Kossakowski wrote: > > After exploring code for a while I came to conclusion that I need to > implement stub implementation of HttpServletRequest, HttpServletResponse > and ServletContext that will forward to Cocoon's corresponding classes. Hmm, or the other way round - if the tests would create httpservlet classes first, perhaps the current cocoon environment wrappers could just be used to wrap them.
> > Additionally, I've read /[RT] Ditching the environment abstraction/ > thread[1] where Daniel proposed to switch to standard servlet interfaces > from Cocoon's own ones. I've seen that several folks were rather > reluctant[2][3] to allow these changes. There were concerns raised[4] > that some methods in our interfaces has no counterparts in Servlet API > interfaces. > > Since ProcessInfoProvider operates on interfaces from Servlet API I > wonder if community's standpoint changed to date. > > Carsten, it was you who introduced ProcessInfoProvider interface, could > you comment? > It's a long time ago....well, the basic idea was that, as Daniel pointed out in the mentioned thread, there are a lot of libraries/code out there which require servlet classes (req/resp/context) are required. The ProcessInfoProvider is a bean which just delivers these and does internally the required wrapping or unwrapping. In addition this creates a migration path as new stuff can be written which depends just on the servlet api and the bridge to the old stuff is this info provider. I totally agree that we should remove our own environment as soon as possible, but this would create a lot of incompatibilities (as outlined in one of those threads). The biggest is that req.getSession() returns a o.a.c.e.Session currently and with switching to the servlet api it becomes a httpsession. Personally I would strongly suggest to leave this stuff as it is and release 2.2 and see what happens. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
