RE: Samples samples/welcome-svg working?

[Hugo Burm]

This is because the extractor generator and transformer pair did disappear.
At least when I last checked out a week ago.

Hugo

-Original Message-
From: David Crossley [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 17, 2003 8:06 AM
To: [EMAIL PROTECTED]
Subject: Re: Samples samples/welcome-svg working?


Bernhard Huber wrote:
> hi, thanks for the response,
> for me hello.jpg is working, too.
> perhaps i have not explained it correctly, but the samples/welcom-svg
> page does not work for me,
> more exactly all svg images using not
> http://www.w3.org/2000/svg"; 
> are working fine.
> 
> so does samples/welcome-svg works for you, too?
> using cooon cvs head?

Yes Bernhard, i can confirm that the samples/welcome-svg
(Samples => More Samples => Static Content => SVG Welcome Page)
does *not* work. The main part of the page is blank. When
the mouse runs over the page then the URLs do properly appear
in the browser status bar. Some of those links are broken too.
--David

> Antonio Gallardo wrote:
> > Hi. For me is working:
> > 
> > http://localhost:8080/cocoon/samples/hello-world/hello.jpg
> > 
> > Antonio Gallardo
> > 
> > Bernhard Huber dijo:
> > 
> >>hi,
> >>
> >>The welcome-svg page is empty on the current CVS Head,
> >>can anybody confirm this?
> >>
> >>the problem seems to be that SVGSerializer, and Batik
> >>do not like to serialize xml document having
> >>svg elements using a namespace prefix as it is
> >>used in the welcome-svg page the samples/svg pages
> >>woks fine as the henry.svg file does not uses namespaces.
> >>
> >>bernhard


-
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/documentation/xdocs/plan release.xml

[cziegeler]

cziegeler2003/01/17 03:05:36

  Modified:src/documentation/xdocs/plan Tag: cocoon_2_0_3_branch
release.xml
  Log:
  Updating plan
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.12  +4 -8  xml-cocoon2/src/documentation/xdocs/plan/release.xml
  
  Index: release.xml
  ===
  RCS file: /home/cvs/xml-cocoon2/src/documentation/xdocs/plan/release.xml,v
  retrieving revision 1.1.2.11
  retrieving revision 1.1.2.12
  diff -u -r1.1.2.11 -r1.1.2.12
  --- release.xml   6 Dec 2002 09:48:23 -   1.1.2.11
  +++ release.xml   17 Jan 2003 11:05:36 -  1.1.2.12
  @@ -15,16 +15,12 @@

 This is the current time frame for the next releases:
 
  -   December 2002 : 2.0.4 (bug fix release)
  -   December 2002 : 2.1 Alpha
  -   End of February 2003  : 2.1 Beta 1
  +   February 2003 : 2.1 Alpha
  +   End of March 2003 : 2.1 Beta 1
  On request: 2.0.5 (bug fix release)
 

   
  - 
  -   See the todo list for more information.
  - 

   
   apply patches
  @@ -37,10 +33,10 @@
   finish the
refactoring of samples
   finish to move scratchpad stuff in main trunk
  -switch to LogEnabled
  -extended sitemap variable substitution, i.e. {request:foo}.
   more tests and examples on the flowmap. Seems to me that this 
   strategic stuff has been a set a bit aside due to lack of time.
  +Move complete Source implementation to Excalibur
  +Change implementation for SitemapConfigurable
   


  
  
  

--
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/documentation/xdocs/plan release.xml

[cziegeler]

cziegeler2003/01/17 03:06:21

  Modified:src/documentation/xdocs/plan release.xml
  Log:
  Updating plan
  
  Revision  ChangesPath
  1.12  +4 -8  xml-cocoon2/src/documentation/xdocs/plan/release.xml
  
  Index: release.xml
  ===
  RCS file: /home/cvs/xml-cocoon2/src/documentation/xdocs/plan/release.xml,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- release.xml   6 Dec 2002 09:48:06 -   1.11
  +++ release.xml   17 Jan 2003 11:06:21 -  1.12
  @@ -15,16 +15,12 @@

 This is the current time frame for the next releases:
 
  -   December 2002 : 2.0.4 (bug fix release)
  -   December 2002 : 2.1 Alpha
  -   End of February 2003  : 2.1 Beta 1
  +   February 2003 : 2.1 Alpha
  +   End of March 2003 : 2.1 Beta 1
  On request: 2.0.5 (bug fix release)
 

   
  - 
  -   See the todo list for more information.
  - 

   
   apply patches
  @@ -37,10 +33,10 @@
   finish the
refactoring of samples
   finish to move scratchpad stuff in main trunk
  -switch to LogEnabled
  -extended sitemap variable substitution, i.e. {request:foo}.
   more tests and examples on the flowmap. Seems to me that this 
   strategic stuff has been a set a bit aside due to lack of time.
  +Move complete Source implementation to Excalibur
  +Change implementation for SitemapConfigurable
   


  
  
  

--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail:  [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[PLAN] Release of 2.1

[Carsten Ziegeler]

Hi Cocooners,

I think it's now time (again) to plan the 2.1 release.
Yes, I know we did this several times in the past and we
moved the date. But we always had good reasons for it :)

I updated the planning docs. Is there anything more
that has to be done before a 2.1 release? Then please
add it to the list.

I suggest to make a 2.1alpha in two weeks and a beta
then in march.

What do you think?

Carsten 

Carsten Ziegeler 
Open Source Group, S&N AG


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: xml-cocoon2/src/blocks/databases/samples/mod-db - New directory

[haul]

haul2003/01/17 03:08:46

  xml-cocoon2/src/blocks/databases/samples/mod-db - New directory

--
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/blocks/databases/samples/org-db - New directory

[haul]

haul2003/01/17 03:08:46

  xml-cocoon2/src/blocks/databases/samples/org-db - New directory

--
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/blocks/databases/samples/xsp - New directory

[haul]

haul2003/01/17 03:08:46

  xml-cocoon2/src/blocks/databases/samples/xsp - New directory

--
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/blocks/databases/samples/transform - New directory

[haul]

haul2003/01/17 03:08:46

  xml-cocoon2/src/blocks/databases/samples/transform - New directory

--
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/blocks/web3 - New directory

[haul]

haul2003/01/17 03:10:56

  xml-cocoon2/src/blocks/web3 - New directory

--
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/blocks/web3/conf - New directory

[haul]

haul2003/01/17 03:11:17

  xml-cocoon2/src/blocks/web3/conf - New directory

--
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/blocks/web3/mocks - New directory

[haul]

haul2003/01/17 03:11:17

  xml-cocoon2/src/blocks/web3/mocks - New directory

--
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/blocks/web3/samples - New directory

[haul]

haul2003/01/17 03:11:17

  xml-cocoon2/src/blocks/web3/samples - New directory

--
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/blocks/web3/java - New directory

[haul]

haul2003/01/17 03:11:17

  xml-cocoon2/src/blocks/web3/java - New directory

--
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/blocks/web3/samples/dtd - New directory

[haul]

haul2003/01/17 03:11:54

  xml-cocoon2/src/blocks/web3/samples/dtd - New directory

--
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/blocks/web3/samples/stylesheets - New directory

[haul]

haul2003/01/17 03:11:54

  xml-cocoon2/src/blocks/web3/samples/stylesheets - New directory

--
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/blocks/web3/mocks/com - New directory

[haul]

haul2003/01/17 03:11:55

  xml-cocoon2/src/blocks/web3/mocks/com - New directory

--
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/blocks/web3/samples/resources - New directory

[haul]

haul2003/01/17 03:11:54

  xml-cocoon2/src/blocks/web3/samples/resources - New directory

--
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/blocks/web3/java/org - New directory

[haul]

haul2003/01/17 03:11:55

  xml-cocoon2/src/blocks/web3/java/org - New directory

--
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/blocks/web3/mocks/com/sap - New directory

[haul]

haul2003/01/17 03:12:11

  xml-cocoon2/src/blocks/web3/mocks/com/sap - New directory

--
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/blocks/web3/java/org/apache - New directory

[haul]

haul2003/01/17 03:12:11

  xml-cocoon2/src/blocks/web3/java/org/apache - New directory

--
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/blocks/web3/java/org/apache/cocoon - New directory

[haul]

haul2003/01/17 03:12:33

  xml-cocoon2/src/blocks/web3/java/org/apache/cocoon - New directory

--
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/blocks/web3/mocks/com/sap/mw - New directory

[haul]

haul2003/01/17 03:12:31

  xml-cocoon2/src/blocks/web3/mocks/com/sap/mw - New directory

--
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/blocks/web3/mocks/com/sap/mw/jco - New directory

[haul]

haul2003/01/17 03:12:43

  xml-cocoon2/src/blocks/web3/mocks/com/sap/mw/jco - New directory

--
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/blocks/web3/java/org/apache/cocoon/transformation - New directory

[haul]

haul2003/01/17 03:12:43

  xml-cocoon2/src/blocks/web3/java/org/apache/cocoon/transformation - New directory

--
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/blocks/web3/java/org/apache/cocoon/components - New directory

[haul]

haul2003/01/17 03:12:43

  xml-cocoon2/src/blocks/web3/java/org/apache/cocoon/components - New directory

--
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/blocks/web3/java/org/apache/cocoon/components/web3 - New directory

[haul]

haul2003/01/17 03:12:52

  xml-cocoon2/src/blocks/web3/java/org/apache/cocoon/components/web3 - New directory

--
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/blocks/web3/java/org/apache/cocoon/components/web3/impl - New directory

[haul]

haul2003/01/17 03:13:02

  xml-cocoon2/src/blocks/web3/java/org/apache/cocoon/components/web3/impl - New 
directory

--
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/blocks/authentication-fw/conf authentication-fw.xsamples

[haul]

haul2003/01/17 03:22:37

  Added:   src/webapp/samples block-samples.xml
   src/blocks/portal-fw/conf portal-fw.xsamples
   src/blocks/databases/samples samples.xml sitemap.xmap
   src/blocks/databases/samples/xsp esql.xsd esql.xsp
sitemap.xmap
   src/blocks/databases/samples/transform sitemap.xmap
sql-page.xml sql-page.xml.sql
   src/blocks/databases/samples/org-db add-department.xsp
add-employee.xsp employee.xml employee.xsp
process-department.xsp process-employee.xsp
sitemap.xmap
   src/blocks/databases/samples/mod-db database.xml
edit-groups.xsp schema.sql sitemap.xmap stupid.xsl
user-list.xsp
   src/blocks/databases/conf databases.xsamples
   src/blocks/authentication-fw/conf authentication-fw.xsamples
  Log:
  Move database samples to block
  Modify build system to merge *.xsample files to block-samples.xml
  Move authentication-fw samples to block-samples.xml
  Move portal-fw samples to block-samples.xml
  Fix simple-samples2html.xsl
- only one group works
- include groups and notes in balancing
- make gif rooted path
  
  Revision  ChangesPath
  1.1  xml-cocoon2/src/webapp/samples/block-samples.xml
  
  Index: block-samples.xml
  ===
  
  
  
  
  http://www.w3.org/1999/xlink"; name="blocks">

  
  
  
  
  1.1  xml-cocoon2/src/blocks/portal-fw/conf/portal-fw.xsamples
  
  Index: portal-fw.xsamples
  ===
  
  
  
  

  
  This is a demo of the portal framework integrated into Cocoon.
 


  
  
  
  
  1.1  xml-cocoon2/src/blocks/databases/samples/samples.xml
  
  Index: samples.xml
  ===
  
  
  
  
  http://www.w3.org/1999/xlink"; name="database block">
  

   
 Documentation for this component.
   
   
 Simple example using the SQL transformer.
   

  

   
 Documentation for this component.
   
   
 Simple example of embedding SQL in a serverpage using the ESQL logicsheet.
   

  

   
 Documentation for this component.
   
   
 An example web-application built around database actions from the
 modular package which supports auto increments and more.
   

  

   
 Documentation for this component.
   
   
 Adds, updates and deletes Employees to the employees table.
   
   
 Adds new Departments to the department table.
   
   
 Adds new Employees to the employees table.
   


  
  
  
  
  1.1  xml-cocoon2/src/blocks/databases/samples/sitemap.xmap
  
  Index: sitemap.xmap
  ===
  
  http://apache.org/cocoon/sitemap/1.0";>
  
  
  
   






   
  
  
  
  
   

 

  

  
  



 

  
   
  
  
  
   
  

  
 
   
 
 
 
  
  
  
 
  
   
 
   
 
  

   
  
  
  
  
  
  
  
  1.1  xml-cocoon2/src/blocks/databases/samples/xsp/esql.xsd
  
  Index: esql.xsd
  ===
  
  
  
  
  http://www.w3.org/2000/10/XMLSchema";
xmlns:esql="http://apache.org/cocoon/SQL/v2";
  >
  
  

  Opens a new database connection.


  

  


  
The name of the driver to use
  


  
The URL of the database
  


  
The database user's name
  


  
The database user's password
  

  
  

  The name of the database pool

  


  

  Executes a query on the database


  

  
The query to execute
  
  

  

  A parameter for a prepared 
statement

  

  


  
This element's children are instantiated in the 
result tree when the query ret

cvs commit: xml-cocoon2/src/webapp/samples/chaperon sitemap.xmap

[haul]

haul2003/01/17 03:29:23

  Modified:.build.xml changes.xml
   src/webapp/samples samples.xml sitemap.xmap
   src/webapp/samples/docs/samples sample-apps.xml
sample-dynamic.xml sample-xsp.xml
   src/webapp/samples/common/style/xsl/html
simple-samples2html.xsl
   src/webapp/samples/chaperon sitemap.xmap
  Log:
  Move database samples to block
  Modify build system to merge *.xsample files to block-samples.xml
  Move authentication-fw samples to block-samples.xml
  Move portal-fw samples to block-samples.xml
  Fix simple-samples2html.xsl
- only one group works
- include groups and notes in balancing
- make gif rooted path
  
  Revision  ChangesPath
  1.308 +11 -6 xml-cocoon2/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/xml-cocoon2/build.xml,v
  retrieving revision 1.307
  retrieving revision 1.308
  diff -u -r1.307 -r1.308
  --- build.xml 14 Jan 2003 09:26:56 -  1.307
  +++ build.xml 17 Jan 2003 11:29:22 -  1.308
  @@ -1449,10 +1449,15 @@
 extension="xconf"
 configuration="${build.war}/WEB-INF/cocoon.xconf"/>
 
  +  
  +
 
 
  +
 
   
 
  @@ -1844,7 +1849,7 @@
 
  -
  +
   
  @@ -1858,8 +1863,8 @@
 destdir="${build.javadocs}"
 author="true"
 version="true"
  -  use="false"
  -  noindex="true"
  +  use="true"
  +  noindex="false"
 windowtitle="${Name} API (${version}, ${TODAY})"
 doctitle="${Name}"
 bottom="Copyright © ${year} Apache Software Foundation. All 
Rights Reserved."
  @@ -1868,7 +1873,7 @@
  


  - 
  + 
  
  

  @@ -1882,8 +1887,8 @@
 destdir="${build.javadocs}"
 author="true"
 version="true"
  -  use="false"
  -  noindex="true"
  +  use="true"
  +  noindex="false"
 windowtitle="${Name} API (${version}, ${TODAY})"
 doctitle="${Name}"
 bottom="Copyright © ${year} Apache Software Foundation. All 
Rights Reserved."
  
  
  
  1.339 +8 -5  xml-cocoon2/changes.xml
  
  Index: changes.xml
  ===
  RCS file: /home/cvs/xml-cocoon2/changes.xml,v
  retrieving revision 1.338
  retrieving revision 1.339
  diff -u -r1.338 -r1.339
  --- changes.xml   14 Jan 2003 17:22:29 -  1.338
  +++ changes.xml   17 Jan 2003 11:29:22 -  1.339
  @@ -40,11 +40,14 @@

   

  -  
  -Fix PNG output of SVGSerializer because The PNGTranscoder of Batik 
  -closes the stream.
  +  
  +SAP R/3 connectivity components added.
  
  +  
  +Moved block samples to own category, modified build system to merge
  +.xsample files to block-samples.xml.
  +  
 
   Renaming components section for pipeline implementations to "pipes" and "pipe".
 
  
  
  
  1.36  +8 -7  xml-cocoon2/src/webapp/samples/samples.xml
  
  Index: samples.xml
  ===
  RCS file: /home/cvs/xml-cocoon2/src/webapp/samples/samples.xml,v
  retrieving revision 1.35
  retrieving revision 1.36
  diff -u -r1.35 -r1.36
  --- samples.xml   16 Jan 2003 13:02:08 -  1.35
  +++ samples.xml   17 Jan 2003 11:29:22 -  1.36
  @@ -56,12 +56,6 @@
  
 
 
  -
  -This is a demo of the authentication framework integrated into Cocoon.
  -   
  -
  -This is a demo of the portal framework integrated into Cocoon.
  -   
   
   Samples showing how to perform form processing, state management,
   and simple web-application with login and protected resources.
  @@ -196,6 +190,13 @@
   
   Here is a peek of what the next release of Cocoon will bring.
   To test these samples, you must have built Cocoon with "build (sh|bat) 
installscratchpadwar".
  +   
  +  
  +  
  +
  +Functionality outside the core has been moved to units called "blocks". This
  +will lead to a more modular Cocoon. Some samples depend on additional
  +components that need to be installed and configured correctly.
  
 
   
  
  
  
  1.25  +12 -47xml-cocoon2/src/webapp/samples/sitemap.xmap
  
  Index: sitemap.xmap
  ===
  RCS file: /home/cvs/xml-cocoon2/src/webapp/samples/sitemap.xmap,v
  retrieving revision 1.24
  retrieving revision 1.25
  diff -u -r1.24 -r

Re: [CVS] - A rare message when downloading....

[Steven Noels]

Antonio Gallardo wrote:


Hi Steve:

Sorry, but I dont understand the point. :-(

Vadim told me that:

"Conflict. Rename your .cvsignore, checkout, then you can merge."
Then I saw the file there in the cvs site. I dont understand if this is
correct or not.


It is.

You modified your local .cvsignore file, and CVS wasn't able to 
automagically merge with an updated version of .cvsignore from the 
repository.

So Vadim suggested to rename your local copy so that it isn't in the way 
anymore, 'cvs update' so that you get the repository version of the 
file, and then you can manually merge the differences between both. 
There even exist conflict editors for such a purpose: 
http://sourceforge.net/projects/conflicteditor

HTH,


--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/webservices/instrument DeploymentDescriptor.wsdd InstrumentationService.java InstrumentationServiceImpl.java

[crafterm]

crafterm2003/01/17 03:31:18

  Modified:src/scratchpad/src/org/apache/cocoon/webservices/instrument
DeploymentDescriptor.wsdd
InstrumentationService.java
InstrumentationServiceImpl.java
  Log:
  * Implemented getSampleNames(). This allows one to obtain a list of available
instrument samples, eg. for browsing purposes.
  
  Revision  ChangesPath
  1.2   +1 -1  
xml-cocoon2/src/scratchpad/src/org/apache/cocoon/webservices/instrument/DeploymentDescriptor.wsdd
  
  Index: DeploymentDescriptor.wsdd
  ===
  RCS file: 
/home/cvs/xml-cocoon2/src/scratchpad/src/org/apache/cocoon/webservices/instrument/DeploymentDescriptor.wsdd,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- DeploymentDescriptor.wsdd 8 Nov 2002 17:39:19 -   1.1
  +++ DeploymentDescriptor.wsdd 17 Jan 2003 11:31:17 -  1.2
  @@ -5,7 +5,7 @@
 
 
 
  -  
  +  

   
   
  
  
  
  1.2   +8 -1  
xml-cocoon2/src/scratchpad/src/org/apache/cocoon/webservices/instrument/InstrumentationService.java
  
  Index: InstrumentationService.java
  ===
  RCS file: 
/home/cvs/xml-cocoon2/src/scratchpad/src/org/apache/cocoon/webservices/instrument/InstrumentationService.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- InstrumentationService.java   8 Nov 2002 17:39:19 -   1.1
  +++ InstrumentationService.java   17 Jan 2003 11:31:17 -  1.2
  @@ -98,4 +98,11 @@
*/
   int[] getSampleSnapshot(String path)
   throws Exception;
  +
  +/**
  + * Obtains an array of instrumentable sample names
  + *
  + * @return a {@link String[]} array of sample names
  + */
  +String[] getSampleNames();
   }
  
  
  
  1.2   +59 -13
xml-cocoon2/src/scratchpad/src/org/apache/cocoon/webservices/instrument/InstrumentationServiceImpl.java
  
  Index: InstrumentationServiceImpl.java
  ===
  RCS file: 
/home/cvs/xml-cocoon2/src/scratchpad/src/org/apache/cocoon/webservices/instrument/InstrumentationServiceImpl.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- InstrumentationServiceImpl.java   8 Nov 2002 17:39:19 -   1.1
  +++ InstrumentationServiceImpl.java   17 Jan 2003 11:31:17 -  1.2
  @@ -50,10 +50,15 @@
   */
   package org.apache.cocoon.webservices.instrument;
   
  +import java.util.ArrayList;
  +import java.util.List;
  +
   import org.apache.avalon.framework.logger.AbstractLogEnabled;
   import org.apache.excalibur.instrument.InstrumentManager;
   import org.apache.excalibur.instrument.manager.DefaultInstrumentManager;
   import org.apache.excalibur.instrument.manager.interfaces.InstrumentableDescriptor;
  +import org.apache.excalibur.instrument.manager.interfaces.InstrumentDescriptor;
  +import 
org.apache.excalibur.instrument.manager.interfaces.InstrumentSampleDescriptor;
   
   /**
* Implementation of {@link InstrumentationService} component. This component
  @@ -65,8 +70,8 @@
   public final class InstrumentationServiceImpl extends AbstractLogEnabled
   implements InstrumentationService {
   
  -// empty integer array, used if a sample is request, but no manager exists.
   private static final int[] EMPTY_INT_ARRAY = {};
  +private static final String[] EMPTY_STRING_ARRAY = {};
   
   // instrument manager reference
private DefaultInstrumentManager m_iManager;
  @@ -129,12 +134,11 @@
   throws Exception {
   
   // ensure we have an instrument manager available
  -if (m_iManager == null) {
  -if (getLogger().isWarnEnabled())
  -getLogger().warn(
  -"No instrument manager available," +
  -"please enable instrumentation in your web.xml"
  -);
  +if (!haveInstrumentManager()) {
  +getLogger().warn(
  +   "No instrument manager available," +
  +   "please enable instrumentation in your web.xml"
  +);
   return EMPTY_INT_ARRAY;
   }
   
  @@ -144,12 +148,54 @@
   }
   
   /**
  - * REVISIT: this is currently unused, but might be good for browsing
  - * instrument samples in the future.
  + * Obtain a list of available samples, useful for browsing
  + * available samples.
  + *
  + * @return an {@link String}[] array of sample names
  + */
  +public String[] getSampleNames() {
  +
  +// ensure we have an instrument manager available
  +if (!haveInstrumentManager()) {
  +getLogger().warn(
  +"No instrument manager available," +
  +"please enable instrumentation in yo

cvs commit: xml-cocoon2/src/webapp/samples/docs/samples/sql sql-page.xml sql-page.xml.sql

[haul]

haul2003/01/17 03:31:19

  Removed: src/webapp/samples/docs/samples/sql sql-page.xml
sql-page.xml.sql
  Log:
  Move database samples to block
  Modify build system to merge *.xsample files to block-samples.xml
  Move authentication-fw samples to block-samples.xml
  Move portal-fw samples to block-samples.xml
  Fix simple-samples2html.xsl
- only one group works
- include groups and notes in balancing
- make gif rooted path

--
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/modules/input DigestMetaModule.java

[haul]

haul2003/01/17 03:31:55

  Modified:src/java/org/apache/cocoon/components/modules/input
DigestMetaModule.java
  Log:
  Additional encodings
  
  Revision  ChangesPath
  1.12  +113 -20   
xml-cocoon2/src/java/org/apache/cocoon/components/modules/input/DigestMetaModule.java
  
  Index: DigestMetaModule.java
  ===
  RCS file: 
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/components/modules/input/DigestMetaModule.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- DigestMetaModule.java 15 Jan 2003 15:55:13 -  1.11
  +++ DigestMetaModule.java 17 Jan 2003 11:31:55 -  1.12
  @@ -54,20 +54,26 @@
   import org.apache.avalon.framework.configuration.ConfigurationException;
   import org.apache.avalon.framework.thread.ThreadSafe;
   
  +import org.apache.cocoon.util.HashMap;
  +
   import java.net.URLEncoder;
   import java.security.MessageDigest;
   import java.security.NoSuchAlgorithmException;
   import java.security.NoSuchProviderException;
   import java.util.Iterator;
   import java.util.Map;
  +import java.io.UnsupportedEncodingException;
   
   /** Meta module that obtains values from other module and returns
* message digest of value. Very useful for storing and checking
* passwords. Input module configured through nested element
* "input-module", message digest algorithm, security provider, salt,
  - * and URL encoded output configurable through attributes
  - * "algorithm", "provider", "salt", "encode" of configuration root
  - * element. Defaults are "sha", null, "salt", and "false".
  + * and URL encoded output configurable through attributes "algorithm",
  + * "provider", "salt", "encode" of configuration root
  + * element. Defaults are "sha", null, "salt", and "false". Available
  + * value for encode are "none" (returns byte[]), "string" (return hash
  + * as string), "url" (returns url encoded string), "hex" (returns
  + * string of hex values).
*
* @author mailto:[EMAIL PROTECTED]";>Christian Haul
* @version CVS $Id$
  @@ -77,7 +83,31 @@
   private String defaultAlgorithm = "SHA";
   private String defaultProvider = null;
   private String defaultSalt = "salt";
  -private boolean defaultEncode = false;
  +private String defaultEncode = "false";
  +
  +/** output encoding none */
  +static final int ENCODING_NONE = 0;
  +/** output encoding url encoding */
  +static final int ENCODING_STR = 1;
  +/** output encoding hex */
  +static final int ENCODING_URL = 2;
  +/** output encoding hex */
  +static final int ENCODING_HEX = 3;
  +
  +private static final HashMap encodingNames;
  +/** setup mapping tables */
  +static {
  +HashMap names = new HashMap();
  +names.put("false", new Integer(ENCODING_NONE));
  +names.put("no", new Integer(ENCODING_NONE));
  +names.put("none", new Integer(ENCODING_NONE));
  +names.put("string", new Integer(ENCODING_STR));
  +names.put("yes", new Integer(ENCODING_URL));
  +names.put("true", new Integer(ENCODING_URL));
  +names.put("hex", new Integer(ENCODING_HEX));
  +encodingNames = names;
  +names = null;
  +}
   
   
   public void configure(Configuration config) throws ConfigurationException {
  @@ -87,7 +117,12 @@
   this.defaultAlgorithm = 
this.inputConf.getAttribute("algorithm",this.defaultAlgorithm);
   this.defaultProvider = 
this.inputConf.getAttribute("provider",this.defaultProvider);
   this.defaultSalt = this.inputConf.getAttribute("salt",this.defaultSalt);
  -this.defaultEncode = 
this.inputConf.getAttributeAsBoolean("encode",this.defaultEncode);
  +this.defaultEncode = this.inputConf.getAttribute("encode","false");
  +if (this.encodingNames.get(this.defaultEncode) == null) {
  +if (getLogger().isErrorEnabled())
  +getLogger().error("Requested encoding is unknown: 
"+this.defaultEncode);
  +this.defaultEncode="false";
  +}
   }
   
   
  @@ -110,7 +145,7 @@
   String algorithm = this.defaultAlgorithm;
   String provider  = this.defaultProvider;
   String salt  = this.defaultSalt;
  -boolean encode = this.defaultEncode;
  +int encode = ((Integer) encodingNames.get(this.defaultEncode)).intValue();
   if (modeConf!=null) {
   inputName   = 
modeConf.getChild("input-module").getAttribute("name",null);
   if (inputName != null) {
  @@ -120,7 +155,7 @@
   algorithm = modeConf.getAttribute("algorithm", algorithm);
   provider  = modeConf.getAttribute("provider" , provider );
   salt  = modeConf.getAttribute("salt" , salt );
  -encode = modeConf.getAttributeAsBoolean("encode" , encode );
  +encod

cvs commit: xml-cocoon2/src/webapp/WEB-INF/entities sitemap-v06.rng

[haul]

haul2003/01/17 03:33:51

  Modified:.project-info.xml properties.xml
   src/webapp/WEB-INF/entities sitemap-v06.rng
  Log:
  Added web3 (SAP connectivity) block
  
  Revision  ChangesPath
  1.5   +17 -0 xml-cocoon2/project-info.xml
  
  Index: project-info.xml
  ===
  RCS file: /home/cvs/xml-cocoon2/project-info.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- project-info.xml  2 Jan 2003 10:50:05 -   1.4
  +++ project-info.xml  17 Jan 2003 11:33:50 -  1.5
  @@ -524,6 +524,23 @@

 
   
  +  
  +org.apache.cocoon
  +
  +
  +  
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +  
 
 
 
 
   
 
  
  
  
  1.5   +6 -0  xml-cocoon2/src/webapp/WEB-INF/entities/sitemap-v06.rng
  
  Index: sitemap-v06.rng
  ===
  RCS file: /home/cvs/xml-cocoon2/src/webapp/WEB-INF/entities/sitemap-v06.rng,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- sitemap-v06.rng   14 Jan 2003 10:48:58 -  1.4
  +++ sitemap-v06.rng   17 Jan 2003 11:33:51 -  1.5
  @@ -313,6 +313,11 @@
   
 
   
  +
  +  
  +
  +  
  +
   
 
   
  @@ -459,6 +464,7 @@
 
 
 
  +  
 
   
   
  
  
  

--
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/webapp/samples/mod-db database.xml edit-groups.xsp schema.sql sitemap.xmap stupid.xsl user-list.xsp

[haul]

haul2003/01/17 03:34:35

  Removed: src/webapp/samples/mod-db database.xml edit-groups.xsp
schema.sql sitemap.xmap stupid.xsl user-list.xsp
  Log:
  Move database samples to block
  Modify build system to merge *.xsample files to block-samples.xml
  Move authentication-fw samples to block-samples.xml
  Move portal-fw samples to block-samples.xml
  Fix simple-samples2html.xsl
- only one group works
- include groups and notes in balancing
- make gif rooted path

--
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/webapp/samples/docs/samples/forms add-department.xsp add-employee.xsp employee.xml employee.xsp process-department.xsp process-employee.xsp

[haul]

haul2003/01/17 03:35:11

  Removed: src/webapp/samples/docs/samples/forms add-department.xsp
add-employee.xsp employee.xml employee.xsp
process-department.xsp process-employee.xsp
  Log:
  Move database samples to block
  Modify build system to merge *.xsample files to block-samples.xml
  Move authentication-fw samples to block-samples.xml
  Move portal-fw samples to block-samples.xml
  Fix simple-samples2html.xsl
- only one group works
- include groups and notes in balancing
- make gif rooted path

--
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/webapp/samples/docs/samples/xsp esql.xsd esql.xsp

[haul]

haul2003/01/17 03:36:08

  Removed: src/webapp/samples/docs/samples/xsp esql.xsd esql.xsp
  Log:
  Move database samples to block
  Modify build system to merge *.xsample files to block-samples.xml
  Move authentication-fw samples to block-samples.xml
  Move portal-fw samples to block-samples.xml
  Fix simple-samples2html.xsl
- only one group works
- include groups and notes in balancing
- make gif rooted path

--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail:  [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [OT] London Cocoon meet (was Re: Back in London)

[Stefano Mazzocchi]

Andrew Savory wrote:

On Thu, 16 Jan 2003, Thom May wrote:



+1 to date/time/food
-1 to me having to pick the bar, its someone else's turn ;-)



Ok, slug and lettuce from about 6pm, probably downstairs near the pool
table. See http://www.slugandlettuce.co.uk/directions/soho.htm


Great, thanks for picking it up Andrew :)

See you people there.

I'll try to bring both Pier and Fede with me :)

--
Stefano Mazzocchi   <[EMAIL PROTECTED]>




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [PLAN] Release of 2.1

[Stefano Mazzocchi]

Carsten Ziegeler wrote:

Hi Cocooners,

I think it's now time (again) to plan the 2.1 release.
Yes, I know we did this several times in the past and we
moved the date. But we always had good reasons for it :)

I updated the planning docs. Is there anything more
that has to be done before a 2.1 release? Then please
add it to the list.

I suggest to make a 2.1alpha in two weeks and a beta
then in march.

What do you think?


I don't want to rain on the party but I would not feel that comfortable 
with a release (even if alpha and with all disclaimers attached) right 
before a very important pending vote on the semantics of the hooks 
between the sitemap and the flow layer.

I hope you see my concerns.

--
Stefano Mazzocchi   <[EMAIL PROTECTED]>




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: [PLAN] Release of 2.1

[Carsten Ziegeler]

Stefano Mazzocchi wrote:
> 
> Carsten Ziegeler wrote:
> > Hi Cocooners,
> > 
> > I think it's now time (again) to plan the 2.1 release.
> > Yes, I know we did this several times in the past and we
> > moved the date. But we always had good reasons for it :)
> > 
> > I updated the planning docs. Is there anything more
> > that has to be done before a 2.1 release? Then please
> > add it to the list.
> > 
> > I suggest to make a 2.1alpha in two weeks and a beta
> > then in march.
> > 
> > What do you think?
> 
> I don't want to rain on the party but I would not feel that comfortable 
> with a release (even if alpha and with all disclaimers attached) right 
> before a very important pending vote on the semantics of the hooks 
> between the sitemap and the flow layer.
> 
> I hope you see my concerns.
> 
Yes, I agree, but I have the hope that this is solved by then. If not,
ok, we wait until it's solved.

Carsten

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [Fwd: [announce] Agora 1.1]

[Stefano Mazzocchi]

Gerd Mueller wrote:

Hi,

That's an really interesting piece of software. 

Thank you.


Some ideas for improvement:

- some kind of zoom mode to zoom into the dense dataclouds


yes, several people have asked for something like this, I might work on it.


- I assume that the three clouds represent the three mailing lists
  but I'm not sure which cloud is which list, so some more
  detailed information about the connections between the squares 
  would be nice

Good point, I'll try to work something out (I have a couple of simple 
ideas to try out)


- some more statistics about a mailing list member could be
  interesting, e.g. the amount of emails s/he wrote


No, I'm very concerned about the abuses that this software might 
receive, like "I'm more important than you" based on positional 
location. Agora was designed to *reduce* those "star stages" and keep 
people as uniform as possible, by providing numbers and direct ways to 
confront you are adding the ability for people to abuse their values by 
providing their own significance, while the evolutionary significance of 
a runtime symulation is more subdle and easier to abuse.

I consider lack of numerical statistical data a feature, not a bug and 
I'll do my best to keep it that way.

Thanks for the input, though, very appreciated.

--
Stefano Mazzocchi   <[EMAIL PROTECTED]>




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [vote] finilizing the pending votes on flow [was Re: [RT] Flow/SitemapIntegration]

[Stefano Mazzocchi]

Reinhard Poetz wrote:

Stefano Mazzocchi wrote:




Let me add:

 - make a new method that allows the flow to call a pipeline and pass a
different output stream. This will allow to use pipelines as tools to
serialize things, say, to disk or to other means.

What do you think?




I think you mean a function in the system.js, don't you?


Yes, exactly. A function equivalent to sendPageAndContinue() that I can 
use to call a pipeline but to use it orthogonally from the normal stream 
of data that flows from the request to the response.

This is very useful, for example, to save stuff to disk or to CVS or to 
any other repository and will finally, IMO, give an end to the need for 
a forked pipeline that goes in two different places.

For my flows I use a self-defined function which makes this for me:

function callPipeline(src) {
xc = cocoon.componentManager.lookup( myXMLConsumer.ROLE );
resolver = cocoon.environment.getObjectModel().get("source-resolver");
srce = resolver.resolveURI(src);
resolver.toSAX( srce, xc );
return xc;
}

The component myXMLConsumer has a method public String
getDocument() ... mabe there is a better/more elegant way, but it
works for me ;-)


nonono, careful. You are calling a pipeline to have its data as an 
object model to play with. While this is fair, I don't like it at all 
and would not want it included in system.js. It looks like an hack from 
miles away (sorry, no offense, just stating my impressions honestly)

What I want is something different.

I'll come up with an RT later today or tomorrow.

For now, consider it separated from this vote since it has not been 
discussed well and I want more feedback on it.

--
Stefano Mazzocchi   <[EMAIL PROTECTED]>




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [vote] finilizing the pending votes on flow [was Re: [RT] Flow/SitemapIntegration]

[Stefano Mazzocchi]

Sylvain Wallez wrote:

Sorry to jump in lately, but the "vote" made me consider that thread as 
important and I finally looked at it. So here we go...

Which was the reason to call for a vote even if the discussion is not 
yet finalized :-)

I do know how lazy you people are :-) (oh, just because I'm even worse)

Semantic confusion induced by "map:pipeline"

First of all, I wonder if all this started because the sitemap top-level 
processing element is named _pipeline_.

This is a very good point. I've thought about it as well.


There was a discussion recently about renaming map:pipelines because of 
a naming conflict with the new map:pipelines components. At that time, I 
proposed the word "process" to replace the current ("old" one) 
map:pipeline (see [1]).

I suggested "process" because the sitemap is the top-level authority in 
Cocoon that drives how a request is _processed_. And the fact that the 
sitemap implements the "Processor" interface shows that this is what was 
meant from the beginning.

Michael proposes to put the flow map out of map:pipeline because a flow 
doesn't build a pipeline. That's true, but even without flow, processing 
a request may not build a pipeline : consider redirects with 
"map:redirect" and actions (I know, you don't like actions, but you 
can't deny their usefulness).

All true, action usefulness included.


The redirect can also be a "forward" (in the servlet meaning) if the 
redirect URI starts with "cocoon:". In that case, a pipeline is actually 
built, but indirectly (it definition is not explicitly visible at the 
redirect point in the sitemap).

Again, true.


I consider a call to a flow like a "computed" forward. Continuations are 
an added bonus, but a flow function finishes by a sendPage() which is 
actually a forward. So a flow handles application logic and indirectly 
builds a pipeline.

True, that is what I see replacing actions in the future, but that might 
not sound appealing in a programming environment where nobody knows 
ecmascript nor wants to learn it.

As a side note, I realize while writing this that I unconciously was 
aware of this when writing the TreeProcessor, as there's a subtle 
behavioural difference with the compiled sitemap engine : the compiled 
engine creates a pipeline instance right at the beginning of the 
sitemap, while the TreeProcessor defers this up to the _first 
encountered_ sitemap statement (generate, etc), which may _never come_ 
if there's a redirect. So the TreeProcessor is really a processor and 
not only a pipeline builder.

Yes, that makes sense.

Now, do you propose we change "pipelines/pipeline" with "processes/process"?

Besides the huge back compatibility effort of migration (not only code, 
but user knowledge), I don't find myself resonating with the concept of 
"process" since "pipeline" is... well... more fun :)

I mean, pipelines are something that cocoon was first to introduce in 
the xml server side world. Maybe it doesn't make sense from a purely 
core-up technological perspective, but it should does make sense from a 
user-reading-a-simple-sitemap-for-the-first-time point of view.

And, to be honest, I care about the second more than about the elegance 
of the first.

Do you see my point?

[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104221105317073&w=2

Overlap between "map:map" and "map:match"
-
The discussion outlined the overlap between "map:map" (compact notation 
for the flow) and "map:match". What priority should be given to one or 
the other ? Michael's opinion to give priority to the flow makes sense, 
but I share Stefano's wonders about "creative uses" of the flow ?

And I also find it very confusing to have the same component type used 
with two different statements.

This is not only confusing, it's disturbing me a little.


Also, what about selectors ? Selectors are IMO largely under-used 
because their definition is too poor compared to matchers. I recently 
had some thoughts about this and will write a RT about "super-selectors" 
soon. Basically, the idea is to have selectors that are like a sequence 
of matchers of the same type. This allows for a more compact notation 
for successive matchers of the same type (which we have a lot in most 
sitemaps) and may lead to tremendous speed optimisations (hashmap lookup 
compared to sequential lookup).

For example, a "wildcard-uri" super-selector may allow the following 
notation :

 
   
 
 
   
  
   
 
 
   
 


yes, I see your point, even if, again, it's a technologically-driven 
perspective and will only confuse people before normal matching and 
super-selective matching. You know to know a lot about the internals to 
understand this can't we make it an internal transparent 
optimization of the sitemap interpreter? doesn't seem that hard.

Also (but this may be a spec detail), I've not seen how variables set by 
matchers in "map:map" are made avai

Re: [Fwd: [announce] Agora 1.1]

[Bertrand Delacretaz]

Stefano Mazzocchi wrote:
>. . .

No, I'm very concerned about the abuses that this software might 
receive, like "I'm more important than you" based on positional 
location. 
>. . .

I think this kind of information is already present in the current 
version, even if less obvious: dragging a point far away from the 
current cloud and watching how many others follow gives a good feel of 
the influence (as perceived by Agora) of a person in  the community.

Great piece of software, by the way!
Helps get a feel for the kind of community relationships that exist.

-Bertrand


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: [vote] finilizing the pending votes on flow [was Re: [RT] Flow/SitemapIntegration]

[Reinhard Poetz]

Thank you very much! I thought that it would work the other way!

Regards,
Reinhard

> -Original Message-
> From: Christopher Oliver [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 17, 2003 7:18 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [vote] finilizing the pending votes on flow [was Re: [RT]
> Flow/SitemapIntegration]
> 
> 
> Hi Reinhard,
> 
> Just a warning, you should always use the "var" keyword with local 
> variables in JavaScript.  Your function should probably read:
> 
> function callPipeline(src) {
> var xc = cocoon.componentManager.lookup( myXMLConsumer.ROLE );
> var resolver = 
> cocoon.environment.getObjectModel().get("source-resolver");
> var srce = resolver.resolveURI(src);
> resolver.toSAX( srce, xc );
> return xc;
> }
> 
> Without "var" you are creating global variables named "xc", "resolver", 
> "srce". .
> 
> Regards,
> 
> Chris
> 
> Reinhard Poetz wrote:
> 
> >For my flows I use a self-defined function which makes this for me:
> >
> >function callPipeline(src) {
> >xc = cocoon.componentManager.lookup( myXMLConsumer.ROLE );
> >resolver = 
> cocoon.environment.getObjectModel().get("source-resolver");
> >srce = resolver.resolveURI(src);
> >resolver.toSAX( srce, xc );
> >return xc;
> >}
> >
> >  
> >
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

redefine the serializer parameters

[Yury Mikhienko]

Hi all cocooners!

What you think about the following idea:

I want to  modify the serializer parameters localy (with the global serializer 
settings in sitemap)
For example:
now in root sitemap I have the following serializer settings:

  



  1024
  KOI8-R

   ...
  
   ...

in mounted sitemap I have a chance to redefine serializers:



  1024
  UTF-8




but this is global serializer definition for all pipelines on sitemap.
I want to redefine the serializer parameters in matching step, for example:
in mounted sitemap:



 ...
  

...




  UTF-8

   
...
 




   
...

 

Any suggestions?

-- 
 
Best regards,
Yury Mikhienko.
IT engineer, ZAO "Mobicom-Kavkaz"

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: [vote] finilizing the pending votes on flow [was Re: [RT] Flow/SitemapIntegration]

[Reinhard Poetz]

> -Original Message-
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 17, 2003 1:27 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [vote] finilizing the pending votes on flow [was Re: [RT]
> Flow/SitemapIntegration]
>
>
> Reinhard Poetz wrote:
> > Stefano Mazzocchi wrote:
> >
> > 
> >
> >>Let me add:
> >>
> >>  - make a new method that allows the flow to call a pipeline and pass a
> >>different output stream. This will allow to use pipelines as tools to
> >>serialize things, say, to disk or to other means.
> >>
> >>What do you think?
> >
> > 
> >
> > I think you mean a function in the system.js, don't you?
>
> Yes, exactly. A function equivalent to sendPageAndContinue() that I can
> use to call a pipeline but to use it orthogonally from the normal stream
> of data that flows from the request to the response.
>
> This is very useful, for example, to save stuff to disk or to CVS or to
> any other repository and will finally, IMO, give an end to the need for
> a forked pipeline that goes in two different places.
>
> > For my flows I use a self-defined function which makes this for me:
> >
> > function callPipeline(src) {
> > xc = cocoon.componentManager.lookup( myXMLConsumer.ROLE );
> > resolver =
> cocoon.environment.getObjectModel().get("source-resolver");
> > srce = resolver.resolveURI(src);
> > resolver.toSAX( srce, xc );
> > return xc;
> > }
> >
> > The component myXMLConsumer has a method public String
> > getDocument() ... mabe there is a better/more elegant way, but it
> > works for me ;-)
>
> nonono, careful. You are calling a pipeline to have its data as an
> object model to play with. While this is fair, I don't like it at all
> and would not want it included in system.js. It looks like an hack from
> miles away (sorry, no offense, just stating my impressions honestly)

I had the same impression but no idea of making it better. I'm looking
forward to reading your RT.
(I have no problem with other ideas and valuable feedback from people who
have the same/different needs - I think that's the big difference between
commercial software and open source software because commercial software is
nearly always focused and once written and working only reviewed if problems
arise.)

Therefore I'll come up with a solution of using the flow as controller for
XMLForms - a 'pre-alpha' version is already running at my laptop. I know
that my solution is far from being perfect (continuations can be very tricky
...) but I want to learn and the feedback will make me learn new things and
this will make our/my solutions better.

One note: If I look back the last two years it's really incredible what I
learned about design patterns (coming from the M$ visual programming world I
have never heard of it before), java programming, xml, xslt, ...  only by
studying Cocoon and Avalon concepts/source code/examples and
following/taking part in disussions. I don't know which university/school
can offer an education at this level - maybe I'm wrong.

What are the experiences of others?

Reinhard

>
> What I want is something different.
>
> I'll come up with an RT later today or tomorrow.
>
> For now, consider it separated from this vote since it has not been
> discussed well and I want more feedback on it.
>
> --
> Stefano Mazzocchi   <[EMAIL PROTECTED]>
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: top-level project?

[Steven Noels]

Stefano Mazzocchi wrote:


This has been on my post-it notes on my desktop for a while now... I 
think I'm too lazy sometimes, sorry.

don't we all? glad I could help out.

next steps:

 - submitting to board for review & approval before next Wednesday
 - suggestion to start a Wiki page for the Cocoon project bylaws
   - PMC chair & member renewal rules
   - subproject creation and management
   - http://jakarta.apache.org/avalon/pmc/ (specific bylaws on voting, 
dunnow if we need them over here)


--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: redefine the serializer parameters

[Vadim Gritsenko]

Yury,

What you want is not implmented as of today, but when it was discussed 
last time the outcome was that it can be implemented [1]. It just 
happened that nobody needed this urgenttly enough to jump in and implement.

Vadim

[1] http://marc.theaimsgroup.com/?t=10180675811&r=1&w=2



Yury Mikhienko wrote:

Hi all cocooners!

What you think about the following idea:

I want to  modify the serializer parameters localy (with the global serializer settings in sitemap)
For example:
now in root sitemap I have the following serializer settings:

 
   

   
 1024
 KOI8-R
   
  ...
 
  ...

in mounted sitemap I have a chance to redefine serializers:
   
   
   
 1024
 UTF-8
   
   
   

but this is global serializer definition for all pipelines on sitemap.
I want to redefine the serializer parameters in matching step, for example:
in mounted sitemap:

   
   
...
 
   
...
   
   
   
   
 UTF-8
   
  
...
 
   
   
   
   
  
...
   


Any suggestions?

 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [Fwd: [announce] Agora 1.1]

[Dirk-Willem van Gulik]

On Fri, 17 Jan 2003, Stefano Mazzocchi wrote:

> > - I assume that the three clouds represent the three mailing lists
> >   but I'm not sure which cloud is which list, so some more
> >   detailed information about the connections between the squares
> >   would be nice
>
> Good point, I'll try to work something out (I have a couple of simple
> ideas to try out)

Colour :-)

