[
http://issues.apache.org/jira/browse/COCOON-1928?page=comments#action_12441939
]
Jörg Heinicke commented on COCOON-1928:
---
> Cyriaque, have you tried declaring the serializer in your project's
> sitemap.xmap file? I am not sure which one
[
http://issues.apache.org/jira/browse/COCOON-1931?page=comments#action_12441936
]
Georg Hüttenegger commented on COCOON-1931:
---
One more thing: The stack traces are from cocoon 2.1.7 (with a slightly
modified FOM_JavaScriptInterpreter
[
http://issues.apache.org/jira/browse/COCOON-1931?page=comments#action_12441935
]
Georg Hüttenegger commented on COCOON-1931:
---
Not sure if fixing the NullPointerException is going to be easy. It would
definitely be great to get the l
[
http://issues.apache.org/jira/browse/COCOON-1928?page=comments#action_12441895
]
David Crossley commented on COCOON-1928:
Sitemap precedence would probably be better, if possible.
Another technique that i wonder about: Let the project
Dear developers,
This afternoon I did a fresh download of the Cocoon 2.2 trunk and tried to
build it. Unfortunately I'm getting build errors. Here's the output from
maven. I replaced the actual path to the trunk with '/path/to/cocoon/trunk':
[INFO] Generating war
/path/to/cocoon/trunk/dists/cocoo
[
http://issues.apache.org/jira/browse/COCOON-1933?page=comments#action_12441773
]
Carsten Ziegeler commented on COCOON-1933:
--
Looking into the Spring code, I think Spring doesn't support unpacked war files
at all. This would mean that
Hi there,
In a small cforms demo I'm trying out today I've been hitting quite a
number of issues. Each of these are (some even important) bugs IMHO, I
still need to perform a full scan of jira and svn history to see if some
of these are known and/or understand how we got here...
this upfront mess
[
http://issues.apache.org/jira/browse/COCOON-1933?page=comments#action_12441770
]
Carsten Ziegeler commented on COCOON-1933:
--
All the contents of a block or an application can be served directly from
within a jar or war. So we have to
[
http://issues.apache.org/jira/browse/COCOON-1933?page=comments#action_12441768
]
Alexander Klimetschek commented on COCOON-1933:
---
Good question. I don' t know the spring Resource abstraction apart from looking
at the interface m
[
http://issues.apache.org/jira/browse/COCOON-1933?page=comments#action_12441752
]
Carsten Ziegeler commented on COCOON-1933:
--
Does this also work with an unexpanded war? What does the getFile() method on
the resource return in that ca
>
> Ard Schrijvers hippo.nl> writes:
>
> > > It should be available in the list of possible actions
> (menu on the
> > > left), otherwise you do not have the appropriate rights.
> >
> > Yes that is my problem. These rights are related to being
> committer I suppose?
> > Is it something that
Ard Schrijvers hippo.nl> writes:
> > It should be available in the list of possible actions (menu on the
> > left), otherwise you do not have the appropriate rights.
>
> Yes that is my problem. These rights are related to being committer I suppose?
> Is it something that is arranged by infrastr
Created a jira issue including a patch that only takes files directly
under flow/ into account.
http://issues.apache.org/jira/browse/COCOON-1933
Alex
Alexander Klimetschek schrieb:
I just run into a problem with the automatic loading of all files inside
flow/: if there is a subversion direc
[ http://issues.apache.org/jira/browse/COCOON-1933?page=all ]
Alexander Klimetschek updated COCOON-1933:
--
Attachment: cocoon-flow-only-files.patch
This patches makes the FlowNodeBuilder only load files directly under flow/.
> [Patch] Automatic
[Patch] Automatic loading of flow scripts in "flow/" must not load directories
--
Key: COCOON-1933
URL: http://issues.apache.org/jira/browse/COCOON-1933
Project: Cocoon
>
>
> Ard Schrijvers hippo.nl> writes:
>
> > Can I create some sort of dependency between the to, or do
> I need to make a
> > cocoon JIRA issue that says "update excalibur jars", and
> somehow relate
> > http://issues.apache.org/jira/browse/COCOON-1909 to it (in
> > principal, then when the
On 10/12/06, Vadim Gritsenko <[EMAIL PROTECTED]> wrote:
...Only if feedback means stacktrace or any other essential information original
submitter failed to furnish, then yes, such issue can be closed...
But if feedback means "please send in a patch"... That's a different story. Not
everybody
Bertrand Delacretaz wrote:
On 10/12/06, David Crossley <[EMAIL PROTECTED]> wrote:
...Closing issues prematurely is disrespectful...
Agreed, with "prematurely" as the key aspect.
I must admit I haven't looked at the particular issue being discussed,
I was thinking in general terms: if an issue
Ard Schrijvers hippo.nl> writes:
> Can I create some sort of dependency between the to, or do I need to make a
> cocoon JIRA issue that says "update excalibur jars", and somehow relate
> http://issues.apache.org/jira/browse/COCOON-1909 to it (in
> principal, then when the "update" jira issue is c
Carsten Ziegeler wrote:
Vadim Gritsenko wrote
... we can, though, introduce new behavior for new "cocoon:" scoped attributes.
(Similarly, there is special processing going on for "cocoon:" prefixed request
parameters).
You mean adding special handling for example for all request attributes
u
[ http://issues.apache.org/jira/browse/COCOON-1932?page=all ]
Guillaume Déflache updated COCOON-1932:
---
Attachment: forms-advanced-field-styling_disabled_suggestion_list.patch
Patch against Cocoon 2.1.9's forms-advanced-field-styling.xsl: should app
I just run into a problem with the automatic loading of all files inside
flow/: if there is a subversion directory (.svn) inside, it will try to
call getInputStream() on it, which will fail on a directory.
So the problem is very general: you probably want to traverse
sub-directories in order t
[PATCH] correct styling of disabled suggestion lists
Key: COCOON-1932
URL: http://issues.apache.org/jira/browse/COCOON-1932
Project: Cocoon
Issue Type: Bug
Components: Blocks: Fo
>
> On 10/11/06, Antonio Gallardo <[EMAIL PROTECTED]> wrote:
>
> > ...IMHO, we should leave open this bug, because the fixi is
> not finished
> > yet until we update excalibur...
>
> Same here. If "update excalibur" is a Jira or bugzilla issue
> somewhere, I'd make a link or a dependency to it
[
http://issues.apache.org/jira/browse/COCOON-1909?page=comments#action_12441677
]
Ard Schrijvers commented on COCOON-1909:
The bug is in XSLTProcessorImpl in public javax.xml.transform.Source resolve(
String href, String base ), at Lis
[ http://issues.apache.org/jira/browse/COCOON-1918?page=all ]
Jean-Baptiste Quenot updated COCOON-1918:
-
Summary: [PATCH] Strip out spurious whitespace or "block" characters in
browser tooltips/help bubbles (was: unwanted whitespace or "block" c
[ http://issues.apache.org/jira/browse/COCOON-1194?page=all ]
Jörg Heinicke closed COCOON-1194.
-
Resolution: Cannot Reproduce
Assignee: (was: Colin Adams)
No reaction since 2 years, so closing the issue. Feel free to reopen it if it
still appl
[ http://issues.apache.org/jira/browse/COCOON-1372?page=all ]
Jörg Heinicke closed COCOON-1372.
-
Resolution: Won't Fix
As Antonio explained it has an incompatible license.
> [PATCH] SmbAuthAction
> -
>
> Key: COCOON-1
> Joerg Heinicke wrote:
>
> >
> > Yes, that should be the way to go. Furthermore (if it is
> possible) you
> > should add a dependency on the xmlutil issue to the Cocoon
> issue, so
> > that we get informed when xmlutil is fixed.
>
> Yes that sounds about right to me. Create the ticket and I
[ http://issues.apache.org/jira/browse/COCOON-1549?page=all ]
Jörg Heinicke updated COCOON-1549:
--
> [PATCH] Batik Rhino support incompatible with Cocoon's
> --
>
> Key: COCOON-1549
>
[ http://issues.apache.org/jira/browse/COCOON-1564?page=all ]
Jörg Heinicke updated COCOON-1564:
--
> [html block] HTMLGenerator doesn't copy POST parameters
> ---
>
> Key: COCOON-1564
>
[ http://issues.apache.org/jira/browse/COCOON-1570?page=all ]
Jörg Heinicke updated COCOON-1570:
--
> fi:validation-errors styling element does not work in AJAX mode
> ---
>
> Key: CO
[ http://issues.apache.org/jira/browse/COCOON-1655?page=all ]
Jörg Heinicke updated COCOON-1655:
--
> JavaFlow/CForm/select-list crash
>
>
> Key: COCOON-1655
> URL: http://issues.apache.org/jira
[ http://issues.apache.org/jira/browse/COCOON-1664?page=all ]
Jörg Heinicke closed COCOON-1664.
-
Fix Version/s: 2.2-dev (Current SVN)
Resolution: Won't Fix
As explained by Carsten JAAS is already integrated in 2.2 auth-fw block.
> Jaas based Auth
[ http://issues.apache.org/jira/browse/COCOON-1664?page=all ]
Jörg Heinicke updated COCOON-1664:
--
> Jaas based Authenticator
>
>
> Key: COCOON-1664
> URL: http://issues.apache.org/jira/browse/COCOON-1
[ http://issues.apache.org/jira/browse/COCOON-1825?page=all ]
Jörg Heinicke updated COCOON-1825:
--
> Ajax errror when an active state widget become invisible state widget
> -
>
>
[ http://issues.apache.org/jira/browse/COCOON-1345?page=all ]
Jörg Heinicke updated COCOON-1345:
--
Bugzilla Id: (was: 32223)
Component/s: Blocks: Forms
(was: Blocks: (Undefined))
Summary: [PATCH] Extract convertors into
[ http://issues.apache.org/jira/browse/COCOON-1881?page=all ]
Jörg Heinicke updated COCOON-1881:
--
Component/s: - Components: Sitemap
(was: Blocks: (Undefined))
> Xinclude transformer has changed behaviour with Saxon 8.7.1
>
[ http://issues.apache.org/jira/browse/COCOON-1816?page=all ]
Jörg Heinicke updated COCOON-1816:
--
Component/s: Blocks: Templating
(was: Blocks: (Undefined))
IIRC this issue has been fixed in the refactored template generator availab
39 matches
Mail list logo
