On 7/30/07, Daniel Fagerstrom <[EMAIL PROTECTED]> wrote:
> Carsten Ziegeler skrev:
> > Grzegorz Kossakowski wrote:
+100
>
> So to summarize, it would be a great benefit to let our environment
> abstractions extend the http servlet ones and the cost would be low. So
> it is time to do it.
>
--
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
"A lot of incompatibilities" is an exaggeration. If we just let or
Request, Response, Session and Cookie extend the corresponding http
servlet ones, we would just get a few minor incompatibilities that IMO
would be rather minor in comparison with
Daniel Fagerstrom wrote:
>
> "A lot of incompatibilities" is an exaggeration. If we just let or
> Request, Response, Session and Cookie extend the corresponding http
> servlet ones, we would just get a few minor incompatibilities that IMO
> would be rather minor in comparison with the benefits of
Carsten Ziegeler skrev:
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 -
Grzegorz Kossakowski wrote:
>
> What about wrapping these few classes by dynamic proxies that would
> implement lacking methods? These wrapping would happen in
> CocoonObjectModelProvider[1], would be narrowed to the Object Model only
> and could be quite transparent to the rest.
>
Sounds good t
Carsten Ziegeler pisze:
Yes, this is an open question - we should avoid these methods if
possible :) Now, I can guess that you don't like the answer, but to have
general components which might be reusable outside of Cocoon we should
stick to available interfaces where possible.
Generally speaki
Grzegorz Kossakowski wrote:
>
> What about getParameters() sort of methods that enable you to have
> expressions like cocoon.request.parameters.param1 ?
>
> Since ProcessInfoProvider returns implementation of HttpServletRequest
> there is no access to these methods. Any idea on this?
>
Yes, thi
Grzegorz Kossakowski wrote:
> Carsten Ziegeler pisze:
>> Grzegorz Kossakowski wrote:
>>> Carsten Ziegeler pisze:
>>>
>>> Hmmm, something worth trying. Do you think that changing
>>> o.a.c.environment.* classes (like MockRequest) so they implement Servlet
>>> interfaces and wrapping them in Abstract
Carsten Ziegeler pisze:
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 -
Carsten Ziegeler pisze:
Grzegorz Kossakowski wrote:
Carsten Ziegeler pisze:
Hmmm, something worth trying. Do you think that changing
o.a.c.environment.* classes (like MockRequest) so they implement Servlet
interfaces and wrapping them in AbstractTestCase won't break anything?
Hmm, it *should*
Grzegorz Kossakowski wrote:
> Carsten Ziegeler pisze:
>
>> 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.
>
> Hmmm, something worth trying. Do you think that changing
> o.a.c
Carsten Ziegeler pisze:
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.
Hmmm, something worth trying. Do you think that changing o.a.c.environment.* classes (like MockRequest) so
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
Grzegorz Kossakowski pisze:
Hi,
I'll give you some background to my problem. I use ProcessInfoProvider
for accessing environmental data because I've read[1] that it is a
proffered way to do this in Cocoon 2.2. Now, I would like to write tests
for Spring beans depending on ProcessInfoProvider.
Hi,
I'll give you some background to my problem. I use ProcessInfoProvider for accessing environmental data because I've read[1] that it is a
proffered way to do this in Cocoon 2.2. Now, I would like to write tests for Spring beans depending on ProcessInfoProvider. I thought that
it makes sense
15 matches
Mail list logo
