It seems to be bad luck that it always hits you ;-)
I'm used to this - somehow I attract those kind of problems. So please
be patient with me I'm sure to fall into the next trap pretty soon ;-)
Felix
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
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
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'-filter
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
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 will be
Take a look at sitemap[1] in cocoon-forms-impl; there is following
snippet:
map:match pattern=resource/external/forms/**.js
map:read
src=resource://org/apache/cocoon/forms/resources/{1}.js
type=servletLinkRewriter/
/map:match
It matches all request for js files so in your case
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?).
map:match
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?).
map:match
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 case of
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
Sylvain Wallez wrote:
Or a new map:log statement we talked about a long time ago, e.g.
map:log level=warn msg={1} is deprecated/
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
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
Or a new map:log statement we talked about a long time ago, e.g.
map:log level=warn msg={1} is deprecated/
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
Felix Knecht wrote:
Or a new map:log statement we talked about a long time ago, e.g.
map:log level=warn msg={1} is deprecated/
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
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Or a new map:log statement we talked about a long time ago, e.g.
map:log level=warn msg={1} is deprecated/
Yeah, sounds good as well - this statement has the advantage that it's
always configured and it looks a little bit nicer.
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
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
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)
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
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
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*
[
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:
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
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]
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 AbstractTestCase won't
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, this is
27 matches
Mail list logo