Dw.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/modules/input DigestMetaModule.java

[haul]

haul2003/01/17 05:58:53

  Modified:src/java/org/apache/cocoon/components/modules/input Tag:
cocoon_2_0_3_branch DigestMetaModule.java
  Log:
  Added new encoding formats for the returned hash
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.4.4.4   +112 -19   
xml-cocoon2/src/java/org/apache/cocoon/components/modules/input/DigestMetaModule.java
  
  Index: DigestMetaModule.java
  ===
  RCS file: 
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/components/modules/input/DigestMetaModule.java,v
  retrieving revision 1.4.4.3
  retrieving revision 1.4.4.4
  diff -u -r1.4.4.3 -r1.4.4.4
  --- DigestMetaModule.java 15 Jan 2003 16:15:35 -  1.4.4.3
  +++ DigestMetaModule.java 17 Jan 2003 13:58:53 -  1.4.4.4
  @@ -54,20 +54,26 @@
   import org.apache.avalon.framework.configuration.ConfigurationException;
   import org.apache.avalon.framework.thread.ThreadSafe;
   
  +import org.apache.cocoon.util.HashMap;
  +
   import java.net.URLEncoder;
   import java.security.MessageDigest;
   import java.security.NoSuchAlgorithmException;
   import java.security.NoSuchProviderException;
   import java.util.Iterator;
   import java.util.Map;
  +import java.io.UnsupportedEncodingException;
   
   /** Meta module that obtains values from other module and returns
* message digest of value. Very useful for storing and checking
* passwords. Input module configured through nested element
* "input-module", message digest algorithm, security provider, salt,
  - * and URL encoded output configurable through attributes
  - * "algorithm", "provider", "salt", "encode" of configuration root
  - * element. Defaults are "sha", null, "salt", and "false".
  + * and URL encoded output configurable through attributes "algorithm",
  + * "provider", "salt", "encode" of configuration root
  + * element. Defaults are "sha", null, "salt", and "false". Available
  + * value for encode are "none" (returns byte[]), "string" (return hash
  + * as string), "url" (returns url encoded string), "hex" (returns
  + * string of hex values).
*
* @author mailto:[EMAIL PROTECTED]";>Christian Haul
* @version CVS $Id$
  @@ -77,7 +83,31 @@
   private String defaultAlgorithm = "SHA";
   private String defaultProvider = null;
   private String defaultSalt = "salt";
  -private boolean defaultEncode = false;
  +private String defaultEncode = "false";
  +
  +/** output encoding none */
  +static final int ENCODING_NONE = 0;
  +/** output encoding url encoding */
  +static final int ENCODING_STR = 1;
  +/** output encoding hex */
  +static final int ENCODING_URL = 2;
  +/** output encoding hex */
  +static final int ENCODING_HEX = 3;
  +
  +private static final HashMap encodingNames;
  +/** setup mapping tables */
  +static {
  +HashMap names = new HashMap();
  +names.put("false", new Integer(ENCODING_NONE));
  +names.put("no", new Integer(ENCODING_NONE));
  +names.put("none", new Integer(ENCODING_NONE));
  +names.put("string", new Integer(ENCODING_STR));
  +names.put("yes", new Integer(ENCODING_URL));
  +names.put("true", new Integer(ENCODING_URL));
  +names.put("hex", new Integer(ENCODING_HEX));
  +encodingNames = names;
  +names = null;
  +}
   
   
   public void configure(Configuration config) throws ConfigurationException {
  @@ -87,7 +117,12 @@
   this.defaultAlgorithm = 
this.inputConf.getAttribute("algorithm",this.defaultAlgorithm);
   this.defaultProvider = 
this.inputConf.getAttribute("provider",this.defaultProvider);
   this.defaultSalt = this.inputConf.getAttribute("salt",this.defaultSalt);
  -this.defaultEncode = 
this.inputConf.getAttributeAsBoolean("encode",this.defaultEncode);
  +this.defaultEncode = this.inputConf.getAttribute("encode","false");
  +if (this.encodingNames.get(this.defaultEncode) == null) {
  +if (getLogger().isErrorEnabled())
  +getLogger().error("Requested encoding is unknown: 
"+this.defaultEncode);
  +this.defaultEncode="false";
  +}
   }
   
   
  @@ -110,7 +145,7 @@
   String algorithm = this.defaultAlgorithm;
   String provider  = this.defaultProvider;
   String salt  = this.defaultSalt;
  -boolean encode = this.defaultEncode;
  +int encode = ((Integer) encodingNames.get(this.defaultEncode)).intValue();
   if (modeConf!=null) {
   inputName   = 
modeConf.getChild("input-module").getAttribute("name",null);
   if (inputName != null) {
  @@ -120,7 +155,7 @@
   algorithm = modeConf.getAttribute("algorithm", algorithm);
   provider  = modeConf.getAttribute("provider" , provider );
   

Re: [vote] finilizing the pending votes on flow [was Re: [RT] Flow/SitemapIntegration]

[Ugo Cei]

Reinhard Poetz wrote:

Therefore I'll come up with a solution of using the flow as controller for
XMLForms - a 'pre-alpha' version is already running at my laptop. I know
that my solution is far from being perfect (continuations can be very tricky
...) but I want to learn and the feedback will make me learn new things and
this will make our/my solutions better.


Do you mean something like this?

var form = getForm("progetto-form", progetto,
	"context://flows/workflow-schema.xml");
while (true) {
	form.save(cocoon.environment.getObjectModel(), "request");
	sendPageAndWait("progetto-form",  { "username" : user.name });
	form.populate(cocoon.environment.getObjectModel());
	form.validate("progetto");
	if (form.getViolations() != null &&
	form.getViolations().size() > 0) {
		continue;
	break;
}


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

[GUMP] Build Failure - xml-cocoon2

[Sam Ruby]

This email is autogenerated from the output from:
<http://cvs.apache.org/builds/gump/2003-01-17/xml-cocoon2.html>


Buildfile: build.xml

init:
 [echo] --
 [echo] Apache Cocoon 20030117 [1999-2003]  
 [echo] --
 [echo] Building with Apache Ant version 1.6alpha compiled on January 17 2003
 [echo] using build file /home/rubys/jakarta/xml-cocoon2/build.xml
 [echo] --
 [echo]  WARNING: 
 [echo]This build is targeted for use with JVM 1.4
 [echo]   
 [echo]Using this build on a virtual machine other than the one   
 [echo]it is targeted for may result in runtime errors.  
 [echo]   
 [echo] --
  [taskdef] dropping /home/rubys/php/lib/php/phpsrvlt.jar from path as it doesn't exist
  [taskdef] dropping /home/rubys/jakarta/xml-cocoon2/build/cocoon/classes from path as 
it doesn't exist
  [taskdef] dropping /home/rubys/jakarta/xml-cocoon2/tools/anttasks from path as it 
doesn't exist
[mkdir] Created dir: /home/rubys/jakarta/xml-cocoon2/tools/anttasks
[javac] Compiling 2 source files to /home/rubys/jakarta/xml-cocoon2/tools/anttasks
[javac] 9 warnings

optional-tests:
 [echo] Testing for optional components

bsf-warn:

op-warning:
 [echo] **
 [echo] *
 [echo] *  Classes of the optional package BSF are not 
 [echo] *  available. Apache Cocoon builds without them.
 [echo] *
 [echo] *  BSF is required for the script action.
 [echo] *
 [echo] *  Recovery:
 [echo] *  Get the BSF package from 
http://oss.software.ibm.com/developerworks/projects/bsf/ and place the jar in the 
lib/optional dir
 [echo] *
 [echo] ***

rhino-warn:

jfor-warn:

op-warning:
 [echo] **
 [echo] *
 [echo] *  Classes of the optional package JFOR are not 
 [echo] *  available. Apache Cocoon builds without them.
 [echo] *
 [echo] *  JFOR is required for the fo2rtf serializer.
 [echo] *
 [echo] *  Recovery:
 [echo] *  Get the JFOR package from http://www.jfor.org/ and place the jar in the 
lib/optional dir
 [echo] *
 [echo] ***

xmldb-warn:

php-warn:

op-warning:
 [echo] **
 [echo] *
 [echo] *  Classes of the optional package PHP are not 
 [echo] *  available. Apache Cocoon builds without them.
 [echo] *
 [echo] *  PHP is required for the php generator.
 [echo] *
 [echo] *  Recovery:
 [echo] *  Get the PHP servlet (phpsrvlt.jar) from http://www.php.net/ and place 
the jar in the lib/optional dir
 [echo] *
 [echo] ***

naming-warn:

svg-warn:

op-warning:
 [echo] **
 [echo] *
 [echo] *  Classes of the optional package Batik are not 
 [echo] *  available. Apache Cocoon builds without them.
 [echo] *
 [echo] *  Batik is required for the svg serializers.
 [echo] *
 [echo] *  Recovery:
 [echo] *  Get Batik from http://xml.apache.org/batik/ and place the jar in the 
lib/optional dir
 [echo] *
 [echo] ***

tidy-warn:

op-warning:
 [echo] **
 [echo] *
 [echo] *  Classes of the optional package JTidy are not 
 [echo] *  available. Apache Cocoon builds without them.
 [echo] *
 [echo] *  JTidy is required for the html generator.
 [echo] *
 [echo] *  Recovery:
 [echo] *  Get JTidy from http://sourceforge.net/projects/jtidy/ and place the jar 
in the lib/optional dir
 [echo] *
 [echo] ***

maybeupload-warn:

lucene-warn:

op-warning:
 [echo] **
 [echo] *
 [echo] *  Classes of the optional package Lucene are not 
 [echo] *  available. Apache Cocoon builds without them.
 [echo] *
 [echo] *  Lucene is required for the Cocoon searches.
 [echo] *
 [echo] *  Recovery:
 [echo] *  Get Lucene from http://jakarta.apache.org/lucene/ and place the jar in 
the lib/optional dir
 [echo] *
 [echo] ***

deli-warn:

velocity-warn:

o

DO NOT REPLY [Bug 9075] - [PATCH] Contribution of SAP R/3(r) connectivity components

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=9075

[PATCH] Contribution of SAP R/3(r) connectivity components

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-01-17 11:46 
---
Added to 2.1 -- please check and close bug report

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [vote] finilizing the pending votes on flow [was Re: [RT] Flow/SitemapIntegration]

[Ugo Cei]

[I'm resending this, since the first time I managed to inadvertently cut 
the last part of the message.]

Reinhard Poetz wrote:

> Therefore I'll come up with a solution of using the flow as 
controller for
> XMLForms - a 'pre-alpha' version is already running at my laptop. I  know
> that my solution is far from being perfect (continuations can be very 
tricky
> ...) but I want to learn and the feedback will make me learn new 
things and
> this will make our/my solutions better.

Do you mean something like this?

var form = getForm("progetto-form", progetto,
"context://flows/workflow-schema.xml");
while (true) {
form.save(cocoon.environment.getObjectModel(), "request");
sendPageAndWait("progetto-form",  { "username" : user.name });
form.populate(cocoon.environment.getObjectModel());
form.validate("progetto");
if (form.getViolations() != null &&
form.getViolations().size() > 0) {
continue;
break;
}

I'm working on this for a customer. At the moment it basically works for 
single page forms, but there's a lot of code duplication that I'd like 
to factor out before submitting anything to the public.

How about joining efforts instead of duplicating them?

	Ugo


--
Ugo Cei - http://www.beblogging.com/blog/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: [vote] finilizing the pending votes on flow [was Re: [RT] Flow/SitemapIntegration]

[Reinhard Poetz]

> > For my flows I use a self-defined function which makes this for me:
> >
> > function callPipeline(src) {
> > xc = cocoon.componentManager.lookup( myXMLConsumer.ROLE );
> > resolver =
> cocoon.environment.getObjectModel().get("source-resolver");
> > srce = resolver.resolveURI(src);
> > resolver.toSAX( srce, xc );
> > return xc;
> > }
> >
> > The component myXMLConsumer has a method public String
> > getDocument() ... mabe there is a better/more elegant way, but it
> > works for me ;-)
>
> nonono, careful. You are calling a pipeline to have its data as an
> object model to play with. While this is fair, I don't like it at all
> and would not want it included in system.js. It looks like an hack from
> miles away (sorry, no offense, just stating my impressions honestly)

After having a second look at my sources I think I don't really need the
part generating the string. This would reduce it to following lines:

function callPipeline( src ) {
  var xc = cocoon.componentManager.lookup( anyXMLConsumer.ROLE );
  var resolver = cocoon.environment.getObjectModel().get(
"source-resolver" );
  var srce = resolver.resolveURI( src );
  resolver.toSAX( srce, xc );
}

Then the pipeline called with "src" makes everything on its own.
  1. gather the necessary information from somewhere (input modules,
database, ...)
  2. save the information (send a mail, write to cvs, write to disc, ...)

There remains one open question for me: How to I get 'feedback' whether the
called pipeline did its job well or not? And if not, how to I get
information about what happend (error message/status information)?

What do you think?

Reinhard







-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

[GUMP] Build Failure - xml-cocoon2

[Sam Ruby]

This email is autogenerated from the output from:



Buildfile: build.xml

init:
 [echo] --
 [echo] Apache Cocoon 20030116 [1999-2003]  
 [echo] --
 [echo] Building with Apache Ant version 1.5.2alpha compiled on January 17 2003
 [echo] using build file /home/bodewig/dev/gump/xml-cocoon2/build.xml
 [echo] --
 [echo]  WARNING: 
 [echo]This build is targeted for use with JVM 1.4
 [echo]   
 [echo]Using this build on a virtual machine other than the one   
 [echo]it is targeted for may result in runtime errors.  
 [echo]   
 [echo] --
[mkdir] Created dir: /home/bodewig/dev/gump/xml-cocoon2/tools/anttasks
[javac] Compiling 2 source files to 
/home/bodewig/dev/gump/xml-cocoon2/tools/anttasks

optional-tests:
 [echo] Testing for optional components

bsf-warn:

op-warning:
 [echo] **
 [echo] *
 [echo] *  Classes of the optional package BSF are not 
 [echo] *  available. Apache Cocoon builds without them.
 [echo] *
 [echo] *  BSF is required for the script action.
 [echo] *
 [echo] *  Recovery:
 [echo] *  Get the BSF package from 
http://oss.software.ibm.com/developerworks/projects/bsf/ and place the jar in the 
lib/optional dir
 [echo] *
 [echo] ***

rhino-warn:

jfor-warn:

op-warning:
 [echo] **
 [echo] *
 [echo] *  Classes of the optional package JFOR are not 
 [echo] *  available. Apache Cocoon builds without them.
 [echo] *
 [echo] *  JFOR is required for the fo2rtf serializer.
 [echo] *
 [echo] *  Recovery:
 [echo] *  Get the JFOR package from http://www.jfor.org/ and place the jar in the 
lib/optional dir
 [echo] *
 [echo] ***

xmldb-warn:

php-warn:

op-warning:
 [echo] **
 [echo] *
 [echo] *  Classes of the optional package PHP are not 
 [echo] *  available. Apache Cocoon builds without them.
 [echo] *
 [echo] *  PHP is required for the php generator.
 [echo] *
 [echo] *  Recovery:
 [echo] *  Get the PHP servlet (phpsrvlt.jar) from http://www.php.net/ and place 
the jar in the lib/optional dir
 [echo] *
 [echo] ***

naming-warn:

svg-warn:

op-warning:
 [echo] **
 [echo] *
 [echo] *  Classes of the optional package Batik are not 
 [echo] *  available. Apache Cocoon builds without them.
 [echo] *
 [echo] *  Batik is required for the svg serializers.
 [echo] *
 [echo] *  Recovery:
 [echo] *  Get Batik from http://xml.apache.org/batik/ and place the jar in the 
lib/optional dir
 [echo] *
 [echo] ***

tidy-warn:

op-warning:
 [echo] **
 [echo] *
 [echo] *  Classes of the optional package JTidy are not 
 [echo] *  available. Apache Cocoon builds without them.
 [echo] *
 [echo] *  JTidy is required for the html generator.
 [echo] *
 [echo] *  Recovery:
 [echo] *  Get JTidy from http://sourceforge.net/projects/jtidy/ and place the jar 
in the lib/optional dir
 [echo] *
 [echo] ***

maybeupload-warn:

lucene-warn:

op-warning:
 [echo] **
 [echo] *
 [echo] *  Classes of the optional package Lucene are not 
 [echo] *  available. Apache Cocoon builds without them.
 [echo] *
 [echo] *  Lucene is required for the Cocoon searches.
 [echo] *
 [echo] *  Recovery:
 [echo] *  Get Lucene from http://jakarta.apache.org/lucene/ and place the jar in 
the lib/optional dir
 [echo] *
 [echo] ***

deli-warn:

velocity-warn:

op-warning:
 [echo] **
 [echo] *
 [echo] *  Classes of the optional package Velocity are not 
 [echo] *  available. Apache Cocoon builds without them.
 [echo] *
 [echo] *  Velocity is required for the velocity generator.
 [echo] *
 [echo] *  Recovery:
 [echo] *  Get Velocity from http://jakarta.apache.org/velocity/ and place the jar 
in t

cvs commit: xml-cocoon2/src/documentation/xdocs/developing web3.xml book.xml

[haul]

haul2003/01/17 06:18:03

  Modified:src/documentation/xdocs/developing book.xml
  Added:   src/documentation/xdocs/developing web3.xml
  Log:
  docs for web3
  
  Revision  ChangesPath
  1.12  +4 -0  xml-cocoon2/src/documentation/xdocs/developing/book.xml
  
  Index: book.xml
  ===
  RCS file: /home/cvs/xml-cocoon2/src/documentation/xdocs/developing/book.xml,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- book.xml  1 Jul 2002 19:53:45 -   1.11
  +++ book.xml  17 Jan 2003 14:18:02 -  1.12
  @@ -23,6 +23,10 @@
   
 
   
  +  
  +
  +  
  +
 
   
 
  
  
  
  1.1  xml-cocoon2/src/documentation/xdocs/developing/web3.xml
  
  Index: web3.xml
  ===
  
  
  

Web3
Web3 Connectivity Toolkit







http://www.efp.cc/web3";>EFP Consulting 
Austria produced an open-source library called Web3
that allows you to integrate SAP R/3 seamlessly into 
Cocoon 2. With these components you are able to call Remote 
Function Calls via an easy to use XML-syntax. For most 
BAPIs and Remote enabled Function Calls you simply need 
a text editor.

This toolkit offers you ...

... synchron communication to any SAP 
system above release 3.1H.
... easy to use ABAP function calls from 
outside R/3 with a se37-like markup-syntax.


The following guide helps you to setup cocoon with 
your SAP R/3. Reasonably this guide cannot answer
all questions dealing with your environment. For 
further questions be advised to contact your favorite SAP Consultant.




Be sure to proper install the appropriate SAP 
Java-Connector from http://service.sap.com/connectors";>
www.sap.com. To install the connector 
refer to the included documentations.




With Web3 you have a flexible Toolkit where 
you can connect to multiple R/3 System within one single Cocoon-
Instance. Enter your backend configuration 
into cocoon.xconf like this:



Configuration elements

Element
Description


web3
Declare your logger here.


pool
The pool element is the logical 
unit of all your SAP settings.


client
The systems client you log 
onto.


user, password, language
...


route
The route to your SAP system. 
Please refer to your http://help.sap.com";>SAP help to prepare the 
connection string.


system
The system-number of your SAP 
system you log onto.


gateway, program-id
Are mandatory and not used within 
Web3's szenario.

RE: [vote] finilizing the pending votes on flow [was Re: [RT] Flow/SitemapIntegration]

[Reinhard Poetz]

Ugo Cei wrote:
>
>
> Reinhard Poetz wrote:
> > Therefore I'll come up with a solution of using the flow as
> controller for
> > XMLForms - a 'pre-alpha' version is already running at my laptop. I know
> > that my solution is far from being perfect (continuations can
> be very tricky
> > ...) but I want to learn and the feedback will make me learn
> new things and
> > this will make our/my solutions better.
>
> Do you mean something like this?
>
> var form = getForm("progetto-form", progetto,
>   "context://flows/workflow-schema.xml");
> while (true) {
>   form.save(cocoon.environment.getObjectModel(), "request");
>   sendPageAndWait("progetto-form",  { "username" : user.name });
>   form.populate(cocoon.environment.getObjectModel());
>   form.validate("progetto");
>   if (form.getViolations() != null &&
>   form.getViolations().size() > 0) {
>   continue;
>   break;
> }
>


Yes. (Additionally?) I use continuations to move forward/backward within the
flow. This works well but sometimes I get some strange results after using
the previous/next button of the *browser*.
My next step will be controlling Ivelin's XMLForm example with a flow
script. If this works I'll submit a patch that enables others to have a look
at it.

Reinhard




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: xml-cocoon2/src/blocks/databases/samples/tutorial - New directory

[haul]

haul2003/01/17 06:25:34

  xml-cocoon2/src/blocks/databases/samples/tutorial - New directory

--
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/blocks/databases/samples/tutorial/docs - New directory

[haul]

haul2003/01/17 06:25:50

  xml-cocoon2/src/blocks/databases/samples/tutorial/docs - New directory

--
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/blocks/databases/samples/tutorial/stylesheets - New directory

[haul]

haul2003/01/17 06:25:50

  xml-cocoon2/src/blocks/databases/samples/tutorial/stylesheets - New directory

--
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/blocks/databases/samples/tutorial/resources - New directory

[haul]

haul2003/01/17 06:25:50

  xml-cocoon2/src/blocks/databases/samples/tutorial/resources - New directory

--
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/blocks/databases/samples/tutorial/stylesheets/system - New directory

[haul]

haul2003/01/17 06:26:02

  xml-cocoon2/src/blocks/databases/samples/tutorial/stylesheets/system - New directory

--
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/blocks/databases/samples/tutorial/docs/dtd - New directory

[haul]

haul2003/01/17 06:26:02

  xml-cocoon2/src/blocks/databases/samples/tutorial/docs/dtd - New directory

--
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/blocks/databases/samples/tutorial/resources/images - New directory

[haul]

haul2003/01/17 06:26:02

  xml-cocoon2/src/blocks/databases/samples/tutorial/resources/images - New directory

--
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/webapp/samples/tutorial/docs/dtd changes-v10.dtd characters.ent document-v10.dtd faq-v10.dtd javadoc-v04draft.dtd specification-v10.dtd todo-v10.dtd

[haul]

haul2003/01/17 06:30:55

  Removed: src/webapp/samples/tutorial menu.xml sitemap.xmap
   src/webapp/samples/tutorial/stylesheets apache.xsl
   src/webapp/samples/tutorial/stylesheets/system
error2document.xsl
   src/webapp/samples/tutorial/resources/images
bar-border-bottom.gif bar-border-left.gif
bar-border-right.gif bar-border-top.gif
bar-bottom-left.gif bar-bottom-right.gif
bar-top-left.gif bar-top-right.gif bottom.gif
button-asf-hi.gif button-asf-lo.gif
button-w3c-hi.gif button-w3c-lo.gif
button-xml-hi.gif button-xml-lo.gif close.gif
dot.gif join.gif line.gif logo.gif note.gif
right.gif separator.gif void.gif
   src/webapp/samples/tutorial/docs confirm-dept.xsp
confirm-empl.xsp create-dept.xsp create-empl.xsp
department-form.xml edit-dept.xsp edit-empl.xsp
employee-form.xml home.xml results-dept.xsp
results-empl.xsp search-dept.xsp search-empl.xsp
   src/webapp/samples/tutorial/docs/dtd changes-v10.dtd
characters.ent document-v10.dtd faq-v10.dtd
javadoc-v04draft.dtd specification-v10.dtd
todo-v10.dtd
  Log:
  move also database tutorial to block
  note: the tutorial is broken because of 
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9835
   ([2.1] Nested actions in action-sets do not execute)

--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail:  [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Instrumentation client in Cocoon CVS ?

[Frank Taffelt]

Hi Markus,

i tried out the instrumention client. After making the the required changes
in web.xml
and restarting tomcat i get the following message from cocoon:

[ERROR] Unexpected IOE in StreamServerConnection #1
java.io.InvalidClassException:
org.apache.excalibur.altrmi.common.OpenConnection
Request; local class incompatible: stream classdesc serialVersionUID
= -29042861
24933186290, local class serialVersionUID = 1773735791378198918
at
java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:454)
at
java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:151
1)
at
java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1425)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1
616)
at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1264)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:322)
at
org.apache.excalibur.altrmi.common.SerializationHelper.getInstanceFro
mBytes(SerializationHelper.java:94)
at
org.apache.excalibur.altrmi.common.SerializationHelper.getInstanceFro
mBytes(SerializationHelper.java:71)
at
org.apache.excalibur.altrmi.server.impl.ServerCustomStreamReadWriter.
readRequest(ServerCustomStreamReadWriter.java:84)
at
org.apache.excalibur.altrmi.server.impl.ServerCustomStreamReadWriter.
writeReplyAndGetRequest(ServerCustomStreamReadWriter.java:46)
at
org.apache.excalibur.altrmi.server.impl.StreamServerConnection.run(St
reamServerConnection.java:91)
at java.lang.Thread.run(Thread.java:536)


