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
>
> Felix, I see that you are going to deprecate HTMLArea right now.
No.
Have
> you seen Reinhard's response[1], especially this:?
Yes. There are also others who think that not even depracation is needed
[2]. For now I'm just going to implement a LogAction.
[2] http://marc.info/?l=xml-cocoon
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 -
[
https://issues.apache.org/jira/browse/COCOON-2085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Kossakowski updated COCOON-2085:
-
Assignee: Grzegorz Kossakowski
> Implement new, universal Object Model
> ---
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
I'm forwarding this message to dev so people more familiar with Spring
Configurator can comment on it.
Does Kazó is right with his comments and we need to adjust documentation or not?
Respond to user list, thanks.
Wiadomość oryginalna
Thank you, this ([2]) is indeed the conf
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.
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>
>> Or a new map:log statement we talked about a long time ago, e.g.
>>
>>
> Yeah, sounds good as well - this statement has the advantage that it's
> always "configured" and it looks a little bit nicer.
>
>
>> Nothing that can be done wit
Felix Knecht wrote:
>> Or a new map:log statement we talked about a long time ago, e.g.
>>
>>
>> Nothing that can be done with an action though...
>>
>>
> I'm not quite sure but I think this [1] is the discussion about it.
> Reading across I think at that time the problem was how to debug sitem
> Or a new map:log statement we talked about a long time ago, e.g.
>
>
> Nothing that can be done with an action though...
>
>
I'm not quite sure but I think this [1] is the discussion about it.
Reading across I think at that time the problem was how to debug sitemap
and/or propagate messages
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
Sylvain Wallez wrote:
>
> Or a new map:log statement we talked about a long time ago, e.g.
>
Yeah, sounds good as well - this statement has the advantage that it's
always "configured" and it looks a little bit nicer.
>
> Nothing that can be done with an action though...
^^^
Carsten Ziegeler wrote:
> Felix Knecht wrote:
>
>>> Take a look at sitemap[1] in cocoon-forms-impl; there is following
>>>
>> I propose to have a a parameter we can set in the sitemap for readers
>> indicating that the read resource is deprecated.
>> This parameter will be read in the o.a
Felix Knecht wrote:
>> Take a look at sitemap[1] in cocoon-forms-impl; there is following
> I propose to have a a parameter we can set in the sitemap for readers
> indicating that the read resource is deprecated.
> This parameter will be read in the o.a.c..r.AbstractReader and log a
> warning in ca
Felix Knecht pisze:
I propose to have a a parameter we can set in the sitemap for readers
indicating that the read resource is deprecated.
This parameter will be read in the o.a.c..r.AbstractReader and log a
warning in case of (is a System.out.println also needed?).
Felix, I
Felix Knecht pisze:
I propose to have a a parameter we can set in the sitemap for readers
indicating that the read resource is deprecated.
This parameter will be read in the o.a.c..r.AbstractReader and log a
warning in case of (is a System.out.println also needed?).
WDYT?
> Take a look at sitemap[1] in cocoon-forms-impl; there is following
> snippet:
>
>
> src="resource://org/apache/cocoon/forms/resources/{1}.js"
> type="servletLinkRewriter"/>
>
>
> It matches all request for js files so in your case you would need to
> create more specific matcher (for
I was completely at the wrong corner. I saw a kind of DebugFilter you
can add and thought your talking about this kind of (servlet)-filter :-(
This make things much clearer.
Thanks
> Felix Knecht pisze:
>>> Thanks to servlet-service-fw migration in CForms we can be pretty sure
>>> that files wil
Felix Knecht pisze:
Thanks to servlet-service-fw migration in CForms we can be pretty sure
that files will be accessed through our matcher.
I'm not uptodate with the servlet-service-fw. Can you point me to this
matcher please?
Take a look at sitemap[1] in cocoon-forms-impl; there is following
>
> Thanks to servlet-service-fw migration in CForms we can be pretty sure
> that files will be accessed through our matcher.
I'm not uptodate with the servlet-service-fw. Can you point me to this
matcher please?
Not sure if this is the case, but when we need to add a specific
'deprecation'-filt
Felix Knecht pisze:
I advice everyone to test their applications that use template or
forms blocks so we can hunt all bugs early and fix them easily.
Thanks for your ongoing big works :-)
No problem, it's my GSoC duty.
To be honest, I'm still not satisfied with peace of changes applied to Co
> I advice everyone to test their applications that use template or
> forms blocks so we can hunt all bugs early and fix them easily.
Thanks for your ongoing big works :-)
The problems I had are resolved with commit 558681 and everything in my
applications runs smoothly again.
Felix
26 matches
Mail list logo
