Re: Web Service for a generator
Jean-Claude Moissinac wrote: Hello I plan to write a generator which gets his data from a web service. Someone interested? Your inputs and advices are welcome. There are two already, I believe, in the proxy and web3 blocks. Better to merge those, and extend that as necessary, than to create another! Regards, Upayavira
Re: RresultSet within JXTemplate?
Stephan Coboos wrote: Hello, is it possible to set a java.sql.ResultSet witin a JXTemplate and then iterate over the contents? I need this way to print out > 60 Elements from a database into an xml. So it is not possible to create beans before. First answer: dunno. Second answer: does ResultSet implement java.util.Collection? If so, I suspect you could do it. Third answer: if ResultSet doesn't implement Collection, then you could write a simple wrapper class that does, along with a simple implementation of Iterator, that can iterate over the rows of a ResultSet. Hope that helps. Upayavira
Re: [QVOTE] Locking Down CVS
Vadim Gritsenko wrote: Hi All, Next step in CVS to SVN migration is locking down CVS and doing real conversion into SVN. I propose to lock down CVS today evening (say, 4pm on US east coast). How is everybody with this decision? Vadim Go for it, I say! Upayavira
Re: new wiki, editing permissions
[EMAIL PROTECTED] wrote: hi people how can someone obtain editing permissions for the new cocoon's wiki i want to update some pages i have add in the previews system, and add some examples Click on UserPreferences at top right, create an account for yourself, and you'll be able to edit away. Upayavira
Re: spam/viruses from andrew@luminas.co.uk
Ralph Goers wrote: I have a filter that routes messages with "to" or "cc" as [EMAIL PROTECTED] to a separate folder. The "spam" messages purportedly from you don't get routed there, but are left in my inbox, so they are easy to delete. The one below did get routed to the folder. Since I don't open the spam messages before deleting them, I don't really know how they are different. Actually going to [EMAIL PROTECTED] Why does that work? Upayavira
Re: JCS logging
Dave Brondsema wrote:
Upayavira wrote:
The CLI way would be to add a property tag into the cli.xconf. Now, this
would be a pretty trivial fix to one Cocoon class. Is this what would be
needed?
Sounds like it to me. Can we try it?
Don't have time to do _any_ testing on this (shouldn't really have been
doing this little bit). Here's a patch for
o.a.c.bean.helpers.BeanConfigurator.
Try this. This should mean that you can put into cli.xconf. If it works, either commit it if you
can, or tell me and I will.
(watch out for the email wrapped line!)
Regards, Upayavira
Index: src/java/org/apache/cocoon/bean/helpers/BeanConfigurator.java
===
RCS file:
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/bean/helpers/BeanConfigurator.java,v
retrieving revision 1.8
diff -u -r1.8 BeanConfigurator.java
--- src/java/org/apache/cocoon/bean/helpers/BeanConfigurator.java28
Mar 2004 20:51:24 -1.8
+++ src/java/org/apache/cocoon/bean/helpers/BeanConfigurator.java22
Jul 2004 14:00:01 -
@@ -90,6 +90,9 @@
private static final String ATTR_URI_SOURCEURI = "src";
private static final String ATTR_URI_DESTURI = "dest";
+private static final String NODE_SYSPROP = "system-property";
+private static final String ATTR_SYSPROP_NAME = "name";
+private static final String ATTR_SYSPROP_VALUE = "value";
private static final String NODE_URIS = "uris";
private static final String ATTR_NAME = "name";
@@ -213,6 +216,9 @@
} else if (nodeName.equals(NODE_URIS)) {
parseURIsNode(cocoon, node, destDir, uriGroup);
+} else if (nodeName.equals(NODE_SYSPROP)) {
+parsePropertyNode(cocoon, node);
+
} else if (nodeName.equals(NODE_URI_FILE)) {
if (hasAttribute(root, ATTR_URI_FILE)) {
throw new IllegalArgumentException("Cannot have
"+NODE_URI_FILE+" as both element and attribute");
@@ -241,6 +247,20 @@
if (nodes.getLength()!=0) {
throw new IllegalArgumentException("Unexpected children of
<" + NODE_LOGGING + "> node");
}
+}
+
+private static void parsePropertyNode(CocoonBean cocoon, Node node)
throws IllegalArgumentException {
+NodeList nodes = node.getChildNodes();
+if (nodes.getLength()!=0) {
+throw new IllegalArgumentException("Unexpected children of
<" + NODE_LOGGING + "> node");
+}
+if (!hasAttribute(node, ATTR_SYSPROP_NAME) ||
!hasAttribute(node, ATTR_SYSPROP_VALUE)) {
+throw new IllegalArgumentException("A property node
requires both name and value attributes");
+}
+String name = getAttributeValue(node, ATTR_SYSPROP_NAME);
+String value = getAttributeValue(node, ATTR_SYSPROP_VALUE);
+
+System.setProperty(name, value);
}
private static void parseIncludeLinksNode(CocoonBean cocoon, Node
node) throws IllegalArgumentException {
Re: [butterfly] spring dependant tests (was Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?))
Nicola Ken Barozzi wrote: What about a mailing list? We're having an unpleasant discussion about creating mailing lists on the community list... ugh IMO the right thing is to ask a vote for it, and then ask infra to set it up as per the Cocoon PMC decision. I don't want to see another mailing list. That would create a fork of Cocoon, which is _not_ what I understand you as trying to do. All discussion of Butterfly _must_ happen here, so that we all have some oversight over what is going on, whether we want to participate or not. (I'm sure we're all skilled enough at skipping irrelevant messages, aren't we!) Regards, Upayavira
Re: JCS logging
Vadim Gritsenko wrote: Dave Brondsema wrote: On Thu, 15 Jul 2004, Dave Brondsema wrote: We at Forrest are seeing more JCS log messages than we want. I tried setting up a log4j.properties file to control it, but that didn't seem to work. At any rate, it looks like they're using commons logging now, so according to http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108665505130942&w=2 it can be controlled with LogKit by cocoon. Could somebody do this? Since nobody is eager to do this, could give me some guidance so I can do it myself? What files would I have to edit? How does logkit work in cocon? If you declare system variable: org.apache.commons.logging.Log=org.apache.commons.logging.impl.LogKitLogger commons logging will use LogKit. See web.xml, force-property parameter. LogKit is set up by CocoonServlet. Are you suggesting setting this property in web.xml? Well, as Forrest uses the CLI, they won't use a web.xml. The CLI way would be to add a property tag into the cli.xconf. Now, this would be a pretty trivial fix to one Cocoon class. Is this what would be needed? Regards, Upayavira
Re: Remove sending the mail adresses in Wiki diff messages
Reinhard Poetz wrote: Is there a way to avoid sending our mail adresses in Wiki diff messages? AFAIK also cocoon-docs is archived and public available. Send to [EMAIL PROTECTED] This is now an apache wide wiki, and such questions are best dealt with there. There's a wider range of people with wiki knowledge there. Regards, Upayavira
Re: Xindice on Jetty
Andrew Thornton wrote: Upayavira wrote: Andrew Thornton wrote: Hi. I'm trying to get the embedded Xindice working with Cocoon 2.1.5 on Jetty. All works fine when starting up the servlet engine, and I'm able to create and drop collections and resources. However when I shutdown the servlet engine and restart it I find that I have lost data from the collections tree. Has anyone got any ideas as to how to fix this? (I'm using the standard configuration that comes with Cocoon 2.1.5 for this.) (a) Make sure you'e not using the Xindice command line tools to access the same database. That will not work, and you'll find collections disappearing Definitely not doing this. (b) Make sure you don't store the database within Jetty's work directory. That gets removed each time jetty restarts. Store it instead, say, in WEB-INF/db How do you mean? I've tried using the db-home to set it to /var/xindice/db. And is that where your DB is? If that is the case, then my guesses are wrong, and I'm out of ideas :-( Regards, Upayavira
Re: Xindice on Jetty
Andrew Thornton wrote: Hi. I'm trying to get the embedded Xindice working with Cocoon 2.1.5 on Jetty. All works fine when starting up the servlet engine, and I'm able to create and drop collections and resources. However when I shutdown the servlet engine and restart it I find that I have lost data from the collections tree. Has anyone got any ideas as to how to fix this? (I'm using the standard configuration that comes with Cocoon 2.1.5 for this.) (a) Make sure you'e not using the Xindice command line tools to access the same database. That will not work, and you'll find collections disappearing (b) Make sure you don't store the database within Jetty's work directory. That gets removed each time jetty restarts. Store it instead, say, in WEB-INF/db Regards, Upayavira
Re: Questions about the CocoonTask class
Carsten Ziegeler wrote:
The CocoonTask class in o.a.c has a javadoc error for
the execute() method:
/**
* Do the execution and return a return code.
*
* @return the return code from the execute java class if it was
* executed in a separate VM (fork = "yes").
*
* @throws BuildException if required parameters are missing
*/
public void execute() throws BuildException {
// FIXME - This is never read
int err= -1;
This method doesn't return anything, so the javadoc is wrong. It seems
that the original author wanted to return the int "err", but the
signature of execute() (from Ant's Task class) doesn't allow this.
I guess that a BuildException should be thrown?
To be honest, I hadn't got my head around how to handle error conditions
within the task. Maybe it should throw a BuildException, but as you
observed, I didn't quite know what to do with this error - my Ant
knowledge was too shaky (and stil is) to work out exactly what to do. Do
you have any ideas of the best way to handle error reporting here?
The CocoonTask is based upon a simplified Java task, taken from within
Ant itself, and with references to forking and a lot of other stuff
removed.
Regards, Upayavira
Re: [RT] Document based I18n sites with Cocoon
Sjur Nørstebø Moshagen wrote:
På 9. jul. 2004 kl. 14.04 skrev Vadim Gritsenko:
Sjur Nørstebø Moshagen wrote:
I guess the full list would be: {lang}, {country}, {encoding},
{variant}, {full-locale}, {matched-locale}. {locale} could be a
shorthand for {full-locale}.
This list should be compatible with LocaleAction: language (not
lang), country, variant.
Another point to remember to be compatible with LocaleAction:
Upayavira originally wrote:
The site will cater for locale provided as a request parameter, as
the one of the acceptable locales configured within the browser, or
as a site default.
If possible this should also be enhanced to look for a 'locale'
session attribute, or cookie, cf.
<http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/acting/
LocaleAction.html>:
The following search criteria are used in order when ascertaining
locale values:
1. Request CGI parameter locale
2. Session attribute locale
3. First matching Cookie parameter locale within each
cookie sent with the current request
4. Locale setting of the requesting object
The site default would then be the fift case.
I've committed it as it was. If you fancy making a patch to add that
functionality, feel free!
I'm now going to get on with the CLI functionality.
Regards, Upayavira
Re: Migrating Processor & Pipeline to ServiceManageable
Unico Hommes wrote: Sylvain Wallez wrote: Unico Hommes wrote: Btw. The only code I use from the treeprocessor is the variable resolver stuff. I think this code is of general enough interest to dedicate its own subpackage for (away from treeprocessor). I noticed Carsten currently has duplicated that code in the portal block. WDYT? I use the variable resolver also ;-) For now I changed it so that it accepts both ServiceManager and ComponentManager. IMO, we should not make a component with the variable resolver, but some utility class providing some common base resolution (e.g. input modules) yet allowing extensions in the places where it is used (e.g. named anchors and parent stack in the sitemap). I feel the same way. Your plan sounds like a clean solution to me. Should nested variable resolving be optional though? Perhaps in cases where it is not needed it would optimize performance to turn it off? It might be an option when getting a variable resolver from the factory or else when calling the resolve method on a variable resolver. Although I have no figures to put behind it, my impression is that the nested variable resolver would not be any less performant that its predecessor. It just makes sensible use of a stack and reverse polish notation (or some such). Upayavira
Re: [RT] Document based I18n sites with Cocoon
Vadim Gritsenko wrote:
Upayavira wrote:
Sjur Nørstebø Moshagen wrote:
På 9. jul. 2004 kl. 14.04 skrev Vadim Gritsenko:
I guess the full list would be: {lang}, {country}, {encoding},
{variant}, {full-locale}, {matched-locale}. {locale} could be a
shorthand for {full-locale}.
This list should be compatible with LocaleAction: language (not
lang), country, variant.
Agree.
Site default locale is defined within the config of the matcher
at the top of the sitemap. It could easily be overridden with a
within the
matcher itself.
OK.
If no default is given, it should defaults to empty locale.
Ok, but how do you decide which document version to serve then? Or
should Cocoon throw an error ("No resource found")?
Exactly, if no default is given, the matcher doesn't match.
No, it should match document without locale - same behavior we have
now. Given your example:
file.ru_EE-KOI8.xml
file.ru_EE.xml
file.ru.xml
file.xml
And if none of the files above are present, *then* it should not match.
Hmm. But the matcher says pattern="file.*.xml" where the * is the
locale. Now file.xml cannot match that pettern.
So we'd need to build in a special case, which says something like, if
the characters before and after the locale are the same, then only use
one of those characters when looking for a default file.
This would allow it to cater for:
contents/ru_EE/file.xml
contents/file.xml
as well as your naming scheme above.
Does this seem reasonable?
Upayavira
Re: Cocoon 2.1.5.1 uploaded
Upayavira wrote: Carsten Ziegeler wrote: Upayavira wrote: Carsten Ziegeler wrote: I just created a branch in CVS, fixed the problem and tagged the release as 2.1.5.1. The release is now in the dist directory and I removed the 2.1.5 dist from there. What else should we do? Remove the 2.1.5 from the archives? Add a statement to the website? Create an announcement (when the mirrors are uptodate)? Personally, I'd say, just update any statements about the latest version to be 2.1.5.1, and put a file in the dist folder called something like cocoon-2.1.5-removed.txt which is just a notice for people looking for it, telling them to use 2.1.5.1. That way new people get the new version, people looking for the old will know where they should go. Reasonable? Yes. Can you (or please someone else) put this file on the server? I'm currently a little bit busy :) Where? Done.
Re: Cocoon 2.1.5.1 uploaded
Upayavira wrote: Carsten Ziegeler wrote: Upayavira wrote: Carsten Ziegeler wrote: I just created a branch in CVS, fixed the problem and tagged the release as 2.1.5.1. The release is now in the dist directory and I removed the 2.1.5 dist from there. What else should we do? Remove the 2.1.5 from the archives? Add a statement to the website? Create an announcement (when the mirrors are uptodate)? Personally, I'd say, just update any statements about the latest version to be 2.1.5.1, and put a file in the dist folder called something like cocoon-2.1.5-removed.txt which is just a notice for people looking for it, telling them to use 2.1.5.1. That way new people get the new version, people looking for the old will know where they should go. Reasonable? Yes. Can you (or please someone else) put this file on the server? I'm currently a little bit busy :) Where? Found it. Writing now... Upayavira
Re: Cocoon 2.1.5.1 uploaded
Carsten Ziegeler wrote: Upayavira wrote: Carsten Ziegeler wrote: I just created a branch in CVS, fixed the problem and tagged the release as 2.1.5.1. The release is now in the dist directory and I removed the 2.1.5 dist from there. What else should we do? Remove the 2.1.5 from the archives? Add a statement to the website? Create an announcement (when the mirrors are uptodate)? Personally, I'd say, just update any statements about the latest version to be 2.1.5.1, and put a file in the dist folder called something like cocoon-2.1.5-removed.txt which is just a notice for people looking for it, telling them to use 2.1.5.1. That way new people get the new version, people looking for the old will know where they should go. Reasonable? Yes. Can you (or please someone else) put this file on the server? I'm currently a little bit busy :) Where? Carsten
Re: [RT] Document based I18n sites with Cocoon
Sjur Nørstebø Moshagen wrote:
På 9. jul. 2004 kl. 14.04 skrev Vadim Gritsenko:
I guess the full list would be: {lang}, {country}, {encoding},
{variant}, {full-locale}, {matched-locale}. {locale} could be a
shorthand for {full-locale}.
This list should be compatible with LocaleAction: language (not
lang), country, variant.
Agree.
Site default locale is defined within the config of the matcher at
the top of the sitemap. It could easily be overridden with a
within the
matcher itself.
OK.
If no default is given, it should defaults to empty locale.
Ok, but how do you decide which document version to serve then? Or
should Cocoon throw an error ("No resource found")?
Exactly, if no default is given, the matcher doesn't match.
Upayavira
Re: Cocoon 2.1.5.1 uploaded
Carsten Ziegeler wrote: I just created a branch in CVS, fixed the problem and tagged the release as 2.1.5.1. The release is now in the dist directory and I removed the 2.1.5 dist from there. What else should we do? Remove the 2.1.5 from the archives? Add a statement to the website? Create an announcement (when the mirrors are uptodate)? Personally, I'd say, just update any statements about the latest version to be 2.1.5.1, and put a file in the dist folder called something like cocoon-2.1.5-removed.txt which is just a notice for people looking for it, telling them to use 2.1.5.1. That way new people get the new version, people looking for the old will know where they should go. Reasonable? Regards, Upayavira
Re: [RT] Document based I18n sites with Cocoon
Sjur Nørstebø Moshagen wrote:
Yesterday Upayavira wrote:
Introducing the I18NMatcher
---
Here's a sample sitemap snippet:
Once an ordinary wildcard matcher has done its job, in comes the i18n
matcher. Its job is to see whether it can find a suitable source
document for the requested page. The * is used to symbolise the place
where the locale is to be placed. If a match is successful, it will
make sitemap variables available for the source that was found, and
the locale that matched.
Now, this seems to be quite in keeping with the Cocoon sitemap model,
and gives some rather nice, flexible functionality.
What do you all think?
This looks great! Exactly what I need;)
Firstly, thank you for your thorough response!
A couple of small questions for clarification:
1) The requested locale might be complex in the sense that it contains
more information than merely the preferred language (e.g. en_GB,
de_AU, sv_FI, ru_EE-KOI8). The {source} returns the best match given
the available documents, but what would the {locale} be, given that
{source} is not a complete match for the requested locale? One
beneficial approach would IMHO be to return the "complete" locale that
matched the returned document. To illustrate:
The locales requested as above: en_GB, de_AU, sv_FI, ru_EE-KOI8
Available documents: content/de/foo.xml, content/sv/foo.xml
{source} = content/de/foo.xml
{locale} = de_AU
The way it is currently coded, if de_AU was not found, it wouldn't find
de. Which is not ideal. I'll extend it so that for ru_EE-KOI8 it will try:
* ru_EE-KOI8
* ru_EE
* ru
in turn. Is that the correct behaviour?
This way it is possible for the subsequent i18n processing to cater
for country-(or whatever)-specific requirements in menus etc. without
the document itself necessarily being adjusted for such variation.
Then, we can have {matched-locale} being the one that was actually
matched, e.g. ru_EE, {full-locale} being the full, original locale that
caused the match, e.g. ru_EE-KOI8. That's easy, it is just a question of
chosing decent names.
2) What happens if the locale of the returned document is not
available in the rest of the i18n chain? There are at least two
possible solutions:
- just use the default locale
- provide in {locale} not only the returned locale of the document,
but the whole list of preferred locales _from the document match on_.
In the example above that would have given:
Making various bits of the locale available would allow the site
developer handle this as they please. {lang}, {locale}, {encoding}, etc,
etc as well as the above.
{locale} = de_AU, sv_FI, ru_EE-KOI8
That would be {locales}
Pros: This might be considered a better aproach by the user, as the
further i18n processing will return locales more preferred than the
default
Cons: This might appear confusing to the user, as it might not seem to
be any connection between the locale of the document and the locale of
the surrounding widgets (menus, dates, etc.).
One could even let this choice be an option, and let the
webmaster/developer decide - in the end, it is up to her/him to decide
whether such a situation will arise in the first place;) (by allowing
document languages that are not available in other parts of the
site/webapp/i18n processing).
3) How do you define the 'site default locale'? In Cocoon's existing
i18n it is done through a translation file without locale tags, but
that's hardly appropriate in this case. At the same time it would be
nice to define the default language within Cocoon, and not rely on
external settings (e.g. in the servlet, web server, etc.). Suggestions?
Site default locale is defined within the config of the matcher at the
top of the sitemap. It could easily be overridden with a within the matcher itself.
When I've finished implementing this, I'll go onto extend the CLI to
be able to work effectively with this kind on i18n site, enableing it
to crawl a site for each of a range of locales. But that's for
another time.
Looking forward to it;)))
Let's get this first bit working, first!
Great work, Upayavira, keep up!
Thanks. I'm glad to have got this one off the ground, at last, and to
have at last worked out a way that isn't just way too complicated for
sitemap developers to understand.
Regards, Upayavira
Re: XMLDBSource and credentials
Luigi Bai wrote: I'd like to modify XMLDBSource to allow the URI to override the credential information. This would allow different users to access collections/resources as themselves in eXist (http://exist.sf.net). Any objections? My first thought is to allow URIs of the form: xmldb:exist://user:[EMAIL PROTECTED]:port/coll/coll/resource.xml I take it there is no such definition of providing user/pass within the XMLDB spec? Regards, Upayavira
[RT] Document based I18n sites with Cocoon
I'm building a 'document centric' internationalised site which, to my
mind, Cocoon can't 'quite' do yet. Cocoon's i18n functionality works
well on 'webapps', where you have snippets of text to be translated, but
not when the content is whole pages.
The most complex part of this is identifying the most appropriate
language content, given the combination of the user's desired
locales/languages, and the available translations.
The site will cater for locale provided as a request parameter, as the
one of the acceptable locales configured within the browser, or as a
site default.
When a page is requested, it will look for a page with the preferred
locale (request parameter, if provided), if not found, it will look for
a page using each of the locales in turn. If none are found, the default
page is used.
So, say we have three locales to try: pt, es, en. We have resources:
content/pl/foo.xml
content/es/foo.xml
content/en/foo.xml
When the user requests foo.html, Cocoon will look to see if
content/pt/foo.xml exists. It doesn't, so it will look for
content/es/foo.xml. That it finds, so that is what it uses to as a
source for the pipeline.
Similarly, this system would be able to handle a file structure such as:
content/foo_pl.xml
content/foo_es.xml
content/foo_en.xml
Now, handling this functionality within a Cocoon component really isn't
that easy to work out. To achieve it, the component needs to take a
configurable path, e.g content/{locale}/{1}.xml, and needs to be told
what to use for finding the locale (request param, accept-language
header, default locale for site). Once it has made a decision, it might
also want to make its choice of locale available to other components
(e.g. the i18nTransformer) so that it can localise any other bits of
text on the page, e.g. navigation.
I have mulled on whether an input module, a generator or maybe an action
would do the job. In fact, I think it is a job for an I18n matcher.
Introducing the I18NMatcher
---
Here's a sample sitemap snippet:
Once an ordinary wildcard matcher has done its job, in comes the i18n
matcher. Its job is to see whether it can find a suitable source
document for the requested page. The * is used to symbolise the place
where the locale is to be placed. If a match is successful, it will make
sitemap variables available for the source that was found, and the
locale that matched.
Now, this seems to be quite in keeping with the Cocoon sitemap model,
and gives some rather nice, flexible functionality.
What do you all think?
When I've finished implementing this, I'll go onto extend the CLI to be
able to work effectively with this kind on i18n site, enableing it to
crawl a site for each of a range of locales. But that's for another time.
Regards, Upayavira
Re: [GUMP] please remove/rename the nekohtml project in Cocoon's descriptor
Stefan Bodewig wrote: Hi, Gump already has a project named nekohtml for NekoHTML 0.9.3. If this is what you need in Cocoon then please simple remove your project definition, otherwise please rename the project. Gump tries to merge the like-named project and drops both of them since their jar ids clash (and would claim there were missing build outputs if the ids didn't clash). Done. Sorry for the hassle. I'm a complete Gump newbie, and figured I would get something wrong! Regards, Upayavira
NekoHTMLGenerator and Gump
I have written a simple NekoHTMLGenerator, much like the existing one, but based around NekoHTML. This does much less clever stuff compared to JTidy, and parses to SAX events instead of via a DOM object, which should be much more efficient. I have also been told by one happy user of my generator that it fixed a problem where JTidy didn't preseve CDATA sections in scripts, or some such. The NekoHTML jar adds 46k to the distribution, and its licence is ASL1.1 based. I'd like to commit it to the HTML block. I have one question though, which relates to gump.xml. If I am adding a new jar, presumably I need to reference NekoHTML as a project. In which case, presumably the NekoHTML needs to be defined somewhere else? Or should I just not mention NekoHTML in gump.xml? Regards, Upayavira
SVN conversion (was Re: Overwrote/removed jakarta-commons website files)
Brian W.Fitzpatrick wrote: On Jul 2, 2004, at 12:42 AM, William A. Rowe, Jr. wrote: I chatted with Fitz very recently, and he's hoping folks wait to adopt his next release (coming -very- soon) of the cvs2svn tool. He's made massive improvements in the speed of conversion and resulting svn dataset. I expect he will give a yell as soon as it's ready. (He was actually hacking on the last few bugs as we were chatting a week or two ago.) While it's not 1.0 yet (a few non-correctness bugs left), it's ready. I'm planning on converting httpd-1.0 and cocoon next week, and then it's open season. -Fitz Above from Infrastructure. So it seems we can expect a conversion soon, then! Upayavira
Re: [RT] The Cocoon Handbook
Vadim Gritsenko wrote: Sylvain Wallez wrote: Now we have that nice thing called OpenOffice that is a wordprocessor storing its content as XML in a zip archive. We've used it as a front-end for a CMS, providing template documents with style sheets that have to be used. These styles match the structure of the target XML document that is produced from the OO file. This solution just rocks, as anybody (even a boss :-) is able to write content in a userfriendly and productive environment with spell checking, typing completion, etc etc. On the CMS side, the sxw archive is exploded, the XML content is transformed into the target markup (e.g. DocBook) and images are stored. Sure, for the Cocoon docs, we cannot wait to have a CMS setup and ready, or we'll never have docs ;-) What is rather simple, however, is to have some offline processing (based on the CLI) that would do the exploding/recomposition job to allow editing Cocoon docs with a real wordprocessor. It would be simplier to store docs in sxw file itself; no recomposition is necessary, and html/pdf publishing out of sxw "repository" can be added to forrest. I believe Reinhard added it a while ago. Upayavira
Re: [RT] The Cocoon Handbook
Tony Collen wrote: Upayavira wrote: Tony, I think I'd say simply that Cocoon operates as a 'do-ocracy'. He who does, chooses (usually!). It is widely accepted that something needs to happen on the docs. And really, what it is going to take is someone just getting on and doing it. I suspect that someone putting in the legwork would get a lot of support from the rest of us. That is the missing component, not the ideas. Are you offering? ;-) Yeah, more or less ;) Great! My time should be freeing up a little more in the coming week, so I'll keep progress posted in this thread. Well, why not knock something up, and show us. Regards, Upayavira
Re: [RT] The Cocoon Handbook
Tony, I think I'd say simply that Cocoon operates as a 'do-ocracy'. He who does, chooses (usually!). It is widely accepted that something needs to happen on the docs. And really, what it is going to take is someone just getting on and doing it. I suspect that someone putting in the legwork would get a lot of support from the rest of us. That is the missing component, not the ideas. Are you offering? ;-) Regards, Upayavira Tony Collen wrote: This is a late-night, rambling [RT]. I think it's a good idea. You may or may not. Please flame, argue, discuss, rant, etc... it's an [RT], after all... Have fun! >> The Problem: Documentation << Right here is where I would discuss the problem in a more in-depth sort of way, but since my brain is pretty much shut down, that's not going to happen. Insert your own rambling explanation of why the docs stink. ;) >> The Solution << I propose we create a free, high-quality electronic book (entitled _The_Cocoon_Handbook_), which will eventually replace the mess of docs we currently have. It will be in DocBook (possibly simplified) format. Not only are we having a hard enough time keeping the documentation up-to-date normally, fightning the rampant wiki spamming has become almost a full-time job as it is. We can integrate the eventual book with user-added notations, similar to how PHP lets people log in and annotate the existing docs. >> Considerations << There are several things we need to take into consideration. In no particular order, they seem to be: - The existing documentation. How can we take advantage of what we already have? Further, how can we lose the crap and keep the good stuff? - Forrest. How will it affect this plan, if at all? - The Wiki. We need to be able to allow people to annotate or refine the docs with ease. How can this be done? IMO there are two separate things that need to happen with the docs. One is annotating the docs, adding user comments, etc, just like the PHP docs. The other is to actually maintain the docs which are being annotated. That is, if a new component comes out, or a feature is added, to change the actual DocBook source. If someone is willing to help maintain the docs (although might not be all that experienced of a Cocoon user), we should be willing to let them become a committer in order to maintain the docs. That's about all that my brain can spew out for now. I really think this is a good idea, and I've been throwing the idea around in my head for a while now. Regards, Tony
Re: Wiki conversion status
Bertrand Delacretaz wrote: Le 23 juin 04, à 15:33, David Crossley a écrit : I tried doing some edits today and noticed that the diff emails are very strange. I only changed one line, yet the diff shows that many lines were "changed". I did not have the box selected to "Remove trailing whitespace". I've seen this before, seems like it happens on the first edit after importing from the old wiki - the line endings are not the same after you edit the page using the wiki, hence the many diffs. IIRC all is ok from the second edit done on the wiki. If someone can tell me what needs to be done (e.g. a run of dos2unix on Minotaur) I can add it to my conversion script. However, as the files now go straight from cocoondev.org (Unix) to wiki.apache.org (Minotaur on Unix), without passing through Charya (my PC, Win2k), I can't see that line endings would be wrong anyway. Hmm. --Bertrand
CLI Caching and JCS - almost there
I have implemented some code to allow the Cocoon bean to check whether a page can be read from the cache (and if so, the bean can ignore it). To be able to ignore it, the links must be cached too. I've got this working, which is great. However, it only actually works the second time a page is generated within a session. So it seems that the first time it isn't in the cache, which implies that maybe the cache isn't surviving Cocoon restarts. Now that I know my code works, I'll dig deeper into the JCS store to see if I can work out what is happening. Does the JCS cache actually survive shutdowns correctly? Carsten? (If this works, it could reap significant time benefits for the CLI, and thus particularly for Forrest). Upayavira
SVN (was Re: Removing groovy)
Vadim Gritsenko wrote: PS I've not heard news about SVN move. Shall we start a branch or wait some more for SVN? I read on infra that Brian Fitzpatrick is busy finishing a major revision to CVS2SVN, and would like to do migrations when this is finished. Maybe a week more. Regards, Upayavira
Re: Removing groovy
Antonio Gallardo wrote: Tony Collen dijo: Vadim Gritsenko wrote: Hi, I'm not sure (yet) where Groovy is used - but it has to be removed from core Cocoon, lib/optional, into some block. Reason is simple - Cocoon supports JDK1.3, and Groovy - not. Either JDK1.3 support should go, or Groovy should go (into the block, at least). Opinions? Move into its own block, mark as unstable (and possibly disabled by default). Perhaps we can think of losing 1.3 support once 1.5 is finalized. Yep. AFAIK, it was already decided for the next version. No, it was decided for 2.2, but 2.1.x will always have JDK1.3 support. That is how I remember it. Regards, Upayavira
Re: [Plan] The future of Cocoon
[EMAIL PROTECTED] wrote: On Wed, 26 May 2004, Pier Fumagalli wrote: On 26 May 2004, at 10:17, Carsten Ziegeler wrote: Some things that come to my mind for 2.2: - first finished version of CForms. - deprecate XSP (and provide a viable alternative) many people talking about "deprecate XSP" but can i ask something? is any better alternative to produce xml quering databases? i think that until now the way ESQL-->XML--> any tranfrormation --> .. has no better alternative No there isn't. And until there is, XSP can't be deprecated. Hence Carsten saying, "and provide a viable alternative". Upayavira - cleaning up the caching/store mess - remove deprecated blocks etc. I like it, I like it! :-) (yep, twice). Starting on 2.2 to bring the current 2.1 to a level of complete solidity of contracts and features is, IMVHO, an optimal idea, and puts us in the position (also) to start using the Linux-like versioning scheme. 2.2 will be our "stable" tree, and all crummy development (real blocks, and you name it) can easily happen in 2.3 which will always be kept as "unstable", to end up with a 2.4 release! :-P Now, the only thing I'm horrified about is that voice about a BRANCH in our current CVS (aaag)... I'd say we clear out the 2.2 CVS repo and do a clean re-import of 2.1.5, or switch to Subversion now, but purlllease don't add any branch in the tree... If someone wants, I can rename the 2.2 repository into a 2.3 straight away (so that we ain't going to lose anything)... Pier
Re: RawRequestParameterModule
Leszek Gawron wrote:
Currently it returns url decoded values (so exactly like
RequestParameterModule). I found in the archives that this might not
be fixable as request does not provide url-encoded values. If so it
should be removed and an input module url-encode introduced. So you
could do:
map:generate
src="http://remote/page?param={url-encode:{request-param:param1}}
PS. Is that the proper syntax for module nesting?
Yup.
PS2. Can I provide a patch?
Looks useful to me. I'd say go for it.
Regards, Upayavira
Re: Including source files in jars
Sylvain Wallez wrote: Nicola Ken Barozzi wrote: Sylvain Wallez wrote: Hi all, I updated the build process so that we can optionally include the java source files in jar archives. Very nice :-) What about making this the default? I'm all for it! The only problem is that it augments the size of jar archives. How much? Regards, Upayavira
Re: extending LuceneCocoonSearcher
Jeremy Quinn wrote: On 7 Jun 2004, at 14:27, Upayavira wrote: Jeremy Quinn wrote: Hi All I have developed some CForms that allow you to assemble a set of Beans that represent Queries. These are converted directly to Lucene Query objects without using the QueryParser. At the moment, they set up a new Searcher for each hit. I would prefer to use a cached Component for this like LuceneCocoonSearcher. Would anyone object to my adding the following to the LuceneCocoonSearcher Interface and SimpleLuceneCocoonSearcherImpl Implementation: Hits search(Query query) throws ProcessingException; and, after we upgrade to Lucene 1.4: Hits search(Query query, Sort sort) throws ProcessingException; where Hits is: org.apache.lucene.search.Hits where Query is: org.apache.lucene.search.Query where Sort is org.apache.lucene.search.Sort WDYT? Looks fine to me. I'd like to have the beans, too! Thanks Upayavira. The beans are relatively simple. I would be happy to donate them . but they deal with our chosen subset of what a query is to be composed of .. and that might not be everybody's cup of tea. I would be happy to send them to you for your evaluation, then see if you still think they are generally useful .. Incidentally . The Query Bean has a repeater, to which you add Criterion Beans. At the moment, all Criteria in the form are represented by a 'field', a 'match' and a 'term', where the 'field' is a popup of Lucene Search Index fields, match is a popup that can be 'contains', 'like', or 'phrase' and the term is a textfield. Since some of the fields it is possible to search on are populated from fixed keyword lists, we would like be able to show a popup of those keywords instead of the text-field for 'term'. So the display (what kind of formfield, which selectionlist) of the Criterion would change depending on the setting of the 'field' property. (A bit like MacOSX Finder's search window, for those that know it.) How do you do that in CForms? I suspect you need to use those Widgets I never understood like 'union', 'class', 'struct' etc. Is that the case? Thanks for any suggestions. Just skimming your mail (got a project to finish by last Friday)... Have you seen the car selector sample? There's drop downs there that change dependent upon the previous entry. Does that do what you want? Regards, Upayavira
Re: extending LuceneCocoonSearcher
Jeremy Quinn wrote: Hi All I have developed some CForms that allow you to assemble a set of Beans that represent Queries. These are converted directly to Lucene Query objects without using the QueryParser. At the moment, they set up a new Searcher for each hit. I would prefer to use a cached Component for this like LuceneCocoonSearcher. Would anyone object to my adding the following to the LuceneCocoonSearcher Interface and SimpleLuceneCocoonSearcherImpl Implementation: Hits search(Query query) throws ProcessingException; and, after we upgrade to Lucene 1.4: Hits search(Query query, Sort sort) throws ProcessingException; where Hits is: org.apache.lucene.search.Hits where Query is: org.apache.lucene.search.Query where Sort is org.apache.lucene.search.Sort WDYT? Looks fine to me. I'd like to have the beans, too! Upayavira
Re: [VOTE RESULTS] Cocoon PMC chair
Steven Noels wrote: On 04 Jun 2004, at 10:32, Steven Noels wrote: Dear all, a nice set of people volunteered for taking on the PMC chair job and it's time we conclude this vote. :-) Thanks for your votes: this was a close call and we are bound to change the voting rules and procedures for next elections. Anyway, it looks like our new PMC chair is Sylvain Wallez: thanks for taking over! I'd like to thank the other candidates for offering their time and energy, and be sure to volunteer next year! Congrats Sylvain! And I'm not sure if it is commiserations to the rest - looks like you just escaped from some work! Regards, Upayavira
Re: [VOTE] new Cocoon PMC chair
Sylvain Wallez wrote: Steven Noels wrote: - Sylvain Wallez Well, just like Matthew, +1 for me! Sylvain Difficult choice, but: +1 for Sylvain. Upayavira
Re: JXTG and caching - IT'S DONE
Leszek Gawron wrote: Upayavira wrote: It seems to me that Sylvains suggested extension of jxt has a great deal of power in it. OK. Then I'll continue my work and try to provide the appropriate patch as I have already started to make needed changes. Great. I'd love to see a cacheable jxt. Regards, Upayavira You can test the first implementation if you fetch this file : http://ouzo.wlkp.org/cjxtg.zip Fab. The below all reads okay to me. It would seem reasonable that the template must be read in setup now. [As an aside, is the jxt file cached? Or does it need to be read with every request? Maybe the parsed jxt could be put into the transient store or something?] I would suggest: (a) patch the JXTemplateGenerator itself, rather than creating a new class. (b) Post this as a patch to Bugzilla. Then, hopefully someone'll get the chance to check it and commit it. Regards, Upayavira it contains : CachingJXTemplateGenerator.java which you should put to the same directory as JXTG.java and rebuild your cocoon. There also is a simple test case in test directory. Put it into your webapp root and then issue this url: http://localhost:/test/test.do?key= if I got it right the view is generated once for each key and cached so the date on the page won't change if you refresh your page. How it works: 1. every attribute in "http://apache.org/cocoon/templates/jx/1.0"; namespace get stripped from attributes and end up in StartDocument event in templateProperties map (which I added). This is something that could be used for providing additional parameters to template in the future. These attributes are not generated to output. They are only stored in map. This was the simplest solution. I think it's acceptable. How about you? 2. In template's root element (or any element really) you put: The key should be Serializable and the Validity should be SourceValidity of course. Voilla .. the page gets cached. What changed: 1. CachingJXTemplateGenerator implements CacheableProcessingComponent of course :) 2. StartDocument.templateProperties added 3. I had to move template parsing from generate to setup(). Otherwise that happened: - fetch http://localhost:/test/test.do?key=abc - setup() called - getKey() called - template not parsed yet, cannot compute key - no view caching will be done - generate() - template gets parsed and generated, template cached - refresh browser - setup() called - getKey() - got parsed template, can evaluate cache-key - lookup from cache fails as the first response was not cached - generate() - template already parsed - response cached, getValidity() called somewhere of course The response gets cached after second page hit because getKey() first time is called before template is parsed. When parsing is moved to setup() this happens: - fetch http://localhost:/test/test.do?key=abc - setup() called, template gets parsed - getKey() called, template accessible, key computed - cache lookup falils - generate() called - response cached! This class can become standard JXTemplateGenerator as if you do not provide caching attributes the page never gets cached so it works like it did before. Please make your comments
Re: swf block
Torsten Curdt wrote: As we decided to deprecate the swf block in the last 2.1.5 release I create a new sample how to use flash with cocoon. If there aren't any objections I will nuke the swf block and add the flash sample. (no further components are needed anymore) Everyone alright with that? +1 I'm interested to see what you come up with. Upayavira
Re: JXTG and caching
Leszek Gawron wrote:
Upayavira wrote:
I think you are getting something wrong here.
If you have two objects bizObj1 and bizObj2, and you pass these to a
pipeline that does
JXT(bizObj1)->tx->tx-\
>-aggregate->tx->serlialize
JXT(bizObj2)->tx->tx-/
You would do:
sendPage("your-pipeline", {"bizObj1": bizObj1, "bizObj2": bizObj2});
It feel like it breaks SoC a little as controller has to know how your
view is rendered. Also if you change your rendering to 3 aggregate
parts you have to make appropriate changes in controller.
Huh? Surely, your controller needs to tell the view what information
(models) it needs to display? This is a necessary part of MVC?
Does that make sense?
Now it does. I never thought of a wrapper. It's real pleasure to
discuss with you all.
Glad that helped.
It seems to me that Sylvains suggested extension of jxt has a great
deal of power in it.
OK. Then I'll continue my work and try to provide the appropriate
patch as I have already started to make needed changes.
Great. I'd love to see a cacheable jxt.
Regards, Upayavira
Re: JXTG and caching
Leszek Gawron wrote:
Replying myself :)
Leszek Gawron wrote:
It would have to look somewhat like this:
function showData() {
var validityKey = "request-param:a!!spacer!!request-param:b";
var pipeline = "view/someview.jx"
if ( someCacheManager.isValid( pipeline, validityKey ) ) {
// hope the cache entry does not expire between isValid and page
// generation
var dummyBizData = {};
cocoon.sendPage( "view/someview.jx", dummyBizData );
return;
}
// the page is not cached
// do the heavy processing here and send new page
var bizData = {};
bizData[ "pageData" ] = fetchBizDataByHeavyDBRetrieval();
var validity = cocoon.createObject( DBViewValidity );
bizData[ "cacheingInfo" ] = validity;
cocoon.sendPage( "view/someview.jx",
bizData,
function() {
cocoon.releaseObject( validity );
} );
}
It does not look like SoC.
It does not look like it is possible to implement either if you take
aggregated views into account - one part of the view might need
rendering because it expired while other could still be fetched from
cache. Controller would have to know what parts is the view build of
and generate appropriate data which breaks SoC completely.
The conclusion is: the only way we can generate a cached view is to
use some technlogogy that "pulls" data (like a java generator or XSP).
While xsp is not considered a good practise nowadays it needs a
replacement fast.
JXTG could be made cacheable for simple cases - ones that do not need
heavy bizData preparation. Still JXTG gets data pushed into which
needs prior data retrieval. In cases when data preparation is much
more resource consuming than view rendering caching hardly makes sense.
I think you are getting something wrong here.
If you have two objects bizObj1 and bizObj2, and you pass these to a
pipeline that does
JXT(bizObj1)->tx->tx-\
>-aggregate->tx->serlialize
JXT(bizObj2)->tx->tx-/
You would do:
sendPage("your-pipeline", {"bizObj1": bizObj1, "bizObj2": bizObj2});
Then, your objects would implement:
bizObj.getValidity()
And the jxtemplate would ask the business object for its validity as
Sylvain has described.
Thus, if bizObj1 says it can be cached, and bizObj2 says it can't, then
at least one of your two aggregated pipelines doesn't need to be
generated, which will speed up processing.
Remember, the jxtemplate pulls the validity from the business object.
The flow doesn't need to even know that caching might be happening (and
in fact _shouldn't_ know it is happening). If you have to write
flowscript to deal with this, then something is probably wrong.
If your business object takes an age to instantiate, and you can decide
whether or not to instantiate it based upon request parameters, then
wrap it in a lighter component that does (in pseudocode):
lightObject.getValidity() {
return request.parameters["a"]+ request.parameters["b"];
}
lightObject.getHeavyBusinessObject() {
if (this.heavyBusinessObject == null) {
this.heavyBusinessObject = HeavyBusinessObjectBuilder.newObject();
}
return this.heavyBusinessObject;
}
Then, in your jxt, you use Sylvains
jx:cacheKey="lightObject.getValidity()" construct, and then later in
your jxt, you access your heavy object with
#{/lightObject/HeavyObject/property1}. This latter expression will only
be invoked if the page is not cached.
Does that make sense?
It seems to me that Sylvains suggested extension of jxt has a great deal
of power in it.
Regards, Upayavira
Re: JXTG and caching
Leszek Gawron wrote:
Upayavira wrote:
Leszek Gawron wrote:
Sylvain Wallez wrote:
One question: if this NewsHelper is NOT an avalon component (or
object instantiated by flow.createObject) then it doesn't have acces
to any backend logic or data (for example database that stores
expiration time for different news services). Would it be possible
to instantiate this object via flow.createObject analogy?
Of course. You could equally well say:
sendPage("my-url", {"myObject", myAvalonObject});
Regards, Upayavira
But that does not differ from what I proposed in first post and
Sylvain wrote it is a bad idea.
I would say it is different, in as much as previously you calculated the
validity in flowscript. Now, you pass in an object, and the template
asks the object for its validity. So the object itself knows how to
decide whether it is valid or not, which seems quite reasonable to me.
Adding that level of complexity to flowscript can make your flowscripts
very complex very quickly. That is what I believe Sylvain is objecting to.
Regards, Upayavira
Re: JXTG and caching
Leszek Gawron wrote:
Sylvain Wallez wrote:
One question: if this NewsHelper is NOT an avalon component (or object
instantiated by flow.createObject) then it doesn't have acces to any
backend logic or data (for example database that stores expiration
time for different news services). Would it be possible to instantiate
this object via flow.createObject analogy?
Of course. You could equally well say:
sendPage("my-url", {"myObject", myAvalonObject});
Regards, Upayavira
Re: Large xml's in cocoon
Ugo Cei wrote: Pier Fumagalli wrote: Oh, on a side note, Ugo, I'd seriously switch your development/production environments... I'm not going into performance details (I don't want to raise a can of worms), but at least on my tests Tomcat is using 3x the memory that Jetty is using per single request, so it's more likely for you to have OOMEs on Tomcat rather than Jetty. I couldn't agree more with this, Pier, but until my boss gets me a new engineer, I'm not going to learn how to properly configure Jetty for vhosts, authentication, logging and HTTPS and switch over. I don't want to do this job anymore, so they stay where they are ;-). Whilst I can undestand the sentiment of not wanting to do sysadmin work, I would say that Jetty is _far_ easier to configure than Tomcat. It is in fact just far simpler alround. Vhosts are easy, as is authentication realms (I can send you config samples). For logging, I'm not that sure (we just redirect Jetty's console to a file). HTTPs listeners are available in Jetty's default config file, including examples of how to refer to your keystore. Switching to Jetty was the best thing we did - Tomcat fell over all the time. Jetty has just stayed up. If you ever decide to switch, let me know and I'll send you config samples. Regards, Upayavira
Re: Wiki conversion status
Mark Leicester wrote: Sorry not be more explicit first time, and, yes I can: http://wiki.apache.org/cocoon/MIDI see: ==Sample Xmidi== http://wiki.apache.org/cocoon/Action see: === Built-in Actions === Fixed. Never realised that \s matches a \n. So replacing ^\s*!! with ^[\t ]*!! fixed it. Also, I've spoiled Steven's fun - I've added an option to create an Apache mod_rewrite rewrite map, which means we can map from the old to the new Wiki with just three lines of Apache config. I've also split the Cocoon and Lenya wikis as Lenya have voted to have their own. I've set up scripts so that I can now run a conversion on cocoondev which will then upload directly onto Minotaur, so further round trips and updates should be _much_ quicker. All - please check again. Upayavira
Re: Adding a global validation message to a form?
Bruno Dumon wrote: On Fri, 2004-05-28 at 23:58, Joerg Heinicke wrote: Moving this to dev list. Find the original thread at http://marc.theaimsgroup.com/?t=10855910974&r=1&w=4. On 28.05.2004 20:13, Bruno Dumon wrote: I'm not sure if this is a good solution, since those messages are not specifically recognized as being validation errors, and so this wouldn't work together with fi:validation-errors. Maybe the best would be to allow adding validation errors (multiple ones) on the form itself. The form itself becomes ValidationErrorAware? I searched for it when thinking about a solution, but unfortunately the form is not implementing the interface. No, I would rather have a method like addValidationError on the form, not setValidationError. One global validation error message seems to limitting to me. At the mo only want one message but I can see times when multiples might be wanted. So +1 for addValidationError So +1. fi:validation-errors would then better be replaced with a ft:validation-errors (which can crawl the widget tree), since otherwise it wouldn't find the errors attached to the form. Hmm, I guess it is also possible to add a fi:validation-message to the form widget as it is done for all other widgets. It must be possible to differ between form widget (= global) validation errors, collected "somewhere" and widget specific errors. In other words I do not want to be forced to collect all errors at one place just because of using ft:validation-errors for the global errors. This behaviour could be made configurable via an attribute on the element: all=false would give only the errors added directly to the form, while all=true would give all errors from all widgets (including those added to the form). Sounds very useful. Once we have this kind of functionality, we can drop the fd:messages widget which was introduced as a temporary solution. OTOH, from monitoring the users list, it seems a fd:message widget (singular) would be useful since many users are now using the fd:output widget for outputting messages (and then need to do special things to get i18n working for that). +1 from me! Except I wouldn't know where to start to implement it! Regards, Upayavira
Re: SVN and Certificates
Reinhard Poetz wrote: As Cocoon will move to SVN soon, I tried to work with the latest Subclipse client. Unfortunatly I always get an error: svn: Commit failed (details follow): svn: OPTIONS request failed on '/repos/test/cz/new' svn: OPTIONS of '/repos/test/cz/new': Server certificate verification failed: issuer is not trusted (https://svn.apache.org) Subclipse doesn't offer the possibility to accept untrusted certificates like command-line SVN or TortoiseSVN does. A workaround is using one of the mentioned tools and accept the certificate permanently. But this can't be a final solution, IMO. Are there any plans to setup a valid certificate for svn.apache.org? I believe there are plans for a certification server, yes. But there may be other ways around it. I'd suggest asking about this on infrastructure list. Regards, Upayavira
Re: [IMP] Re: Samples block SWF not working....
Antonio Gallardo wrote: Torsten Curdt dijo: Though I think we should deprecate the SWF stuff anyway. The used library is dead and still needs some work. WDYT? Fix it and deprecate it after 2.1.5 is out? ...and of course replace it it with a flash example. While I am not a Flash fan. I thought it is not good idea to deprecated it. Because many people is using flash or just this is the perception I got in my country. Seems to be a "hot" technology around web designers. They are developing or looking for "flash" these days. I know Cocoon is a step forward of these solutions. But the same as JSP I think we can support it as an entry point for some people. Modern Flash movies can collect data using XML over HTTP. So there doesn't seem much point in actually generating the movie itself from within Cocoon. I'd build a flash movie as a static entity, and have it collect its data from Cocoon as XML over HTTP. So, I'm not sure that this thing is that useful really. Don't know. Regards, Upayavira WDYT? BTW, I was reviewing the CVS of the spark library and the newest commit is 2 years old (the exception is a 21 month license file). As you, I think the project is dead. If someone what to check it: CVS repo: http://cvs.berlios.de/cgi-bin/viewcvs.cgi/spark-xml/ Website: http://developer.berlios.de/projects/spark-xml/ Best Regards, Antonio Gallardo
Re: Wiki conversion status
Mark Leicester wrote: Hi Upayavira, Keep up the great work! I had a little look around and noticed that 2nd and 3rd level headings don't appear to convert correctly. Can you give an example? Regards, Upayavira
Re: Wiki conversion status
David Crossley wrote: But it is odd how it works. JXTemplateGenerator will only see TemplateGenerator as the link without the JX. It is going to be tough just using this, as even when we've done the conversion people are going to be inadvertently adding CamelCase to their new Wiki pages. I guess I can give my regexp skills another test to see if I can come up with a CamelCase detector, but I'm a little reluctant. Is it really important? Yes, i think so, for the reasons described above. Upayavira, who's trying to avoid a bit more work! Thanks, and we do not want to hold you up in any way. Is this something that can be switched off by default and we switch it on if we decide that we want it? Well, I must be a regexp whizz, because I got this working within five minutes. I was distracted by the fact that it didn't work on my local Moin, but it works on Apache's so it is fine. I have uploaded a current conversion. I coded it so as to exclude Lenya content, which can be put onto a separate wiki (about which they are currently voting). Please review. If no comments, I'll start a conversion vote in a couple of days. Upayavira
Re: [VOTE] Release on monday
Ugo Cei wrote: Upayavira wrote: I need to remove the test-suite and use samples/test, and confirm that Ugo's fixes have made the CocoonBeanTestCase work, and then re-enable it. A word of caution. My fixes add the blocks directory and block-provided jars to the classpath for tests and make the "junit-tests" target depend upon the "blocks" target. This is necessary because the CocoonBeanTestCase loads "build/webapp/WEB-INF/cocoon.xconf", which contains references to components provided by blocks. This strikes me as a typical anti-pattern. What are we testing here? The CocoonBean or the components that it relies upon? If it's the latter, fine, but it's not a unit test anymore, it's an integration test and does not belong under the "junit-tests" target. If it's the former, it should be testable in isolation. In any case, it would be probably advisable to load the CocoonBean under test with a cocoon.xconf derived from a "no-blocks-included" configuration. This is all fair comment. Whilst I have a 'unit test' for the bean, in fact, the bean really depends upon the entirety of Cocoon, and is thus really more of a functional test. Given that some blocks have been known to break the bean, it is important that the test is run across the entire Cocoon. It is there somewhat more akin to an anteater test. Therefore, given these facts, I propose to leave the CocoonBeanTestCase disabled, and simply remove the test suite (as it isn't needed anyway.). I will continue to use the test case locally on my own testing, and will reflect on a better place for it (or some equivalent) within the build process, perhaps alongside the anteater tests. Upayavira
Re: [VOTE] Release on monday
Carsten Ziegeler wrote: I think we fixed the most serious problems for 2.1.5 now. If noone objects I will release the current state on monday, 24th of May. So the code freeze will continue until then. This gives us some more days to test and possibly fix bugs. Or is there anything serious that I did oversee? I need to remove the test-suite and use samples/test, and confirm that Ugo's fixes have made the CocoonBeanTestCase work, and then re-enable it. But, as that test is currently disabled, releasing with it in its current state is not a major problem. I'd just like to get it done before we release. Upayavira
Re: Persistent storing should work now
Carsten Ziegeler wrote: Due to our change to JCS I found a serious bug in our own caching keys: the hash code wasn't always calculated properly :( This resulted in a) an unusable persistent store as after an application restart the keys didn't match anymore and b) other environments like CLI etc. couldn't use the cache at all. Great work Carsten. Can you explain why other environments couldn't use the cache? I'm sure I've seen stuff go in and out of the cache within the CLI (but only within a single session). Upayavira
Re: [IMP] Something is wrong with out stores
Carsten Ziegeler wrote: The more I look into this store problem, the more I get confused. I think I understood from Sylvains explanation that the persistent store should only be used by our store as a back up. Looking through our code, I found out, that some components still use the persistent store: - StatusGenerator - ClearPersistentStoreAction - EventAwareCaching So, should we simply change them to use the store? Well, no. Surely the StatusGenerator is telling you the state of the persistent store, the ClearPersistentStoreAction is, well, need I say (not sure about the EventAwareCaching). Probably what Sylvain was saying is that nothing stores objects directly into the persistent store, they all go via the default store. But, for status, etc, reasons, it seems okay to me to access the persistent store directly. Upayavira
Re: Testing the cache implementation....
Carsten Ziegeler wrote: Good question! I think it's not a blocker, but others might have different opinion. As I said in another mail, I'd propose we: * Revert * Release * Fix with JCS * Release That way we get 2.1.5 out now, same cache as before, but with CForms. And as soon as we can we get 2.1.6 out with a better cache. Upayavira -Original Message- From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 18, 2004 10:02 AM To: [EMAIL PROTECTED] Subject: Re: Testing the cache implementation Le 18 mai 04, à 08:52, Carsten Ziegeler a écrit : ..but unfortunately the data does not survive a Cocoon restart on my system. Any idea? IMHO this is not a blocker for the release, or is it? (it's great that you guys are working on it, just trying to make sure we don't let the release slip too much). -Bertrand
Re: Testing the cache implementation....
Carsten Ziegeler wrote: Ok, I thought I read somewhere that this had been fixed. Anyways, yes, contacting them is the better way. No, I believe it was an NPE on shutdown, or something like that - not very graceful. We'll see how they reply. I'd say it probably is a showstopper, but I'm not sure how much people rely upon the survival of the cache over shutdowns. The other option is to release with JISP, and fix straight after release, maybe then do a quick 2.1.6. After all, the JISP problems have been in releases already, so they're not quite showstoppers in the same way. Otherwise we're in danger of loosing our release often, release early maxim. Right here is where loosing that begins!!! Regards, Upayavira -Original Message- From: Upayavira [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 18, 2004 9:47 AM To: [EMAIL PROTECTED] Subject: Re: Testing the cache implementation Carsten Ziegeler wrote: Good, but unfortunately the data does not survive a Cocoon restart on my system. Any idea? I don't believe it is supposed to. I've just joined jcs-dev and asked whether they'll add it! They seem responsive enough. Regards, Upayavira -Original Message- From: Antonio Gallardo [mailto:[EMAIL PROTECTED] Sent: Monday, May 17, 2004 6:04 PM To: [EMAIL PROTECTED] Subject: Testing the cache implementation Hi: I already did the following test: started lucene building index with transformer then on another client I sent to clear the cache. The cache was cleared and on the jetty console no error. I remember that caused a problem in 2.1.4 If this is true, then it is a point for JCS. :-D Best Regards, Antonio Gallardo.
Re: Testing the cache implementation....
Carsten Ziegeler wrote: Good, but unfortunately the data does not survive a Cocoon restart on my system. Any idea? I don't believe it is supposed to. I've just joined jcs-dev and asked whether they'll add it! They seem responsive enough. Regards, Upayavira -Original Message- From: Antonio Gallardo [mailto:[EMAIL PROTECTED] Sent: Monday, May 17, 2004 6:04 PM To: [EMAIL PROTECTED] Subject: Testing the cache implementation Hi: I already did the following test: started lucene building index with transformer then on another client I sent to clear the cache. The cache was cleared and on the jetty console no error. I remember that caused a problem in 2.1.4 If this is true, then it is a point for JCS. :-D Best Regards, Antonio Gallardo.
Re: Revert JCS, Re: XSP not working in CVS head?
Vadim Gritsenko wrote: Ugo Cei wrote: Vadim Gritsenko wrote: Why then we need EHCache at all? MRUMemoryStore works well and does not require extra jar files. What EHCache gives us? ... Overflowing to disk when the memory store fills, all with a single implementation, IF you configure the disk store with a greater-than-zero size, which requires changing a parameter in cocoon.xconf, since - as shipped - it defaults to "memory only". Hope it is clearer, now :-). Ok, but your original plan requires couple of changes due to ehcache inability to store objects... EHCache can take place of PersistentStore, but not Store or TransientStore. Apart from the fact that it doesn't persist through restarts, which our current implementation does. As I say, not so useful for servlets, extremely valuable for CLI, and I wouldn't like to loose that option. Upayavira
Re: XSP not working in CVS head?
Carsten Ziegeler wrote: Sylvain Wallez wrote: ! A LogicSheet cannot be Serializable ! It extends AbstractLogEnabled and has attributes of type ServiceManager and SourceResolver, which aren't serializable ! Furthermore, I don't understand why LogicSheets go to JCS since the transient store is used (see AbstractMarkupLanguage.service()) Don't have much time ATM, but looking at the recent changes I see a JCSTransientCache. We must be *very careful* with transient cache being actually transient, i.e. *not requiring objects to be serializable*. If JCS requires objects to be serializable even without a persistent backend, so let's *not use it* for the transient cache, and keep the previous MRU memory store. And please, please, do not make Serializable objects that intrinsically are not. This is the root of many evils. I'm currently a little bit confused. We have a store, a transient store and a persistent store, right? So, we can make the MemoryStore the transient store (no data is serialized) and we can make JCS the persistent store (this requires the objects to be serializable which is ok). What about the "simple store"? Surely we have: Transient: stored in memory, lost on shutdown Persistent: stored on disc, kept through shutdown "Simple": stored in memory, pushed to disc when overflowing, persists contents to disc during shutdown. It is this third case that is the complicated one to handle (and the one that is most useful to me for the CLI). Upayavira
Re: [Java 1.3] Cocoon build fail....
Carsten Ziegeler wrote: Bertrand Delacretaz wrote: Le 17 mai 04, à 10:30, Antonio Gallardo a écrit : ...Cocoon is failing under Java 1.3.1_10: Here is the output:... Just did a full compile with all blocks under macosx 10.3.3 / JDK 1.3.1. Build went fine, tried a few samples which look ok. Two JUnit tests fail: CocoonBeanTestCase.testProcessToStream fails: Resource not found: 500 org.apache.cocoon.ProcessingException: Resource not found: 500 at org.apache.cocoon.bean.CocoonWrapper.processURI(CocoonWrapper. java:375) at org.apache.cocoon.bean.CocoonBeanTestCase.testProcessToStream( CocoonBean TestCase.java:48) 17.104 (but I think this is being fixed?) This has been fixed, but changed by someone again...I fixed this for the second time now :) No-no. Ugo put it back, because he 'almost' fixed the test. All that is required to have it fully working it seems is some pretty trivial changes that I am now working on. Upayavira
Re: Release tomorrow?
Ugo Cei wrote: I *almost* got the CocoonBeanTestCase to succeed. After adding the blocks' lib directories to the classpath, we still have a failure, because the src/webapp/test-suite/sitemap.xmap file references a file named stylesheets/xdoc2html.xslt that is not there! There is a file named "simple-xdoc2html.xsl" but using it instead gives a failure when checking the length of the pipeline output. Where has "xdoc2html.xslt" gone? If you've got there, you've got the job done, which is great. The rest should be pretty easy. I'll try to look at it tomorrow. Also, since committing the webapp/test-suite, I found webapp/samples/test, which serves much the same purpose. So I should really change the test suite to use that, and remove the webapp/test-suite. I'll try to do this before the release, as it would be best if it doesn't go out with a release. Regards, Upayavira
Re: Wiki conversion status
David Crossley wrote: Upayavira wrote: David Crossley wrote: Links inside headings are not handled e.g. http://wiki.apache.org/cocoon/BlockDescriptions should have a local link in the heading which goes to our Batik wiki page. old: http://wiki.cocoondev.org/Wiki.jsp?page=BlockDescriptions I presume that would be a minor problem. People could add them post-conversion. This is something Moin can't do. This is something I think we'll just have to do manually post (or pre-) conversion. Just move the link out of the heading. Okay, post-conversion. We can add them back if really needed. David Crossley wrote: The process of running the conversion script is an excellent opportunity to automatically catch some spam that has crept in. There is no doubt that we have missed some vandalism cases. We are only a few humans trying to manually catch it. Also remember the problem with the diff notification that only runs every hour and we only get the most recent change. Is it possible to generate a list of vandalised pages? For example one pattern is "emmss.com". On the other hand, we could probably run some 'find | grep' commands on the server-side after the conversion. If we can come up with simple rules as to how to implement this, then yes, but I'd rather just get the conversion done. Definitely, just get the conversion done. We can fix those afterwards. I've got an exclusions file which says which pages to exclude from conversion. I can add files to that. Otherwise, I think a manual grep for http:// would probably be a good idea, and then edit the links out via the gui. Where does the content end up on the apache server? /www/wiki.apache.org/data/cocoon/data/text is where the actual pages are. Those of us with commit access can ssh in and start building some tools to find the vandalism. Or just use grep. It is just a directory full of text files. Upayavira
Re: a solution for the xmldb prefix pb
Joerg Heinicke wrote: On 14.05.2004 11:08, lilia ighmouracene wrote: hi, I have changed the XMLDBsource.java in the cocoon src, and i have build the cocoon webapps application. the change that i have did is to remplace the string 'xmldb' ,for example, by 'query' and you can change it as that's seems for you. now,the pb of xmldb prefix is resolved. So, when i query a xindice document within cocoon, i have a well formed document result You mean you removed the namespace prefix 'xmldb' from the created elements so that not is in the result, but in no namespace? Obvioulsy this works, but I understand this only as workaround for the real problem. Out of curiosity, I missed the original problem. What was it? Upayavira
Re: Wiki conversion status
David Crossley wrote: Upayavira wrote: David Crossley wrote: Upayavira wrote: The only remaining thing I _could_ do is where Moin detects CamelCase and makes links of it. These can be worked around with !CamelCase, which stops it becoming a link. But that one we can do manually when we see it. ... It would be good to handle this somehow. We don't want to encourage people to create a new Wiki page, just because a text term uses CamelCase. This is a big problem with describing our Cocoon bits and pieces, e.g. DirectoryGenerator. The CamelCase gets used so often in our descriptions. We would rather that links were deliberately made to the relevant cocoon.apache.org main documentation, wouldn't we? Also if it makes links out of everything it sees, then we will end up with link disease, where a term that is used multiple times in a sentence has many repetitive links. This is a feature of Moin that is configurable - does CamelCase get interpreted as a link? The rest of Apache has it switched on. Well, all Apache projects are different. I would like it switched off if it causes such damage. What do others think. But it is odd how it works. JXTemplateGenerator will only see TemplateGenerator as the link without the JX. It is going to be tough just using this, as even when we've done the conversion people are going to be inadvertently adding CamelCase to their new Wiki pages. I guess I can give my regexp skills another test to see if I can come up with a CamelCase detector, but I'm a little reluctant. Is it really important? Yes, i think so, for the reasons described above. Okay, I'll have a go. But I make no guarantees. We'll see how I get on. It is quite a complex problem - to precede all occurances of CamelCase, that isn't in a link, with an exclamation mark. Upayavira, who's trying to avoid a bit more work! Thanks, and we do not want to hold you up in any way. Thanks. I'll try not to get held up like I did last time (was it two months long?) ;-) Is this something that can be switched off by default and we switch it on if we decide that we want it? I think it can be switched on on a per wiki basis, but the issue is whether we want to do something different from the rest of Apache. Upayavira
Caching and the CLI (Again)
I'm trying to get caching working again with the CLI/bean, and could do with a little help. In CachingProcessingPipeline,. I want to write the links, taken from the ObjectModel, into the Store. The this.cache.store() method takes a SourceValidity[] array and a CachedResponse as its arguments. I need to make a new SourceValidity array, perhaps just appending "links" to the end of it, and make a CachedResponse from a java.util.List containing all of the gathered links. Now, for someone who knows this stuff, this should be easy. For me :-( Any one able to throw some sample code my way? Regards, Upayavira
Re: Wiki conversion status
[EMAIL PROTECTED] wrote:
Hi,
In my effort to help I switched my Cocoon215TOC to link to the apache wiki
pages, rather than their cocoondev counterparts. :-( I hope it won't be
broken in the conversion.
If it is, it won't be hard to fix. Remember, there'll be a certain
amount of search/replace fixing for us to do as we find things.
There is also a Cocoon215TOCOldWiki around, but I stopped updating that one,
so I suppose it can go (i.e. don't convert it).
I've added it to my 'excludes' list.
Thanks.
Upayavira
-Original Message-
From: Upayavira [mailto:[EMAIL PROTECTED]
Sent: Friday, 14 May 2004 16:32
To: [EMAIL PROTECTED]
Subject: Wiki conversion status
Gianugo Rabellino (on infrastructure@) wrote:
Yup. I have (a few) experience with MoinMoin and, of course, would
love to see the Cocoon wiki migrate here. :-)
Given your expression of interest, I have restarted my work
on JSP->Moin
conversion.
If you read no further - read this: Please review the wiki at
wiki.apache.org/cocoon. I consider this to be a valid final
pass at the
wiki conversion (on data that is a few weeks out of date). I believe
that all the remaining conversion issues should be handled
manually, if
you disagree, please let me know.
No, to move on:
The one outstanding problem was that the script was converting things
that appeared in {{{ }}}, which it shouldn't. For example, on the
LoadBalancingWithModProxy, there is a [P,L] which was getting
converted
to [:P,L]. When I tried using this within Apache, it took me
quite some
time to work out that the problem was with my Wiki conversion rather
than with Apache! Anyway, I believe I have fixed this
already, and will
have uploaded a new version by the time you read this.
The only remaining thing I _could_ do is where Moin detects CamelCase
and makes links of it. These can be worked around with
!CamelCase, which
stops it becoming a link. But that one we can do manually when we see
it. The previous {{{}}} problem would have been too esoteric to fix
manually and thus needed to be done within the script.
The other thing that was unresolved, but now works, is admin
access to
the wiki. After I do a small change, anyone within the cocoon
group on
Minotaur (all Cocoon committers) can add a password so that they can
have administrative access to the wiki (e.g.
deleting/reverting pages,
etc, I believe).
So, I need people to review the site at
wiki.apache.org/cocoon, and to
point out anything that is unacceptable. If no objections, we should
make the JSP wiki read only, run the conversion script,
upload the new
content to wiki.apache.org. The new wiki will then be live.
After that
(as Steven has previously suggested), some clever mod_rewrite
rules on
wiki.cocoondev.org could redirect people to the new Wiki. The below
would do _most_ of it:
RewriteCond %{REQUEST_URI} Wiki.jsp
RewriteCond %{QUERY_STRING} ?page=(abc)
RewriteRule .* http://wiki.apache.org/cocoon/%1 [R=301]
So, please review the new wiki conversion, and hopefully we
can switch
pretty soon. If I hear nothing, I'll start a vote in a few days.
Regards, Upayavira
Re: Wiki conversion status
David Crossley wrote: Links inside headings are not handled e.g. http://wiki.apache.org/cocoon/BlockDescriptions should have a local link in the heading which goes to our Batik wiki page. old: http://wiki.cocoondev.org/Wiki.jsp?page=BlockDescriptions I presume that would be a minor problem. People could add them post-conversion. This is something Moin can't do. This is something I think we'll just have to do manually post (or pre-) conversion. Just move the link out of the heading. David Crossley wrote: The process of running the conversion script is an excellent opportunity to automatically catch some spam that has crept in. There is no doubt that we have missed some vandalism cases. We are only a few humans trying to manually catch it. Also remember the problem with the diff notification that only runs every hour and we only get the most recent change. Is it possible to generate a list of vandalised pages? For example one pattern is "emmss.com". On the other hand, we could probably run some 'find | grep' commands on the server-side after the conversion. If we can come up with simple rules as to how to implement this, then yes, but I'd rather just get the conversion done. I've got an exclusions file which says which pages to exclude from conversion. I can add files to that. Otherwise, I think a manual grep for http:// would probably be a good idea, and then edit the links out via the gui. Regards, Upayavira
Re: Wiki conversion status
David Crossley wrote: Upayavira wrote: The only remaining thing I _could_ do is where Moin detects CamelCase and makes links of it. These can be worked around with !CamelCase, which stops it becoming a link. But that one we can do manually when we see it. ... It would be good to handle this somehow. We don't want to encourage people to create a new Wiki page, just because a text term uses CamelCase. This is a big problem with describing our Cocoon bits and pieces, e.g. DirectoryGenerator. The CamelCase gets used so often in our descriptions. We would rather that links were deliberately made to the relevant cocoon.apache.org main documentation, wouldn't we? Also if it makes links out of everything it sees, then we will end up with link disease, where a term that is used multiple times in a sentence has many repetitive links. This is a feature of Moin that is configurable - does CamelCase get interpreted as a link? The rest of Apache has it switched on. But it is odd how it works. JXTemplateGenerator will only see TemplateGenerator as the link without the JX. It is going to be tough just using this, as even when we've done the conversion people are going to be inadvertently adding CamelCase to their new Wiki pages. I guess I can give my regexp skills another test to see if I can come up with a CamelCase detector, but I'm a little reluctant. Is it really important? Upayavira, who's trying to avoid a bit more work!
Re: [vote] Reschedule the release
Ugo Cei wrote: Il giorno 14/mag/04, alle 19:26, Antonio Gallardo ha scritto: The JCS goes beyond simply caching objects in memory. It provides several important features, necessary for any Enterprise level caching system, features include Memory management, disk overflow, element grouping, quick nested categorical removal, data expiration, extensible framework, fully configurable runtime parameters, remote synchronization, remote store recovery, non-blocking "zombie" pattern, optional lateral distribution of elements, remote server clustering and failover. These features provide a framework with no point of failure, allowing for full session failover including session data across up to 256 servers. That is what we are looking for? :-D Frankly, no. At least, not in most applications. We already have too much complexity in Cocoon, too many "configurable runtime parameters". I have been looking for this functionality for a long time (persisting store to disc on shutdown), in a version that is faster than Jisp. Basically, a servlet environment, restarts are uncommon. But with the CLI/bean, it happens every time it is run. With a store that quickly persists to disc, it will be possible to make it check the store before actually generating a page, and thus will be able to offer a speed improvement over the existing version. I had this working a while ago with Jisp, but it was no faster than generating the pages themselves. With something other than Jisp, I suspect we could get a worthwhile performance improvement. Regards, Upayavira
Wiki conversion status
Gianugo Rabellino (on infrastructure@) wrote:
Yup. I have (a few) experience with MoinMoin and, of course, would
love to see the Cocoon wiki migrate here. :-)
Given your expression of interest, I have restarted my work on JSP->Moin
conversion.
If you read no further - read this: Please review the wiki at
wiki.apache.org/cocoon. I consider this to be a valid final pass at the
wiki conversion (on data that is a few weeks out of date). I believe
that all the remaining conversion issues should be handled manually, if
you disagree, please let me know.
No, to move on:
The one outstanding problem was that the script was converting things
that appeared in {{{ }}}, which it shouldn't. For example, on the
LoadBalancingWithModProxy, there is a [P,L] which was getting converted
to [:P,L]. When I tried using this within Apache, it took me quite some
time to work out that the problem was with my Wiki conversion rather
than with Apache! Anyway, I believe I have fixed this already, and will
have uploaded a new version by the time you read this.
The only remaining thing I _could_ do is where Moin detects CamelCase
and makes links of it. These can be worked around with !CamelCase, which
stops it becoming a link. But that one we can do manually when we see
it. The previous {{{}}} problem would have been too esoteric to fix
manually and thus needed to be done within the script.
The other thing that was unresolved, but now works, is admin access to
the wiki. After I do a small change, anyone within the cocoon group on
Minotaur (all Cocoon committers) can add a password so that they can
have administrative access to the wiki (e.g. deleting/reverting pages,
etc, I believe).
So, I need people to review the site at wiki.apache.org/cocoon, and to
point out anything that is unacceptable. If no objections, we should
make the JSP wiki read only, run the conversion script, upload the new
content to wiki.apache.org. The new wiki will then be live. After that
(as Steven has previously suggested), some clever mod_rewrite rules on
wiki.cocoondev.org could redirect people to the new Wiki. The below
would do _most_ of it:
RewriteCond %{REQUEST_URI} Wiki.jsp
RewriteCond %{QUERY_STRING} ?page=(abc)
RewriteRule .* http://wiki.apache.org/cocoon/%1 [R=301]
So, please review the new wiki conversion, and hopefully we can switch
pretty soon. If I hear nothing, I'll start a vote in a few days.
Regards, Upayavira
Re: [vote] Reschedule the release
Carsten Ziegeler wrote: Ugo Cei wrote: Carsten Ziegeler wrote: - switching to EHCache now +1 - testing it in the next days +1 - stick to the code freeze of course +1 - release on monday/tuesday if no issues arise -0 Just a couple of days over the weekend to test a component that probably no-one has used extensively and that might be intrinsically hard to test, seems too little to me. Might be better to wait one more week. That would be ok for me. I can do the release on Mo/Tu/We next week or any day the week after next week. BTW, if someone thinks that JCS is better, we could switch to that one as well. It seems that Antonio has got a positive response to his question about the outstanding bug in JCS. I can't help in this area. To be precise, here's the reply he got: *List: turbine-jcs-dev <http://marc.theaimsgroup.com/?l=turbine-jcs-dev&r=1&w=2> Subject:RE: JCS status <http://marc.theaimsgroup.com/?t=10578955134&r=1&w=2> From: Aaron Smuts <http://marc.theaimsgroup.com/?a=10578955505&r=1&w=2> Date: 2004-05-14 12:56:47 <http://marc.theaimsgroup.com/?l=turbine-jcs-dev&r=1&b=200405&w=2> * The diskcache shutdown storage problem (where the keys were not being stored) should be solved. Let me know if you have any problems. Cheers, Aaron Upayavira
Re: Release tomorrow?
Ralph Goers wrote: What about the issues with Rhino? Was the licensing issue resolved? Do we have permission to do a release with the current Rhino? Basically, the view was that, until something clear comes from the board stating how we should be operating, we should carry on as we have done. That is, we can release. That doesn't mean we shouldn't still persue an up-to-date Rhino with continuations though. Regards, Upayavira -Original Message- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Sent: Friday, May 14, 2004 2:04 AM To: [EMAIL PROTECTED] Subject: RE: Release tomorrow? Bertrand Delacretaz wrote: Le 14 mai 04, à 10:50, Sylvain Wallez a écrit : ...What's the status of EHCache and JCS? Can't we consider one of them as the default persistent store? I think there's an issue with JCS, something at shutdown IIRC? And, also IIRC, Unico reported using EHCache with no problems. Ah, thanks, Sylvain for the info! So, I think we should not release today, switch to EHCache, test it over the weekend and then release on monday or tuesday. Carsten
Re: Release tomorrow?
Ugo Cei wrote: Il giorno 13/mag/04, alle 23:57, Joerg Heinicke ha scritto: Running org.apache.cocoon.bean.CocoonBeanTestCase Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0,864 sec TEST org.apache.cocoon.bean.CocoonBeanTestCase FAILED Some info on it from Upayavira: http://marc.theaimsgroup.com/?t=10801146423&r=1&w=4 We just need an Avalon guru, then ;-). Yup. This test case just shows up something that has been wrong for a _very_ long time. I'm reluctant to remove it, as that which it shows up should be fixed rather than ignored. Either I finally work it out (which probably won't happen in a hurry) or someone else looks into it. How to remove reliance upon the servlet.jar. Hmm. Regards, Upayavira
Re: XConfToolTask and more than one patch action per file
Ralph Goers wrote: This looks fine to me. If you'd like me to do it I'd be happy to, but I won't be able to do it until sometime next week. Go for it. Some time next week sounds good - it wouldn't get committed this week anyway, because of the code freeze. Upayavira Ralph -Original Message- From: Upayavira [mailto:[EMAIL PROTECTED] Sent: Thursday, May 13, 2004 7:34 AM To: [EMAIL PROTECTED] Subject: Re: XConfToolTask and more than one patch action per file Ralph Goers wrote: I was thinking I would just look at the child nodes of the root. If they are all then they are all patches. That all feels a little magic to me. How about Thus, it is the root node that states that what comes are a number of patches, and the contents are a number of patch nodes much like existing files. Seems the best to me, and probably the easiest to implement. Upayavira Ralph -Original Message- From: Claas Thiele [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 12, 2004 11:45 PM To: [EMAIL PROTECTED] Subject: Re: XConfToolTask and more than one patch action per file Ralph Goers wrote: I had thought about doing this in my last update to XConfToolTask, but I didn't want to add two features in one patch. Doing this could actually be pretty easy. Currently, it looks at the root node and grabs info from it. It would be pretty easy to see if the child nodes are some sort of "patch" node, At the moment all nested content will be copied to the document to be patched. So we need a switch, an attribute on root for instance, or a namespace? or: if the root node has no attributes, the child nodes are interpreted as "patch" nodes. Claas
Re: XConfToolTask and more than one patch action per file
Ralph Goers wrote: I was thinking I would just look at the child nodes of the root. If they are all then they are all patches. That all feels a little magic to me. How about Thus, it is the root node that states that what comes are a number of patches, and the contents are a number of patch nodes much like existing files. Seems the best to me, and probably the easiest to implement. Upayavira Ralph -Original Message- From: Claas Thiele [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 12, 2004 11:45 PM To: [EMAIL PROTECTED] Subject: Re: XConfToolTask and more than one patch action per file Ralph Goers wrote: I had thought about doing this in my last update to XConfToolTask, but I didn't want to add two features in one patch. Doing this could actually be pretty easy. Currently, it looks at the root node and grabs info from it. It would be pretty easy to see if the child nodes are some sort of "patch" node, At the moment all nested content will be copied to the document to be patched. So we need a switch, an attribute on root for instance, or a namespace? or: if the root node has no attributes, the child nodes are interpreted as "patch" nodes. Claas
Re: Using CocoonBean in a CocoonServlet
Sylvain Wallez wrote: Upayavira wrote: Sylvain Wallez wrote: Hi folks, In one of our projects, we use CocoonBean in a CocoonServlet environment to dump a collection of generated documents on disk. Doing this, we encountered two problems: - CocoonComponentManager.checkEnvironment barfs and throws an Exception since the servlet environment exists on the stack when the CocoonBean starts its processing. Obvious solution is to remove this test, as indicated in the method's comments. I'm okay with it. Although it would be better if the Bean within a servlet could share the Cocoon object, along with all that goes with it. That would make the Bean really quick to start up. I believe Unico had ideas about this. If the CLI and Servlet environments were sharing the same Cocoon object, the CLI wouldn't load a logkit.xconf and there would therefore be no problem. But in my particular case, it's better for the two environments not to share the same Cocoon object, as this allows to cleanly separate the application front end (the CocoonServlet) from the publishing part (the CocoonBean). Does this mean that you have two webapps? I guess my ideal would be one bean per webapp. Is that what you mean by "clean separation"? What do you do about the slow startup of the bean? It needs to initialise an entire Cocoon instance before it can do anything. Do you run the bean in the background, or keep a app context bean? Would it help if the bean was known to work in multithreaded environments? Regards, Upayavira Sylvain
Re: Supersonic block has landed (Power Trio tutorial/example app)
Bertrand Delacretaz wrote: Le 10 mai 04, à 21:21, Joerg Heinicke a écrit : On 10.05.2004 14:28, Bertrand Delacretaz wrote: ...I think that it should be called the "tour" block, yet still have the familiar name of "Supersonic Tour"... Do others have the same opinion? If so I'm ok to rename the block, I agree that it's a more descriptive name. I prefer 'tour' as blockname and 'Supersonic Tour' as name for the tour itself. I guess that's the same David suggested. I also would do this step before the release, supersonic block was only introduced some days ago and there are no external dependencies on it. +1 for changing the name before the release (I'm ok with "tour" as I said before) Feel free to do it if you have time, I won't have time before Wednesday. +1 from me too. Upayavira
Re: Using CocoonBean in a CocoonServlet
Sylvain Wallez wrote: Hi folks, In one of our projects, we use CocoonBean in a CocoonServlet environment to dump a collection of generated documents on disk. Doing this, we encountered two problems: - CocoonComponentManager.checkEnvironment barfs and throws an Exception since the servlet environment exists on the stack when the CocoonBean starts its processing. Obvious solution is to remove this test, as indicated in the method's comments. I'm okay with it. Although it would be better if the Bean within a servlet could share the Cocoon object, along with all that goes with it. That would make the Bean really quick to start up. I believe Unico had ideas about this. - CocoonWrapper reconfigures the default log hierarchy which is also used by CocoonServlet, thus leading to a big mess in loggers. I have a simple patch here that makes CocoonBean create its own hierarchy. I'm okay with this. Never looked much at the logging code myself. I consider these as bugs and would like to commit the changes even if we're in code freeze. Note that this changes _nothing_ when CocoonBean is run in normal CLI mode. Regards, Upayavira
Re: [GUMP@lsd]: cocoon-2.1/cocoon failed
Adam R. B. Jack wrote: So, we have three choices: (1) Accept that Gump just will not work until we fix this. Not really acceptable (2) Remove the CocoonBeanTestCase (3) Someone more versed in Avalon initialisation have a look into getting the test case working on a full Cocoon. Don't know if a 4th interests you. Does the Cocoon build allow you to separate compilation/jaring from testing? Meaning could you call one ant target to compile/jar (without testing) and another to test? If so, we could split the Cocoon project into cocoon and cocoon-test and have folks depend solely upon the former. This would allow you to take some time & decide upon how to resolve the tests. It isn't just the compilation - it is the building of the Avalon configuration that causes some components to be initialised. It is the initialisation that fails. We could build Cocoon twice, which would get around it. But, to be honest, I'd rather we looked into getting the thing fixed. For an Avalon guru, I don't think it would be hard. Regards, Upayavira
Re: [CForms]FormattingDateConvertor can't convert blank to date in current cvs version.
Bruno Dumon wrote:
On Sun, 2004-05-09 at 12:07, roy huang wrote:
Hi All:
If I user xml as data to binding cocoon forms,I must using DateConvertor to convert string to date like:
-MM-dd
the data may looks like:
1971-05-06
But if the data is it will error like:
org.apache.avalon.framework.CascadingRuntimeException:
"resource://org/apache/cocoon/forms/flow/javascript/Form.js", line 160: uncaught JavaScript
exception: at bindingSample
(file:/D:/eclipse/workspace/cocoon-2.1/build/webapp/samples/blocks/forms/flow/bindings.js, Line 73) at
(resource://org/apache/cocoon/forms/flow/javascript/Form.js, Line 160): java.lang.RuntimeException:
Incorrect value type for "date" (expected class java.util.Date, got class java.lang.String.
But it works only several days ago,so I check the cvs and believe is Bruno's change in 5.6 makes it. Here's what he said in cvs comments:
Made Convertor.convertFromString contract more solid by letting it
return a ConversionResult object (instead of null/not-null to indicate
successful conversion). This also moves the responsibility
of creating the ValidationError to the Convertor, allowing convertors
to set more specialised messages in them.
What can I do to convert an blank ("") string to Date type? Or this should be considered in the FormattingDateConvert.java?I believe this function is need because date may be blank.
WDYT?
I made a little error in my change, it simply needs an "else value =
null" added. I'll fix it after the code freeze.
Why after? Surely the code freeze is intended to be a time for fixing
bugs (but not for committing 'innovations')? Otherwise, this bug will be
enshrined in 2.1.5, which would be a shame.
Regards, Upayavira
Re: [GUMP@lsd]: cocoon-2.1/cocoon failed
Joerg Heinicke wrote:
On 08.05.2004 15:29, Adam R. B. Jack wrote:
If you could add :
Applied it. Thanks.
I can also reproduce the failure on my local system. When I tried to
do all tests some days ago (NetUtils.normalize()) it still worked.
Hmm. Now there's an interesting consequence of the CocoonBeanTestCase.
It was supposed to just test one method, and when run on a Cocoon with
only a few blocks, it works fine. But
I haven't been able to run the Bean on a complete Cocoon since I can
remember. So this test case has inadvertently shown up a bigger error.
I've started trying to locate the code that breaks it, but am not enough
of an Avalon guru to be able to follow it all through. I suspect it is
to do with not having servlet.jar in the classpath. I've got a local
patch on the Deli block that should remove one such problem (attached),
but when trying to debug this I've felt like I'm working pretty much in
the dark.
So, we have three choices:
(1) Accept that Gump just will not work until we fix this. Not really
acceptable
(2) Remove the CocoonBeanTestCase
(3) Someone more versed in Avalon initialisation have a look into
getting the test case working on a full Cocoon.
Thoughts?
Regards, Upayavira
Testsuite: org.apache.cocoon.bean.CocoonBeanTestCase
Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 1,5 sec
Testcase: testProcessToStream took 1,109 sec
Caused an ERROR
Could not get class
org.apache.avalon.framework.configuration.ConfigurationException:
Could not get class
at
org.apache.avalon.excalibur.component.ExcaliburComponentManager.configure(ExcaliburComponentManager.java:456)
at
org.apache.avalon.framework.container.ContainerUtil.configure(ContainerUtil.java:240)
at org.apache.cocoon.Cocoon.configure(Cocoon.java:438)
at org.apache.cocoon.Cocoon.initialize(Cocoon.java:296)
at
org.apache.avalon.framework.container.ContainerUtil.initialize(ContainerUtil.java:283)
at
org.apache.cocoon.bean.CocoonWrapper.initialize(CocoonWrapper.java:151)
at org.apache.cocoon.bean.CocoonBean.initialize(CocoonBean.java:97)
at
org.apache.cocoon.bean.CocoonBeanTestCase.getCocoonBean(CocoonBeanTestCase.java:74)
at
org.apache.cocoon.bean.CocoonBeanTestCase.testProcessToStream(CocoonBeanTestCase.java:46)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
Caused by: java.lang.ClassNotFoundException:
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl
at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)
at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
at
org.apache.avalon.excalibur.component.ExcaliburComponentManager.configure(ExcaliburComponentManager.java:442)
... 22 more
Index: src/blocks/deli/java/org/apache/cocoon/components/deli/DeliImpl.java
===
RCS file:
/home/cvs/cocoon-2.1/src/blocks/deli/java/org/apache/cocoon/components/deli/DeliImpl.java,v
retrieving revision 1.10
diff -u -r1.10 DeliImpl.java
--- src/blocks/deli/java/org/apache/cocoon/components/deli/DeliImpl.java5 Mar
2004 13:01:55 - 1.10
+++ src/blocks/deli/java/org/apache/cocoon/components/deli/DeliImpl.java9 May
2004 07:42:51 -
@@ -49,6 +49,7 @@
import org.apache.avalon.framework.thread.ThreadSafe;
import org.apache.cocoon.Constants;
import org.apache.cocoon.environment.Request;
+import org.apache.cocoon.environment.http.HttpContext;
import org.apache.excalibur.xml.dom.DOMParser;
import org.w3c.dom.Document;
import org.w3c.dom.Element;
@@ -85,19 +86,27 @@
/** A context, used to retrieve the path to the configuration file */
protected CocoonServletContext servletContext;
+private boolean isHTTPContext;
/** Contextualize this class */
public void contextualize(Context context) throws ContextException {
org.apache.cocoon.environment.Context ctx =
(org.apache.cocoon.environment.Context)context.get(
Constants.CONTEXT_ENVIRONMENT_CONTEXT);
-this.servletContext = new CocoonServletContext(ctx);
+isHTTPContext = ctx instanceof HttpContext;
+if (!isHTTPContext) {
+getLogger().error("Deli is only available in an HTTP Environment");
+} else {
+this.servletContext = new CocoonServletContext(ctx);
+}
}
/** Service this class */
public void service(ServiceManager manager) throws ServiceException {
Re: Moving to subversion - volunteers?
Nicola Ken Barozzi wrote: Carsten Ziegeler wrote: We agreed that we move to subversion as soon as possible. Next friday we will (hopefully) release 2.1.5, so we should move right after the release. Any volunteers for doing this? Err... what should we actually do? I mean, let's say that we have decided that the format will be: /cocoon/ <- this is the repository /2.0/ /trunk/ <- trunk of 2.0 /tags/ <- tags of 2.0 /2.1/ /trunk/ <- trunk of 2.1 /tags/ <- tags of 2.1 IIUC we just need to ask infrastructure to run cvs2svn to the cocoon-2.1 and cocoon-2.2 repos and put them under "cocoon" as 2.1 and 2.2. Personally, I would leave 2.0 as is, and then: /cocoon/ /trunk/ <- current trunk /tags/new-kernel/ <- current 2.2 code I would do it this way as, if we are to follow our new versioning scheme, we cannot identify the new kernel with the version 2.2, so we shouldn't use version numbers in our repository names. We should use 'feature names' in our branches/tags. E.g. Forrest has its 'copyless' branch. So we should have a 'new kernel' branch. Regards, Upayavira /cocoon
Re: [BUG] NPE in VariableResolver
Carsten Ziegeler wrote:
Seems like a good change to me.
Yup. I wondered what the sample was supposed to do when I looked at it -
it seemed pretty useless as it was.
I've committed your change Jorg, thanks for that.
Upayavira
-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Jorg Heymans
Sent: Thursday, May 06, 2004 11:20 PM
To: [EMAIL PROTECTED]
Subject: Re: [BUG] NPE in VariableResolver
Coincidentally, i was just clicking through the HEAD samples
to see if there were any broken links i could (easily) fix. (see also
http://issues.apache.org/bugzilla/show_bug.cgi?id=28810)
The baselink module sitemap should be patched to something
more appropriate like inlined patch below. There are two
variables available (looking at the source) in this module,
SitemapBaseLink and RequestBaseLink. They both take a URL and
return a relative path. I don't know if this module is used a
lot, but at least with the patch the sample is showing the
module's functionality again.
Index: src/webapp/samples/modules/sitemap.xmap
===
RCS file:
/home/cvspublic/cocoon-2.1/src/webapp/samples/modules/sitemap.xmap,v
retrieving revision 1.9
diff -u -r1.9 sitemap.xmap
--- src/webapp/samples/modules/sitemap.xmap 10 Mar 2004 13:36:09
- 1.9
+++ src/webapp/samples/modules/sitemap.xmap 6 May 2004
21:05:40 -
@@ -101,14 +101,16 @@
-
+
+
HTH
Jorg
Upayavira wrote:
Carsten Ziegeler wrote:
I just tried some examples for the upcomming release and the input
module sample for baseLink
http://localhost:/samples/modules/baselink.html
throws an NPE in the variable resolver.
Is this due to the variable resolver changes (nested variables)?
The broken variable is {baselink:}. My code couldn't handle nothing
after the colon. I've committed a fix (along with some
files I didn't
mean to commit - I rolled them back).
Having said that, I can't work out what the example should
have been
doing. But at least it shouldn't break now.
Regards, Upayavira
Re: [BUG] NPE in VariableResolver
Carsten Ziegeler wrote:
I just tried some examples for the upcomming release
and the input module sample for baseLink
http://localhost:/samples/modules/baselink.html
throws an NPE in the variable resolver.
Is this due to the variable resolver changes (nested variables)?
The broken variable is {baselink:}. My code couldn't handle nothing
after the colon. I've committed a fix (along with some files I didn't
mean to commit - I rolled them back).
Having said that, I can't work out what the example should have been
doing. But at least it shouldn't break now.
Regards, Upayavira
[QVOTE] Add global forwards to Flow
I have previously posted this message with no reply, which I take to be
no objection:
I would like to enable global redirects from within FOM, such as:
cocoon.redirectTo("http://www.foo.com";, true); where 'true' says 'global'.
cocoon.redirectTo("http://www.foo.com";) or
cocoon.redirectTo("http://www.foo.com";, false) would do the same
redirection as currently.
This is why:
function go() {
cocoon.redirectTo("http://www.foo.com";);
}
Going to http://localhost:/uv2 will redirect correctly. Going to
http://localhost:/uv1 will not.
I do not see any reason why we shouldn't add this functionality to FOM.
Please state any objections. If no objections by the end of Friday, I
will commit my fix.
Upayavira, who is learning to take silence as assent, rather than
rejection ;-)
Re: Supersonic block has landed (Power Trio tutorial/example app)
Bertrand Delacretaz wrote: I've just committed the new "supersonic" block, a tutorial/example app called "Supersonic Tour of Apache Cocoon", focused on Pipelines, Flow, Forms (aka "the Power Trio"). It is accessible from the "blocks with samples" page if you run the current Cocoon CVS version. The tutorial is meant to be studied independently of other docs, and give a quick overview of the most important components of Cocoon. There are probably a few typos here and there, and I'm no Forms guru (yet..) so enhancements are certainly possible (for example: why does this "Calendar" link show up next to the date entry fields ;-) Enjoy, and as always feedback and contributions are very welcome! Haven't looked at this yet (but expect it to be good!). My immediate response is 'why the name supersonic'. It obfuscates the contents of the block. Why not just have a tutorial block, or a tutorials block if there are more than one in there? That way it is completely obvious to someone looking at Cocoon what is in there, and they'll be off coding, without any additional help from us. But with this name, it just becomes one amongst many unclear names: fop, deli, cron, batik, axis, slide, slop, stx, velocity, etc, etc, etc. In a block called tutorials, I think this could be an invaluable addition. Regards, Upayavira
Re: modifying attributes with xpatch
Ralph Goers wrote: We are copying the sitemap from the cocoon build into ours and then using xpatch to modify it. However, we need to change the pool sizes for the various components. I'd like to modify xpatch so that it can modify multiple attributes in one patch file instead of having to provide a separate file for each attribute. It would also be "nicer" to allow multiple patches (like changing all the pool sizes) in a file. I have no problem modifying xpatch if I can get some suggestions on a good syntax to specify this. Why don't you suggest a syntax here? I'd be fine with this change. Upayavira
Re: InitParameters in Cocoon
Anna Bikkina wrote:
Hi,
I have been struggling with this problem since a week. Can someone please shed
some light.
I have some init-parameters defined in web.xml which are related to my
application running on cocoon. When I do
context.getInitParameter("paramname") in a xsp it returns null. Also in
action files
String limit1 =
ObjectModelHelper.getContext(objectModel).getInitParameter("timelimit");
when I use the above command I get limit1 as null. Am I missing something
here.
Why do you need them there. Can't you put them somewhere else? I've
failed before to get hold of web.xml parameters.
Upayavira
Re: NetUtils / StringUtils / Tokenizer
Ugo Cei wrote:
Joerg Heinicke wrote:
3. while the Tokenizer correctly works on "/../" the
NetUtils.normalize() method has a problem with it:
What is the correct output for "/../"? I'd say "/", but the testcase
expects "/../".
I would consider /../ an error.
What does new File("/../foo") do?
Upayavira
Re: generator type value substitution
Ugo Cei wrote:
Il giorno 29/apr/04, alle 11:11, Leszek Gawron ha scritto:
As I have stated before this is not a WEB application. I use cocoon
as xml
data provider for my C++ application. I know this usage is not common.
I have used xsps before but I decided to switch to a compiled
solution. I had
lot of problems with compile time errors and completely no support in
refactoring I have now with eclipse and java generators.
Wouldn't it be possible to retrieve your data into JavaBeans and
serialize them to XML using one of the many Java-to-XML serialization
libraries (XMLBeans comes to mind and Cocoon already includes Castor)?
Or, you could use the flow/javabean/jxtemplate approach. It really is
quite easy, and powerful.
What you do is:
* forward the request to a flow function
* That function instantiates a java bean object, and calls methods on it
to get data into it
* Then call cocoon.sendPage, calling a pipeline that begins with a
JXTemplateGenerator, and passing it the javabean object, which'll be
available to JXTemplateGenerator
* In the JXTemplateGenerator, you can interrogate your javabean in many
ways, e.g. with or , and accessing bits of your java
beans with either JEXL or JXPATH, so maybe
#{/bean/services/first/address/postalcode}.
That's how I would do it these days.
And then, if you want to, you can have your javabean, which is accessed
from flow, making connections to some object relational mapping tool, to
get even cleverer.
Just in case this approach is useful. feel free to ignore me.
Regards, Upayavira
Re: NetUtils / StringUtils / Tokenizer
Ugo Cei wrote: Il giorno 29/apr/04, alle 02:48, Joerg Heinicke ha scritto: After Cheche's bug report I had a look at NetUtils. Though Ugo fixed it with a quick fix, it does not really solve the problem as a test with the updated NetUtilsTestCase and the NetUtils before my latest commit can easily show. Frankly, I don't even know what NetUtils.normalize is supposed to do, so I cannot be of any help here. Doesn't it replace, for example /cocoon/src/java/../webapp with /cocoon/src/webapp? i.e. removing .. from paths? Regards, Upayavira
Re: Minor bug: reference to Woody in 2.1.5-dev welcome.xml
[EMAIL PROTECTED] wrote: src/webapp/samples/samples.xml Since the Cocoon Control Flow is a core technology you find more examples that make use of it e.g. the Petstore, JXForms and Woody block Examples of Cocoon's control flow of Web pages. And I suppose the reference to the JXForms can also be removed? Done. BTW. It would be easier if these examples cross-link to the other flow examples (like Petstore). Would that be a difficult task to do? Hmm. You might end up with broken links if it is to blocks that haven't been included. You'd need to find a way around that. Regards, Upayavira Bye, Helma -Original Message- From: Upayavira [mailto:[EMAIL PROTECTED] Sent: Wednesday, 28 April 2004 23:09 To: [EMAIL PROTECTED] Subject: Re: Minor bug: reference to Woody in 2.1.5-dev welcome.xml [EMAIL PROTECTED] wrote: Hi, Reading about the upcoming 2.1.5 release I just noticed that on the "root" welcome.xml of the samples the Control Flow section still mentions Woody, should be CForms. Could you find the source file for it? Somewhere in src/webapp/samples, I should think. Find it and I'll fix it. Regards, Upayavira
A (very small) test suite webapp
I've just committed a very basic test suite to the built webapp. I plan to use this suite within the CocoonBeanTestCase I'm writing at the mo, but could imagine it being used for other tests (e.g. anteater) too. The purpose of these, as opposed to the samples, is that these are designed to go along with the tests - they won't get changed for reasons that have nothing to do with the tests, whereas the samples might. Regards, Upayavira
Re: Minor bug: reference to Woody in 2.1.5-dev welcome.xml
[EMAIL PROTECTED] wrote: Hi, Reading about the upcoming 2.1.5 release I just noticed that on the "root" welcome.xml of the samples the Control Flow section still mentions Woody, should be CForms. Could you find the source file for it? Somewhere in src/webapp/samples, I should think. Find it and I'll fix it. Regards, Upayavira
Re: Planning the 2.1.5 release
Sylvain Wallez wrote: Upayavira wrote: Carsten Ziegeler wrote: It's time to think about the next release. As far as I can see there are currently no real showstoppers. So, is there something that we should do for the 2.1.5 release? Liaise with the CForms guys to find the best time for them.Theirs is the code that is changing the most, and if 2.1.5 is going to be a CForms snapshot, we want it to be a reasonably good one! CForms is stabilizing quickly, but we'll still need a bit more time to stamp it as "stable". So let's not consider CForms as a blocking item for a 2.1.5. On the contrary, I think many people are waiting for it to start the move from Woody to CForms. I wasn't considering it a blocking item - I was just saying, more or less, "let's not release in the middle of a commit!" All I'd want is a CForms chap to say, "Yes, now is an okay time to release, CForms is working". Then I'd be happy (and delighted, actually) to have a release. Hope that's clear enough! Upayavira Sylvain
Re: Planning the 2.1.5 release
Carsten Ziegeler wrote: It's time to think about the next release. As far as I can see there are currently no real showstoppers. So, is there something that we should do for the 2.1.5 release? Liaise with the CForms guys to find the best time for them.Theirs is the code that is changing the most, and if 2.1.5 is going to be a CForms snapshot, we want it to be a reasonably good one! Otherwise - just go for it! Upayavira
Re: cocoon.sendPage and redirect-to not compatible?
黄 海冬 wrote: > Just after submit my mail I saw an archive mail-list describe the same: > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=10756461460&w=2,but > nobody response. Just curious, try: See if that works. Upayavira