the instrumentation client shows [Not Connected] after trying to establish a
connection to localhost on port 1. Any ideas ?

Frank


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Instrumentation client in Cocoon CVS ?

[Marcus Crafter]

Hi Frank,

Thanks for the information mate. Can you please let me know what JDK 
version you are using with the instrumentation client, and with your
servlet environment when running Cocoon ?

Thanks, once I get your info, I'll see if I can reproduce the
problem locally, and fix it.

Cheers,

Marcus

On Fri, Jan 17, 2003 at 03:31:17PM +0100, Frank Taffelt wrote:
> Hi Markus,
> 
> i tried out the instrumention client. After making the the required changes
> in web.xml
> and restarting tomcat i get the following message from cocoon:
> 
> [ERROR] Unexpected IOE in StreamServerConnection #1
> java.io.InvalidClassException:
> org.apache.excalibur.altrmi.common.OpenConnection
> Request; local class incompatible: stream classdesc serialVersionUID
> = -29042861
> 24933186290, local class serialVersionUID = 1773735791378198918
> at
> java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:454)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:151
> 1)
> at
> java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1425)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1
> 616)
> at
> java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1264)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:322)
> at
> org.apache.excalibur.altrmi.common.SerializationHelper.getInstanceFro
> mBytes(SerializationHelper.java:94)
> at
> org.apache.excalibur.altrmi.common.SerializationHelper.getInstanceFro
> mBytes(SerializationHelper.java:71)
> at
> org.apache.excalibur.altrmi.server.impl.ServerCustomStreamReadWriter.
> readRequest(ServerCustomStreamReadWriter.java:84)
> at
> org.apache.excalibur.altrmi.server.impl.ServerCustomStreamReadWriter.
> writeReplyAndGetRequest(ServerCustomStreamReadWriter.java:46)
> at
> org.apache.excalibur.altrmi.server.impl.StreamServerConnection.run(St
> reamServerConnection.java:91)
> at java.lang.Thread.run(Thread.java:536)
> 
> 
> the instrumentation client shows [Not Connected] after trying to establish a
> connection to localhost on port 1. Any ideas ?
> 
> Frank
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 

