On 19.02.2008 21:17, [EMAIL PROTECTED] wrote:
Compare these examples:
map:select
map:when test=first
map:transform
map:parameter name=choice value=first/
/map:transform
/map:when
map:otherwise
map:transform
map:parameter name=choice value=other/
On 20.02.2008 21:04, [EMAIL PROTECTED] wrote:
Writing a reusable InputModule that can handle:
if(resource1.exists()){ return parameter1;}
else if(resource2.exists()){return parameter2;}
else if(resource3.exists()){return parameter3; }
...
else return finalparameter;
is possible.
On 11.02.2008 18:36, Gabriel Gruber wrote:
I noticed a change in behavior of cforms lately. the submit widget now
has false as default value for the validate attribute (opposed to the
documenation which says, true is the default value).
In general just raise an issue at Jira - even though
On 08.02.2008 10:58, [EMAIL PROTECTED] wrote:
Author: gkossakowski
Date: Fri Feb 8 07:58:03 2008
New Revision: 619921
URL: http://svn.apache.org/viewvc?rev=619921view=rev
Log:
Created a integration test for servlet Spring scope.
Added:
On 07.02.2008 11:11, Alfred Nathaniel wrote:
I now added exclusion rules to all our explicit dependencies which pick
up the old avalon-framework through transitive dependencies.
Thanks very much, Alfred. That's really appreciated!
Joerg
On 07.02.2007 05:17, Grzegorz Kossakowski wrote:
It's little bit off-topic but my question is related to my patches I've
recently sent on JIRA. I've seen that all my patches produced by
Subclipse contain absolute path of Index: field. I think it's not
desired and these patches will cause
On 02.02.2008 10:36, Carsten Ziegeler wrote:
URL: http://svn.apache.org/viewvc?rev=617586view=rev
Log:
SOLVED - issue COCOON-2164: Bug in JaxpResolver in validation block
https://issues.apache.org/jira/browse/COCOON-2164
Modified:
On 04.02.2008 08:43, Dev at weitling wrote:
if the migration to Dojo 1.0 tends to become a big piece of work what
about migrating to Prototype/Scriptaculous (or similar)?
The last Dojo update to 0.4.3 was not that long ago, was it? So it can't
be too hard to update ... Of course I might be
On 31.01.2008 16:35, Thorsten Scherler wrote:
Have you made sure that your dispatcher transformer is configured correctly? If
it is *not* threadsafe, you have to use the prototype scope. Otherwise you can
use the singleton scope (which is actually the default!).
This is what I always thought
On 25.01.2008 15:49, Vadim Gritsenko wrote:
In normal mode everything runs fine. But when running a jmeter test
with 40 concurrent users, the AbstractWidgetDefinitionBuilder throws
a NullPointerException.
It's now fixed in 2.1 branch, cocoon-forms-1.0.0 branch, and in trunk.
Thanks Vadim!
On 22.01.2008 15:08, Continuum VMBuild Server wrote:
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=40435projectId=51
Build statistics:
State: Failed
Previous State: Failed
Started at: Tue 22 Jan 2008 12:00:51 -0800
Finished at: Tue 22 Jan 2008 12:07:22
On 17.01.2008 05:45, Harald Entner wrote:
In normal mode everything runs fine. But when running a jmeter test with
40 concurrent users, the AbstractWidgetDefinitionBuilder throws a
NullPointerException. see the full stacktrace at (1)
java.lang.NullPointerException
at
On 16.01.2008 01:10, [EMAIL PROTECTED] wrote:
Author: joerg
Date: Tue Jan 15 22:09:53 2008
New Revision: 612363
URL: http://svn.apache.org/viewvc?rev=612363view=rev
Log:
convert status.xml (Forrest) to changes.xml (Maven), see also
http://marc.info/?t=12001912511r=1w=4
Only one missing
On 13.01.2008 05:17, Grzegorz Kossakowski wrote:
cocoon/trunk/blocks/cocoon-imageop/cocoon-imageop-impl/src/changes/changes.xml
Could it be we switched from status.xml to changes.xml? :)
Yes, I believe so. I haven't touch any status.xml since I'm committer and
nobody complained to date. :)
On 13.01.2008 09:30, Grzegorz Kossakowski wrote:
You can use CDATA section and put HTML tags into it. See[1]
It's a pain that they disable output escaping! Why not allowing free
markup? Wherever we put escaped markup into our changes to show them to
the user they will end up as markup in
On 13.01.2008 09:20, Reinhard Poetz wrote:
Could it be we switched from status.xml to changes.xml? :)
yes. We had some discussion about it when I switched our doc generation
to be based on Maven 2.
I'm going to move changes put into status.xml to corresponding
changes.xml and get rid of
On 12.01.2008 09:48, Grzegorz Kossakowski wrote:
I think at this point it is easier to release XSP 1.0.
but then we would need to maintain it which is what I would like to really
avoid :(
XSPs should be killed long time ago IMO.
I don't think you can get rid of XSP block in 2.2 - we have
On 12.01.2008 21:20, [EMAIL PROTECTED] wrote:
Modified:
cocoon/trunk/blocks/cocoon-imageop/cocoon-imageop-impl/src/changes/changes.xml
Could it be we switched from status.xml to changes.xml? :)
There are still 100 status.xml in trunk. Before I clean them up I want
to know if that's
On 09.01.2008 12:20, Carsten Ziegeler wrote:
it would be great if you could add it, the link is just
http://cocoon.apache.org/mirror.cgi
It would also be great if someone could update the version number of our
latest release to 2.1.11.
Reinhard done it already but t wasn't published to our
On 08.01.2008 22:59, Ralph Goers wrote:
But I am still getting 1 unit
test failure in cocoon core - CachingSourceTestCase is failing on line
88. How could this possibly have anything to do with what I changed?
Since our Continuum build now runs successful it seems to be an issue
with your
On 08.01.2008 23:23, Joerg Heinicke wrote:
But I am still getting 1 unit test failure in cocoon core -
CachingSourceTestCase is failing on line 88. How could this possibly
have anything to do with what I changed?
Since our Continuum build now runs successful it seems to be an issue
On 08.01.2008 16:07, Carsten Ziegeler wrote:
The vote for releasing 2.1.11 as assembled here
http://people.apache.org/~cziegeler/releases/cocoon/
past successfully with
7 +1 votes from Grzegorz Kossakowski, Jeroen Reijn, Bertrand Delacretaz,
David Crossley, Felix Knecht, Joerg Heinicke
On 08.01.2008 14:45, Grzegorz Kossakowski wrote:
We were not shipping samples because samples should depend on released
artifacts, only. Anyway, I
agree that we need to find a way for distribution of our samples.
However, I wonder how we will treat them? As official released packages with
On 09.01.2008 00:11, Ralph Goers wrote:
Maybe we are on the same page, but I'm unclear what you mean by
include. A cocoon release should consist of nothing more than
deploying artifacts to the maven repository. End users should be getting
the release by specifying the version number of the
On 06.01.2008 04:35, [EMAIL PROTECTED] wrote:
Author: rgoers
Date: Sun Jan 6 01:35:48 2008
New Revision: 609282
URL: http://svn.apache.org/viewvc?rev=609282view=rev
Log:
Created XPathXMLFileModule to fix problems with XMLFileModule. Added
getAttributeValue to JXPathHelper and changed all
On 06.01.2008 05:05, Continuum VMBuild Server wrote:
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=35020projectId=51
Build statistics:
State: Failed
Previous State: Ok
Started at: Sun 6 Jan 2008 02:01:03 -0800
Finished at: Sun 6 Jan 2008 02:03:40 -0800
On 03.01.2008 8:23 Uhr, Grzegorz Kossakowski wrote:
Affects version (Component): Parent values: Blocks: Forms(10167).
Level 1 values: 1.0.0-RC1(10321). Fix version (Component):
Parent values: Blocks: Forms(10239).
Where can these values be administered? There is no 1.0-dev or
IIRC this is the one test case that fails from time to time. The test
case is probably wrong itself.
Ha, found it [1]. See Carsten's reply to my mail.
Joerg
[1] http://marc.info/?l=xml-cocoon-devm=116647934703319w=4
On 03.01.2008 17:10 Uhr, Antonio Gallardo wrote:
Hi,
Not sure if this 1
On 02.01.2008 11:26 Uhr, Robin Wyles wrote:
Looking at the pom I don't see any version numbers, but the dependencies
seem to be:
cocoon-core
cocoon-eventcache-impl
excalibur-datasource
servlet-api
From what I know in this case these versions are in the parent POM. And
all these
On 03.01.2008 8:36 Uhr, Grzegorz Kossakowski wrote:
But I forgot about one more thing: in a trunk we are having Forms
1.1.0-SNAPSHOT so your fix landed
there. We increased version number due to Springification process that was
rather major change.
If you want to backport your fix to 1.0.0
On 02.01.2008 20:48 Uhr, Jörg Heinicke (JIRA) wrote:
[
https://issues.apache.org/jira/browse/COCOON-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jörg Heinicke closed COCOON-2052.
-
Resolution: Fixed
On 31.12.2007 8:58 Uhr, Grzegorz Kossakowski wrote:
-/*
- * (non-Javadoc)
- *
- * @see javax.servlet.ServletRequest#getProtocol()
- */
public String getProtocol() {
return PROTOCOL;
}
Was there any good reason for removing these comments?
I have
On 31.12.2007 8:49 Uhr, Grzegorz Kossakowski wrote:
Do you have any clue what's wrong? May it be a classpath issue? (some old
version of Xalan/Xerces
from Java 1.4 or something like this?)
Even with Java 1.4 the Xalan version we specified should be used. Maybe
we should add a test case
On 31.12.2007 10:20 Uhr, Grzegorz Kossakowski wrote:
Do you have any clue what's wrong? May it be a classpath issue? (some
old version of Xalan/Xerces
from Java 1.4 or something like this?)
Even with Java 1.4 the Xalan version we specified should be used. Maybe
we should add a test case that
On 31.12.2007 4:41 Uhr, Carsten Ziegeler wrote:
i've put up the 2.1.11 release at:
http://people.apache.org/~cziegeler/releases/cocoon/
please check, verify and cast your votes.
+1
Joerg
On 28.12.2007 11:19 Uhr, Bertrand Delacretaz wrote:
IIUC (please correct me if I'm wrong), solprovider has commit rights
on Cocoon by way of being a Lenya committer - that's fine, but we
expect you guys to ask on list before committing stuff.
In other words, commits from non-Cocoon committers
On 27.12.2007 15:00 Uhr, Grzegorz Kossakowski wrote:
Second, that's not quite correct. Xalan 2.7.1 fixes the issue. Our
DOMBuilder is only a wrapper. It does not replace the Xalan DOMBuilder
at all.
I'm not sure if it's only me but this wrapper is not as simple as I would like
to see it.
On 27.12.2007 21:51 Uhr, Reinhard Poetz wrote:
How about
servlet:com.mycompany.project.servlet.service:!/test/foo/bar
Hmmm, I'm not perfectly happy with this solution either. In this case
the path is enriched with information that actually belongs to the
sub-protocol part of the URI.
I remember there have often been issues with either encoding or binary
files. I have no idea if that's still the case and I'm ok with the
change. I also looked into the revision log of the file [1] but could
not find anything particular (only last 4 years available).
Joerg
[1]
On 26.12.2007 20:09 Uhr, Grzegorz Kossakowski wrote:
URL: http://svn.apache.org/viewvc?rev=597535view=rev
Log:
Fix FlowJXPathSelectionList test-case in a different way:
Since it was the test case that's broken, not our code, fix the issue
in the test case.
Modified:
Just curious: Is there a reason for having identical TraxTransformer and
XSLTTransformer? If it is just for the name why does the one not extend
the other?
Joerg
On 18.12.2007 22:50 Uhr, Antonio Gallardo wrote:
Here is the full 2.1 series release dates:
Version 2.1 (August 12 2003)
Version 2.1.1 (September 05 2003)
Version 2.1.2 (September 30 2003)
Version 2.1.3 (November 13 2003)
Version 2.1.4 (February 12 2004)
Version 2.1.5.1 (July 9 2004)
Version
On 04.12.2007 5:44 Uhr, Thorsten Scherler wrote:
http://vmbuild.apache.org/continuum/buildResult.action?buildId=25860projectId=51
...
Changed: thorsten @ Tue 4 Dec 2007 01:47:53 -0800
Comment: Making Paginator spring enable
Files changed:
On 26.11.2007 21:03 Uhr, Jörg Heinicke (JIRA) wrote:
Jörg Heinicke closed COCOON-2146.
-
Resolution: Fixed
Assignee: Jörg Heinicke (was: Grzegorz Kossakowski)
URL: https://issues.apache.org/jira/browse/COCOON-2146
Sorry Grek, that
On 25.11.2007 10:45 Uhr, Grzegorz Kossakowski wrote:
PS: There is also an error somewhere with the dependencies I think. XSP
block includes Avalon Framework 4.1.3 instead of 4.3.1 which causes
bunch of problems in Eclipse. How to trace the dependencies? Grek sent
once a mail with mvn
On 23.11.2007 9:58 Uhr, Giacomo Pati wrote:
How can this be null after all? From what I see value can only be null
if value was null in the first place, i.e. before replace(..). This
means that null must already have been in the Properties object which is
kind of impossible since
On 25.11.2007 10:32 Uhr, Grzegorz Kossakowski wrote:
I added an issue with a new input module which returns the full file
path location of the base dir/resource of a block.
https://issues.apache.org/jira/browse/COCOON-2145
Can I apply the patch?
Sorry but I've no idea - I'm not clear yet on
On 22.11.2007 6:04 Uhr, Andreas Hartmann wrote:
I used an action to pass the current source resolver to the
SourceProtocolHandler, but this resulted in an NPE because the URI of
the TranscoderInput object was null. After I applied a little patch to
the SourceProtocolHandler which enabled the
On 25.11.2007 23:47 Uhr, Joerg Heinicke wrote:
PS: There is also an error somewhere with the dependencies I think. XSP
block includes Avalon Framework 4.1.3 instead of 4.3.1 which causes
bunch of problems in Eclipse. How to trace the dependencies? Grek sent
once a mail with mvn project-info
Is there any reason why we create a new BeanDefinitionStoreException
from a BeanDefinitionStoreException? Do we add more information? Is
there a reason for getting rid of the root cause?
AbstractSettingsBeanFactoryPostProcessor:
protected void processProperties(ConfigurableListableBeanFactory
On 22.11.2007 16:06 Uhr, Vadim Gritsenko wrote:
And what can be the actual reason for the error. I grepped the code
base and did not find any reference to 'file-generator.pool-max'.
My first guess was that somebody tries to set this property but Spring
doesn't find a placeholder where this
On 22.11.2007 10:49 Uhr, [EMAIL PROTECTED] wrote:
Author: giacomo
Date: Thu Nov 22 07:49:00 2007
New Revision: 597440
URL: http://svn.apache.org/viewvc?rev=597440view=rev
Log:
fixing NPE
Modified:
On 22.11.2007 20:13 Uhr, Vadim Gritsenko wrote:
I wonder where he got this sitemap code from when we have them all
declared in Spring config now.
I think he mentioned that it was copied from 2.1
We did not replace placeholders in 2.1, did we?
Joerg
On 21.11.2007 8:47 Uhr, Ard Schrijvers wrote:
BTW IncludeTransformer operation can not be changed easily.
If you try to resolve each included URI, to check its new key
and validity, you'd also have to parse (or store somewhere!)
included parts in order to resolve nested includes - if
I wanted to try the servlet service samples, but I did not find them
linked in the samples. So I just tried
http://localhost:/cocoon-servlet-service-sample/ following the
scheme of the other blocks but I get some error messages which I can not
really interpret..
In the browser I see the
On 02.11.2007 18:24 Uhr, [EMAIL PROTECTED] wrote:
Author: gkossakowski
Date: Fri Nov 2 15:24:41 2007
New Revision: 591496
URL: http://svn.apache.org/viewvc?rev=591496view=rev
Log:
Fixed FlowJXPathSelectionList test-case by:
* fixed generation of SAX stream so if it is serialized it
On 22.11.2007 22:49 Uhr, [EMAIL PROTECTED] wrote:
Author: joerg
Date: Thu Nov 22 19:49:58 2007
New Revision: 597535
URL: http://svn.apache.org/viewvc?rev=597535view=rev
Log:
Fix FlowJXPathSelectionList test-case in a different way:
Since it was the test case that's broken, not our code, fix the
On 23.11.2007 2:04 Uhr, Ralph Goers wrote:
I'm not sure why you are asking but, the sitemap he showed must have
come from 2.1 and would be valid there. Carsten originally wrote the
support for replaceable properties in 2.2. I ported some of that back to
2.1 quite a while ago. Carsten's code in
On 19.11.2007 17:54 Uhr, Alfred Nathaniel wrote:
If I get enough positive feedback about the current state I'm happy to
prepare a release of 2.1.11 in December.
+1 I'd like to have a final 2.1 release as well.
Joerg
On 13.11.2007 8:06 Uhr, [EMAIL PROTECTED] wrote:
Author: felixk
Date: Tue Nov 13 05:06:32 2007
New Revision: 594521
URL: http://svn.apache.org/viewvc?rev=594521view=rev
Log:
Don't catch RuntimeException, otherwise hardcoded deprecation of
On 07.11.2007 15:52 Uhr, Grzegorz Kossakowski wrote:
Now, at some point we have to break compatibility to get a cleaner
architecture and an even better way of doing things. Perhaps removing
sub sitemaps is one of these things, perhaps not.
Before we start to think about migration path and
On 03.11.2007 7:30 Uhr, [EMAIL PROTECTED] wrote:
Author: felixk
Date: Sat Nov 3 04:30:13 2007
New Revision: 591599
URL: http://svn.apache.org/viewvc?rev=591599view=rev
Log:
Method invokes inefficient Boolean constructor; use Boolean.valueOf(...) instead
Creating new instances of
It's probably better to ask such questions on the dev list. I have no
idea in which state the validation block is. Anybody else?
Joerg
On 24.10.2007 5:00 Uhr, Jean-Claude Vogel wrote:
Hello,
I would like to use cocoon-validation-impl block in my project to have XSD
validation availability.
Both trunk and 2.1 branch seem to have a problem ...
Another, totally unrelated problem:
link from http://cocoon.apache.org/2.2/1347_1_1.html to FOPNGSerializer
(http://cocoon.apache.org/2.2/blocks/fop/1.0/1333_1_1.html) is a 404.
Joerg
On 10/17/07 12:20 PM, Tobia Conforto wrote:
But I cannot pass null to my own input module in place of the third
parameter (Map objectModel) because I use that objectModel in my class!
Is this the recommended way of accessing input modules from flowscript?
If so, how do I pass it the
On 17.10.2007 15:35 Uhr, Grzegorz Kossakowski wrote:
The reason is crap code in the maven release plugin!
See http://jira.codehaus.org/browse/MRELEASE-255
I thought that in these days reliable handling of XML is just a must... :-)
OT: Unfortunately, Maven guys are not the only ones:
On 10/17/07 5:27 PM, András Hatvani wrote:
I would like to work on the Cocoon Profiler, but since I never worked
on an open source project I have no idea where to start.
Can you please advise me where to start?
What exactly do you have in mind? Have you already been working with it
and do
On 15.10.2007 3:38 Uhr, Reinhard Poetz wrote:
I've prepared another series of releases from trunk, see the list of all 45
artifacts below. This time most of the modules are proposed to be
released as RC2 (release candidate 2) or RC1.
+1
Joerg
Hey Lenya developers,
would be nice if you could change the template that is used for
displaying an error so that you get these reports and not Cocoon :-)
Regards
Joerg
On 16.10.2007 9:04 Uhr, Anirudhdha Jani (JIRA) wrote:
Problems using lenya 1.2 with JBOSS application server. doesnt
On 10.10.2007 4:45 Uhr, Leszek Gawron wrote:
1. Can somebody tell me why do we need all these:
protected static final ContentHandler EMPTY_CONTENT_HANDLER = new
DefaultHandler();
/** The codeXMLConsumer/code receiving SAX events. */
protected XMLConsumer xmlConsumer;
/** The
On 09.10.2007 9:44 Uhr, Reinhard Poetz wrote:
At CocoonGT we had some sort of agreement to create optional modules
Please, no more modules. It is bad already as it is - adding *more*
modules only makes it worse. What's wrong with simply deprecating
them, with placing appropriate javadoc?
On 09.10.2007 16:44 Uhr, Felix Knecht wrote:
Maybe we should create new AbstractXMLProducer implementation that is free of
Avalon interfaces?
I think we should try to get Avalon free implementations (especially for
Abstract classes) as soon as possible. This
will make springification of
On 09.10.2007 16:19 Uhr, Grzegorz Kossakowski wrote:
After taking quick look on this problem I saw that JXTemplateGenerator is
broken by the fact that it
implements (indirectly, by extending AbstractXMLProducer) Recycable interface.
Implementing this
interface makes JXTemplateGenerator
On 30.09.2007 17:02 Uhr, [EMAIL PROTECTED] wrote:
Author: danielf
Date: Sun Sep 30 14:02:24 2007
New Revision: 580786
URL: http://svn.apache.org/viewvc?rev=580786view=rev
Log: Spring-OSGi doesn't contain any support for beans with prototype
scope. This is mainly because there is no direct
On 28.09.2007 5:05 Uhr, Robby Pelssers wrote:
I forgot to mention we are working with cocoon-2.1.10. Did somebody
already try to use a newer version of FOP for this cocoon version?
So far it should still be pretty straight-forward to use a 2.2 block in
2.1 as long as it has not been
Vadim Gritsenko vadim at reverycodes.com writes:
... I forgot to mention we are working with cocoon-2.1.10. Did somebody
already try to use a newer version of FOP for this cocoon version?...
I think that's what http://issues.apache.org/jira/browse/COCOON-1795
does - some assembly
On 25.09.2007 15:45 Uhr, Vadim Gritsenko wrote:
Our problem is not minimum Java requirement for Cocoon 2.2. The problem
is release time lines. [..] Java requirements? Nah, that's peanuts...
Thanks, you hit the nail. When was the vote? 1 year ago?
Despite being still convinced that raising
On 28.09.2007 0:46 Uhr, Ralph Goers wrote:
I'm sure we could find a way to take advantage of NIO if we
really thought about it. But we can't do any of that
because we are stuck at 1.4.
NIO is 1.4.
Joerg
On 25.09.2007 16:20 Uhr, Felix Knecht wrote:
May I ask why can't just make a jump and goto java 1.6?
What's the benefit of using not the latest version - do any contracts
exists that we can't jump over a java version?
And what's the use of it? I just don't get it why a framework should set
On 28.09.2007 0:46 Uhr, Ralph Goers wrote:
However, the language features of 1.5 are worth it.
For example, I would love to replace some pieces of
code that require synchronized blocks with java.util.concurent. I would
love to be able to specify the object types on Maps and Lists. It just
On 19.09.2007 3:12 Uhr, Carsten Ziegeler wrote:
This code was updated on 20.07.2007 with the upgrade to sourceresolve
2.2.3 (rev 557982 and 557994 [1, 2] and 557984 on 2.1 [3]). Since then
it must be failing. From what I get it's now failing for Windows with 2
slashes while the test expects 3.
On 19.09.2007 7:54 Uhr, Felix Knecht wrote:
PS:
Of course now the zip... testcase fails under linux because of commit
577108 again ;-)
You can easily fix this by adding the slash back to the test case locally.
Joerg
On 19.09.2007 8:35 Uhr, Carsten Ziegeler wrote:
But, I think that we need the three slashes in some cases, as the uri is
otherwise not parsable as a uri again. Although its not a correct uri it
works whereas the correct uri does not.
But before we had any os-specific refinement it worked for
On 19.09.2007 8:25 Uhr, Joerg Heinicke wrote:
But can you place double-check that?
... please ...
Joerg
On 19.09.2007 7:11 Uhr, [EMAIL PROTECTED] wrote:
URL: http://svn.apache.org/viewvc?rev=577245view=rev
Log:
COCOON-2134: Implemented Disposable interface in
StringTemplateParserVariableResolver.
I wonder why a Spring-configured bean has to implement Avalon interfaces
especially since it is
On 19.09.2007 18:22 Uhr, Grzegorz Kossakowski wrote:
As you see, this pipeline just process simple JX template that tries to access
one variable
(status.myTasks) and fails at this point. It must fail (by throwing NPE)
because there is no
status.myTasks variable in OM! It's the flowscript code
On 19.09.2007 19:20 Uhr, Vadim Gritsenko wrote:
Whether there is a variable set or not, a NPE is never good sign.
Shouldn't this case be handled? Spring for example throws a
NullValueInPathException instead.
No. No to exception :)
I suspect in this particular case (CTemplate) no exception
On 19.09.2007 11:32 Uhr, Daniel Fagerstrom wrote:
While we have a historical tradition of using 2 slashes, but it is wrong
according to the URL standard
(http://gbiv.com/protocols/uri/rfc/rfc3986.html). 1 or 3 slashes is
correct. No idea about how we should handle this fact though ;)
Ok,
On 18.09.2007 14:43 Uhr, Grzegorz Kossakowski wrote:
No failures in the biggest report! And next biggest, and so on...
Text instead of XML reports should be working. Nevertheless, you have found
more reliable way.
I think the problem is that many tests work with expected exceptions and
On 18.09.2007 19:34 Uhr, Joerg Heinicke wrote:
// toExternalForm() is buggy, see e.g.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4924415
// therefore we check if file: is followed by just one slash
// TODO when we move to JDK 1.4+, we should use
file.toURI().toASCIIString() instead
On 18.09.2007 7:45 Uhr, Reinhard Poetz wrote:
Test set: org.apache.cocoon.components.source.impl.ZipSourceTestCase
---
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.03 sec
FAILURE!
On 17.09.2007 3:53 Uhr, Carsten Ziegeler wrote:
Too many files confuse users, so I would go to put everything in a
single file and only if it makes sense to split it, start a new file.
+1
Joerg
On 14.09.2007 10:46 Uhr, Grzegorz Kossakowski wrote:
Speaking more generally I don't think that whiteboard is a good place. What I
would like to see is:
1. You create branch (like cocoon-forms-1.0.X) in our branches folder
2. We release subsequent candidates for 1.0.0 from that branch and
On 30.08.2007 18:57 Uhr, Joerg Heinicke wrote:
EncodeUrlTransformer [1]
[1] http://cocoon.apache.org/2.1/userdocs/encodeurl-transformer.html
When searching for the exact name I tried to use our API, but the
EncodeUrlTransformer is not included. Any idea why?
Joerg
of them.
Which one gets compiled depends on the version of the compiler you are
using. The jdk1.4 version performs much better and doesn't have the
potential for a StackOverflow like the jdk 1.3 version does.
Ralph
Joerg Heinicke wrote:
On 30.08.2007 18:57 Uhr, Joerg Heinicke wrote
On 27.08.2007 4:17 Uhr, Leszek Gawron wrote:
ok, int this case cocoon template behaves properly:
root xmlns:jx=http://apache.org/cocoon/templates/jx/1.0;
foo:foo xmlns=http://foor.org/bar/1.0;
something/
/foo:foo
foo:foo
something/
/foo:foo
/root
raises an
On 27.08.2007 7:35 Uhr, Carsten Ziegeler wrote:
Actually I don't know - this is a think I have on my long
nice-to-have-wish-list-for-cocoon for years now, but never had time to
look into. I hope that we could just reuse something - if we have to
implement the whole stuff ourselves, then I would
On 27.08.2007 7:38 Uhr, Carsten Ziegeler wrote:
I'm wondering what the opinion about the future of our cron block is? Do
we need such a thing at all? Could we just use the quartz support of Spring?
I'd go with Spring's Quartz integration. Our cron block has (most
probably) nothing to do with
On 26.08.2007 16:07 Uhr, Grzegorz Kossakowski wrote:
Are these valid xml files?:
Nit-picking: None of them is valid as there is nothing to validate
against like a DTD or a schema. You can only talk about well-formedness.
root
foo:foo xmlns:foo=http://foo.org/1.0;
/foo:foo
!--
On 26.08.2007 7:29 Uhr, Grzegorz Kossakowski wrote:
Unexpectedly, Nils Kaiser has come up with much better and, in general, less
intrusive solution. He
proposed[3] to introduce custom fields where information about version specific
to the *component*
would be stored.
I don't want to rain on
101 - 200 of 1595 matches
Mail list logo
