cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/treeprocessor/sitemap ActNodeBuilder.java ActionSetNodeBuilder.java RedirectToNodeBuilder.java SelectNodeBuilder.java
sylvain 02/02/12 01:21:10
Modified:src/scratchpad/src/org/apache/cocoon/treeprocessor/sitemap
ActNodeBuilder.java ActionSetNodeBuilder.java
RedirectToNodeBuilder.java SelectNodeBuilder.java
Log:
Fix bug #6386, plus some minor cleanup
Revision ChangesPath
1.6 +1 -7
xml-cocoon2/src/scratchpad/src/org/apache/cocoon/treeprocessor/sitemap/ActNodeBuilder.java
Index: ActNodeBuilder.java
===
RCS file:
/home/cvs/xml-cocoon2/src/scratchpad/src/org/apache/cocoon/treeprocessor/sitemap/ActNodeBuilder.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ActNodeBuilder.java 6 Feb 2002 18:22:28 - 1.5
+++ ActNodeBuilder.java 12 Feb 2002 09:21:10 - 1.6
@@ -55,9 +55,6 @@
package org.apache.cocoon.treeprocessor.sitemap;
-import org.apache.avalon.framework.component.ComponentManager;
-import org.apache.avalon.framework.component.ComponentSelector;
-import org.apache.avalon.framework.component.Composable;
import org.apache.avalon.framework.configuration.Configuration;
import org.apache.avalon.framework.configuration.ConfigurationException;
@@ -75,19 +72,16 @@
/**
*
* @author a href=mailto:[EMAIL PROTECTED];Sylvain Wallez/a
- * @version CVS $Id: ActNodeBuilder.java,v 1.5 2002/02/06 18:22:28 sylvain Exp $
+ * @version CVS $Id: ActNodeBuilder.java,v 1.6 2002/02/12 09:21:10 sylvain Exp $
*/
public class ActNodeBuilder extends AbstractParentProcessingNodeBuilder
implements LinkedProcessingNodeBuilder {
-private ComponentManager manager;
-
private ActSetNode actSetNode;
private String actSetName;
public ProcessingNode buildNode(Configuration config) throws Exception {
-
// Is it an action-set call ?
this.actSetName = config.getAttribute(set, null);
1.6 +1 -6
xml-cocoon2/src/scratchpad/src/org/apache/cocoon/treeprocessor/sitemap/ActionSetNodeBuilder.java
Index: ActionSetNodeBuilder.java
===
RCS file:
/home/cvs/xml-cocoon2/src/scratchpad/src/org/apache/cocoon/treeprocessor/sitemap/ActionSetNodeBuilder.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ActionSetNodeBuilder.java 6 Feb 2002 18:22:28 - 1.5
+++ ActionSetNodeBuilder.java 12 Feb 2002 09:21:10 - 1.6
@@ -55,9 +55,6 @@
package org.apache.cocoon.treeprocessor.sitemap;
-import org.apache.avalon.framework.component.ComponentManager;
-import org.apache.avalon.framework.component.ComponentSelector;
-import org.apache.avalon.framework.component.Composable;
import org.apache.avalon.framework.configuration.Configuration;
import org.apache.avalon.framework.configuration.ConfigurationException;
import org.apache.avalon.framework.thread.ThreadSafe;
@@ -73,12 +70,10 @@
/**
*
* @author a href=mailto:[EMAIL PROTECTED];Sylvain Wallez/a
- * @version CVS $Id: ActionSetNodeBuilder.java,v 1.5 2002/02/06 18:22:28 sylvain
Exp $
+ * @version CVS $Id: ActionSetNodeBuilder.java,v 1.6 2002/02/12 09:21:10 sylvain
Exp $
*/
public class ActionSetNodeBuilder extends AbstractProcessingNodeBuilder implements
ThreadSafe {
-
-private ComponentManager manager;
public ProcessingNode buildNode(Configuration config) throws Exception {
1.5 +15 -8
xml-cocoon2/src/scratchpad/src/org/apache/cocoon/treeprocessor/sitemap/RedirectToNodeBuilder.java
Index: RedirectToNodeBuilder.java
===
RCS file:
/home/cvs/xml-cocoon2/src/scratchpad/src/org/apache/cocoon/treeprocessor/sitemap/RedirectToNodeBuilder.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- RedirectToNodeBuilder.java4 Feb 2002 14:39:53 - 1.4
+++ RedirectToNodeBuilder.java12 Feb 2002 09:21:10 - 1.5
@@ -69,7 +69,7 @@
/**
*
* @author a href=mailto:[EMAIL PROTECTED];Sylvain Wallez/a
- * @version CVS $Id: RedirectToNodeBuilder.java,v 1.4 2002/02/04 14:39:53 cziegeler
Exp $
+ * @version CVS $Id: RedirectToNodeBuilder.java,v 1.5 2002/02/12 09:21:10 sylvain
Exp $
*/
public class RedirectToNodeBuilder extends AbstractProcessingNodeBuilder
@@ -84,15 +84,14 @@
}
public ProcessingNode buildNode(Configuration config) throws Exception {
-
+
// Is it a redirect to resource ?
-String uri = config.getAttribute(uri, null);
-if (uri != null) {
-ProcessingNode URINode = new RedirectToURINode(uri,
config.getAttributeAsBoolean(session, false));
-return this.treeBuilder.setupNode(URINode, config);
+
DO NOT REPLY [Bug 6386] - [TreeProcessor] Nested map:select in resource malfunction
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6386. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6386 [TreeProcessor] Nested map:select in resource malfunction [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-02-12 09:26 --- Fixed. This was because SelectNodeBuilder wasn't really ThreadSafe even if declared so (a reminiscence of early design iterations). It is now *really* ThreadSafe. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
problems using j2sdk1.4.0 rc
Hi people,
I installed version 1.4.0 release candidate from Sun (under Linux)
but cocoon seems to have problems with this.
I recompiled cocoon-2.1-dev.jar
By calling the first page I got the following error:
ProcessingException: Language Exception ...
Note: sun.tools.javac.Main has been deprecated...
and other (may be following) errors:
EsqlConnectionCocoon2() is an abstract class. It can not be instantiated. ...
In components/language/programming/javac/Javac.java
we ask if it is modern (com.sun...) or not (sun...)
But we have only this line (about line 117):
sun.tools.javac.Main compiler = new sun.tools.javac.Main(err, javac);
Here we don't care about modern or not.
I wrote the compile method as follows:
public boolean compile() throws IOException {
ByteArrayOutputStream err = new ByteArrayOutputStream();
boolean result = false;
if(modern) {
com.sun.tools.javac.Main compiler = new com.sun.tools.javac.Main();
int iresult = compiler.compile(toStringArray(fillArguments(new ArrayList(;
if(iresult == 0) result = true;
else result = false;
}
else {
sun.tools.javac.Main compiler = new sun.tools.javac.Main(err, javac);
result = compiler.compile(toStringArray(fillArguments(new ArrayList(;
this.errors = new ByteArrayInputStream(err.toByteArray());
}
return result;
}
But now I get a java.lang.IncompatibleClassChangeError
The error log says that Excalibur also has problems:
FATAL_E (2002-02-12) 11:29.05:470 [core]
(Unknown-URI) Unknown-thread/LogKitLogger:
Excalibur could not create any connections.
Examine your settings to make sure they are correct.
Make sure you can connect with the same settings on your machine.
Any suggestions?
Michael
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: [FYI] Tomcat 4.0.2 Release notes
De: Stuart Roebuck [mailto:[EMAIL PROTECTED]] Enviado el: lunes 11 de febrero de 2002 19:14 Why does Cocoon 2.0 work better with HTTP 1.0 rather than 1.1 under Tomcat 4? Nothing fancy or weird, simply the HTTP/1.1 connector in Tomcat 4.0 *was* so slow, and a big garbage producer, and the HTTP/1.0 is more or less the same that Tomcat 3.2 had.. But afaik, 4.0.2 has inside the new HTTP/1.1 connector rewrited from scratch by Remy Maucherat, known as Coyote, and the advice contained in the readme perhaps is no longer valid.. Remy can you add some more first hand info ?, thanks Stuart. Saludos , Ignacio J. Ortega - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/store FilesystemStore.java
cziegeler02/02/12 04:55:24
Modified:src/java/org/apache/cocoon/components/store
FilesystemStore.java
Log:
Fixed Filesystemstore:
- keys can now be any values
- the get() method now returns the object previously stored and not a File
Revision ChangesPath
1.7 +58 -4
xml-cocoon2/src/java/org/apache/cocoon/components/store/FilesystemStore.java
Index: FilesystemStore.java
===
RCS file:
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/components/store/FilesystemStore.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- FilesystemStore.java 4 Feb 2002 12:31:09 - 1.6
+++ FilesystemStore.java 12 Feb 2002 12:55:24 - 1.7
@@ -75,12 +75,18 @@
*
* @author ?
* @author a href=mailto:[EMAIL PROTECTED];Vadim Gritsenko/a
- * @version CVS $Id: FilesystemStore.java,v 1.6 2002/02/04 12:31:09 cziegeler Exp $
+ * @version CVS $Id: FilesystemStore.java,v 1.7 2002/02/12 12:55:24 cziegeler Exp $
*/
public final class FilesystemStore
extends AbstractLoggable
implements Store, Contextualizable, Parameterizable, ThreadSafe {
+protected static final int BYTE_MASK = 0x0f;
+protected static final char[] HEX_DIGITS =
+{
+'0','1','2','3','4','5','6','7','8','9','A','B','C','D','E','F'
+};
+
protected File workDir;
protected File cacheDir;
@@ -182,7 +188,11 @@
if (this.getLogger().isDebugEnabled()) {
getLogger().debug(Found file: + key);
}
-return file;
+try {
+return IOUtils.deserializeObject(file);
+} catch (Exception any) {
+getLogger().error(Error during deseralization., any);
+}
} else {
if (this.getLogger().isDebugEnabled()) {
getLogger().debug(NOT Found file: + key);
@@ -284,7 +294,7 @@
if (files[i].isDirectory()) {
this.addKeys(enum, files[i]);
} else {
-enum.add(files[i].getAbsolutePath().substring(subStringBegin));
+
enum.add(this.decode(files[i].getAbsolutePath().substring(subStringBegin)));
}
}
}
@@ -339,7 +349,7 @@
/* Utility Methods*/
protected File fileFromKey(final Object key) {
-return IOUtils.createFile(this.directoryFile, key.toString());
+return IOUtils.createFile(this.directoryFile, this.encode(key.toString()));
}
public String getString(final Object key)
@@ -364,4 +374,48 @@
return null;
}
+
+/**
+ * Returns a String that uniquely identifies the object.
+ * bNote:/b since this method uses the Object.toString()
+ * method, it's up to the caller to make sure that this method
+ * doesn't change between different JVM executions (like
+ * it may normally happen). For this reason, it's highly recommended
+ * (even if not mandated) that Strings be used as keys.
+ */
+protected String encode( final String key )
+{
+final byte[] bytes = key.getBytes();
+final char[] buffer = new char[ bytes.length 1 ];
+
+for( int i = 0, j = 0; i bytes.length; i++ )
+{
+final int k = bytes[ i ];
+buffer[ j++ ] = HEX_DIGITS[ ( k 4 ) BYTE_MASK ];
+buffer[ j++ ] = HEX_DIGITS[ k BYTE_MASK ];
+}
+
+return new String(buffer);
+}
+
+/**
+ * Inverse of encode exept it do not use path.
+ * So decode(encode(s) - m_path) = s.
+ * In other words it returns a String that can be used as key to retive
+ * the record contained in the 'filename' file.
+ */
+protected String decode( String filename )
+{
+final int size = filename.length();
+final byte[] bytes = new byte[ size 1 ];
+
+for( int i = 0, j = 0; i size; j++ )
+{
+bytes[ j ] = Byte.parseByte( filename.substring( i, i + 2 ), 16 );
+i +=2;
+}
+
+return new String( bytes );
+}
+
}
--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/store FilesystemStore.java
cziegeler02/02/12 04:57:51
Modified:src/java/org/apache/cocoon/components/store
FilesystemStore.java
Log:
Correction
Revision ChangesPath
1.8 +4 -4
xml-cocoon2/src/java/org/apache/cocoon/components/store/FilesystemStore.java
Index: FilesystemStore.java
===
RCS file:
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/components/store/FilesystemStore.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- FilesystemStore.java 12 Feb 2002 12:55:24 - 1.7
+++ FilesystemStore.java 12 Feb 2002 12:57:51 - 1.8
@@ -75,7 +75,7 @@
*
* @author ?
* @author a href=mailto:[EMAIL PROTECTED];Vadim Gritsenko/a
- * @version CVS $Id: FilesystemStore.java,v 1.7 2002/02/12 12:55:24 cziegeler Exp $
+ * @version CVS $Id: FilesystemStore.java,v 1.8 2002/02/12 12:57:51 cziegeler Exp $
*/
public final class FilesystemStore
extends AbstractLoggable
@@ -243,7 +243,7 @@
public void hold(final Object key, final Object value)
throws IOException {
this.store(key, value);
-final File file = (File) this.get(key);
+final File file = (File) this.fileFromKey(key);
if (file != null) {
file.deleteOnExit();
}
@@ -354,7 +354,7 @@
public String getString(final Object key)
throws IOException {
-final File file = (File) this.get(key);
+final File file = (File) this.fileFromKey(key);
if (file != null) {
return IOUtils.deserializeString(file);
}
@@ -367,7 +367,7 @@
public Object getObject(final Object key)
throws IOException, ClassNotFoundException
{
-final File file = (File) this.get(key);
+final File file = (File) this.fileFromKey(key);
if (file != null) {
return IOUtils.deserializeObject(file);
}
--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Dispatcher/Adapter
Kinga, One more question: I was reviewing the code to see what methods you are actually using from HttpRequest. The only ones i could find are getAttribute/setAttribute/getParameter callsAll these are available in org.apache.cocoon.environment.Request. So what's the problem again? Thanks, dims --- DZIEMBOWSKI,KINGA (HP-NewJersey,ex2) [EMAIL PROTECTED] wrote: Hi, The new way to register Adapter is posted. The http://soap.bluestone.com/proposal has updated difs in the patch.zip. The additions are in xml-cocoon2.zip Kinga _ Kinga Dziembowski Hewlett Packard HP Bluestone Middleware Division 6000 Irwin Road Mt. Laurel, NJ 08054 856.638.6065 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] = Davanum Srinivas - http://jguru.com/dims/ __ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PROPOSAL] mulitple actions per class
While working with actions something bugs me more and more... For each
very simple action you need to have a new class. Although it might be just
a few lines for each, it becomes really ugly when you share code with
other actions or need to call an action from an action. Plus having
thousand of action class for a single webapp. Sure this all possible and
one can say: then use helper classes that hold all the shared code. But
well - possible does not mean confortable.
IIRC with Turbine e.g. it is way more confortable. They use
methods as actions:
class SomeActions {
public void doMyAction(..) {
...
(I'm not quite sure about the arguments and stuff though)
This helps to have all related code at a glance.
Although I'm not yet sure what syntax should be prefered
1. map:action type=SomeActions.doMyAction
!-- directly use the method --
2. map:action type=SomeActions.MyAction
!-- have a fix prefix like do --
3. map:action type=SomeActions method=doMyAction
4. map:action type=SomeActions method=MyAction
Of course this will require the use of the reflection API
for those actions using the new method syntax. (All others
will not be effected and treated as usual)
I have made some tests: if we use some intelligent
caching for the reflection API there will be only little
to no performance loss compared to the old mechanism.
What do guys think?
--
Torsten
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] mulitple actions per class
- Original Message - From: Torsten Curdt [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, February 12, 2002 2:34 PM Subject: [PROPOSAL] mulitple actions per class Although I'm not yet sure what syntax should be prefered 1. map:action type=SomeActions.doMyAction !-- directly use the method -- 2. map:action type=SomeActions.MyAction !-- have a fix prefix like do -- 3. map:action type=SomeActions method=doMyAction 4. map:action type=SomeActions method=MyAction Of course this will require the use of the reflection API for those actions using the new method syntax. (All others will not be effected and treated as usual) You can also use inner classes. I have made some tests: if we use some intelligent caching for the reflection API there will be only little to no performance loss compared to the old mechanism. Jdk 1.4 has way higher performance in using reflection. IMHO a ClassMethodAction, with class name and methos name as parameters, would suffice. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] mulitple actions per class
While working with actions something bugs me more and more... For each
very simple action you need to have a new class. Although it might be just
a few lines for each, it becomes really ugly when you share code with
other actions or need to call an action from an action. Plus having
thousand of action class for a single webapp. Sure this all possible and
one can say: then use helper classes that hold all the shared code. But
well - possible does not mean confortable.
Another possibility is to use a request or sitemap parameter with an
aggregated Action, e.g.:
map:match=cart/*
map:act name=CartAction
map:parameter name=action value={0} /
/map:act
/map:match
So, for requests like: 'cart/add', 'cart/remove', 'cart/update' you can use
a single action that performs something like:
act(...) {
if (ADD_ACTION.equals(actionName) {
// do addition
} else {
...
}
// etc.
}
IIRC with Turbine e.g. it is way more confortable. They use
methods as actions:
class SomeActions {
public void doMyAction(..) {
...
(I'm not quite sure about the arguments and stuff though)
This helps to have all related code at a glance.
Although I'm not yet sure what syntax should be prefered
1. map:action type=SomeActions.doMyAction
!-- directly use the method --
2. map:action type=SomeActions.MyAction
!-- have a fix prefix like do --
3. map:action type=SomeActions method=doMyAction
4. map:action type=SomeActions method=MyAction
I would use a substitution param for setting the 'method' value. You can
select the action to be performed based on request path, request parameter,
maybe even another action. E.g. depending on the time of day or the day of
week you can perform the action in a different way and another action will
define what method to perform.
Of course this will require the use of the reflection API
for those actions using the new method syntax. (All others
will not be effected and treated as usual)
I have made some tests: if we use some intelligent
caching for the reflection API there will be only little
to no performance loss compared to the old mechanism.
What do guys think?
--
Torsten
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: [PROPOSAL] mulitple actions per class
From: Torsten Curdt [mailto:[EMAIL PROTECTED]]
While working with actions something bugs me more and more... For each
very simple action you need to have a new class. Although it might be
just
a few lines for each, it becomes really ugly when you share code with
other actions or need to call an action from an action. Plus having
thousand of action class for a single webapp. Sure this all possible
and
one can say: then use helper classes that hold all the shared code.
But
well - possible does not mean confortable.
IIRC with Turbine e.g. it is way more confortable. They use
methods as actions:
class SomeActions {
public void doMyAction(..) {
...
(I'm not quite sure about the arguments and stuff though)
This helps to have all related code at a glance.
Although I'm not yet sure what syntax should be prefered
1. map:action type=SomeActions.doMyAction
!-- directly use the method --
Do you mean map:act?
2. map:action type=SomeActions.MyAction
!-- have a fix prefix like do --
3. map:action type=SomeActions method=doMyAction
4. map:action type=SomeActions method=MyAction
5.
map:actions
map:action src=com.foo.SomeActions method=doMyAction/
/map:actions
map:act type=SomeActions/
Vadim
Of course this will require the use of the reflection API
for those actions using the new method syntax. (All others
will not be effected and treated as usual)
I have made some tests: if we use some intelligent
caching for the reflection API there will be only little
to no performance loss compared to the old mechanism.
What do guys think?
--
Torsten
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] mulitple actions per class
On Tue, 12 Feb 2002, Nicola Ken Barozzi wrote: Although I'm not yet sure what syntax should be prefered 1. map:action type=SomeActions.doMyAction !-- directly use the method -- 2. map:action type=SomeActions.MyAction !-- have a fix prefix like do -- 3. map:action type=SomeActions method=doMyAction 4. map:action type=SomeActions method=MyAction Of course this will require the use of the reflection API for those actions using the new method syntax. (All others will not be effected and treated as usual) You can also use inner classes. I have been thinking about this, too There are quite some ways to do this... but as I said: will this be confortable? I have made some tests: if we use some intelligent caching for the reflection API there will be only little to no performance loss compared to the old mechanism. Jdk 1.4 has way higher performance in using reflection. Cool. IMHO a ClassMethodAction, with class name and methos name as parameters, would suffice. ...but how to use the cocoon-action parameter then? If you have a form with multiple input buttons with action bound to them you only have a single parameter: form input type=submit name=cocoon-action value=update input type=submit name=cocoon-action value=delete input type=submit name=cocoon-action value=add /form To change a hidden input field with javascript is not an option. So the information which mehtod to be called must be encoded inside the value which is currently the name of the action. That's why I came up with something like this form input type=submit name=cocoon-action value=usermanager.update input type=submit name=cocoon-action value=usermanager.delete input type=submit name=cocoon-action value=usermanager.add /form Unfortunately I think this must be handled from Cocoon and just an ClassMethodAction will not be enough -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PROPOSAL] mulitple actions per class
1. map:action type=SomeActions.doMyAction
!-- directly use the method --
Do you mean map:act?
ups... sure! ;)
2. map:action type=SomeActions.MyAction
!-- have a fix prefix like do --
3. map:action type=SomeActions method=doMyAction
4. map:action type=SomeActions method=MyAction
5.
map:actions
map:action src=com.foo.SomeActions method=doMyAction/
/map:actions
map:act type=SomeActions/
Hm... but then you always have to define each method of the
class inside the sitemap plus you have to come up with all
different names. So let's assume we have a usermanager class
public class UserManagerAction extends SomeAction {
public Map doAdd(...) {
}
public Map doUpdate(...) {
}
public Map doDelete(...) {
}
private void commonStuff() {
}
}
Sitemap:
map:actions
map:action name=usermanager-add src=org.apache..UserManagerAction
method=doAdd/
map:action name=usermanager-update src=org.apache..UserManagerAction
method=doUpdate/
map:action name=usermanager-delete src=org.apache..UserManagerAction
method=doDelete/
/map:actions
...
map:act type=usermanager-add
...
I think this is much to complicated and verbose for the
sitemap. I see no benefit over:
map:actions
map:action name=usermanager src=org.apache..UserManagerAction/
/map:actions
...
map:act type=usermanager.add
...
Isn't this simple and straight forward?
The do prefix could make sure only desire methods can be used
as action from a class.
--
Torsten
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: [PROPOSAL] mulitple actions per class
Torsten Curdt:
snip
Hm... but then you always have to define each method of the
class inside the sitemap plus you have to come up with all
different names. So let's assume we have a usermanager class
public class UserManagerAction extends SomeAction {
public Map doAdd(...) {
}
public Map doUpdate(...) {
}
public Map doDelete(...) {
}
private void commonStuff() {
}
}
Sitemap:
map:actions
map:action name=usermanager-add
src=org.apache..UserManagerAction method=doAdd/
map:action name=usermanager-update
src=org.apache..UserManagerAction method=doUpdate/
map:action name=usermanager-delete
src=org.apache..UserManagerAction method=doDelete/
/map:actions
...
map:act type=usermanager-add
...
I really like the idea of your proposal and agree that the above is too
verbose and complicated.
I think this is much to complicated and verbose for the
sitemap. I see no benefit over:
map:actions
map:action name=usermanager src=org.apache..UserManagerAction/
/map:actions
...
map:act type=usermanager.add
...
Isn't this simple and straight forward?
This is simple, but how do I know which methods are available with this
action? And how do I know that this is a multiple action class?
The verbose solution from above has the advantage that the sitemap editor
(the person writing the pipelines) sees which actions are available.
Carsten
The do prefix could make sure only desire methods can be used
as action from a class.
--
Torsten
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/store FilesystemStore.java
cziegeler02/02/12 07:04:42
Modified:src/java/org/apache/cocoon/components/store
FilesystemStore.java
Log:
Fixing list method()
Revision ChangesPath
1.9 +6 -2
xml-cocoon2/src/java/org/apache/cocoon/components/store/FilesystemStore.java
Index: FilesystemStore.java
===
RCS file:
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/components/store/FilesystemStore.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- FilesystemStore.java 12 Feb 2002 12:57:51 - 1.8
+++ FilesystemStore.java 12 Feb 2002 15:04:42 - 1.9
@@ -75,7 +75,7 @@
*
* @author ?
* @author a href=mailto:[EMAIL PROTECTED];Vadim Gritsenko/a
- * @version CVS $Id: FilesystemStore.java,v 1.8 2002/02/12 12:57:51 cziegeler Exp $
+ * @version CVS $Id: FilesystemStore.java,v 1.9 2002/02/12 15:04:42 cziegeler Exp $
*/
public final class FilesystemStore
extends AbstractLoggable
@@ -294,7 +294,11 @@
if (files[i].isDirectory()) {
this.addKeys(enum, files[i]);
} else {
-
enum.add(this.decode(files[i].getAbsolutePath().substring(subStringBegin)));
+try {
+// FIXME: if for any reason we get a file which was not created
using
+//this store, decoding will fail.
+
enum.add(this.decode(files[i].getAbsolutePath().substring(subStringBegin)));
+} catch (Exception ignore) {}
}
}
}
--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] mulitple actions per class
On Tue, 12 Feb 2002, Carsten Ziegeler wrote: Torsten Curdt wrote: snip The verbose solution from above has the advantage that the sitemap editor (the person writing the pipelines) sees which actions are available. Hm... that's true. But I guess these actions are would be mainly used for webapp purposes and will be used with the cocoon-action parameter anyway. Not inside the sitemap. ...but maybe we could provide both syntaxes? Ah, you mean as an action-set, right? So something like this (don't quote me on the syntax): map:action-set name=mysuperactionset map:action type=multiaction method=a action=add/ map:action type=multiaction method=d action=delete/ /map:action-set For this I'm +1. But I'm not sure about a map:act type=multiaction method=a/ somewhere in the pipelines section. Yes, in particular for action-sets. Actually right now I am +0 for supporting it within the pipelines but for consistancy reasons I tend to +1. What would we tell someone on cocoon-users why it is not supported within the pipelines?! Is this also a +1 for the method-attribute syntax? ;) -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Dispatcher/Adapter
From: DZIEMBOWSKI,KINGA (HP-NewJersey,ex2) [mailto:[EMAIL PROTECTED]] Vadim, Lets make clear that the core elements are: In the Adapter family: Adapter.java AbstractAdapter.java AbstractComposerAdapter.java AbstractComplementaryConfigurableAdapter.java In the Dispatcher family: Dispatcher.java AbstractDispatcher.java Everything in the demo package is just a simple real extension and usage. Let's start with the Adapter. Adapter is an entity able to do something, using HttpRequest as a means to exchange the information. Why HTTP request? It makes this concept totally useless in any other environment. How it would operate in JMS environment? EJB environment? Non-HTTP servlets (e.g., maillets)? Anything can be an adapter and it is no specific implementation connected to it at front. Adapter is modeled on Action family and it is big similarity between Adapter and Action. If Adapter is an action, then just use Action. If adapter like an Action, but acts on the XML, then there is a difference. That's why I suggested to extend from XMLPipe. In addition to pipe, extending from SitemapModelComponent provides you with the same information that action has. Both are able to do something Action between pipeline stages, Action can not act between pipeline stages. Adapter from inside pipeline stage. Here I agree with you: Adapter as I see it (ATM) can act between stages, on parts of XML. The concrete adapter implementation can be written by somebody who has no Cocoon programming knowledge, as well by the Cocoon programmer who will make his adapter integrated to the Cocoon framework. It is an implementation domain not the definition of the interface. The interface just standardize the API. Ok. Your suggestion for the Adapter is great start of some specific adapter implementation. Here I do not agree with you. It is the most abstract interface, and here you can build up more concrete ones, like DOMAdapter. But again, may be you just need to explain this in more details. But I fill strongly that Adapter ( like Action is an interface of its own ). Some Adapter can be XMLPipe operating in the sitemap pipeline, and reacting on certain XML element but can be something else too. Like what? Explain this in more details, so I better understand you. Right now I'm under impression that Adapter is an action on the XML. Adapter should return some result, and as we are working with XML, it is obvious choice for Adapter to return XML. Adapter also should have some input, and it consists (in my current vision) from whatever provided by SitemapModelComponent and from input XML. Now Dispatcher: One of the candidates to be a Dispatcher is Transformer. But not necessarily. The Transformer can became a Dispatccher but not all Dispatchers need to be Transformers. Any pipeline stage which will need to dispatch something to somebody can decide to became an Dispatcher. Action can be a Dispatcher, Generator can be a dispatcher - let say encryption is needed before generator can pump SAX events to the pipeline. To make things more clear we can change the name of AbstractDispatcher to be AbstractTransformerDispatcher as a beginning of the TransformersDispatcher implementations. Ok. Now I'm at loss. Why we need Dispatcer/Adapter for actions? Isn't actions are enough? Of course, may be not, then you can show why you think it is required there. At the moment, Sitemap/Action already implement Dispatcher/Adapter paradigm: sitemap selects an action and calls it, same as Dispatcher does with Adapter. Why another level of abstraction here? In general my point is Dispatcher and Adapter definitions should assume as little as possible about implementations. Those are open to the implementations and needs. The Cocoon's minimum is defined by: Redirector redirector, SourceResolver resolver, Map objectModel before pipeline starts, and by: SourceResolver resolver, Map objectModel when pipeline processing is started. For the HttpServletRequest/HttpRequest/Request problem - the fact that I am not using any other methods that get/setAttribute does not mean anything. The discussion is about fundamentals not specific usage in the simplistic example. The Adapter or Dispatcher may need to access some information associated with the transport on which the request was sent, including for example InputStream for some reason. Can you read twice the same InputStream? I doubt it. Then you won't be able to use more than one and only one Adapter. What's the point in such abstraction then? Hope you find my questions reasonable, as I sincerely trying to get what you are driving at, Regards, Vadim When you expose some public interface you try to make this as usable as possible with the minimal number of dependencies. My preferred choice will be HttpServletRequest and I said already why. I am able to compromise this to use Cocoon abstraction but it cannot be
Re: [FYI] Tomcat 4.0.2 Release notes
De: Stuart Roebuck [mailto:[EMAIL PROTECTED]] Enviado el: lunes 11 de febrero de 2002 19:14 Why does Cocoon 2.0 work better with HTTP 1.0 rather than 1.1 under Tomcat 4? Nothing fancy or weird, simply the HTTP/1.1 connector in Tomcat 4.0 *was* so slow, and a big garbage producer, and the HTTP/1.0 is more or less the same that Tomcat 3.2 had.. Nope, that's not the reason why the HTTP/1.1 connector is (a lot) slower that the HTTP/1.0 connector for Cocoon. Both generate the same amount of garbage, and share the same design. That design is not adapted to HTTP/1.1, and makes chunking performance bad, especially when writing data byte by byte, which is apparently what Cocoon 2 is doing. But afaik, 4.0.2 has inside the new HTTP/1.1 connector rewrited from scratch by Remy Maucherat, known as Coyote, and the advice contained in the readme perhaps is no longer valid.. Remy can you add some more first hand info ?, thanks No, next version. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Unable to create indexes with Lucene Cocoon 2.0.1 // Content-Typeproblems
Hi,
I'm trying to create indexes on a custom C2.0.1 webapp. Currently my
/search/ directory is a copy of the example provided, but when I try and
create an index using create-index.xsp I get the following error:
DEBUG (2002-02-11) 23:06.55:344 [core] (/search/create)
Ajp13Processor[8009][1]/SimpleLuceneXMLIndexerImpl: Ignoring
http://foo.internal.luminas.co.uk:80/welcome.html?cocoon-view=content (text/xml;
charset=iso-8859-1)
As far as I can tell, lucene is ignoring the page because it has a content
type of text/xml; charset=iso-8859-1 and not just text/xml. I've
hacked cocoon to accept a content-type and an encoding, but it doesn't
seem like the right way to do it.
So, questions:
1) Is there any way to tell cocoon to turn off charset additions to the
Content-type header?
2) If there isn't, it looks like the Lucene bits will need modifying to
either add to the allowedContentType or to do more parsing of the
contentType string. Any thoughts on the best way to do this? I've attached
patches that do this, but it's probably not the most elegant solution...
Andrew.
--
Andrew SavoryEmail: [EMAIL PROTECTED]
Managing Director Tel: +44 (0)20 8553 6622
Luminas Internet Applications Fax: +44 (0)870 28 47489
This is not an official statement or order.Web:www.luminas.co.uk
Index: SimpleCocoonCrawlerImpl.java
===
RCS file:
/home/cvspublic/xml-cocoon2/src/java/org/apache/cocoon/components/crawler/SimpleCocoonCrawlerImpl.java,v
retrieving revision 1.6
diff -u -r1.6 SimpleCocoonCrawlerImpl.java
--- SimpleCocoonCrawlerImpl.java4 Feb 2002 12:22:21 - 1.6
+++ SimpleCocoonCrawlerImpl.java12 Feb 2002 15:11:37 -
@@ -82,6 +82,7 @@
import java.util.Iterator;
import java.util.List;
import java.util.ArrayList;
+import java.util.StringTokenizer;
/**
* A simple cocoon crawler.
@@ -485,6 +486,15 @@
BufferedReader br = new BufferedReader(new InputStreamReader(is));
String content_type = links_url_connection.getContentType();
+// split Content-Type header into type and encoding
+if (content_type != null) {
+StringTokenizer st = new StringTokenizer (content_type, ;);
+if (st.countTokens() 2) {
+content_type = st.nextToken();
+}
+content_type = st.nextToken();
+String content_encoding = st.nextToken();
+}
if (getLogger().isDebugEnabled()) {
getLogger().debug(Content-type: + content_type);
}
Index: SimpleLuceneXMLIndexerImpl.java
===
RCS file:
/home/cvspublic/xml-cocoon2/src/java/org/apache/cocoon/components/search/SimpleLuceneXMLIndexerImpl.java,v
retrieving revision 1.5
diff -u -r1.5 SimpleLuceneXMLIndexerImpl.java
--- SimpleLuceneXMLIndexerImpl.java 4 Feb 2002 12:31:09 - 1.5
+++ SimpleLuceneXMLIndexerImpl.java 12 Feb 2002 15:12:03 -
@@ -64,6 +64,7 @@
import java.util.Iterator;
import java.util.List;
import java.util.Map;
+import java.util.StringTokenizer;
import javax.xml.parsers.*;
@@ -179,6 +180,15 @@
+ CONTENT_QUERY);
URLConnection contentURLConnection = contentURL.openConnection();
String contentType = contentURLConnection.getContentType();
+// split Content-Type header into type and encoding
+if (contentType != null) {
+StringTokenizer st = new StringTokenizer (contentType, ;);
+if (st.countTokens() 2) {
+contentType = st.nextToken();
+}
+contentType = st.nextToken();
+String contentEncoding = st.nextToken();
+}
if (contentType != null
allowedContentType.contains(contentType)) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
accessing request parameters in sitemap
Currently the sitemap has a syntax which allows referring to matching
portions of the URL. Is there a way to refer to request arguments,
headers or session related properties directly in the sitemap?
Something like this:
map:match pattern=doc/**
map:generate src=documents/{1}
map:parameter name=type value={parameter(type)}/
map:parameter name=browser value={header(X-Browser)}/
/map:generate
...
/map:match
Thanks,
--
Ovidiu Predescu [EMAIL PROTECTED]
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Pipeline in pipeline not allowed in TreeProcessor
I'm porting a cocoon2.0dev based product to use the latest CVS version with TreeProcessor. But reading the sitemap, it doesn't allow directly nested pipeline tags. Is this the correct behaviour? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Pipeline in pipeline not allowed in TreeProcessor
On Tuesday 12 February 2002 12:48 pm, Nicola Ken Barozzi wrote: I'm porting a cocoon2.0dev based product to use the latest CVS version with TreeProcessor. But reading the sitemap, it doesn't allow directly nested pipeline tags. Is this the correct behaviour? I didn't think nested pipeline's were legal in the sitemap? -pete -- peter royal - [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: accessing request parameters in sitemap
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
Behalf Of
Currently the sitemap has a syntax which allows referring to matching
portions of the URL. Is there a way to refer to request arguments,
headers or session related properties directly in the sitemap?
Something like this:
map:match pattern=doc/**
map:generate src=documents/{1}
map:parameter name=type value={parameter(type)}/
map:parameter name=browser value={header(X-Browser)}/
/map:generate
...
/map:match
It can look like (not exactly, that's the hint):
map:match type=request-header pattern=X-Browser
map:generate src=documents/xxx
map:parameter name=browser value={1}/
/map:generate
...
/map:match
Check out matching and selection packages.
PS: It might be that some matchers are missing. If you find a miss, tell
me.
Vadim
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: accessing request parameters in sitemap
On Tue, 12 Feb 2002 13:58:19 -0500, Vadim Gritsenko [EMAIL PROTECTED]
wrote:
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
Behalf Of
Currently the sitemap has a syntax which allows referring to matching
portions of the URL. Is there a way to refer to request arguments,
headers or session related properties directly in the sitemap?
Something like this:
map:match pattern=doc/**
map:generate src=documents/{1}
map:parameter name=type value={parameter(type)}/
map:parameter name=browser value={header(X-Browser)}/
/map:generate
...
/map:match
It can look like (not exactly, that's the hint):
map:match type=request-header pattern=X-Browser
map:generate src=documents/xxx
map:parameter name=browser value={1}/
/map:generate
...
/map:match
Check out matching and selection packages.
Right, but with this approach, I match on a request header, when what
I want is to still match on the URL, but access various parts of the
request.
With your example, I instead match on the request-header, and invoke
the pipeline with it. What should be the xxx in the documents/xxx?
Thanks,
Ovidiu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Heads Up: Cocoon and Web Services
As we are just starting on a project where we need to provide access to our Cocoon based solution via a web service centric approach I have been musing around about the best way to achieve this. Now to start with Cocoon is really ideal for web services. Basically it already is capable of providing a web service platform. After all you can communicate with it using HTTP and XML - so it already caters for two of the requirements. And Cocoon allows you to define services flexibly by configuring components into pipelines as you need them. The ability to actually use Cocoon as an XML application platform - as opposed to (just) an XML publishing platform will increase as more and more components are developed. However it has one major drawback (in the world of web services): It does not provide a way of describing the available functions (read: pipelines) in a standardized manner (read: WSDL). But let's look at this step by step. Cocoon as web service client The client side (i.e. integrating services into a Cocoon based solution) is pretty easy. One way is to write a custom transformer dependent on the spec of the service (or using the WSDL). Of course an ideal solution would allow me to generate a transformer using the WSDL automatically (hint). There are also several ways of doing this. One way is to use something like WSDL2Java from Axis and then perform a further step that generates a transformer from the classes WSDL2Java spits out. Another way would be to hook directly into the flow that emits the Java code in Axis. Another way of writing the client side is to use XSP and that has been discussed before so I'll leave it at that. Cocoon as web service server Ok, this is where it gets more interesting. Here is basically what _we_ need: Publish a pipeline (set of pipelines) as a web service accessible via SOAP and providing a self-description in WSDL. Apart from the last part (which I really think is just as important as the first - if we think Cocoon can become a platform for WS) there are several approaches that would probably work: * Use XSL in a pipeline that interprets the SOAP request and then passes off to the appropriate pipeline * Use the Kinga/HP approach of the Adapter/Dispatcher model with additional SOAP stuff * Integrate Axis Personally I think we should be looking at working with the Axis project and integrating it into Cocoon. Here are my reasons: * They are hard at work on the interop side of web services * The architecture is flexible and uses SAX * The architecture allows you to hook in nearly everywhere (handlers, pivots,...) * You get tools for free * It's Apache :-) Now, I do not (yet?) understand enough about the current Axis code and I am now quite a bit removed from actually implementing (as Carsten likes to remind me) to start to give any roadmap as to how it would be possible - but here are a few ideas. The first step would be to install the Axis servlet parallel to the Cocoon servlet and write a service, handler, pivot that can bridge into Cocoon. One simple way would be to hook into the SOAP processing and call the relevant pipeline based on what is sent. Later we could then merge the servlets so that we only have one endpoint. But then again having it seperate may allow better scalability. Ok, so then how can we publish a pipeline as WSDL? Well perhaps we can use Views for that. Something like a WebService view that the bridging class can then turn into WSDL. Axis allows WSDL generation on the fly if you append ?wsdl to the URI. So maybe something there would work. It is not that I don't think the HP solution is a good idea and perhaps it fits Cocoon even better than Axis would. However at the moment I would be very interested in how the HP solution caters for stuf like WSDL. Does it? I know I am repeating this but: If we think Cocoon can move in this direction then we really really need some way of generating WSDL from a set of pipelines. Imagine firing up Visual Studio .Net and being able to generate a Visual Basic program that can call a Cocoon pipeline - just by accessing the WSDL that the pipeline has provided. Ok, so any comments welcome. Fire away. Matthew Langham Keine verlorenen Lotto-Quittungen, keine vergessenen Gewinne mehr! Beim WEB.DE Lottoservice: http://tippen2.web.de/?x=13 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Dispatcher/Adapter
On Tue, 12 Feb 2002, DZIEMBOWSKI,KINGA (HP-NewJersey,ex2) wrote: snipped/ For the HttpServletRequest/HttpRequest/Request problem - the fact that I am not using any other methods that get/setAttribute does not mean anything. The discussion is about fundamentals not specific usage in the simplistic example. The Adapter or Dispatcher may need to access some information associated with the transport on which the request was sent, including for example InputStream for some reason. When you expose some public interface you try to make this as usable as possible with the minimal number of dependencies. My preferred choice will be HttpServletRequest and I said already why. I am able to compromise this to use Cocoon abstraction but it cannot be Request ( as it is today ) it does not expose all HttpServletRequest definitions. Well, again. This discussion has been held a year ago. Originally the Cocoon Request interfaces *were* based on the ServletRequest interfaces but over the time the decided has been to move onto it's own implementation to allow a more generic abstraction of an Environment (which is good IMHO). So, I don't really want to go the same path again and I don't see your objection does really matter in the Cocoon environment to use the original HttpServletRequest or the abstracted Cocoon Request. I also don't see why the Cocoon request has to expose all HttpServletRequest as the name is too specific for Servlets and that's what Cocoon wants to avoid to show that it has its own abstraction of an Environment. The objectModel contains the original environmental objects IRRC for parts which needs to know and run in a specific environment. The Cocoon core itself will and should not be be bound to any specific environment. Components which needs the specific environmental objects will not run in other environments (i.e. Commandline). This was very clear from the beginning of the design of this abstracted environment (and to tell you the truth, everybody knew there might be components with those needs but we avoided those being part of the distributions so far). And thus the more a Component can rely on the most abstracted environment the more they can be reused in other environments as more of those will be implemented anytime. The way to go was to implement a set of methods in the abstract environmental interfaces and add more if there will be a requirement. Giacomo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Heads Up: Cocoon and Web Services
Matthew Langham wrote: It does not provide a way of describing the available functions (read: pipelines) in a standardized manner (read: WSDL). Publish a pipeline (set of pipelines) as a web service accessible via SOAP and providing a self-description in WSDL. Ok, so then how can we publish a pipeline as WSDL? Well perhaps we can use Views for that. Something like a WebService view that the bridging class can then turn into WSDL. Axis allows WSDL generation on the fly if you append ?wsdl to the URI. So maybe something there would work. I know I am repeating this but: If we think Cocoon can move in this direction then we really really need some way of generating WSDL from a set of pipelines. Imagine firing up Visual Studio .Net and being able to generate a Visual Basic program that can call a Cocoon pipeline - just by accessing the WSDL that the pipeline has provided. You actually asked a number of good questions, and made good suggestions on implementations. For now, however, I am just going to pick off one question (i.e., the one posed by the snippets quoted above) and focus on it. This question is essentially equivalent to asking given a schema for an input and a pipeline, can we predict the schema of the output?. If you can do that, you have described a wsdl:operation which is the fundamental building block in a web services based architecture. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Dispatcher/Adapter
On Tue, 12 Feb 2002, Vadim Gritsenko wrote: From: DZIEMBOWSKI,KINGA (HP-NewJersey,ex2) [mailto:[EMAIL PROTECTED]] Vadim, Lets make clear that the core elements are: In the Adapter family: Adapter.java AbstractAdapter.java AbstractComposerAdapter.java AbstractComplementaryConfigurableAdapter.java In the Dispatcher family: Dispatcher.java AbstractDispatcher.java Everything in the demo package is just a simple real extension and usage. Let's start with the Adapter. Adapter is an entity able to do something, using HttpRequest as a means to exchange the information. Why HTTP request? It makes this concept totally useless in any other environment. How it would operate in JMS environment? EJB environment? Non-HTTP servlets (e.g., maillets)? This is exactly the point why we have those abstractions. To take the concrete sample of Kinga's Adapter/Dispatcher concept, even the SOAP spec dosn't really care about environments as there are different transports proposed to work )i.e. SMTP). So why should the Adapter/Dispatcher have the need for such specific interfaces like HttpServletRequest? Anything can be an adapter and it is no specific implementation connected to it at front. Adapter is modeled on Action family and it is big similarity between Adapter and Action. If Adapter is an action, then just use Action. If adapter like an Action, but acts on the XML, then there is a difference. That's why I suggested to extend from XMLPipe. In addition to pipe, extending from SitemapModelComponent provides you with the same information that action has. Both are able to do something Action between pipeline stages, Action can not act between pipeline stages. Absolutely. Actions are pre-pipeline controller logic (to use the MVC metaphor where the pipeline is the view) Adapter from inside pipeline stage. Here I agree with you: Adapter as I see it (ATM) can act between stages, on parts of XML. The concrete adapter implementation can be written by somebody who has no Cocoon programming knowledge, as well by the Cocoon programmer who will make his adapter integrated to the Cocoon framework. It is an implementation domain not the definition of the interface. The interface just standardize the API. Ok. Your suggestion for the Adapter is great start of some specific adapter implementation. Here I do not agree with you. It is the most abstract interface, and here you can build up more concrete ones, like DOMAdapter. But again, may be you just need to explain this in more details. But I fill strongly that Adapter ( like Action is an interface of its own ). Some Adapter can be XMLPipe operating in the sitemap pipeline, and reacting on certain XML element but can be something else too. Like what? Explain this in more details, so I better understand you. Right now I'm under impression that Adapter is an action on the XML. Adapter should return some result, and as we are working with XML, it is obvious choice for Adapter to return XML. Adapter also should have some input, and it consists (in my current vision) from whatever provided by SitemapModelComponent and from input XML. Acting on XML and returning XML is obiously a Transformer (or an XMLPipe to be more abstract). Over the time I smell FS as the Adaptor concept wants to combine all kinds of interfaces we separated in Cocoon (SitemapModelComponent, Actions, Transformers). Now Dispatcher: One of the candidates to be a Dispatcher is Transformer. But not necessarily. The Transformer can became a Dispatccher but not all Dispatchers need to be Transformers. Any pipeline stage which will need to dispatch something to somebody can decide to became an Dispatcher. Action can be a Dispatcher, Generator can be a dispatcher - let say encryption is needed before generator can pump SAX events to the pipeline. To make things more clear we can change the name of AbstractDispatcher to be AbstractTransformerDispatcher as a beginning of the TransformersDispatcher implementations. Ok. Now I'm at loss. Why we need Dispatcer/Adapter for actions? Isn't actions are enough? Of course, may be not, then you can show why you think it is required there. At the moment, Sitemap/Action already implement Dispatcher/Adapter paradigm: sitemap selects an action and calls it, same as Dispatcher does with Adapter. Why another level of abstraction here? I can see the dispatching concept/role made into a Avalon Component so that specific implementations can dispatch anything among a set of something. But those don't belong to anything in the Cocoon concepts. Any Cocoon part (Action, Generator, other Avalon Components, etc.) can use them by looking up the CM. In general my point is Dispatcher and Adapter definitions should assume as little as possible about implementations. Those are open to the implementations and needs. Sounds like an excerpt from the
Re: Pipeline in pipeline not allowed in TreeProcessor
On Tue, 12 Feb 2002, Nicola Ken Barozzi wrote: I'm porting a cocoon2.0dev based product to use the latest CVS version with TreeProcessor. But reading the sitemap, it doesn't allow directly nested pipeline tags. Why do you have nested pipelines. Does this makes any sense? I cannot remember we stated this a feature. Giacomo Is this the correct behaviour? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
schedule/batch feature inside cocoon
hi everybody first, i really like the cocoon framework. but unfortunally i am missing something, that's (i know) not so usual for servlet based applications. i've just implemented some kind of html parsing logic inside cocoon, which now looks very nice (thanx to cocoon). but i can't start the whole parsing process as a scheduled task, without using a tool outside cocoon. but before i start hacking something together for myself, i thought that maybe it would be a cool feature for cocoon. so i am asking you about your opinion for such a feature inside cocoon. cool would be, if it would also be configurable inside the sitemap, like a matcher. but instead of for example an url it would match a time/interval. but i know, the whole thing is very request driven. maybe it would also be nice, if a pipeline could be treated like a batch job. request comes in, independed thread will get started and the response comes imediately. but this is (IMHO) another thing. at the moment i'm finding my path through the jungle, so don't expect too much. maybe there are some inputs/warnings out there. greetings, lars steiger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: schedule/batch feature inside cocoon
hi everybody hi but i can't start the whole parsing process as a scheduled task, without using a tool outside cocoon. Remote scheduler will do the job. i thought that maybe it would be a cool feature for cocoon. I'm answering on this messsage because I've implemented one JobThreads/Schedule-based piece of software a while ago and remember how I was happy when managed to separate whole thing into several modules. I think that cocoon2 is one thing, and tasks/schedule machinery is another. It will be good if they will use each other, but that is the reason for combining all this stuff in a single application ? One real thing I can think of is calling cocoon by jndi calls, not by http requests, and getting response via jndi. If I only had anough time right now. :) ps. Or I've missed something and it is already there ? Mikhail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 5593] - [PATCH] Form encoding enhancement.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5593. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5593 [PATCH] Form encoding enhancement. --- Additional Comments From [EMAIL PROTECTED] 2002-02-12 22:55 --- Hi, sorry, sorry for that late response. But this patch is really old. MIYABE can you please re-send it? I'll book it then. TIA ~Gerhard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 5593] - [PATCH] Form encoding enhancement.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5593. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5593 [PATCH] Form encoding enhancement. --- Additional Comments From [EMAIL PROTECTED] 2002-02-12 22:57 --- grummel...with re-send I mean re-diff! ~Gerhard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[SCRATCHPAD] action package
Hi, I see a bunch of new actions in the scratchpad. Did somebody re-viewed them, and how is the status. I have the feeling they get mouldy (is this correct) in their ;). ~Gerhard God put me on this Earth to accomplish a certain number of things. Right now, I am so far behind I shall never die. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Creating An eXist Generator for Cocoon
Hi, I am quite new to this side of the Cocoon project ( usually I was just using Cocoon ), so please be patient. A few weeks ago I joined the group developing the eXist Xml-Database and because of my experience with Cocoon I was assigned the task of integrating eXist into Cocoon. After finishing all work for being able to start/stop/access eXist locally ( not over HTTP or RPC ), I have started creating a new Generator called org.apache.cocoon.generation.ExistGenerator ( If I am not allowed to place the class there please tell me. I just thought that it belonged there ). After finishing a first prototype of the generator, I wanted to test it. So I added following part to the Sitemap where the generators are defined : map:generator name=exist src=org.apache.cocoon.generation.ExistGenerator/ This didnt seem to cause any problems so I added a simple match in the standard sample pipeline ( I am using a totally fresh installation of Tomcat and Cocoon 2 ) map:match pattern=exist map:generate type=exist src=xPathExpression/ map:serialize/ /map:match When accessing this page I get a : UnnamedSelector: ComponentSelector could not find the component for hint: exist From Cocoon. Does this mean that the class couldnt be found, or could there be a problem with the class itself ? My Generator extends the AbstractGenerator class. I hope this is the right way. If not, could someone please send me a small tutorial with the steps needed to create a new Generator ? Thanx in advance, Christofer Dutz C-Ware IT-Service Inh. Christofer Dutz Goethestr. 18 64372 Ober-Ramstadt www.c-ware.de
Cocoon works from the WAR file
Hi, Please try out new feature: deployment of packed cocoon.war, without exploding. To try this (under tomcat): build -Dinclude.webapp.libs=yes webapp copy build/cocoon/cocoon.war $TOMCAT_HOME/webapps $TOMCAT_HOME/bin/startup It employs ugly but verified hack: extract all the libraries into the temporary directory. This takes place *only* when running Cocoon from the unpacked WAR file. Some optimization is applied: library is extracted only when it was not extracted before or its modification time has changed. To get library list and timestamps, Manifest file is used, created by the custom ant task. Regards, Vadim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/language/markup/xsp/java action.xsl capture.xsl cookie.xsl esql.xsl form-validator.xsl log.xsl logicsheet-util.xsl request.xsl response.xsl sel.xsl sendmail.xsl session.xsl soap.xsl util.xsl xscript-lib.xsl xscript.xsl xsp.xsl
vgritsenko02/02/12 17:09:08 Modified:src/java/org/apache/cocoon/components/language/markup/xsp/java action.xsl capture.xsl cookie.xsl esql.xsl form-validator.xsl log.xsl logicsheet-util.xsl request.xsl response.xsl sel.xsl sendmail.xsl session.xsl soap.xsl util.xsl xscript-lib.xsl xscript.xsl xsp.xsl Log: Unify logicsheets headers Revision ChangesPath 1.2 +54 -11 xml-cocoon2/src/java/org/apache/cocoon/components/language/markup/xsp/java/action.xsl Index: action.xsl === RCS file: /home/cvs/xml-cocoon2/src/java/org/apache/cocoon/components/language/markup/xsp/java/action.xsl,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- action.xsl3 Jan 2002 12:31:11 - 1.1 +++ action.xsl13 Feb 2002 01:09:07 - 1.2 @@ -1,19 +1,62 @@ ?xml version=1.0 encoding=ISO-8859-1? + +!-- $Id: action.xsl,v 1.2 2002/02/13 01:09:07 vgritsenko Exp $-- !-- - * - * Copyright (C) The Apache Software Foundation. All rights reserved.* - * _ * - * This software is published under the terms of the Apache Software License * - * version 1.1, a copy of which has been included with this distribution in * - * the LICENSE file. * - * + + + The Apache Software License, Version 1.2 + + + Copyright (C) 1999-2002 The Apache Software Foundation. All rights reserved. + + Redistribution and use in source and binary forms, with or without modifica- + tion, are permitted provided that the following conditions are met: + + 1. Redistributions of source code must retain the above copyright notice, +this list of conditions and the following disclaimer. + + 2. Redistributions in binary form must reproduce the above copyright notice, +this list of conditions and the following disclaimer in the documentation +and/or other materials provided with the distribution. + + 3. The end-user documentation included with the redistribution, if any, must +include the following acknowledgment: This product includes software +developed by the Apache Software Foundation (http://www.apache.org/). +Alternately, this acknowledgment may appear in the software itself, if +and wherever such third-party acknowledgments normally appear. + + 4. The names Cocoon and Apache Software Foundation must not be used to +endorse or promote products derived from this software without prior +written permission. For written permission, please contact +[EMAIL PROTECTED] + + 5. Products derived from this software may not be called Apache, nor may +Apache appear in their name, without prior written permission of the +Apache Software Foundation. + + THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, + INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND + FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE + APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, + INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU- + DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS + OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON + ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + + This software consists of voluntary contributions made by many individuals + on behalf of the Apache Software Foundation and was originally created by + Stefano Mazzocchi [EMAIL PROTECTED]. For more information on the Apache + Software Foundation, please see http://www.apache.org/. + -- !-- - Logicsheet for XSP executed in actions using ServerPagesAction. - - @author a href=mailto:[EMAIL PROTECTED];Sylvain Wallez/a - @version CVS $Revision: 1.1 $ $Date: 2002/01/03 12:31:11 $ + * Logicsheet for XSP executed in actions using ServerPagesAction. + * + * @author a href=mailto:[EMAIL PROTECTED];Sylvain Wallez/a + * @version CVS $Revision: 1.2 $ $Date: 2002/02/13 01:09:07 $ -- xsl:stylesheet version=1.0 1.2
DO NOT REPLY [Bug 5593] - [PATCH] Form encoding enhancement.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5593. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5593 [PATCH] Form encoding enhancement. --- Additional Comments From [EMAIL PROTECTED] 2002-02-13 01:29 --- Created an attachment (id=1166) re-diffed for current cvs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/scratchpad/schecoon/src/org/apache/cocoon/scheme/sitemap CocoonModule.java
ovidiu 02/02/12 17:47:12
Added: src/scratchpad/schecoon/src/org/apache/cocoon/scheme/sitemap
CocoonModule.java
Log:
Added. Common class for all the Schecoon SISC modules which implement
native Scheme functions.
Revision ChangesPath
1.1
xml-cocoon2/src/scratchpad/schecoon/src/org/apache/cocoon/scheme/sitemap/CocoonModule.java
Index: CocoonModule.java
===
package org.apache.cocoon.scheme.sitemap;
import org.apache.avalon.framework.component.ComponentManager;
import org.apache.avalon.framework.parameters.Parameters;
import org.apache.cocoon.components.pipeline.StreamPipeline;
import org.apache.cocoon.environment.Environment;
import org.apache.cocoon.environment.Source;
import sisc.ModuleAdapter;
import sisc.data.Pair;
import sisc.data.Value;
import sisc.modules.J2S;
public abstract class CocoonModule extends ModuleAdapter
{
static protected Parameters emptyParam = new Parameters();
/**
* Type cast function from a Scheme wrapper of a SchemeSitemap.
*
* @param scm a Scheme wrapper instance of a SchemeSitemap.
* @return a codeSchemeSitemap/code value
*/
static public SchemeSitemap schemeSitemap(Value scm)
{
try {
return (SchemeSitemap)(((J2S.JavaObject)scm).o);
}
catch (ClassCastException ex) {
typeError(SchemeSitemap, scm);
}
return null;
}
/**
* Type cast function from a Scheme wrapper of an Environment
* instance.
*
* @param scm a Scheme wrapper of an Environment instance.
* @return an codeEnvironment/code value
*/
static public Environment environment(Value scm)
{
try {
return (Environment)(((J2S.JavaObject)scm).o);
}
catch (ClassCastException ex) {
typeError(Environment, scm);
}
return null;
}
/**
* Type cast function from a Scheme wrapper of an StreamPipeline
* instance.
*
* @param scm a Scheme wrapper of an StreamPipeline instance.
* @return an codeStreamPipeline/code value
*/
static public StreamPipeline streamPipeline(Value scm)
{
try {
return (StreamPipeline)(((J2S.JavaObject)scm).o);
}
catch (ClassCastException ex) {
typeError(StreamPipeline, scm);
}
return null;
}
/**
* Type cast function from a Scheme wrapper of
* codeComponentManager/code instance.
*
* @param scm a Scheme wrapper of a Cocoon
* codeComponentManager/code instance.
* @return an codeComponentManager/code value
*/
static public ComponentManager componentManager(Value scm)
{
try {
return (ComponentManager)(((J2S.JavaObject)scm).o);
}
catch (ClassCastException ex) {
typeError(ComponentManager, scm);
}
return null;
}
/**
* Type cast function from a Scheme wrapper of a Cocoon
* codeSource/code instance.
*
* @param scm a Scheme wrapper of a Cocoon codeSource/code
* instance.
* @return an codeSource/code value
*/
static public Source source(Value scm)
{
try {
return (Source)(((J2S.JavaObject)scm).o);
}
catch (ClassCastException ex) {
typeError(Source, scm);
}
return null;
}
/**
* Retrieve an entry from an association list. Uses eq? to compare
* the CAR of each entry.
*
* @param l the association list
* @param v the value to be searched for
* @return a codePair/code value representing the entry, or
* ttFALSE/tt if no such entry is present.
*/
static public Value assq (Value l, Value v)
{
Pair list = pair(l);
while (list != EMPTYLIST) {
Pair entry = pair(list.car);
if (entry.car.eq(v))
return entry;
list = pair(list.cdr);
}
return FALSE;
}
/**
* Assumes the ttsparams/tt is either an association list or the
* FALSE value. It returns either an empty Avalon
* ttParameters/tt instance, or a ttParameters/tt instance
* that contains the values extracted from the association list.
*
* @param sparams a codeValue/code value, either ttFALSE/tt
* or an association list
* @return an Avalon codeParameters/code instance
*/
static public Parameters getParameters(Value sparams)
{
Parameters params = emptyParam;
if (!sparams.eq(FALSE)) {
params = new Parameters();
Pair sparamValues = pair(pair(sparams).cdr);
while (sparamValues != EMPTYLIST) {
Pair entry = pair(sparamValues.car);
String name = string(entry.car);
String value = string(entry.cdr);
params.setParameter(name, value);
sparamValues = pair(sparamValues.cdr);
}
}
return
cvs commit: xml-cocoon2/src/scratchpad/schecoon/scheme functions.scm
ovidiu 02/02/12 17:50:21 Modified:src/scratchpad/schecoon/scheme functions.scm Log: Removed user-defined functions outside. Define send-page and schecoon:handle-continuation. Revision ChangesPath 1.3 +17 -10xml-cocoon2/src/scratchpad/schecoon/scheme/functions.scm Index: functions.scm === RCS file: /home/cvs/xml-cocoon2/src/scratchpad/schecoon/scheme/functions.scm,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- functions.scm 1 Feb 2002 01:36:43 - 1.2 +++ functions.scm 13 Feb 2002 01:50:21 - 1.3 @@ -40,18 +40,25 @@ (eval `(,funname ,sitemap ,env (quote ,params)) (interaction-environment -(define continuations '()) +(define (send-page sitemap env resource-name params bean-dict) + (call/cc + (lambda (k) + (let ((kont-id (continuations:register k)) +(suicide (environ:get-attr env suicide))) + (environ:set-attr env kont kont-id) + (environ:set-attr env bean-dict bean-dict) + (printf send-page: kont ~s, kont id ~s~% k kont-id) + (resource-call-v sitemap env + (list (cons 'resource resource-name) + (cons 'params params))) + (suicide k)) + ))) -(function (my-function sitemap env a b) - (call/cc - (lambda (k) -(set! continuations (cons k continuations) +(function (schecoon:handle-continuation sitemap env kont-id) + (printf handle-continuation invoked ~s~% kont-id) + (let ((kont (continuations:get kont-id))) +(if kont (kont kont -;(function (my-function sitemap env a b) -; (call/cc -; (lambda (k) -;(set! continuations (cons k continuations)) -;(display (format a = ~s, b = ~s, continuations = ~s~% a b continuations) ;(function-call-v 1 2 '((function . my-function) ; (params . ((a . 3) (b . 4) -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/scratchpad/schecoon/scheme sitemap.scm
ovidiu 02/02/12 17:51:20
Modified:src/scratchpad/schecoon/scheme sitemap.scm
Log:
Add support for defining external flow script files to be included in
the sitemap.
Revision ChangesPath
1.10 +121 -52 xml-cocoon2/src/scratchpad/schecoon/scheme/sitemap.scm
Index: sitemap.scm
===
RCS file: /home/cvs/xml-cocoon2/src/scratchpad/schecoon/scheme/sitemap.scm,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- sitemap.scm 9 Feb 2002 00:19:13 - 1.9
+++ sitemap.scm 13 Feb 2002 01:51:20 - 1.10
@@ -7,6 +7,7 @@
(load-module sisc.modules.Regexp)
(load-module sisc.modules.J2S)
(load-module org.apache.cocoon.scheme.sitemap.SchemeSitemapFunctions)
+(load-module org.apache.cocoon.scheme.sitemap.SchemeEnvironmentFunctions)
(load-module org.apache.cocoon.scheme.sitemap.ContinuationsManager)
;; A Cocoon XML sitemap description is processed by the Scheme code in
@@ -125,6 +126,9 @@
((symbol? name) (name-resource (symbol-string name)))
(else #f)))
+;; The global scope.
+(define top-level (interaction-environment))
+
;; The main function to process an SXML representation of the sitemap,
;; and generate a function which is the executable version of the
;; sitemap.
@@ -137,7 +141,7 @@
;; The side effect of executing this returned function is the
;; processing of the input HTTP request as defined by the sitemap.
;;
-(define (process-sitemap sitemap)
+(define (process-sitemap sitemap xsxml)
(let ((exit #f)
;; Regular expressions for matching various types of arguments
(res-arg-regexp (regexp /({[^0-9].*})/))
@@ -516,8 +520,40 @@
(match-match pipeline #t)))
)))
-;; This function is called by the `apply-templates' function below
-;; to process SXML nodes corresponding to map:resource.
+;; This function is called to process map:script elements
+;; embedded inside map:resource elements that have a type=flow
+;; attribute.
+;;
+;; As opposed to the rest of the process- functions, this function
+;; doesn't generate any code. Instead it has the side-effect of
+;; reading, and possibly translating the script file, into the
+;; running Scheme engine.
+(define (process-script node)
+ (let ((resource (sxml:attr node 'src))
+ (lang (or (sxml:attr node 'language) scheme)))
+ (if (not resource)
+ (xml-error node required 'src' attribute for script is not present))
+ (cond ((string-ci=? lang scheme)
+(call-with-failure-continuation
+ (lambda ()
+ (let* ((content (sitemap:read-resource sitemap resource))
+ (port (open-input-string content)))
+ (let loop ()
+ (let ((form (read port)))
+ (if (not (eof-object? form))
+ (begin
+ (eval form (interaction-environment))
+ (loop)))
+ (lambda (message error-continuation parent-fk)
+ (xml-error
+ node
+ (format Error parsing ~s: ~s~% resource message)
+
+ (else
+(xml-error node unknown script language '~s'~% lang)))
+ ))
+
+;; Handle pipeline definitions defined using map:resource name=...
;;
;; For each named resource we create a function whose name is
;; r_resource-name, which contains the definition of the
@@ -543,52 +579,82 @@
;; `function' macro, instead of the normal Scheme `define'. This
;; allows for named parameters to be passed to the function at
;; runtime.
+(define (define-pipeline node)
+ (let* ((resname (sxml:attr node 'name))
+ (funname (name-resource resname))
+ ;; Check to see if a similar resource has already
+ ;; been defined.
+ (_ (if (lookup-resource funname)
+ (xml-error node A resource named ~s already defined
+funname)))
+ (attributes (map (lambda (x) (cadr x))
+ ((sxpath '(// @ (*))) node)))
+ (source-arguments
+ (filter (lambda (x)
+ (if (and (string? x)
+ (regexp-match res-arg-regexp-match x))
+ x
+ #f))
+ attributes))
+ ;; `source-arguments' contains all the attributes
+ ;; that contain named parameters. We need to
+ ;; extract the names from within curly braces
+ (arguments
+ (flatten
+(map
+ (lambda (x)
+ (let* ((v
cvs commit: xml-cocoon2/src/scratchpad/schecoon/src/org/apache/cocoon/scheme/sitemap ContinuationsManager.java
ovidiu 02/02/12 17:52:01
Modified:src/scratchpad/schecoon/src/org/apache/cocoon/scheme/sitemap
ContinuationsManager.java
Log:
Inherit from the common CocoonModule class.
Revision ChangesPath
1.2 +5 -4
xml-cocoon2/src/scratchpad/schecoon/src/org/apache/cocoon/scheme/sitemap/ContinuationsManager.java
Index: ContinuationsManager.java
===
RCS file:
/home/cvs/xml-cocoon2/src/scratchpad/schecoon/src/org/apache/cocoon/scheme/sitemap/ContinuationsManager.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ContinuationsManager.java 9 Feb 2002 00:19:50 - 1.1
+++ ContinuationsManager.java 13 Feb 2002 01:52:01 - 1.2
@@ -6,6 +6,7 @@
import sisc.ContinuationException;
import sisc.Interpreter;
import sisc.ModuleAdapter;
+import sisc.Util;
import sisc.data.ImmutableString;
import sisc.data.Value;
@@ -15,7 +16,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Ovidiu Predescu/a
* @since February 8, 2002
*/
-public class ContinuationsManager extends ModuleAdapter
+public class ContinuationsManager extends CocoonModule
{
static protected int CONTINUATION_ID_LENGTH = 20;
@@ -128,14 +129,14 @@
* continuation.
*
* @param id the string identifier
- * @return the continuation object, or codenull/code if no such
+ * @return the continuation object, or code#f/code if no such
* continuation is registered.
*/
public Value getContinuationFromId(Value id)
{
String continuationId = string(id);
-
-return (Value)continuations.get(continuationId);
+Value kont = (Value)continuations.get(continuationId);
+return (kont != null ? kont : Util.FALSE);
}
/**
--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/scratchpad/schecoon/src/org/apache/cocoon/scheme/sitemap SchemeInterpreterImpl.java
ovidiu 02/02/12 17:53:20 Modified:src/scratchpad/schecoon/src/org/apache/cocoon/scheme/sitemap SchemeInterpreterImpl.java Log: Reorganized imports. Revision ChangesPath 1.2 +1 -1 xml-cocoon2/src/scratchpad/schecoon/src/org/apache/cocoon/scheme/sitemap/SchemeInterpreterImpl.java Index: SchemeInterpreterImpl.java === RCS file: /home/cvs/xml-cocoon2/src/scratchpad/schecoon/src/org/apache/cocoon/scheme/sitemap/SchemeInterpreterImpl.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- SchemeInterpreterImpl.java19 Jan 2002 00:54:58 - 1.1 +++ SchemeInterpreterImpl.java13 Feb 2002 01:53:20 - 1.2 @@ -12,6 +12,7 @@ import org.apache.avalon.framework.context.Context; import org.apache.avalon.framework.context.ContextException; import org.apache.avalon.framework.context.Contextualizable; +import org.apache.avalon.framework.thread.ThreadSafe; import org.apache.cocoon.Constants; import org.apache.cocoon.environment.http.HttpContext; import org.apache.cocoon.scheme.servlet.REPLGenericServlet; @@ -21,7 +22,6 @@ import sisc.data.Procedure; import sisc.data.Symbol; import sisc.data.Value; -import org.apache.avalon.framework.thread.ThreadSafe; public class SchemeInterpreterImpl implements SchemeInterpreter, Component, Contextualizable, Configurable, ThreadSafe -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/scratchpad/schecoon/src/org/apache/cocoon/scheme/sitemap SchemeSitemap.java
ovidiu 02/02/12 17:54:25
Modified:src/scratchpad/schecoon/src/org/apache/cocoon/scheme/sitemap
SchemeSitemap.java
Log:
(readResource) New function for reading files from the Web application.
Revision ChangesPath
1.4 +33 -1
xml-cocoon2/src/scratchpad/schecoon/src/org/apache/cocoon/scheme/sitemap/SchemeSitemap.java
Index: SchemeSitemap.java
===
RCS file:
/home/cvs/xml-cocoon2/src/scratchpad/schecoon/src/org/apache/cocoon/scheme/sitemap/SchemeSitemap.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- SchemeSitemap.java19 Jan 2002 01:07:13 - 1.3
+++ SchemeSitemap.java13 Feb 2002 01:54:25 - 1.4
@@ -1,6 +1,7 @@
package org.apache.cocoon.scheme.sitemap;
import java.io.InputStream;
+import java.io.InputStreamReader;
import java.util.Date;
import org.apache.avalon.framework.component.Component;
import org.apache.avalon.framework.component.ComponentException;
@@ -90,6 +91,36 @@
}
/**
+ * Reads a resource from the current webapp and return its content
+ * as a string.
+ *
+ * @param source a codeString/code representing the resource
+ * name to be read.
+ * @return a codeString/code with the contents of the Webapp
+ * resource
+ * @throws Exception if anything goes wrong
+ */
+ public String readResource(String source)
+throws Exception
+ {
+org.apache.cocoon.environment.Context context =
+
(org.apache.cocoon.environment.Context)cocoonContext.get(Constants.CONTEXT_ENVIRONMENT_CONTEXT);
+InputStream is = context.getResource(source).openStream();
+InputStreamReader isr = new InputStreamReader(is);
+int size = 8192;
+int len = size;
+char[] cbuf = new char[size];
+StringBuffer buffer = new StringBuffer();
+
+while ((len = isr.read(cbuf, 0, len)) != -1)
+ buffer.append(cbuf, 0, len);
+
+isr.close();
+is.close();
+return buffer.toString();
+ }
+
+ /**
* Initialize the sitemap components according to the configuration
* in components.xconf.
*
@@ -237,9 +268,10 @@
Date start = new Date();
+J2S.JavaObject ssitemap = new J2S.JavaObject(this);
J2S.JavaObject sManager = new J2S.JavaObject(manager);
J2S.JavaObject ssource = new J2S.JavaObject(sitemapSource);
-Value[] args = new Value[] { sManager, ssource };
+Value[] args = new Value[] { ssitemap, sManager, ssource };
SchemeInterpreter interpreters
= (SchemeInterpreter)manager.lookup(SchemeInterpreter.ROLE);
--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/scratchpad/schecoon/src/org/apache/cocoon/scheme/sitemap SchemeSitemapFunctions.java
ovidiu 02/02/12 17:55:34
Modified:src/scratchpad/schecoon/src/org/apache/cocoon/scheme/sitemap
SchemeSitemapFunctions.java
Log:
(read-resource): New native Scheme function.
Moved all the cast functions in CocoonModule.
Revision ChangesPath
1.3 +27 -141
xml-cocoon2/src/scratchpad/schecoon/src/org/apache/cocoon/scheme/sitemap/SchemeSitemapFunctions.java
Index: SchemeSitemapFunctions.java
===
RCS file:
/home/cvs/xml-cocoon2/src/scratchpad/schecoon/src/org/apache/cocoon/scheme/sitemap/SchemeSitemapFunctions.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- SchemeSitemapFunctions.java 1 Feb 2002 01:41:54 - 1.2
+++ SchemeSitemapFunctions.java 13 Feb 2002 01:55:34 - 1.3
@@ -11,6 +11,7 @@
import sisc.ContinuationException;
import sisc.Interpreter;
import sisc.ModuleAdapter;
+import sisc.data.ImmutableString;
import sisc.data.Pair;
import sisc.data.Symbol;
import sisc.data.Value;
@@ -99,7 +100,7 @@
* @see org.apache.cocoon.components.pipeline.StreamPipeline
* @see org.apache.cocoon.reading.Reader
*/
-public class SchemeSitemapFunctions extends ModuleAdapter
+public class SchemeSitemapFunctions extends CocoonModule
{
public String getModuleName()
{
@@ -117,9 +118,8 @@
TRANSFORM = 3,
SERIALIZE = 4,
PROCESS = 5,
-PARSE = 6;
-
- protected Parameters emptyParam = new Parameters();
+PARSE = 6,
+LOAD_SCHEME = 7;
/**
* Creates a new codeSchemeSitemapFunctions/code instance. Defines
@@ -133,6 +133,7 @@
define(sitemap:serialize, SERIALIZE);
define(sitemap:process, PROCESS);
define(sitemap:parse, PARSE);
+define(sitemap:read-resource, LOAD_SCHEME);
}
/**
@@ -143,18 +144,20 @@
* @param primid an codeint/code value
* @param r an codeInterpreter/code value
* @return a codeValue/code value
+ * @exception ContinuationException if an error occurs
*/
public Value eval(int primid, Interpreter r)
throws ContinuationException
{
try {
switch (r.vlr.length) {
-
// Two argument functions
case 2:
switch (primid) {
case PARSE:
return parse(r.vlr[0], r.vlr[1]);
+case LOAD_SCHEME:
+ return readResource(r.vlr[0], r.vlr[1]);
}
// Three argument functions
@@ -187,146 +190,29 @@
}
/**
- * Type cast function from a Scheme wrapper of a SchemeSitemap.
+ * Read a resource from the current Web application and return its
+ * content as a Scheme codeImmutableString/code.
*
- * @param scm a Scheme wrapper instance of a SchemeSitemap.
- * @return a codeSchemeSitemap/code value
- */
- static public SchemeSitemap schemeSitemap(Value scm)
+ * @param sManager a codeValue/code wrapper for an Avalon
+ * codeComponentManager/code
+ * @param ssource a Scheme codeString/code string representing
+ * the name of the resource to read.
+ * @return a Scheme codeImmutableString/code value, containing
+ * the Scheme representation of the XML document read from
+ * codessource/code
+ * @exception Exception if an error occurs during reading of the
+ * resource
+ */
+ public Value readResource(Value scm, Value ssource)
+throws Exception
{
-try {
- return (SchemeSitemap)(((J2S.JavaObject)scm).o);
-}
-catch (ClassCastException ex) {
- typeError(SchemeSitemap, scm);
-}
-return null;
- }
-
- /**
- * Type cast function from a Scheme wrapper of an Environment
- * instance.
- *
- * @param scm a Scheme wrapper of an Environment instance.
- * @return an codeEnvironment/code value
- */
- static public Environment environment(Value scm)
- {
-try {
- return (Environment)(((J2S.JavaObject)scm).o);
-}
-catch (ClassCastException ex) {
- typeError(Environment, scm);
-}
-return null;
- }
+SchemeSitemap sitemap = schemeSitemap(scm);
+String source = string(ssource);
- /**
- * Type cast function from a Scheme wrapper of an StreamPipeline
- * instance.
- *
- * @param scm a Scheme wrapper of an StreamPipeline instance.
- * @return an codeStreamPipeline/code value
- */
- static public StreamPipeline streamPipeline(Value scm)
- {
-try {
- return (StreamPipeline)(((J2S.JavaObject)scm).o);
-}
-catch (ClassCastException ex) {
- typeError(StreamPipeline, scm);
-}
-return null;
+String content = sitemap.readResource(source);
+return new ImmutableString(content);
}
-
- /**
- * Type cast function from a Scheme wrapper of
- *
cvs commit: xml-cocoon2/src/scratchpad/schecoon/webapp sitemap.xmap
ovidiu 02/02/12 17:56:22
Modified:src/scratchpad/schecoon/webapp sitemap.xmap
Log:
Added support for including flow scripts and to invoke saved continuations.
Revision ChangesPath
1.3 +12 -0 xml-cocoon2/src/scratchpad/schecoon/webapp/sitemap.xmap
Index: sitemap.xmap
===
RCS file: /home/cvs/xml-cocoon2/src/scratchpad/schecoon/webapp/sitemap.xmap,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- sitemap.xmap 1 Feb 2002 01:44:14 - 1.2
+++ sitemap.xmap 13 Feb 2002 01:56:22 - 1.3
@@ -4,6 +4,10 @@
map:resources
+map:resource type=flow
+ map:script src=/example.scm language=scheme/
+/map:resource
+
map:resource name=document2html
map:generate src={source} type=file/
map:transform src=stylesheets/document2html.xsl/
@@ -70,7 +74,15 @@
/map:call
/map:match
+ !-- This pipeline executes continuations stored on the server --
+ map:match pattern=kont/(.*)
+map:call function=schecoon:handle-continuation
+ map:param name=kont-id value={1}/
+/map:call
+ /map:match
+
/map:pipeline
+
/map:pipelines
/map:sitemap
--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/scratchpad/schecoon/lib commons-jpath-0.1-dev.jar
ovidiu 02/02/12 17:57:02 Added: src/scratchpad/schecoon/lib commons-jpath-0.1-dev.jar Log: Added. Revision ChangesPath 1.1 xml-cocoon2/src/scratchpad/schecoon/lib/commons-jpath-0.1-dev.jar Binary file -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/scratchpad/schecoon ChangeLog
ovidiu 02/02/12 17:57:54 Modified:src/scratchpad/schecoon ChangeLog Log: 2002-02-12 Ovidiu Predescu [EMAIL PROTECTED] * webapp/sitemap.xmap: Added support for including flow scripts and to invoke saved continuations. * src/org/apache/cocoon/scheme/sitemap/SchemeSitemapFunctions.java (read-resource): New native Scheme function. Moved all the cast functions in CocoonModule. * src/org/apache/cocoon/scheme/sitemap/SchemeSitemap.java (readResource) New function for reading files from the Web application. * src/org/apache/cocoon/scheme/sitemap/SchemeInterpreterImpl.java: Reorganized imports. * src/org/apache/cocoon/scheme/sitemap/ContinuationsManager.java: Inherit from the common CocoonModule class. * scheme/sitemap.scm: Add support for defining external flow script files to be included in the sitemap. * scheme/functions.scm: Removed user-defined functions outside. Define send-page and schecoon:handle-continuation. * webapp/example.scm: Simple example to test flow capabilities in Scheme. * src/org/apache/cocoon/scheme/sitemap/SchemeEnvironmentFunctions.java: Added. Defines primitives for operating on the environment, request and others. * src/org/apache/cocoon/scheme/sitemap/CocoonModule.java: Added. Common class for all the Schecoon SISC modules which implement native Scheme functions. Revision ChangesPath 1.11 +37 -0 xml-cocoon2/src/scratchpad/schecoon/ChangeLog Index: ChangeLog === RCS file: /home/cvs/xml-cocoon2/src/scratchpad/schecoon/ChangeLog,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- ChangeLog 9 Feb 2002 00:20:56 - 1.10 +++ ChangeLog 13 Feb 2002 01:57:54 - 1.11 @@ -1,3 +1,40 @@ +2002-02-12 Ovidiu Predescu [EMAIL PROTECTED] + + * webapp/sitemap.xmap: Added support for including flow scripts + and to invoke saved continuations. + + * src/org/apache/cocoon/scheme/sitemap/SchemeSitemapFunctions.java + (read-resource): New native Scheme function. + + Moved all the cast functions in CocoonModule. + + * src/org/apache/cocoon/scheme/sitemap/SchemeSitemap.java + (readResource) New function for reading files from the Web + application. + + * src/org/apache/cocoon/scheme/sitemap/SchemeInterpreterImpl.java: + Reorganized imports. + + * src/org/apache/cocoon/scheme/sitemap/ContinuationsManager.java: + Inherit from the common CocoonModule class. + + * scheme/sitemap.scm: Add support for defining external flow + script files to be included in the sitemap. + + * scheme/functions.scm: Removed user-defined functions + outside. Define send-page and schecoon:handle-continuation. + + * webapp/example.scm: Simple example to test flow capabilities in + Scheme. + + * src/org/apache/cocoon/scheme/sitemap/SchemeEnvironmentFunctions.java: + Added. Defines primitives for operating on the environment, + request and others. + + * src/org/apache/cocoon/scheme/sitemap/CocoonModule.java: + Added. Common class for all the Schecoon SISC modules which + implement native Scheme functions. + 2002-02-08 Ovidiu Predescu [EMAIL PROTECTED] * src/org/apache/cocoon/scheme/sitemap/ContinuationsManager.java: -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: problems using j2sdk1.4.0 rc
It looks like this is not the only problem of running Cocoon
under JDK 1.4
with best wishes
Alexander Kachanov
-Original Message-
From: Enke Michael [mailto:[EMAIL PROTECTED]]
Sent: 12 urp| 2002 s. 20:29
To: [EMAIL PROTECTED]
Subject: problems using j2sdk1.4.0 rc
Hi people,
I installed version 1.4.0 release candidate from Sun (under Linux)
but cocoon seems to have problems with this.
I recompiled cocoon-2.1-dev.jar
By calling the first page I got the following error:
ProcessingException: Language Exception ...
Note: sun.tools.javac.Main has been deprecated...
and other (may be following) errors:
EsqlConnectionCocoon2() is an abstract class. It can not be instantiated. ...
In components/language/programming/javac/Javac.java
we ask if it is modern (com.sun...) or not (sun...)
But we have only this line (about line 117):
sun.tools.javac.Main compiler = new sun.tools.javac.Main(err, javac);
Here we don't care about modern or not.
I wrote the compile method as follows:
public boolean compile() throws IOException {
ByteArrayOutputStream err = new ByteArrayOutputStream();
boolean result = false;
if(modern) {
com.sun.tools.javac.Main compiler = new com.sun.tools.javac.Main();
int iresult = compiler.compile(toStringArray(fillArguments(new ArrayList(;
if(iresult == 0) result = true;
else result = false;
}
else {
sun.tools.javac.Main compiler = new sun.tools.javac.Main(err, javac);
result = compiler.compile(toStringArray(fillArguments(new ArrayList(;
this.errors = new ByteArrayInputStream(err.toByteArray());
}
return result;
}
But now I get a java.lang.IncompatibleClassChangeError
The error log says that Excalibur also has problems:
FATAL_E (2002-02-12) 11:29.05:470 [core]
(Unknown-URI) Unknown-thread/LogKitLogger:
Excalibur could not create any connections.
Examine your settings to make sure they are correct.
Make sure you can connect with the same settings on your machine.
Any suggestions?
Michael
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: schedule/batch feature inside cocoon
On Tuesday 12 February 2002 21:54, Lars Steiger wrote: . . . i've just implemented some kind of html parsing logic inside cocoon, which now looks very nice (thanx to cocoon). but i can't start the whole parsing process as a scheduled task, without using a tool outside cocoon. . . . Just curious, what kind of output does your parsing logic produce? If it's HTML pages, I'd start a tool like wget to retrieve the pages from Cocoon and save them in the right place. In that case, though, it would IMHO make more sense to use an external scheduling component than to integrate one in Cocoon. -- -- Bertrand Delacrétaz, www.codeconsult.ch -- web technologies consultant - OO, Java, XML, C++ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PROPOSAL] mulitple actions per class
Torsten Curdt wrote: On Tue, 12 Feb 2002, Carsten Ziegeler wrote: Torsten Curdt wrote: snip The verbose solution from above has the advantage that the sitemap editor (the person writing the pipelines) sees which actions are available. Hm... that's true. But I guess these actions are would be mainly used for webapp purposes and will be used with the cocoon-action parameter anyway. Not inside the sitemap. ...but maybe we could provide both syntaxes? Ah, you mean as an action-set, right? So something like this (don't quote me on the syntax): map:action-set name=mysuperactionset map:action type=multiaction method=a action=add/ map:action type=multiaction method=d action=delete/ /map:action-set For this I'm +1. But I'm not sure about a map:act type=multiaction method=a/ somewhere in the pipelines section. Yes, in particular for action-sets. Actually right now I am +0 for supporting it within the pipelines but for consistancy reasons I tend to +1. What would we tell someone on cocoon-users why it is not supported within the pipelines?! Is this also a +1 for the method-attribute syntax? ;) Hehe, nice try. No, sorry, it's rather a -0. If I have a chance to see by looking into the sitemap which methods the multiaction exposes (or which values are valid for the method attribute) then I will change this to +0. Cheers Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/java/org/apache/cocoon/generation FileGenerator.java
cziegeler02/02/12 23:03:15
Modified:src/java/org/apache/cocoon/generation FileGenerator.java
Log:
Don't wrap original exception again if it is throwable
Revision ChangesPath
1.6 +16 -18
xml-cocoon2/src/java/org/apache/cocoon/generation/FileGenerator.java
Index: FileGenerator.java
===
RCS file:
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/generation/FileGenerator.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- FileGenerator.java12 Feb 2002 16:32:34 - 1.5
+++ FileGenerator.java13 Feb 2002 07:03:15 - 1.6
@@ -54,8 +54,6 @@
*/
package org.apache.cocoon.generation;
-import org.apache.avalon.framework.component.ComponentException;
-import org.apache.avalon.framework.component.ComponentManager;
import org.apache.avalon.framework.parameters.Parameters;
import org.apache.cocoon.ProcessingException;
import org.apache.cocoon.caching.CacheValidity;
@@ -79,7 +77,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Pierpaolo Fumagalli/a
* (Apache Software Foundation, Exoffice Technologies)
* @author a href=mailto:[EMAIL PROTECTED];Carsten Ziegeler/a
- * @version CVS $Id: FileGenerator.java,v 1.5 2002/02/12 16:32:34 vgritsenko Exp $
+ * @version CVS $Id: FileGenerator.java,v 1.6 2002/02/13 07:03:15 cziegeler Exp $
*/
public class FileGenerator extends ComposerGenerator
implements Cacheable {
@@ -88,14 +86,6 @@
protected Source inputSource;
/**
- * Set the current codeComponentManager/code instance used by this
- * codeComposable/code.
- */
-public void compose(ComponentManager manager) throws ComponentException {
-super.compose(manager);
-}
-
-/**
* Recycle this component.
* All instance variables are set to codenull/code.
*/
@@ -149,21 +139,29 @@
public void generate()
throws IOException, SAXException, ProcessingException {
try {
-getLogger().debug(processing file + super.source);
-getLogger().debug(file resolved to + this.inputSource.getSystemId());
-
+if (this.getLogger().isDebugEnabled()) {
+this.getLogger().debug(processing file + super.source);
+this.getLogger().debug(file resolved to +
this.inputSource.getSystemId());
+}
this.inputSource.toSAX(super.xmlConsumer);
} catch (ProcessingException e) {
throw e;
} catch (SAXException e) {
-if(e.getException() != null) {
-getLogger().debug(Got SAXException; Rethrowing cause exception,
e);
+final Exception cause = e.getException();
+if( cause != null ) {
+this.getLogger().debug(Got SAXException; Rethrowing cause
exception, e);
+if ( cause instanceof ProcessingException )
+throw (ProcessingException)cause;
+if ( cause instanceof IOException )
+throw (IOException)cause;
+if ( cause instanceof SAXException )
+throw (SAXException)cause;
throw new ProcessingException(Could not read resource
- + this.inputSource.getSystemId(),
e.getException());
+ + this.inputSource.getSystemId(),
cause);
}
throw e;
} catch (Exception e) {
-getLogger().error(Could not read resource
+this.getLogger().error(Could not read resource
+ this.inputSource.getSystemId(), e);
throw new ProcessingException(Could not read resource
+ this.inputSource.getSystemId(), e);
--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/java/org/apache/cocoon/generation HTMLGenerator.java
cziegeler02/02/12 23:06:06
Modified:src/java/org/apache/cocoon/generation HTMLGenerator.java
Log:
Minor clean up
Revision ChangesPath
1.9 +3 -2
xml-cocoon2/src/java/org/apache/cocoon/generation/HTMLGenerator.java
Index: HTMLGenerator.java
===
RCS file:
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/generation/HTMLGenerator.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- HTMLGenerator.java7 Feb 2002 08:17:52 - 1.8
+++ HTMLGenerator.java13 Feb 2002 07:06:06 - 1.9
@@ -93,7 +93,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Davanum Srinivas/a
* @author a href=mailto:[EMAIL PROTECTED];Carsten Ziegeler/a
* @author a href=mailto:[EMAIL PROTECTED];Nicola Ken Barozzi/a
- * @version CVS $Id: HTMLGenerator.java,v 1.8 2002/02/07 08:17:52 cziegeler Exp $
+ * @version CVS $Id: HTMLGenerator.java,v 1.9 2002/02/13 07:06:06 cziegeler Exp $
*/
public class HTMLGenerator extends ComposerGenerator
implements Cacheable, Composable, Disposable {
@@ -108,7 +108,7 @@
private XPathProcessor processor = null;
public void compose(ComponentManager manager) {
-this.manager = manager;
+super.compose( manager );
try {
this.processor =
(XPathProcessor)this.manager.lookup(XPathProcessor.ROLE);
} catch (Exception e) {
@@ -275,6 +275,7 @@
public void dispose()
{
this.manager.release(this.processor);
+this.processor = null;
super.dispose();
}
}
--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2/src/java/org/apache/cocoon/generation HTMLGenerator.java
cziegeler02/02/12 23:07:52
Modified:src/java/org/apache/cocoon/generation HTMLGenerator.java
Log:
Minor clean up
Revision ChangesPath
1.10 +9 -7
xml-cocoon2/src/java/org/apache/cocoon/generation/HTMLGenerator.java
Index: HTMLGenerator.java
===
RCS file:
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/generation/HTMLGenerator.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- HTMLGenerator.java13 Feb 2002 07:06:06 - 1.9
+++ HTMLGenerator.java13 Feb 2002 07:07:52 - 1.10
@@ -57,7 +57,7 @@
import org.apache.avalon.framework.activity.Disposable;
import org.apache.avalon.framework.component.Component;
import org.apache.avalon.framework.component.ComponentManager;
-import org.apache.avalon.framework.component.Composable;
+import org.apache.avalon.framework.component.ComponentException;
import org.apache.avalon.framework.parameters.Parameters;
import org.apache.cocoon.Constants;
import org.apache.cocoon.ProcessingException;
@@ -93,10 +93,10 @@
* @author a href=mailto:[EMAIL PROTECTED];Davanum Srinivas/a
* @author a href=mailto:[EMAIL PROTECTED];Carsten Ziegeler/a
* @author a href=mailto:[EMAIL PROTECTED];Nicola Ken Barozzi/a
- * @version CVS $Id: HTMLGenerator.java,v 1.9 2002/02/13 07:06:06 cziegeler Exp $
+ * @version CVS $Id: HTMLGenerator.java,v 1.10 2002/02/13 07:07:52 cziegeler Exp $
*/
public class HTMLGenerator extends ComposerGenerator
-implements Cacheable, Composable, Disposable {
+implements Cacheable, Disposable {
/** The source */
private Source inputSource;
@@ -107,7 +107,8 @@
/** XPath Processor */
private XPathProcessor processor = null;
-public void compose(ComponentManager manager) {
+public void compose(ComponentManager manager)
+throws ComponentException {
super.compose( manager );
try {
this.processor =
(XPathProcessor)this.manager.lookup(XPathProcessor.ROLE);
@@ -272,9 +273,10 @@
}
}
-public void dispose()
-{
-this.manager.release(this.processor);
+public void dispose() {
+if (this.manager != null) {
+this.manager.release(this.processor);
+}
this.processor = null;
super.dispose();
}
--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-cocoon2 build.xml
cziegeler02/02/12 23:12:29
Modified:.build.xml
Log:
Manifest tool runs after all jars are copied to the libs directory (incl. scratchpad
and tools)
Revision ChangesPath
1.168 +1 -2 xml-cocoon2/build.xml
Index: build.xml
===
RCS file: /home/cvs/xml-cocoon2/build.xml,v
retrieving revision 1.167
retrieving revision 1.168
diff -u -r1.167 -r1.168
--- build.xml 12 Feb 2002 16:18:45 - 1.167
+++ build.xml 13 Feb 2002 07:12:29 - 1.168
@@ -1096,8 +1096,6 @@
/move
copy file=${build.dir}/${name}.jar
tofile=${build.war}/WEB-INF/lib/${name}-${version}.jar/
-
-manifest-tool directory=${build.war}/WEB-INF/lib
manifest=${build.war}/WEB-INF/Manifest.mf/
/target
!-- === --
@@ -1126,6 +1124,7 @@
!-- Creates the war file--
!-- === --
target name=webapp depends=prepare-webapp, prepare-webapp-libs,
prepare-scratchpad-libs, prepare-xsp description=* Generates the war package
+manifest-tool directory=${build.war}/WEB-INF/lib
manifest=${build.war}/WEB-INF/Manifest.mf/
jar jarfile=${build.dir}/${name}.war basedir=${build.war} includes=**
manifest=${build.war}/WEB-INF/Manifest.mf/
/target
--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
AW: schedule/batch feature inside cocoon
On Tuesday 12 February 2002 21:54, Lars Steiger wrote: . . . i've just implemented some kind of html parsing logic inside cocoon, which now looks very nice (thanx to cocoon). but i can't start the whole parsing process as a scheduled task, without using a tool outside cocoon. . . . Just curious, what kind of output does your parsing logic produce? simple xml. the parser is a generator. i call it SimpleTextParserGenerator. it needs an xml configuration für parsing a text stream. the xml configuration defines which text fragment goes under which xml node. If it's HTML pages, I'd start a tool like wget to retrieve the pages from Cocoon and save them in the right place. In that case, though, it would IMHO make more sense to use an external scheduling component than to integrate one in Cocoon. yes, first i also thought about an external scheduling component. but such a process should not be accessible from outside. if i do it with an external scheduling component, i have to secure this by a password or something like this. if it can be done inside the sitemap, this process is by default not accessible from outside. in addition it would be very nice to configure. and because i try to develop most to all application stuff with cocoon, and i don't want to use an ejb container yet, i know that such a feature would be useful for me. ok, i try to implement something for myself first. if it then looks some kind of nice, i will inform you about. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: schedule/batch feature inside cocoon
How about writing a transformer that writes the XML output to a file. In the output to the browser/external process you could give a message that the processing succeeded. Have a look at XMLDBTransformer in scratchpad, it writes data to an XML db as a side effect. HTH, Michael Homeijer -Original Message- From: Lars Steiger [mailto:[EMAIL PROTECTED]] Sent: woensdag 13 februari 2002 8:24 To: [EMAIL PROTECTED] Subject: AW: schedule/batch feature inside cocoon On Tuesday 12 February 2002 21:54, Lars Steiger wrote: . . . i've just implemented some kind of html parsing logic inside cocoon, which now looks very nice (thanx to cocoon). but i can't start the whole parsing process as a scheduled task, without using a tool outside cocoon. . . . Just curious, what kind of output does your parsing logic produce? simple xml. the parser is a generator. i call it SimpleTextParserGenerator. it needs an xml configuration für parsing a text stream. the xml configuration defines which text fragment goes under which xml node. If it's HTML pages, I'd start a tool like wget to retrieve the pages from Cocoon and save them in the right place. In that case, though, it would IMHO make more sense to use an external scheduling component than to integrate one in Cocoon. yes, first i also thought about an external scheduling component. but such a process should not be accessible from outside. if i do it with an external scheduling component, i have to secure this by a password or something like this. if it can be done inside the sitemap, this process is by default not accessible from outside. in addition it would be very nice to configure. and because i try to develop most to all application stuff with cocoon, and i don't want to use an ejb container yet, i know that such a feature would be useful for me. ok, i try to implement something for myself first. if it then looks some kind of nice, i will inform you about. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: AW: schedule/batch feature inside cocoon
On Wednesday 13 February 2002 08:23, Lars Steiger wrote: . . . simple xml. the parser is a generator. i call it SimpleTextParserGenerator. it needs an xml configuration für parsing a text stream. the xml configuration defines which text fragment goes under which xml node. . . . Changing topics, but are you parsing structured text a la PHPwiki or something? I've been thinking for a while (but didn't find time to do it yet) that this would be a nice addition to Cocoon, being able to use structured text as input. . . . yes, first i also thought about an external scheduling component. but such a process should not be accessible from outside. . . . ok I see your point now. Then what about writing an Action that would block access to your pipeline based on the request's IP address? (maybe even already feasible with Cocoon today?) This would probably be far easier than writing a scheduler, and would allow you to use an external tool, provided it runs on the same host. -- -- Bertrand Delacrétaz, www.codeconsult.ch -- web technologies consultant - OO, Java, XML, C++ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