-- 
.
 ,,$,  Marcus Crafter
;$'  ':Computer Systems Engineer
$: :   ManageSoft GmbH
 $   o_)$$$:   82-84 Mainzer Landstrasse
 ;$,_/\ &&:'   60327 Frankfurt Germany
   ' /( &&&
   \_'
  .
&&&:

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Instrumentation client in Cocoon CVS ?

[Frank Taffelt]

- Original Message - 
From: "Marcus Crafter" <[EMAIL PROTECTED]>
To: "Frank Taffelt" <[EMAIL PROTECTED]>
Cc: "Cocoon Developers Mailing List" <[EMAIL PROTECTED]>
Sent: Friday, January 17, 2003 3:58 PM
Subject: Re: Instrumentation client in Cocoon CVS ?


> Hi Frank,
> 
> Thanks for the information mate. Can you please let me know what JDK 
> version you are using with the instrumentation client, and with your
> servlet environment when running Cocoon ?

cocoon is fresh check out from today.

java -version :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

tomcat version:
Tomcat 4.1.18-LE-jdk14

good hunt ;-)

Frank





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [vote] finilizing the pending votes on flow [was Re: [RT] Flow/SitemapIntegration]

[Sylvain Wallez]

Stefano Mazzocchi wrote:


Sylvain Wallez wrote:


