Reinhard Poetz wrote:
I propose making the status code attribute of serializers expandable.
This makes it easier to provide REST style services with Cocoon that
make use of the different meanings of status codes.
+1
Jeroen
Reinhard Poetz wrote:
I propose making the status code attribute of serializers expandable.
This makes it easier to provide REST style services with Cocoon that
make use of the different meanings of status codes.
+1. Should have actually been there right from the start!
Sylvain
--
Sylvain
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
Torsten Curdt wrote:
On 28.03.2007, at 20:14, Vadim Gritsenko wrote:
[EMAIL PROTECTED] wrote:
-public class CacheImpl
-extends AbstractLogEnabled
-implements Cache, ThreadSafe, Serviceable, Disposable,
Parameterizable {
+public class
[EMAIL PROTECTED] wrote:
Make method getLogger() visible for extending
-private Log getLogger() {
+protected Log getLogger() {
Felix,
As far as commons logging usage pattern goes, extending classes should create
own instances of the log, otherwise log will get really confusing,
Vadim Gritsenko wrote:
[EMAIL PROTECTED] wrote:
Make method getLogger() visible for extending
-private Log getLogger() {
+protected Log getLogger() {
Felix,
As far as commons logging usage pattern goes, extending classes should
create own instances of the log, otherwise log will
several requests on the users list) I want to propose to move it to
cocoon-core.
+1
Ard
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log):
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
[EMAIL PROTECTED] wrote:
Make method getLogger() visible for extending
-private Log getLogger() {
+protected Log getLogger() {
Felix,
As far as commons logging usage pattern goes, extending classes should
create own instances of the
[
https://issues.apache.org/jira/browse/COCOON-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Kossakowski reopened COCOON-2022:
--
Unfortunately the issues is still not resolved, but this time I guess that is
Reinhard Poetz wrote:
I propose making the status code attribute of serializers
expandable.
This makes it easier to provide REST style services with Cocoon that
make use of the different meanings of status codes.
+1. Should have actually been there right from the start!
big +1
I missed the discussion before the vote, but have one more question:
Is it also possible to add extra optional http headers in the serializer, like:
map:serialize type=xhtml pragma={cache} cache-control={cache}
I would like to store in a variable wether I am dealing with something that is
not
Ard Schrijvers napisał(a):
I missed the discussion before the vote, but have one more question:
Is it also possible to add extra optional http headers in the serializer,
like:
map:serialize type=xhtml pragma={cache} cache-control={cache}
I would like to store in a variable wether I am
Ard Schrijvers wrote:
I missed the discussion before the vote, but have one more question:
Is it also possible to add extra optional http headers in the serializer, like:
map:serialize type=xhtml pragma={cache} cache-control={cache}
I would like to store in a variable wether I am dealing with
Ard Schrijvers wrote:
I missed the discussion before the vote, but have one more question:
Is it also possible to add extra optional http headers in
the serializer, like:
map:serialize type=xhtml pragma={cache}
cache-control={cache}
I would like to store in a variable wether
Ard Schrijvers napisał(a):
I missed the discussion before the vote, but have one more question:
Is it also possible to add extra optional http headers in
the serializer, like:
map:serialize type=xhtml pragma={cache}
cache-control={cache}
I would like to store in a variable
Ard Schrijvers napisał(a):
I am not in favor of this. When you only create a form with a continuation
based on the contents of some xml file, you do not know which pipelines do,
and which do not contain a form. You do know in flow when you are creating a
form/continuation. Setting a
Configure servlet prefix for link rewriting automatically
-
Key: COCOON-2034
URL: https://issues.apache.org/jira/browse/COCOON-2034
Project: Cocoon
Issue Type: Task
On 3/29/07, Ard Schrijvers [EMAIL PROTECTED] wrote:
... Please see HttpHeaderAction, can set any response header you want
I know. But, it does not work when you set the response header in a
subpipeline, so you *have* to do this in the pipeline which contains the
serializer...
See also
[
https://issues.apache.org/jira/browse/COCOON-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485261
]
Daniel Fagerstrom commented on COCOON-2034:
---
I have a clever idea about how to solve it ;) We discussed
Vadim Gritsenko wrote:
Last I checked, and since 2.2, it is impossible (or just really hard?) to
start
up cocoon without servlet context and related objects, which means it gotta
be
deployed and started as part of the webapp. If that is the case, IMHO there
is
no good reason to have
Ard Schrijvers wrote:
Ard Schrijvers wrote:
I missed the discussion before the vote, but have one more question:
Is it also possible to add extra optional http headers in
the serializer, like:
map:serialize type=xhtml pragma={cache}
cache-control={cache}
I would like to store in a variable
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
Last I checked, and since 2.2, it is impossible (or just really hard?) to start
up cocoon without servlet context and related objects, which means it gotta be
deployed and started as part of the webapp. If that is the case, IMHO there is
no good
[
https://issues.apache.org/jira/browse/COCOON-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Kossakowski closed COCOON-2034.
Resolution: Fixed
Daniel, thanks for reminder! :)
I've implemented new input
22 matches
Mail list logo
