What version of Cocoon is this? The source for excalibur xmlutils 2.1
and 1.0 doesn't match the line numbers in your stack traces. What
version is in your lib/core?
Ralph
Tilman Rassy wrote:
Hello,
On Tuesday 24 January 2006 13:32, Carsten Ziegeler wrote:
Tilman Rassy wrote:
[
http://issues.apache.org/jira/browse/COCOON-1681?page=comments#action_12363933
]
Jean-Baptiste Quenot commented on COCOON-1681:
--
Disabling the expiry check is not an option, because it would mean that we make
a stat() system call for every
Hello Ralph,
On Tuesday 24 January 2006 23:14, Ralph Goers wrote:
Can you send the source for the DocumentGenerator? I'd love to see it.
Yes, of course. Shall I send it to the dev list or to your private address?
(The source is about 400 lines long.)
On Wednesday 25 January 2006 09:11, Ralph
-Original Message-
From: Jean-Baptiste Quenot [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 24, 2006 18:40
To: dev@cocoon.apache.org
Subject: Re: caching for source objects?
* Carsten Ziegeler:
Max Pfingsthorn schrieb:
I've run into some problems with performance (in
* Upayavira:
Jean-Baptiste Quenot wrote:
Any hint on how to add this location to the loader classpath?
The loader source is in tools/src/loader/Loader.java. It seems
that the loader doesn't load class directories. However, a brief
look at the code suggests to me that it wouldn't be too
[ http://issues.apache.org/jira/browse/COCOON-1719?page=all ]
Jean-Baptiste Quenot updated COCOON-1719:
-
Urgency: Urgent
IncludeTransformer: source must not be cached if an error occurs
[ http://issues.apache.org/jira/browse/COCOON-1170?page=all ]
Jean-Baptiste Quenot updated COCOON-1170:
-
Bugzilla Id: (was: 29360)
Urgency: Normal
[PATCH] precompile xsp's without starting URI
[ http://issues.apache.org/jira/browse/COCOON-1344?page=all ]
Jean-Baptiste Quenot updated COCOON-1344:
-
Bugzilla Id: (was: 32219)
Urgency: Normal
Description:
Currently a datatypes convertor-builder selector is not disposed. This
Jean-Baptiste Quenot wrote:
* Upayavira:
Jean-Baptiste Quenot wrote:
Any hint on how to add this location to the loader classpath?
The loader source is in tools/src/loader/Loader.java. It seems
that the loader doesn't load class directories. However, a brief
look at the code suggests to
[ http://issues.apache.org/jira/browse/COCOON-1558?page=all ]
Jean-Baptiste Quenot updated COCOON-1558:
-
Bugzilla Id: (was: 35673)
Urgency: Normal
Description:
Hi, when using validation-error tag, the FormsTemplateTransformer
[ http://issues.apache.org/jira/browse/COCOON-1681?page=all ]
Jean-Baptiste Quenot reassigned COCOON-1681:
Assign To: Jean-Baptiste Quenot (was: Cocoon Developers Team)
Generator directory: Caching too much
Hello,
There is a problem with the urgency field, which is supposed to be
used by the Cocoon team. In the issue navigator, urgency is just
a string value, so when Sorting by: Urgency ascending, you get:
Normal
Urgent
(None)
When sorting by: Urgency descending, you get:
(None)
Urgent
Normal
* Upayavira:
Jean-Baptiste Quenot wrote:
* Upayavira:
Jean-Baptiste Quenot wrote:
Any hint on how to add this location to the loader
classpath?
The loader source is in tools/src/loader/Loader.java. It
seemsthat theloaderdoesn't loadclass
I wish to replace servlet_2_2.jar with servlet_2_3.jar, but keep
compatibility with servlet 2.2, by making servlet2.3-requiring
components optional.
WDYT?
--
Jean-Baptiste Quenot
http://caraldi.com/jbq/
Jean-Baptiste Quenot schrieb:
I wish to replace servlet_2_2.jar with servlet_2_3.jar, but keep
compatibility with servlet 2.2, by making servlet2.3-requiring
components optional.
You can't check if a component uses 2.3 functionality, so if we just
upgrade we might end up with a not 2.2
Hi!
I just did an update of my 2.1.x branch and (even after svn cleanup), svn
complains:
svn: Failed to add directory 'src\blocks\validation': object of the same name
already exists
Did someone make it external or something? Should I delete that dir and do
another svn up?
Best regards,
Max
Hi!
Found something in the current svn 2.1.x branch:
cocoon-2.1.x\src\blocks\cron\java\org\apache\cocoon\components\cron\QuartzDriverDelegate.java:528:
cannot resolve symbol
symbol : method updateSchedulerState
(java.sql.Connection,java.lang.String,long)
location: interface
There have been a lot of changes in the use of externals. You can start
by deleting the problematic dir, but that is probably not enough as
externals is a property of the enclosing directory IIUC. Easiest is
probably to do a fresh checkout.
/Daniel
Max Pfingsthorn wrote:
Hi!
I just did an
Hello!
Is there any special reason the AggregateField does not initialize its children
when it is initialized itself? This is the cause for
https://issues.apache.org/jira/browse/COCOON-1739... If noone shouts at me in
the next hour, I will commit the change so that selection-lists, initial
[ http://issues.apache.org/jira/browse/COCOON-1739?page=all ]
Max Pfingsthorn reassigned COCOON-1739:
---
Assign To: Max Pfingsthorn
Selection list within aggregatefield is ignored
---
Key:
Carsten Ziegeler wrote:
Jean-Baptiste Quenot schrieb:
I wish to replace servlet_2_2.jar with servlet_2_3.jar, but keep
compatibility with servlet 2.2, by making servlet2.3-requiring
components optional.
You can't check if a component uses 2.3 functionality, so if we just
upgrade
Upayavira wrote:
Jean-Baptiste Quenot wrote:
We could hack the Loader. But we could also packages our samples
as jars. That would ease to merge the Cocoon build with an
existing application. Currently, it is quite difficult to mix
Cocoon's WEB-INF/classes with My App's
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote
WDYT?
I'm not sure if a global registry really works. What happens if I want
to use a block twice but with different configurations? Can this be handled?
Yep. How do we (can we) implement the classical scenario that's been
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Jean-Baptiste Quenot schrieb:
I wish to replace servlet_2_2.jar with servlet_2_3.jar, but keep
compatibility with servlet 2.2, by making servlet2.3-requiring
components optional.
You can't check if a component uses 2.3
On 25.01.2006 15:37, Sylvain Wallez wrote:
So depending on servlet 2.3 shouldn't be that much of a problem.
But in 2.1 branch what 1. we assume is legacy, 2. we want to assure
compatibility according to our versioning manifesto [1].
Jörg
[1] http://cocoon.apache.org/versioning.html
[ http://issues.apache.org/jira/browse/COCOON-1739?page=all ]
Max Pfingsthorn closed COCOON-1739:
---
Fix Version: 2.2-dev (Current SVN)
2.1.9-dev (current SVN)
Resolution: Fixed
AggregateField did not initialize its children
I must have missed something. I can understand how you can package the
sample classes in their own jars, but what will you do with the sample
sitemaps and additional xconf configurations?
Ralph
We could hack the Loader. But we could also packages
our samples as jars. That
[ http://issues.apache.org/jira/browse/COCOON-1681?page=all ]
Jörg Heinicke updated COCOON-1681:
--
Generator directory: Caching too much
---
Key: COCOON-1681
URL:
[ http://issues.apache.org/jira/browse/COCOON-1725?page=all ]
Jörg Heinicke updated COCOON-1725:
--
Unexpected attempt to read values of JavaBean while saving form
---
Key: COCOON-1725
[ http://issues.apache.org/jira/browse/COCOON-1711?page=all ]
Jörg Heinicke updated COCOON-1711:
--
[PATCH] correct position of help popup for tab styling
--
Key: COCOON-1711
URL:
I'd be in favor of that but you cannot follow our versioning plan and
introduce it in 2.1.9. We'd have to announce our intent first. On the
other hand, we can always override that with a vote.
Carsten Ziegeler wrote:
Servlet 2.3 has been released more than 4 years ago[1]. IMO it is safe
to
[ http://issues.apache.org/jira/browse/COCOON-1609?page=all ]
Jörg Heinicke updated COCOON-1609:
--
form binding ambiguity creating new paths
--
Key: COCOON-1609
URL:
[ http://issues.apache.org/jira/browse/COCOON-1574?page=all ]
Jörg Heinicke updated COCOON-1574:
--
Memory Leak with XMLFileModule
--
Key: COCOON-1574
URL: http://issues.apache.org/jira/browse/COCOON-1574
OK. I have no idea how to get the source for xmlutil-1.0-dev. I was
looking at the current source and the 2.1.7 source (the oldest I have)
and it looks to me that if there is a problem it is most likely in
XSLTProcessorImpl. However, I'd suggest you look at SitemapSource and
Joerg Heinicke wrote:
On 25.01.2006 15:37, Sylvain Wallez wrote:
So depending on servlet 2.3 shouldn't be that much of a problem.
But in 2.1 branch what 1. we assume is legacy, 2. we want to assure
compatibility according to our versioning manifesto [1].
Btw, Cocoon 2.2 is based on
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
So depending on servlet 2.3 shouldn't be that much of a problem.
Yes, that's why I said in an earlier response that we can vote on
upgrading the requirements to servlet 2.3 officially.
Ok, let's vote!
Sylvain
--
Sylvain Wallez
[
http://issues.apache.org/jira/browse/COCOON-1688?page=comments#action_12363966
]
Max Pfingsthorn commented on COCOON-1688:
-
I've allowed only new's to have a : in their id field, because they may
reference classes in libraries directly. Please
[ http://issues.apache.org/jira/browse/COCOON-1688?page=all ]
Max Pfingsthorn closed COCOON-1688:
---
Fix Version: 2.2-dev (Current SVN)
2.1.9-dev (current SVN)
Resolution: Fixed
Assign To: Max Pfingsthorn
I fixed it, at
[ http://issues.apache.org/jira/browse/COCOON-1734?page=all ]
Max Pfingsthorn reassigned COCOON-1734:
---
Assign To: Max Pfingsthorn
Forms library not honouring cross-referencing classes
-
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
So depending on servlet 2.3 shouldn't be that much of a problem.
Yes, that's why I said in an earlier response that we can vote on
upgrading the requirements to servlet 2.3 officially.
Ok, let's vote!
We have fixed several problems/bugs in the sitemap source and pipeline
implementations after the 2.1.3 release. So I think the best thing for
you is to test your test case with the most recent version (2.1.8) and
see if this problem still exists.
Carsten
Ralph Goers wrote:
OK. I have no idea how
Upayavira wrote:
Sylvain Wallez wrote:
Ok, let's vote!
Why? What does it give us? It _may_ bring an incompatability for some
users, so I'd want to understand what the benefits are.
Personally, I think we should go 2.3 or even 2.4 with Cocoon 2.2, but
stick as we are in 2.1.x. After
Sylvain Wallez schrieb:
Upayavira wrote:
Sylvain Wallez wrote:
Ok, let's vote!
Why? What does it give us? It _may_ bring an incompatability for some
users, so I'd want to understand what the benefits are.
Personally, I think we should go 2.3 or even 2.4 with Cocoon 2.2, but
* Carsten Ziegeler:
Sylvain Wallez schrieb:
Jean-Baptiste can elaborate on this, but AFAIU this is because
an interesting XSP patch requires a servlet listener, which is
something that was added in servlets 2.3.
So, he could just add a mock class for the listener to the xsp
block,
* Ralph Goers:
I must have missed something. I can understand how you can
package the sample classes in their own jars, but what will you
do with the sample sitemaps and additional xconf configurations?
Sitemaps and xconf will remain in webapp/samples and
[ http://issues.apache.org/jira/browse/COCOON-1719?page=all ]
Jean-Baptiste Quenot closed COCOON-1719:
Fix Version: 2.2-dev (Current SVN)
2.1.9-dev (current SVN)
Resolution: Fixed
IncludeTransformer: source must not
[ http://issues.apache.org/jira/browse/COCOON-1718?page=all ]
Jean-Baptiste Quenot reassigned COCOON-1718:
Assign To: (was: Jean-Baptiste Quenot)
Unassigning this bug: the AJAX stuff is currently being refactored. We'll see
in the next
Max Pfingsthorn wrote:
Hi!
Found something in the current svn 2.1.x branch:
cocoon-2.1.x\src\blocks\cron\java\org\apache\cocoon\components\cron\QuartzDriverDelegate.java:528:
cannot resolve symbol
symbol : method updateSchedulerState
(java.sql.Connection,java.lang.String,long)
location:
Jean-Baptiste Quenot wrote:
* Carsten Ziegeler:
Sylvain Wallez schrieb:
Jean-Baptiste can elaborate on this, but AFAIU this is because
an interesting XSP patch requires a servlet listener, which is
something that was added in servlets 2.3.
So, he could just add a mock class for the
-Original Message-
From: Antonio Gallardo [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 25, 2006 17:15
To: dev@cocoon.apache.org
Subject: Re: on another note: error in QuartzDriverDelegate.java
Max Pfingsthorn wrote:
Hi!
Found something in the current svn 2.1.x branch:
Upayavira wrote:
Jean-Baptiste Quenot wrote:
* Carsten Ziegeler:
Sylvain Wallez schrieb:
Jean-Baptiste can elaborate on this, but AFAIU this is because
an interesting XSP patch requires a servlet listener, which is
something that was added in servlets 2.3.
So, he
[ http://issues.apache.org/jira/browse/COCOON-1699?page=all ]
Jean-Baptiste Quenot closed COCOON-1699:
Fix Version: 2.2-dev (Current SVN)
2.1.9-dev (current SVN)
Resolution: Fixed
Committed, thanks!
[Patch] Enables
Sylvain Wallez wrote:
Upayavira wrote:
Jean-Baptiste Quenot wrote:
* Carsten Ziegeler:
Sylvain Wallez schrieb:
Jean-Baptiste can elaborate on this, but AFAIU this is because
an interesting XSP patch requires a servlet listener, which is
something that was added in
[
http://issues.apache.org/jira/browse/COCOON-1609?page=comments#action_12363974
]
Jean-Baptiste Quenot commented on COCOON-1609:
--
You say: « The ValueJXPathBinding class calls createPathAndSetValue() while
others expect that the given path
Upayavira wrote:
Mocking a 4-year old specification. This is s dinosaurish in this
web 2.0 world...
Hmm. If the whole spec is required, I can see where Jean-Baptiste is
coming from. We could extend the build process to use servlet 2.3 for
compilation, but keep the app running with
[ http://issues.apache.org/jira/browse/COCOON-1704?page=all ]
Jean-Baptiste Quenot closed COCOON-1704:
Fix Version: 2.2-dev (Current SVN)
2.1.9-dev (current SVN)
Resolution: Fixed
Committed, thanks!
Error Message
[ http://issues.apache.org/jira/browse/COCOON-1695?page=all ]
Jean-Baptiste Quenot closed COCOON-1695:
Fix Version: 2.2-dev (Current SVN)
2.1.9-dev (current SVN)
Resolution: Fixed
Committed, thanks!
Saxon requires an
* Carsten Ziegeler:
From a quick glance at the stack traces I think this might be a bug in
the sitemap source implementation when getInputStream() is used.
Is the problem related to the following bug:
Calling SitemapSource.getInputStream() twice
Upayavira wrote:
Sylvain Wallez wrote:
Upayavira wrote:
Jean-Baptiste Quenot wrote:
* Carsten Ziegeler:
Sylvain Wallez schrieb:
Jean-Baptiste can elaborate on this, but AFAIU this is because
an interesting XSP patch requires a servlet
[ http://issues.apache.org/jira/browse/COCOON-1734?page=all ]
Max Pfingsthorn closed COCOON-1734:
---
Fix Version: 2.2-dev (Current SVN)
2.1.9-dev (current SVN)
Resolution: Fixed
Changed the way widgets and bindings remember
So this is one way to get us motivated to get 2.2 out.
Carsten Ziegeler said:
I think we don't need to moch the whole spec but just the listener. So
it's
one interface. As soon as we use 2.3 for compilation we can't ensure
that noone else is using 2.3 features.
With the same arguments we
[ http://issues.apache.org/jira/browse/COCOON-1451?page=all ]
Jörg Heinicke closed COCOON-1451:
-
Resolution: Invalid
There was no reaction for nearly one year. It is an often used component and
nobody else reported the error. So we assume this
Sylvain Wallez skrev:
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote
WDYT?
I'm not sure if a global registry really works. What happens if I want
to use a block twice but with different configurations? Can this be
handled?
Yep. How do we (can we) implement the classical
Sylvain Wallez skrev:
Daniel Fagerstrom wrote:
...
A skin block is basically a factory, and a wiring is an instruction to
ask the factory for a component, give it its deploy time configuration
and a unique id and to register the differently configured instances
under the different ids in the
Daniel Fagerstrom wrote:
Sylvain Wallez skrev:
If the scenario where we have several implementations of a block
interface (e.g. skin)
This is solved by agree before hand which id implementations of this
interface should be registered under. Now, this use case is rather
abstract IMO, as we
[
http://issues.apache.org/jira/browse/COCOON-1734?page=comments#action_12364020
]
Ben Pope commented on COCOON-1734:
--
Sorry, but it looks like your added methods in Binding.java broke a subclass, I
get a failed compile (on 2.2):
[ http://issues.apache.org/jira/browse/COCOON-1734?page=all ]
Ben Pope updated COCOON-1734:
-
Attachment: CustomValueWrapBinding.diff
I don't know if this is in the spirit of your additions, but it makes it
compile :)
Forms library not honouring
It seems that despite our concerns and attempts to address it
at the time, we still broke the URL space when publishing the
2.1 docs.
Vadim, Helma, ... does anyone still have a list of the
filenames from when we investigated this. We will need
to set up re-directs now.
-David
Author: rgardler
[
http://issues.apache.org/jira/browse/COCOON-1681?page=comments#action_12364063
]
Antonio Fiol commented on COCOON-1681:
--
No, I am not disabling the expiry check. This was a temporary workaround.
The code in isValid says something like:
if not yet
69 matches
Mail list logo