Sorry to jump in lately, but the "vote" made me consider that thread 
as important and I finally looked at it. So here we go...


Which was the reason to call for a vote even if the discussion is not 
yet finalized :-)

I do know how lazy you people are :-) (oh, just because I'm even worse)


You got me ;-)




Now, do you propose we change "pipelines/pipeline" with 
"processes/process"?

Besides the huge back compatibility effort of migration (not only 
code, but user knowledge), I don't find myself resonating with the 
concept of "process" since "pipeline" is... well... more fun :)

I mean, pipelines are something that cocoon was first to introduce in 
the xml server side world. Maybe it doesn't make sense from a purely 
core-up technological perspective, but it should does make sense from 
a user-reading-a-simple-sitemap-for-the-first-time point of view.

And, to be honest, I care about the second more than about the 
elegance of the first.

Do you see my point?


Sure ! But then you have to be prepared to see this kind of discussion 
coming again periodically.



yes, I see your point, even if, again, it's a technologically-driven 
perspective and will only confuse people before normal matching and 
super-selective matching. You know to know a lot about the internals 
to understand this can't we make it an internal transparent 
optimization of the sitemap interpreter? doesn't seem that hard.


Sure, it can be totally hidden behind the current  syntax, 
by allowing it to handle a new kind of selector (we already have 2 : 
Selector and SwitchSelector).


Also (but this may be a spec detail), I've not seen how variables set 
by matchers in "map:map" are made available to the flow function.


YES! That's it. That's what I couldn't see but perceived as wrong.

This leads a pretty solid -1 to the use of 



Wow !


"map:mount", "map:handle-errors"

"map:mount" is used to call a subsitemap, but _what_ is called in 
that subsitemap ?
- a flow ? Then "map:mount" should be in the "map:flowmap".
- a pipeline ? Then it should be in "map:pipeline".

Same for "map:handle-errors" : how exceptions thrown by a flow 
function are to be handled ?

So we end up with a lot of statements being equally applicable to 
"map:flowmap" and "map:pipeline".


Yes, I think I'm pretty much settled that we should not have two 
different semantics for pipelines and flows. I hear Sylvain about 
 being really the problem but I can't think of a better term 
myself and process really sucks.


So let's keep pipeline, but please add a FAQ entry about this ;-)




I like the underlying concepts, but I think that:

1) I don't like "process" enough and I don't think we have that much 
of an urge to change the semantics at that deep level.

2) the super-selector should be implicit (Berin proposed something 
along these lines a while ago)

Ah, and I have no objection for "cocoon:" calling scripts, and would 
love to call a pipeline with a different output stream !


Cool, but let's make it another vote.



OK. So we have some strong and justified -1's against ...

Sylvain

--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: xml-cocoon2/tools/instrumentation/lib excalibur-altrmi-client-impl-20030116.jar excalibur-altrmi-client-interfaces-20030116.jar excalibur-altrmi-common-20030116.jar excalibur-instrument-client-20030116.jar excalibur-instrument-manager-interfaces-20030116.jar

[crafterm]

crafterm2003/01/17 08:03:31

  Modified:lib/core excalibur-instrument-20021108.jar
excalibur-instrument-manager-20021108.jar
excalibur-instrument-manager-interfaces-20021108.jar
   lib/optional excalibur-altrmi-common-20030116.jar
excalibur-altrmi-registry-20030116.jar
excalibur-altrmi-server-impl-20030116.jar
excalibur-altrmi-server-interfaces-20030116.jar
   tools/instrumentation/lib
excalibur-altrmi-client-impl-20030116.jar
excalibur-altrmi-client-interfaces-20030116.jar
excalibur-altrmi-common-20030116.jar
excalibur-instrument-client-20030116.jar
excalibur-instrument-manager-interfaces-20030116.jar
  Log:
  Updated instrumentation and altrmi jars to fix altrmi connection errors
  between Cocoon and instrumentation client.
  
  Revision  ChangesPath
  1.3   +52 -39xml-cocoon2/lib/core/excalibur-instrument-20021108.jar
  
<>
  
  
  1.3   +90 -91xml-cocoon2/lib/core/excalibur-instrument-manager-20021108.jar
  
<>
  
  
  1.3   +36 -36
xml-cocoon2/lib/core/excalibur-instrument-manager-interfaces-20021108.jar
  
<>
  
  
  1.2   +134 -134  xml-cocoon2/lib/optional/excalibur-altrmi-common-20030116.jar
  
<>
  
  
  1.2   +15 -15xml-cocoon2/lib/optional/excalibur-altrmi-registry-20030116.jar
  
<>
  
  
  1.2   +124 -124  
xml-cocoon2/lib/optional/excalibur-altrmi-server-impl-20030116.jar
  
<>
  
  
  1.2   +44 -44
xml-cocoon2/lib/optional/excalibur-altrmi-server-interfaces-20030116.jar
  
<>
  
  
  1.2   +170 -170  
xml-cocoon2/tools/instrumentation/lib/excalibur-altrmi-client-impl-20030116.jar
  
<>
  
  
  1.2   +44 -44
xml-cocoon2/tools/instrumentation/lib/excalibur-altrmi-client-interfaces-20030116.jar
  
<>
  
  
  1.2   +294 -292  
xml-cocoon2/tools/instrumentation/lib/excalibur-altrmi-common-20030116.jar
  
<>
  
  
  1.2   +226 -226  
xml-cocoon2/tools/instrumentation/lib/excalibur-instrument-client-20030116.jar
  
<>
  
  
  1.2   +36 -36
xml-cocoon2/tools/instrumentation/lib/excalibur-instrument-manager-interfaces-20030116.jar
  
<>
  
  

--
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/blocks/batik/java/org/apache/cocoon/xml/dom SVGBuilder.java

[huber]

huber   2003/01/17 09:23:08

  Modified:src/blocks/batik/java/org/apache/cocoon/xml/dom
SVGBuilder.java
  Log:
  fix namespace, tie svg to SVG namespace http://www.w3.org/2000/svg
  
  Revision  ChangesPath
  1.4   +5 -1  
xml-cocoon2/src/blocks/batik/java/org/apache/cocoon/xml/dom/SVGBuilder.java
  
  Index: SVGBuilder.java
  ===
  RCS file: 
/home/cvs/xml-cocoon2/src/blocks/batik/java/org/apache/cocoon/xml/dom/SVGBuilder.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- SVGBuilder.java   7 Jan 2003 23:56:08 -   1.3
  +++ SVGBuilder.java   17 Jan 2003 17:23:08 -  1.4
  @@ -111,6 +111,10 @@
   String namespaceURI = SVGDOMImplementation.SVG_NAMESPACE_URI;
   this.document = implementation.createDocument(namespaceURI, "svg", 
null);
   super.startDocument();
  +// add svg, and SVG_NAMESPACE to SAXDocumentFactory namespace handling
  +// this is a fix only ties svg to svg namespace uri
  +// it is not as general as tieing any prefix to svg namespace uri
  +namespaces.put("svg", SVGDOMImplementation.SVG_NAMESPACE_URI);
   } catch (Exception ex){
   log.error("SVGBuilder: startDocument", ex);
   ex.printStackTrace();
  
  
  

--
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/webapp/samples sitemap.xmap

[huber]

huber   2003/01/17 09:28:53

  Modified:src/webapp/samples sitemap.xmap
  Log:
  use samples.xml as used on samples/welcome page
  
  Revision  ChangesPath
  1.26  +1 -1  xml-cocoon2/src/webapp/samples/sitemap.xmap
  
  Index: sitemap.xmap
  ===
  RCS file: /home/cvs/xml-cocoon2/src/webapp/samples/sitemap.xmap,v
  retrieving revision 1.25
  retrieving revision 1.26
  diff -u -r1.25 -r1.26
  --- sitemap.xmap  17 Jan 2003 11:29:22 -  1.25
  +++ sitemap.xmap  17 Jan 2003 17:28:53 -  1.26
  @@ -390,7 +390,7 @@
   
   
  
  -
  +
   
   
   

Re: [CVS] - A rare message when downloading....

[Antonio Gallardo]

Thanks Steve.

Antonio Gallardo.

Steven Noels dijo:
> Antonio Gallardo wrote:
>
>> Hi Steve:
>>
>> Sorry, but I dont understand the point. :-(
>>
>> Vadim told me that:
>>
>> "Conflict. Rename your .cvsignore, checkout, then you can merge." Then
>> I saw the file there in the cvs site. I dont understand if this is
>> correct or not.
>
> It is.
>
> You modified your local .cvsignore file, and CVS wasn't able to
> automagically merge with an updated version of .cvsignore from the
> repository.
>
> So Vadim suggested to rename your local copy so that it isn't in the way
>  anymore, 'cvs update' so that you get the repository version of the
> file, and then you can manually merge the differences between both.
> There even exist conflict editors for such a purpose:
> http://sourceforge.net/projects/conflicteditor
>
> HTH,
>
> 
> --
> Steven Noelshttp://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> Read my weblog athttp://blogs.cocoondev.org/stevenn/
> stevenn at outerthought.orgstevenn at apache.org
>
>
> - 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: Samples samples/welcome-svg working?

[Bernhard Huber]

hi,

David Crossley wrote:

Bernhard Huber wrote:





Yes Bernhard, i can confirm that the samples/welcome-svg
(Samples => More Samples => Static Content => SVG Welcome Page)
does *not* work. The main part of the page is blank. When
the mouse runs over the page then the URLs do properly appear
in the browser status bar. Some of those links are broken too.
--David

i

i have update SVGBuilder.java in blocks batik

the solution was to let batik know that
svg may be a prefix for namespace uri http://www.w3.org/2000/svg

any confirmation for fixing would be nice,

moreover changed in sitemap.xmap using samples.xml displaying
all the links as in samples/welcome

added bug http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15638
to this problem

bernhard



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Instrumentation client in Cocoon CVS ?

[Marcus Crafter]

Hi All,

Just reporting back for anyone else watching this thread. Frank
and I have done some offline testing and everything seems to be
working now. The problem seemed to be in differing versions of
altrmi jars.

Hope everyone has a nice weekend! :)

Cheers,

Marcus

On Fri, Jan 17, 2003 at 04:03:00PM +0100, Frank Taffelt wrote:
> 
> - Original Message - 
> From: "Marcus Crafter" <[EMAIL PROTECTED]>
> To: "Frank Taffelt" <[EMAIL PROTECTED]>
> Cc: "Cocoon Developers Mailing List" <[EMAIL PROTECTED]>
> Sent: Friday, January 17, 2003 3:58 PM
> Subject: Re: Instrumentation client in Cocoon CVS ?
> 
> 
> > Hi Frank,
> > 
> > Thanks for the information mate. Can you please let me know what JDK 
> > version you are using with the instrumentation client, and with your
> > servlet environment when running Cocoon ?
> 
> cocoon is fresh check out from today.
> 
> java -version :
> java version "1.4.0"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
> Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)
> 
> tomcat version:
> Tomcat 4.1.18-LE-jdk14
> 
> good hunt ;-)
> 
> Frank
> 
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 

-- 
.
 ,,$,  Marcus Crafter
;$'  ':Computer Systems Engineer
$: :   ManageSoft GmbH
 $   o_)$$$:   82-84 Mainzer Landstrasse
 ;$,_/\ &&:'   60327 Frankfurt Germany
   ' /( &&&
   \_'
  .
&&&:

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [vote] finilizing the pending votes on flow [was Re: [RT] Flow/Sitemap Integration]

[Michael Melhem]

On Fri, Jan 17, 2003 at 04:20:17PM +0100, Sylvain Wallez wrote:
> Stefano Mazzocchi wrote:
> 
> >Sylvain Wallez wrote:
> >
> >Yes, I think I'm pretty much settled that we should not have two 
> >different semantics for pipelines and flows. I hear Sylvain about 
> > being really the problem but I can't think of a better term 
> >myself and process really sucks.
> 
> 
> So let's keep pipeline, but please add a FAQ entry about this ;-)
> 
> 
> 
> >I like the underlying concepts, but I think that:
> >
> >1) I don't like "process" enough and I don't think we have that much 
> >of an urge to change the semantics at that deep level.
> >
> >2) the super-selector should be implicit (Berin proposed something 
> >along these lines a while ago)
> >
> >>Ah, and I have no objection for "cocoon:" calling scripts, and would 
> >>love to call a pipeline with a different output stream !
> >
> >
> >Cool, but let's make it another vote.
> 
> 
> OK. So we have some strong and justified -1's against ...

Yes your argument is convincing, so perhaps we should put 
the flowmap issue on the back-burner .. ;)

One small point though, I still think flow differs from a pipeline
because it contains information at more abstract level. As I noted
earlier, IMHO a pipelines purpose regardless of redirects, forwardings, or
actions is to describe a single "resource". While a flow describes 
a logical set of "resources"...

Anyway, its time for weekend. :) 

regards,
Michael

> 
> Sylvain
> 
> -- 
> Sylvain Wallez  Anyware Technologies
> http://www.apache.org/~sylvain   http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
> 
> 
> 
> -
> 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: [vote] finilizing the pending votes on flow [was Re: [RT] Flow/SitemapIntegration]

[Sylvain Wallez]

Michael Melhem wrote:


On Fri, Jan 17, 2003 at 04:20:17PM +0100, Sylvain Wallez wrote:
 




OK. So we have some strong and justified -1's against ...
   


Yes your argument is convincing, so perhaps we should put 
the flowmap issue on the back-burner .. ;)

One small point though, I still think flow differs from a pipeline
because it contains information at more abstract level. As I noted
earlier, IMHO a pipelines purpose regardless of redirects, forwardings, or
actions is to describe a single "resource". While a flow describes 
a logical set of "resources"...


I agree : the flow chooses among these resources depending on both the 
request and the application state. That's what I called a "computed 
forward".

Anyway, its time for weekend. :) 


Enjoy it, mate :-)

Sylvain

--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Instrumentation client in Cocoon CVS ?

[Sylvain Wallez]

Marcus Crafter wrote:


Hi All,

	Just reporting back for anyone else watching this thread. Frank
	and I have done some offline testing and everything seems to be
	working now. The problem seemed to be in differing versions of
	altrmi jars.



Very cool ! Instrumentation is really a nice feature.


	Hope everyone has a nice weekend! :)



You too.

Sylvain

--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Cocoon PMC Update

[Stefano Mazzocchi]

Diana wrote me privately to say that she would like to be part of the PMC.

We don't need a vote before the PMC is setup so I'm adding her to the 
list. I don't attach the new file because the diff is fairly obvious.

Just wanted to let you know.

--
Stefano Mazzocchi   <[EMAIL PROTECTED]>




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [Fwd: [announce] Agora 1.1]

[Stefano Mazzocchi]

Bertrand Delacretaz wrote:

Stefano Mazzocchi wrote:
 >. . .


No, I'm very concerned about the abuses that this software might 
receive, like "I'm more important than you" based on positional location. 

 >. . .

I think this kind of information is already present in the current 
version, even if less obvious: dragging a point far away from the 
current cloud and watching how many others follow gives a good feel of 
the influence (as perceived by Agora) of a person in  the community.

Yes, you are right on the money. The information is there but it's not 
objectively confrontable like numbers would be. Yes, I admit that the 
'sticky node' feature was added because I was curious to play 'community 
battles' between different people and see how the community reacted.

I expect people to realize how 'forking' is dangerous by realizing how 
much impact even a single major committer leaving will generate in the 
community.

Great piece of software, by the way!
Helps get a feel for the kind of community relationships that exist.


My dream use would be to run the harvester and generate the datacloud of 
the entire foundation. Then use nagoya to render it and save a snapshot 
of its evolution, then make a movie of it and keep the new messages 
adding new links... like a webcam on the 'status of the foundation'... 
would be terribly cool, even if terribly slow... anybody has a few 
teraflops that I can borrow? :)

ok, the wildest dream would be to write a distributed computing 
environment a-la seti@home and have all apache friends run it to help 
the foundation process its own map but that's something for the 
future :)

--
Stefano Mazzocchi   <[EMAIL PROTECTED]>




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [Fwd: [announce] Agora 1.1]

[Stefano Mazzocchi]

Dirk-Willem van Gulik wrote:


On Fri, 17 Jan 2003, Stefano Mazzocchi wrote:



- I assume that the three clouds represent the three mailing lists
 but I'm not sure which cloud is which list, so some more
 detailed information about the connections between the squares
 would be nice


Good point, I'll try to work something out (I have a couple of simple
ideas to try out)



Colour :-)


Yep, CVS-module-based highlighting would be cool... oh, there is so much 
to  :)

--
Stefano Mazzocchi   <[EMAIL PROTECTED]>




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [vote] finilizing the pending votes on flow [was Re: [RT] Flow/SitemapIntegration]

[Stefano Mazzocchi]

Reinhard Poetz wrote:


There remains one open question for me: How to I get 'feedback' whether the
called pipeline did its job well or not? And if not, how to I get
information about what happend (error message/status information)?

What do you think?


I think you are getting right to the bone of the problem and I don't 
think I have a clear-cut solution... but I gotta go now, have to meet 
Pier at a pub downtown and we don't want to make a nice english beer 
wait, don't we? :)

--
Stefano Mazzocchi   <[EMAIL PROTECTED]>




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [Fwd: [announce] Agora 1.1]

[Steven Noels]

Stefano Mazzocchi wrote:


Yes, you are right on the money. The information is there but it's not 
objectively confrontable like numbers would be. Yes, I admit that the 
'sticky node' feature was added because I was curious to play 'community 
battles' between different people and see how the community reacted.

I have another one: "fork the community"... pick your player and see if 
he/she will be followed by the herd when moving away.

Stefano, you have one big group of loyal worshippers here ;-D


--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 16218] New: - IOException stream closed when cocoon redirects

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=16218

IOException stream closed when cocoon redirects

   Summary: IOException stream closed when cocoon redirects
   Product: Cocoon 2
   Version: 2.0.4
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: Minor
  Priority: Other
 Component: core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I noticed our logs were filling with an exception shown below.  A bit of
investigation showed that it was happening when cocoon does a redirect, which
happens a lot in our site.  This does not cause a problem other than the log
filling up with not very useful information.  Perhaps CocoonServlet.java should
check if the stream is still open before closing it?

ERROR   (2003-01-17) 11:24.38:393   [access] (Unknown-URI)
Unknown-thread/CocoonServlet: Cocoon servlet threw an Exception while trying to
close stream.
java.io.IOException: The stream has been closed
at
org.apache.catalina.connector.ResponseStream.flush(ResponseStream.java:238)
at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1166)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:260)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.connector.warp.WarpRequestHandler.handle(Unknown
Source)
at org.apache.catalina.connector.warp.WarpConnection.run(Unknown Source)
at java.lang.Thread.run(Thread.java:536)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

3 errors to go... (Re: [GUMP] Build Failure - xml-cocoon2)

[Nicola Ken Barozzi]

Sam Ruby wrote:


This email is autogenerated from the output from:




We have still 3 errors from Cocoon build in Gump.

It seems that Berin introduced the change in the excalibur component 
package 3 months, 3 weeks ago (update component to use proxies).
The diff is here:
http://cvs.apache.org/viewcvs/jakarta-avalon-excalibur/component/src/java/org/apache/avalon/excalibur/component/ComponentHandler.java.diff?r1=1.6&r2=1.7&diff_format=h

Suggested remedy?

...
 [echo] Compiling with Java 1.4, debug on, optimize off, deprecation off
[mkdir] Created dir: /home/rubys/jakarta/xml-cocoon2/build/cocoon/mock-classes
[javac] Compiling 11 source files to /home/rubys/jakarta/xml-cocoon2/build/cocoon/mock-classes
[javac] Compiling 577 source files to /home/rubys/jakarta/xml-cocoon2/build/cocoon/classes
[javac] /home/rubys/jakarta/xml-cocoon2/build/cocoon/src/org/apache/cocoon/components/language/programming/java/JavaProgram.java:89: cannot resolve symbol
[javac] symbol  : method getComponentHandler (java.lang.Class,org.apache.avalon.framework.configuration.DefaultConfiguration,org.apache.avalon.framework.component.ComponentManager,org.apache.avalon.framework.context.Context,org.apache.avalon.excalibur.component.RoleManager,org.apache.avalon.excalibur.component.LogkitLoggerManager)
[javac] location: class org.apache.avalon.excalibur.component.ComponentHandler
[javac] return ComponentHandler.getComponentHandler(
[javac]^
[javac] /home/rubys/jakarta/xml-cocoon2/build/cocoon/src/org/apache/cocoon/components/language/programming/javascript/JavascriptProgram.java:109: cannot resolve symbol
[javac] symbol  : method getComponentHandler (java.lang.Class,org.apache.avalon.framework.configuration.DefaultConfiguration,org.apache.avalon.framework.component.ComponentManager,org.apache.avalon.framework.context.Context,org.apache.avalon.excalibur.component.RoleManager,org.apache.avalon.excalibur.component.LogkitLoggerManager)
[javac] location: class org.apache.avalon.excalibur.component.ComponentHandler
[javac] return ComponentHandler.getComponentHandler(
[javac]^
[javac] /home/rubys/jakarta/xml-cocoon2/build/cocoon/src/org/apache/cocoon/acting/ServerPagesAction.java:122: cannot resolve symbol
[javac] symbol  : method getComponentHandler (java.lang.Class,org.apache.avalon.framework.configuration.Configuration,org.apache.avalon.framework.component.ComponentManager,,,)
[javac] location: class org.apache.avalon.excalibur.component.ComponentHandler
[javac] this.generatorHandler = ComponentHandler.getComponentHandler(
[javac] ^
[javac] 3 errors

BUILD FAILED



--
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]

DO NOT REPLY [Bug 15350] - [PATCH] BufferedOutputStream, Tomcat >= 4.1.15

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=15350

[PATCH] BufferedOutputStream, Tomcat >= 4.1.15

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|[PATH] BufferedOutputStream,|[PATCH]
   |Tomcat >= 4.1.15|BufferedOutputStream, Tomcat
   ||>= 4.1.15

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 14803] - [PATCH] cacheable.xsp for new AbstractServerPages

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=14803

[PATCH] cacheable.xsp for new AbstractServerPages

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|PATCH: cacheable.xsp for new|[PATCH] cacheable.xsp for
   |AbstractServerPages |new AbstractServerPages

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: xml-cocoon2/tools/instrumentation/bin runclient.bat

[huber]

huber   2003/01/17 13:16:26

  Added:   tools/instrumentation/bin runclient.bat
  Log:
  launch instrumentation under w2k
  
  Revision  ChangesPath
  1.1  xml-cocoon2/tools/instrumentation/bin/runclient.bat
  
  Index: runclient.bat
  ===
  @echo off
  rem CVS $Id: runclient.bat,v 1.1 2003/01/17 21:16:26 huber Exp $
  rem
  rem Script to run instrumentation client (run from the bin directory).
  
  setlocal
  
  set FRAMEWORK=..\lib\avalon-framework-4.1.3.jar
  set 
CLIENT=..\lib\excalibur-instrument-client-20030116.jar;..\lib\excalibur-instrument-manager-interfaces-20030116.jar
  set 
ALTRMI=..\lib\excalibur-altrmi-client-impl-20030116.jar;..\lib\excalibur-altrmi-client-interfaces-20030116.jar;..\lib\excalibur-altrmi-common-20030116.jar
  
  set CLASSPATH=%FRAMEWORK%;%CLIENT%;%ALTRMI%
  
  rem - Verify and Set Required Environment Variables 
  
  rem - Use Java in JAVA_HOME if JAVA_HOME is set.
  set OLD_PATH=%PATH%
  if "%JAVA_HOME%" == "" goto noJavaHome
  echo Using Java from %JAVA_HOME%
  set PATH=%JAVA_HOME%\bin
  :noJavaHome
  
  java -classpath %CLASSPATH% org.apache.excalibur.instrument.client.Main
  
  endlocal
  
  
  

--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail:  [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 15525] - [PATCH] simple patch to add fallback element in XIncludeTransformer

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=15525

[PATCH] simple patch to add fallback element in XIncludeTransformer

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|simple patch to add fallback|[PATCH] simple patch to add
   |element in  |fallback element in
   |XIncludeTransformer |XIncludeTransformer

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 11861] - [PATCH] extend castortransformer to handle collections

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=11861

[PATCH] extend castortransformer to handle collections

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Patch to extend |[PATCH] extend
   |castortransformer to handle |castortransformer to handle
   |collections |collections

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Instrumentation client in Cocoon CVS ?

[Bernhard Huber]

hi,

Marcus Crafter wrote:

Hi All,

	Just reporting back for anyone else watching this thread. Frank
	and I have done some offline testing and everything seems to be
	working now. The problem seemed to be in differing versions of
	altrmi jars.
	



	Hope everyone has a nice weekend! :)


yup, cool stuff, added runclient.bat
thx for the great stuff!

bernhard


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [vote] Jeff Turner as Cocoon committer

[Brian Behlendorf]

On Tue, 14 Jan 2003, Stefano Mazzocchi wrote:
> Jeff Turner <[EMAIL PROTECTED]> has been voted for committership by the
> cocoon development mail list.
>
> Jeff is already an apache committer, but update his karma so that he can
> commit to the cocoon CVS modules.

Done.  Sorry for the delay.

Brian


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/xml/dom DOMBuilder.java DOMUtil.java

[jefft]

jefft   2003/01/17 15:47:20

  Modified:src/blocks/databases/samples/mod-db schema.sql
   src/documentation/xdocs/userdocs/concepts caching.xml
   src/java/org/apache/cocoon/components/xmlform Form.java
FormListener.java
   src/java/org/apache/cocoon/transformation
TraxTransformer.java
   src/java/org/apache/cocoon/xml/dom DOMBuilder.java
DOMUtil.java
  Log:
  Small typos and fixups
  
  Revision  ChangesPath
  1.2   +1 -1  xml-cocoon2/src/blocks/databases/samples/mod-db/schema.sql
  
  Index: schema.sql
  ===
  RCS file: /home/cvs/xml-cocoon2/src/blocks/databases/samples/mod-db/schema.sql,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- schema.sql17 Jan 2003 11:22:37 -  1.1
  +++ schema.sql17 Jan 2003 23:47:19 -  1.2
  @@ -3,7 +3,7 @@
   -- to adapt it to another RDBMS, replace column type identity
   -- with appropriate autoincrement type, e.g. SERIAL for informix
   -- you might want to add "on delete cascade" to foreign keys in
  --- taböe user_groups
  +-- table user_groups
   
   create table user (
uid integer identity primary key,
  
  
  
  1.2   +1 -1  
xml-cocoon2/src/documentation/xdocs/userdocs/concepts/caching.xml
  
  Index: caching.xml
  ===
  RCS file: 
/home/cvs/xml-cocoon2/src/documentation/xdocs/userdocs/concepts/caching.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- caching.xml   3 Jan 2002 12:31:04 -   1.1
  +++ caching.xml   17 Jan 2003 23:47:19 -  1.2
  @@ -27,7 +27,7 @@
  For more information about configuration see the chapter below.
   The following subchapters describe the available caching 
algorithms.

  - The CachingEventPipelineuses a very easy but effective 
approach
  + The CachingEventPipeline uses a very easy but effective 
approach
to cache the event pipelines of a request: The pipeline process
is cached up to the most possible point.
 Each sitemap component (generator or transformer) which might 
be
  
  
  
  1.14  +2 -2  
xml-cocoon2/src/java/org/apache/cocoon/components/xmlform/Form.java
  
  Index: Form.java
  ===
  RCS file: 
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/components/xmlform/Form.java,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- Form.java 15 Jan 2003 13:17:41 -  1.13
  +++ Form.java 17 Jan 2003 23:47:19 -  1.14
  @@ -567,7 +567,7 @@
 * This method is called before 
 * the form is populated with request parameters.
 *
  -  * Semanticly similar to that of the 
  +  * Semantically similar to that of the 
 * ActionForm.reset() in Struts
 *
 * Can be used for clearing checkbox fields,
  
  
  
  1.3   +2 -2  
xml-cocoon2/src/java/org/apache/cocoon/components/xmlform/FormListener.java
  
  Index: FormListener.java
  ===
  RCS file: 
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/components/xmlform/FormListener.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- FormListener.java 15 Jan 2003 13:17:41 -  1.2
  +++ FormListener.java 17 Jan 2003 23:47:19 -  1.3
  @@ -67,7 +67,7 @@
* This method is called before 
* the form is populated with request parameters.
*
  - * Semanticly similar to that of the 
  + * Semantically similar to that of the 
* ActionForm.reset() in Struts
*
* Can be used for clearing checkbox fields,
  
  
  
  1.38  +2 -2  
xml-cocoon2/src/java/org/apache/cocoon/transformation/TraxTransformer.java
  
  Index: TraxTransformer.java
  ===
  RCS file: 
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/transformation/TraxTransformer.java,v
  retrieving revision 1.37
  retrieving revision 1.38
  diff -u -r1.37 -r1.38
  --- TraxTransformer.java  4 Dec 2002 11:06:44 -   1.37
  +++ TraxTransformer.java  17 Jan 2003 23:47:19 -  1.38
  @@ -88,7 +88,7 @@
   import java.util.Set;
   
   /**
  - * This Transformer is used to transform this incomming SAX stream using
  + * This Transformer is used to transform this incoming SAX stream using
* a XSLT stylesheet. Use the following sitemap declarations to define, configure
* and parameterize it:
*
  
  
  
  1.9   +7 -7  xml-cocoon2/src/java/org/apache/cocoon/xml/dom/DOMBuilder.

cvs commit: xml-cocoon2/src/blocks/databases/samples/tutorial/docs/dtd changes-v10.dtd characters.ent document-v10.dtd faq-v10.dtd javadoc-v04draft.dtd specification-v10.dtd todo-v10.dtd

[crossley]

crossley2003/01/17 22:18:56

  Removed: src/blocks/databases/samples/tutorial/docs/dtd
changes-v10.dtd characters.ent document-v10.dtd
faq-v10.dtd javadoc-v04draft.dtd
specification-v10.dtd todo-v10.dtd
  Log:
  Remove old un-necessary copies of old DTDs.

--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail:  [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]