RE: We need a detailed comparison with Struts

[TREGAN Fabien]

>I can only hope such architectural decisions are not solely made based 
>on documentation or 'white papers', but also on evaluating design and 
>codebase.

I wish it were :)

fabien.

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

Re: We need a detailed comparison with Struts

[Steven Noels]

TREGAN Fabien wrote:

> Ok, that's what i'm trying to explain, but the problem is that the first
> lines of the firt page of C2 doc says :
> 
> 
>   What is this? 
>  
> 
> 
>   Apache Cocoon is an XML publishing framework 
> 
> 
> After I've read docs and made some trying, I no longer agree with this.
> Cocoon (C2) is Web application AND publishing framework.

We held this discussion some time ago. Due to XMLForm and the flowmap, 
we could say there has been progress in that direction since then, but 
still, I don't feel Cocoon should position itself as a webapp framework 
as long as XMLForm and flowmap have been integrated, and thoroughly 
documented (or replaced by another solution). When you approach webapp 
development using Struts, it is clear how to handle it - using Cocoon 
however, there exist a myriad of unfinished possibilities, with no clear 
position on when you should use what, nor the documentation to support 
it. Let's not jump onto the webapp bandwagon too soon and too eager.

> Since the question was "we need a detailed comparison with Struts", I think
> it's imporant in this comparison to make it clear that Cocoon is not "just"
> a publishing framework. If this was made clear in Cocoon docs, Cocoon would
> allready have been choosed for the project i'm working on.

I can only hope such architectural decisions are not solely made based 
on documentation or 'white papers', but also on evaluating design and 
codebase.

Adding to the comparison discussion, please have a look at 
http://barracuda.enhydra.org/cvs_source/Barracuda/docs/landscape.html in 
that respective.




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

RE: Cachability (was RE: XInclude Transformer vs CInlude Transformer)

[Carsten Ziegeler]

Conal Tuohy wrote:
>
> I've just been looking at "inclusion" recently and noticed that
> the cinclude
> transformer had caching but the xinclude transformer didn't, and
> I wondered
> if there was some arcane reason or was it just a historial
> accident ;-) And
> BTW I think Carsten is right - the inclusion code should be united.
>
Thanks :)

> But actually my question is about caching of the DirectoryGenerator and
> sub-classes. It seems to me that these transfomers should also be
> cacheable;
> maybe this is just an oversight too? Or is there something tricky
> I haven't
> forseen? ;-)
AFAIK, the directory generator can be made cacheable as well, the
only reason why it isn't is, that noone has done it yet, I think.

>
> I have a pipeline based on a directory listing of xml docs; with
> 9 documents
> it takes 2 or 3 seconds to complete - and with 100 docs it will be
> impossible. But the files aren't often changed.
>
> Anyway, I thought I might make an attempt at adding caching to the
> DirectoryGenerator. It seems to me that the generator could perform the
> search and traverse the file system every time a request is made, but hash
> the resulting xml for the CacheValidity. Is that right? This would be my
> first attempt.
Ok, first question: for what version are you planning to add the caching?
If for 2.0.2/2.0.3 than the Cacheable interface is the right one, if you
are planning it for 2.1 than CacheableProcesingComponent is the correct
one.

Both interfaces are similar regarding their functions but not their return
values. A cacheable component returns a unique key. For the directory
generator this could be the full path of the directory together with the
settings
(include pattern, exclude pattern etc).
Second, a CacheValidity (Cacheable) or a SourceValidity
(CacheableProcesingComponent)
object is returned which is used to detect if the source (= directory)
of the generator changed. So if you use, e.g. the last modificiation
date of the directory here, this should work. (If the last modification date
of the directory changes, if a file changes inside the directory)

>
> I could enhance it to only traverse PART of the file system again to check
> the validity, by keeping a record of the file and directory
> objects involved
> in the last search. In the case of a directory search like "images/*.jpg",
> or "docs/*.xml", the generator should only need to check the timestamp of
> the "images" or "docs" directories, is that right? I've also used searches
> like "images/{1}.jpg" with the ImageDirectoryGenerator, to get the image
> width and height into a pipeline that converts the jpg to svg,
> for scaling,
> etc. In this case the validity could depend on the timestamp of
> that single
> file.

Yes, collecting the files involved together with their last modification
date is another possibility.

HTH
Carsten

Carsten Ziegeler Chief Architect Open Source Group, S&N AG
--
 Cocoon Consulting, Training and Projects
--
mailto:[EMAIL PROTECTED]  http://www.s-und-n.de
http://ziegeler.bei.t-online.de


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

RE: CachingPoint algorithm and treeprocessor

[Carsten Ziegeler]

Michael Melhem wrote:
> 
> As we have been discussing earlier, I have been doing some more work
> on "cache points" I believe I have something that appears to be workng!
> 
> However, there a couple of issues I would like to run by you:
> 
> Issue 1.
> I have added  a new method to the interface "ProcessingPipeline.java".
> Namely,  public void informBranchPoint();

Ok.

> 
> In "AbstractProcessingPipeline.java" the default implementation of this
> method simply does nothing. ie public void informBranchPoint() {}. It is
> redifined in CachingPOINTProcessingPipeline to do something meaningful.
> 
ok.

> The above method is used within the treeprocessor to inform the 
> chosen pipeline
> implementation that we have come across a branch in the tree.  What the
> pipeline does with this information is up to the particular chosen
> implementation. The default caching implementation ignores it. As 
> an example,
> here is a code snippet from GenerateNode.java.
> 
> -
> ...
> if (this.views != null) {
>//
>//
>// Inform the pipeline that we have a branch
>// point
>//
>context.getProcessingPipeline().informBranchPoint();
> 
>String cocoonView = env.getView();
>if (cocoonView != null) {
> ...
> -
> 
> Do you think the above proposed change to treeprocessing is 
> acceptable in terms of
> performance etc? At the moment I dont see a way around it.
> 
> 
Yes, it seems that this is the only working way.

> 
> Issue 2.
> I was thinking of breaking up some of the methods in 
> CachingProcessingPipeline.java
> so that my modifcations can be easly moved into a sub class. This Would
> Involve creating something like AbstractCachingProcessingPipeline.java,
> wth CachingProcessingPipeline.java and 
> CachingIPointProcessingPipeline.java would
> implementing this. What do you think of this?
> 
Yes, that's okay, if it helps you.

Michael, I would suggest that you give this developer list a brief
overview on the topic and intention of your changes. I think, 
currently only we two know, what we are talking about.

Bye
Carsten

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

RE: We need a detailed comparison with Struts

[TREGAN Fabien]

Many people wrote :

>>>yes, but this feeds into the marketing problem.  Just what IS Cocoon?
>> 
>>   This is important : one of the main problem I hade when I 

<...>

>> (maybe a more formal report when I have time to write it, but the
important
>> idea there is : Is Cocoon just a publication framework, or is it a Web
>> Applicatioin Framework ?)
>
>I think you could say that (Xx) Cocoon used to be a publishing
framework.
>Starting with 2.1 it becomes a kick-a** web app platform.

Ok, that's what i'm trying to explain, but the problem is that the first
lines of the firt page of C2 doc says :


  What is this? 
 



  Apache Cocoon is an XML publishing framework 


After I've read docs and made some trying, I no longer agree with this.
Cocoon (C2) is Web application AND publishing framework.
Since the question was "we need a detailed comparison with Struts", I think
it's imporant in this comparison to make it clear that Cocoon is not "just"
a publishing framework. If this was made clear in Cocoon docs, Cocoon would
allready have been choosed for the project i'm working on.


fabien.


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

Serializing Japanese

[Hassan Abolhassani]

How can I serialize html output in Japanese shift_jis encoding.

I have tried the following in sitemap.xmap:
  
 shift_jis
  

but the output is encoded as UTF-8 not Japanese shift_jis.

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

RE: Planning the releases

[Carsten Ziegeler]

Ivelin Ivanov wrote:
> 
> Are Cocoon blocks in or out from 2.1 ?
> 
Currently they are out as (AFAIK) noone has started working on it.
But if someone is able to make a concept *and* implement it by
the 15th of July (or the release date of the beta 1) they can
be in.

Personally, I think we shouldn't add blocks to 2.1 to stick to our
"release early, release often" theme...

Carsten

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

Re: We need a detailed comparison with Struts

[Bertrand Delacretaz]

On Thursday 13 June 2002 05:44, Ivelin Ivanov wrote:
>. . .(11pm typo corrected)
> I think you could say that (Cocoon) used to be a publishing framework.
> Starting with 2.1 it becomes a kick-a** web app platform.
>. . .

Yes - which means Cocoon is mature today *as a publishing framework*, and 
that's how I present it to my coworkers and customers (of which a number have 
"converted" recently ;-)

-Bertrand

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

Null pointer exception

[daniel robinson]

I am trying to install my working app at a Java hosting center.  My app 
works fine on NT.  The app server is running Resin.  Cocoon 2.0.2 seems 
to be running ok.  When I try my app I get:


java.lang.NullPointerException
at 
org.apache.cocoon.components.language.markup.LogicsheetCodeGenerator.addLogicsheet(LogicsheetCodeGenerator.java:101)
at 
org.apache.cocoon.components.language.markup.AbstractMarkupLanguage.addLogicsheetsToGenerator(AbstractMarkupLanguage.java:304)
at 
org.apache.cocoon.components.language.markup.AbstractMarkupLanguage$TransformerChainBuilderFilter.startElement(AbstractMarkupLanguage.java:511)
at 
org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage$SitemapTransformerChainBuilderFilter.startElement(SitemapMarkupLanguage.java:368)
at 
org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:528)
at 
org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage$PreProcessFilter.startElement(SitemapMarkupLanguage.java:211)
at org.apache.xerces.parsers.SAXParser.startElement(SAXParser.java:1376)
at 
org.apache.xerces.validators.common.XMLValidator.callStartElement(XMLValidator.java:1214)
at 
org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch(XMLDocumentScanner.java:1171)
at 
org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner.java:381)
at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1081)
at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:334)
at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:334)
at 
org.apache.cocoon.components.language.markup.LogicsheetCodeGenerator.generateCode(LogicsheetCodeGenerator.java:130)
at 
org.apache.cocoon.components.language.markup.AbstractMarkupLanguage.generateCode(AbstractMarkupLanguage.java:275)
at 
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.generateResource(ProgramGeneratorImpl.java:309)
at 
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.createResource(ProgramGeneratorImpl.java:271)
at 
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:188)
at org.apache.cocoon.sitemap.Handler.run(Handler.java:208)
at java.lang.Thread.run(Thread.java:484)

Any ideas, comments hints welcome.

Dan


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

Re: We need a detailed comparison with Struts

[Ivelin Ivanov]

Vadim Gritsenko wrote:
>>From: Ivelin Ivanov [mailto:[EMAIL PROTECTED]]
> 
> ...
> 
>>I think you could say that Struts used to be a publishing framework.
> 
> 
> Cocoon?
> 
> :)

Darn... it's 11pm. Thanks for ringing the bell Vadim :))



> 
> Take care,
> Vadim
> 
> 
>>Starting with 2.1 it becomes a kick-a** web app platform.
>>
>>
>>Ivelin
> 
> ...
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 
> 



-- 

-= Ivelin =-


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

RE: We need a detailed comparison with Struts

[Vadim Gritsenko]

> From: Ivelin Ivanov [mailto:[EMAIL PROTECTED]]
...
> I think you could say that Struts used to be a publishing framework.

Cocoon?

:)

Take care,
Vadim

> Starting with 2.1 it becomes a kick-a** web app platform.
> 
> 
> Ivelin
...



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

Re: We need a detailed comparison with Struts

[Ivelin Ivanov]

TREGAN Fabien wrote:
>>>Right, but this 3rd party stuff (in lib/optional) is for features that
>>
> Struts doesn't provide.
> 
>>yes, but this feeds into the marketing problem.  Just what IS Cocoon?
> 
> 
>   This is important : one of the main problem I hade when I said that wanted
> to use C2 for my project is that Cocoon defines itself as a "publication
> framework". The answer I hade was "we are not making a news portal, but a
> real application, we do not need to publish the content of our database in
> html, but to provide services with a web client".
>   So, when I hade to compare Cocoon with Struts (yes, I'm one of the 3
> Sylvain spoke about :), I tryed not to present Cocoon as a "publication
> framework" but as :
> -a MVC framework with text configured, extensible, controler
> -a framework that do not provide anything for the business tier (model) and
> oblige you to separate have a separated business tier (EJB, custom API) wich
> can provide XML
> -a pipe system based on XML and "transformers" for the view.
> -Avalon is great
> 
> So now how does it compare to Struts ?
> -Struts is a MVC Framework

So is XMLForm. Cocoon sitemap is far more sophisticated than 
struts-config.xml. Ovidiu's flow control is a working solution which 
delivers what Strut's workflow was planning to do but hasn't achieved 
yet. Plus with Creg's recent emails, it is now clear that Strut's 
development will most likely slow down quite a bit.

> -Struts don't oblige you bother with XML, but don't get real advantage of it
> -Struts leave it up to you to separate business and application tier, and
> JSP don't help you to separate logic and presentation.

Cocoon obliges you to use XML and thus separate logic, content and 
presentation.

> -If you can afford it, an application server is great
> 
> So :
> -Struts is faster to learn
> -(Struts should be faster to run, and use less memory, but we should test
> that, and use an EJB server or use Avalon in struts)
> -With struts, you can reuse all your javabean instead of loosing time to
> XMLize them

XMLForm does not XML-ize JavaBeans. Instead they're accessed directly, 
just like Struts does it. However a big advantage over Struts is that 
the "view" markup is client independent, based on XForms. This way 
styling and rendering forms is a lot more flexible than with Struts.
Remember that with Struts you can only write html forms. XMLForm allows 
you to write forms for HTML, WAP and other clients.

> -If you do not think XML is a must, if you do not want to separate logique
> from presentation, business from application, ok, use struts. I'll have warn
> you.
> 
> (maybe a more formal report when I have time to write it, but the important
> idea there is : Is Cocoon just a publication framework, or is it a Web
> Applicatioin Framework ?)


I think you could say that Struts used to be a publishing framework.
Starting with 2.1 it becomes a kick-a** web app platform.


Ivelin


>>What does seperation of concerns (thanks for not abbreviating it) mean 
>>to my boss?  (Yes I know what it means, but
>>its not a good high-level perspective.  MVC has caught on.  
>>Many of the 
>>paycheck signers don't know what it means but
>>they now know its something they should have...) -- and by the 
>>way...sometimes I sell struts because its better than the
>>approach they have and Cocoon is way over their head or seems more 
>>risky.  I'd still categorize cocoon as an emerging
>>technology.  Struts has nearly achieved "standard" level.
> 
> 
> Is there a "Software Engeneering for Dummys" book, I need one ? (for a
> "friend")
> 
> fabien.
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 
> 



-- 

-= Ivelin =-


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

Re: Session support implemented

[Ivelin Ivanov]

Rock and Roll Jeff !

I'll try it out.

Thanks !


A quick question of low priority. Is https supported at this point?



Ivelin


Jeff Turner wrote:
> Hi,
> 
> I've implemented minimal session support. To test it, run 'ant', then
> './runtests.sh'. The 'session' target in test.xml will run,
> demonstrating session support:
> 
> 
>   debug="${debug}">
> 
> 
> 
>   
>   debug="${debug}">
> 
> 
>   
> 
>   
> 
> 
> After two HTTP requests, our session contains: ${sessionStr}
> 
> This requires an external Tomcat setup with two JSPs, one to set a session
> value and another to retrieve it.
> 
> On my computer, output with debug=10 is as follows:
> 
>  [http] {} Session has no cookie for path '/session'
>  [http]  Sending to localhost:8787
>  [http] GET /session/setname.jsp?name=Joe+Bloggs HTTP/1.0
>  [http] Host: localhost
>  [http] 
>  [http] --
>  [http] Reading response 
>  [http] Got: HTTP/1.1 200 OK
>  [http] Got headers: {Date=Date: Wed, 12 Jun 2002 13:45:05 GMT, Server=Server: 
>Apache Tomcat/4.0 (HTTP/1.1 Connector), Set-Cookie=Set-Cookie: 
>JSESSIONID=20E8B41772E3D0A492694612758860D2;Path=/session, Connection=Connection: 
>close, Content-Type=Content-Type: text/html;charset=ISO-8859-1}
>  [http] Got body: Setting session param
>  [http] 
>  [http] 
>  [http] Got session cookie Set-Cookie: 
>JSESSIONID=20E8B41772E3D0A492694612758860D2;Path=/session
>  [http] {} Session storing cookie: 
>JSESSIONID=20E8B41772E3D0A492694612758860D2;Path=/session
>  [http] {} Session storing mapping '/session' -> 
>'JSESSIONID=20E8B41772E3D0A492694612758860D2'
>  [http] Adding session cookie cookie: JSESSIONID=20E8B41772E3D0A492694612758860D2
>  [http]  Sending to localhost:8787
>  [http] GET /session/getname.jsp HTTP/1.0
>  [http] cookie: JSESSIONID=20E8B41772E3D0A492694612758860D2
>  [http] Host: localhost
>  [http] 
>  [http] --
>  [http] Reading response 
>  [http] Got: HTTP/1.1 200 OK
>  [http] Got headers: {Date=Date: Wed, 12 Jun 2002 13:45:05 GMT, Server=Server: 
>Apache Tomcat/4.0 (HTTP/1.1 Connector), Connection=Connection: close, 
>Content-Type=Content-Type: text/html;charset=ISO-8859-1}
>  [http] Got body: Hello there, Joe Bloggs
>  [http] 
>  [null]OK: 2 passed, 0 failed [Tests session support]
>  [echo] After two HTTP requests, our session contains: 
>{/session=JSESSIONID=20E8B41772E3D0A492694612758860D2}
> 
> 
> 
> Note: the support is *very* rudimentary, given the potential complexity
> of cookies. The HttpClient parse() method is 263 lines; mine is 19. It
> works with Tomcat 4.0 anyway. If anyone has problems precluding a 1.0
> release, please let me know.
> 
> A note on the syntax: why didn't I wrap  tags in a  tag,
> like Latka? Because Ant does not make it easy to nest elements. The
> official mechanism, TaskContainer, is rather deficient because it *only*
> allows tasks to be added; no DataTypes or regular nested elements. So
> I've gone with the (more flexible) session-object-passing approach.
> Same story for the upcoming  element.
> 
> 
> --Jeff
> 
> ___
> 
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> ___
> aft-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/aft-devel
> 



-- 

-= Ivelin =-


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

Re: Planning the releases

[Ivelin Ivanov]

Carsten Ziegeler wrote:
> Hi Team,
> 
> I think it's time to recall the "release early release often" paradigma...
> 
> As others already mentioned over the last weeks, we should try to
> release a 2.0.3 as soon as possible. For this we should collect the
> open issues, do them and release (sounds simple, doesn't it?)
> 
> As I'm next week on vacation near Paris :) what do you think of
> the 1st of July as a release date for 2.0.3?
> 
> And if we are already talking about releases, what do we have
> to do for 2.1? It seems that many things are nearly finished, so
> we can start to think of a beta phase. I would 
> propose the 15th of July for the release date of 2.1 beta 1.


+1

Are Cocoon blocks in or out from 2.1 ?



> 
> What do you think?
> What are the open issues (for both releases)?
> 
> Carsten 
> 
> Carsten Ziegeler Chief Architect Open Source Group, S&N AG
> --
>  Cocoon Consulting, Training and Projects
> --
> mailto:[EMAIL PROTECTED]  http://www.s-und-n.de
> http://ziegeler.bei.t-online.de
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 
> 



-- 

-= Ivelin =-


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

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/xmlform Types.java

[ivelin]

ivelin  2002/06/12 19:40:41

  Removed: src/java/org/apache/cocoon/components/xmlform Types.java
  Log:
  Features from latest JXPath version,
  reduce code in XMLForm

--
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/lib/optional commons-jxpath.jar

[ivelin]

ivelin  2002/06/12 19:39:57

  Modified:lib/optional commons-jxpath.jar
  Log:
  Features from latest JXPath version,
  reduce code in XMLForm
  
  Revision  ChangesPath
  1.4   +911 -828  xml-cocoon2/lib/optional/commons-jxpath.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/java/org/apache/cocoon/components/xmlform Form.java

[ivelin]

ivelin  2002/06/12 19:35:04

  Modified:src/java/org/apache/cocoon/components/xmlform Form.java
  Log:
  Features from latest JXPath version,
  reduce code.
  
  Revision  ChangesPath
  1.3   +11 -59
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.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- Form.java 2 Jun 2002 03:33:35 -   1.2
  +++ Form.java 13 Jun 2002 02:35:04 -  1.3
  @@ -76,6 +76,7 @@
   
   import org.apache.commons.jxpath.JXPathContext;
   import org.apache.commons.jxpath.Pointer;
  +import org.apache.commons.jxpath.JXPathException;
   //import org.apache.commons.jxpath.ri.model.dom.DOMAttributePointer;
   
   import org.apache.cocoon.Constants;
  @@ -190,8 +191,7 @@
 {
   if ( model_ == null)
 throw new IllegalStateException( "Form model not set" );
  -Pointer pointer = jxcontext_.locateValue( xpath ); 
  -setValue( pointer, value );
  +jxcontext_.setValue(xpath, value);
 }
   
 
  @@ -228,10 +228,13 @@
 // when the instance property is array
   if ( property != null && property.getClass().isArray() )
   {
  +  Class componentType = property.getClass ().getComponentType ();
  +  property = java.lang.reflect.Array.newInstance ( componentType, values.length 
);
 java.lang.System.arraycopy(
   values, 0, 
   property, 0, 
   values.length );
  +  pointer.setValue( property );
   }
   else if (property instanceof Collection)
   {
  @@ -243,62 +246,11 @@
   // (and the only) from the values array
   else 
   {
  -  this.setValue( pointer, values[0] );
  +  pointer.setValue( values[0] );
   }
 }
   
 
  -  protected void setValue( Pointer pointer, Object value)
  -  {
  -
  -//// Dmitri Plotnikov's patch
  -//pointer.setValue(value);
  -
  -Object property = pointer.getValue();
  -if ( property != null ) 
  -{
  -
  -  
  -  // handle DOM elements
  -  if (property instanceof Element)
  -  {
  -String textPath = pointer.asPath() + "/text()";
  -setValue( textPath, value );
  -  }
  -  else if (property instanceof Text)
  -  {
  -Text  node = (Text) property;
  -node.setNodeValue ( value.toString() );
  -  }
  -  /*
  -  else if (pointer instanceof DOMAttributePointer)
  -  {
  -Attr  node = (Attr) ( ( (DOMAttributePointer)pointer).getBaseValue() );
  -node.setNodeValue ( value.toString() );
  -  } 
  -   */
  -  else
  -  {
  -Object newValue = convertType( value, property.getClass () );
  -pointer.setValue( newValue );
  -  }
  -}
  -// set null value
  -else pointer.setValue( value );
  -  }
  -  
  -  
  -/**
  - * Attempts to convert the request parameter
  - * String value to the actual model property type
  - */
  -public Object convertType(Object value, Class requiredType)
  -{
  -value = Types.convert(value, requiredType);
  -return value;
  -}
  -  
  -  
 /**
  * Encapsulates access to the model
  *
  @@ -447,7 +399,7 @@
   {
   setValue( path, values );
   }
  -catch (IllegalArgumentException ex)
  +catch (JXPathException  ex)
   {
 Violation v = new Violation();
 v.setPath( path );
  
  
  

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

Re: FW: faq on cocoon-homepage

[David Crossley]

Diana Shannon wrote:
> Diana Shannon wrote:
> >> user feedback wrote:
> >>> [ http://xml.apache.org/cocoon/ ]
> >>> The links to the faq section are linked wrong. They point to faq.html,
> >>> but it's faq/
> >>> Regards, Daniele
> >
> > I'm not sure what links she's referring to, but Vadim astutely pointed 
> > out the reference to faq.html at the bottom of each and every 
> > cocoon-user email. I've added a redirect page for faq.html (points to 
> > faq/index.html) to the live site repository. Now I need Vadim to update 
> > the web site, one *last* time... ;-)
> >
> > Diana
> 
> Actually, Carsten (thanks!) just added a redirect for faqs.html (still 
> listed at the bottom of cocoon-user emails), and I added a redirect 
> (just got my privs working) for faq.html, which was the old link, noted 
> above by Daniele.
> 
> Do we really need to add redirects for all moved docs? I understand the 
> need for faq, etc., but what about recently moved (and very recently 
> committed docs) like xmlform-wizard tutorial? This may be a PITA to 
> manage down the road, especially if we refactor some of the core docs, 
> now spread across several guides.
> 
> Diana

Thanks for picking this up Diana.

There are two other important URLs that have changed
recently ... livesites.html and hosting.html
The xdocs were moved into link/ directory.

This issue is being discussed on Forrest. Please help.
http://marc.theaimsgroup.com/?l=forrest-dev&m=102390892524750



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

Re: [VOTE] Schematron validator in Anteater (and Cocoon validatingTransformer)

[Ivelin Ivanov]

Thanks Ovidiu,

I'll take advantage of your tips.


The value of integrating with JUnit reporting would be that we could 
possibly reuse the reporting code. As I mentioned to Jeff though,
we might consider WebTest's reporting code as well, since it's ant based 
and might be easier to integrate with.
http://webtest.canoo.com/selftest/TestResultOverview.html


Cheers,

Ivelin


Ovidiu Predescu wrote:
> Ivelin,
> 
> I'm not Jeff, but I do have some ideas.
> 
> The Schematron validor would have a correspondent MatcherTest subclass in
> Anteater. You would essentially need to implement the validate() method, in
> which you call the Validator.validate() method. You either return true, if
> Validator.validate() returns null, or you return false, and log the errors
> using the inherited log() method.
> 
> Check out some of the matcher test classes in the
> org/apache/anteater/test/matchers/ directory, like Parameter.java.
> 
> Regarding Junit reporting, I'd still like to understand a bit more what is
> the idea behind this, and what would be the benefits of integrating with it.
> 
> Cheers,
> Ovidiu
> 
> On 6/11/02 9:17 PM, "Ivelin Ivanov" <[EMAIL PROTECTED]> wrote:
> 
> 
>>Jeff,
>>
>>The org.apache.cocoon.components.validation.Validator
>>
>>interface has the following method:
>>
>>List validate(Object instance)
>>
>>It returns either null, when validation is successfull, or a list of
>>Violation objects, each of which has an XPath address of the bad element
>>and a String with the description of the problem.
>>
>>How do you suggest I integrate this in Anteater?
>>
>>Ideally I would like to integrate Anteater scripts with JUnit reports,
>>so that the list of violations is listed in the place where unit test
>>exceptions are repoported.
>>
>>How is you progress with JUnit reports integration?
>>
>>
>>BTW, JARV implements Relax NG validation.
>>http://iso-relax.sourceforge.net/JARV/
>>
>>
>>Ivelin
>>
>>
>>
>>
>>
>>
>>Jeff Turner wrote:
>>
>>>Hi Ivelin,
>>>
>>>On Fri, Jun 07, 2002 at 06:51:09PM -0500, Ivelin Ivanov wrote:
>>>...
>>>
>>>
The ideas is to use references to schema documents of standard XML languages
(like Schematron, DTD, XML Schema, Relax NG) for response validation,
instead of supporting a proprietary grammar.
>>>
>>>
>>>Adding a Schematron validator would be great. It would be a superset of
>>>functionality provided by our existing  validator. I'd also like
>>>to add a Relax NG validator at some stage.
>>>
>>>
>>>
I suggest that we use the org.apache.cocoon.components.validation package
which is an independent component in Cocoon's main tree and is used by
XMLForm.

The Schematron implementation is already available and I think it is quite
suitable for Anteater, because Schematron is a superset of Anteater's match
element.
To be precise it is a superset of the validating use, i.e the cases when
match is used to assign value to a "result" property. Asigning values within
 to other properties which are used for subsequent requests is a
separate concern.
>>>
>>>
>>>So..
>>>
>>>Latka has it's Validator interface, consisting of:
>>>
>>>public abstract void validate(Response response) throws ValidationException;
>>> // throw an exception on validation failure
>>>
>>>Anteater has a MatcherTest abstract class:
>>>
>>>  public void setObjectModel(HashMap objectModel);
>>>  public abstract boolean validate() throws BuildException;
>>>  public boolean getResult();
>>>
>>>And Cocoon has another Validator interface:
>>>
>>>  public abstract void validate(Response response) throws
>>>ValidationException;
>>>  public void setProperty(java.lang.String property, java.lang.Object value);
>>>  public java.lang.Object getProperty(java.lang.String property);
>>>
>>>Here are the validators currently available:
>>>
>>>ByteLengthValidator (Latka)
>>>CookieValidator (Latka, Anteater)
>>>ContentEquals (compare contents vs. file) (Latka, Anteater)
>>>MaxRequestTimeValidator (Latka)
>>>RegexpValidator (Latka, Anteater, Webtest)
>>>StatusCodeValidator (Latka, Anteater)
>>>XPathValidator (Latka, Anteater)
>>>SchematronValidator (Cocoon)
>>>
>>>It would be good if we could come up with a common API that everyone
>>>could implement. Eg, adopt Latka or Cocoon's Request/Response
>>>abstraction, plus Anteater/Cocoon's ability to pass an 'object model'
>>>(aka Avalon Context). Plus I'd like some way to record what's been done,
>>>for later reporting.
>>>
>>>But anyway, that's for down the road. There are few enough validators
>>>currently that it's less effort just to modify the code for each testing
>>>framework.
>>>
>>>
>>>
>>>
>>>Schematron looks very cool. Another even easier-to-use possibility would
>>>be Examplotron (http://examplotron.org/).
>>>
>>>
>>>We live in dark days where the majority of Apache is unthinkingly
>>>adopting XML Schema, despite it's inferiority, simply because it's from
>>>the W3C. Kimbro Staken said it best:
>>>http://radio.weblogs.com/0100213/20

Re: XMLForms and Flowmap

[Ivelin Ivanov]

Reinhard Poetz wrote:
>>We are looking for someone to step up and show us how these two can work
>>together in a nice way.
>>
>>Interested?
>>
>>
>>Ivelin
> 
> 
> Yes I am but my time and my java knowledge are limited (... but I'm
> learning)


So you have the itch. That's all it takes ;-]

> 
> Anyway, I'll try it. Maybe there is somebody who has already some experience
> (Daniel?) who want's to join.
> 
> Reinhard
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 
> 



-- 

-= Ivelin =-


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

Re: XMLForm hello world in the works

[Ken C]

Andrew,
Your action needs the Cocoon XMLForm classes, don't
comment them out. Also note the 'components' is
missing in each 'imports'. Thus it should read,

// Schematron classes
import
org.apache.cocoon.components.validation.SchemaFactory;
import org.apache.cocoon.components.validation.Schema;
import
org.apache.cocoon.components.validation.Validator;
import
org.apache.cocoon.components.validation.Violation;


Also, for your sitemap, I have modified it a bit for
your reference, 

   
  
  
  http://www.ascc.net/xml/schematron"/>
  
  
  
  

  
  
   

  
  
 
  


...
 
Note that I am using the given stylesheets, they are
good and working. Just an opinion. 

Kenny

__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

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

Re: Anteater session support (Re: Anteater tests)

[Ivelin Ivanov]

Great to know that you're cracking away JUinit reporting and session 
support.
As far as a new HttpClient is concerned, I can care less if session 
support is implemented.

I looked at Anteater code and was surprised how simple and small it is,
yet the scripts can be quite flexible.
The power of code *reuse*.

I am looking at Schematron integration for better error reporting.
Please let me know your thoughts on how to integrate violation list in 
the JUnit reports (see my previous message on the subject).

Actually if JUnit report integration is too hard, you could look at the 
Canoo WebTest reporting. It is also ant based and might be easier to 
integrate with.



Ivelin


PS: If the rest of the Cocoon people think this thread is OT, let me 
know. Since Cocoon doesn't have a functional testing framework itself,
I find Anteater as an important component.





Jeff Turner wrote:
> On Tue, Jun 11, 2002 at 11:40:24PM -0500, Ivelin Ivanov wrote:
> 
>>Jeff,
>>
>>Do you have any fresh ideas/code on session support.
>>Latka's  tag is nice.
>>How hard would it be to do this for Anteater?
>>Is it just about receiving and resending cookies.
> 
> 
> I'll take a break from JUnit formatting (taking longer than I thought),
> and have a play tonight. It shouldn't be too hard at all. Just a Session
> 'DataType' object shared among HttpRequest objects, eg:
> 
> 
> 
> 
>   
> 
>   
> 
> 
>   
> 
> ...
>   
> 
> 
> 
>>Ovidiu mentioned possibly using another HttpClient lib, that will make
>>session support easier. Did you guys decide on this?
> 
> 
> Well, the 'correct' way to fix the problem is to turf out Ovidiu's
> lovingly handcrafted HttpMessage class ;) and write an Ant interface to
> HttpClient (either Commons' or the innovation.ch one). This would also
> allow Anteater to test Tomcat4-hosted apps (see bug
> 
>http://sourceforge.net/tracker/index.php?func=detail&aid=547890&group_id=42970&atid=434732).
> 
> Big change though. A HttpClient-Ant interface would be a project in it's
> own right. Probably can be done post-1.0 for Anteater.
>  
> 
> --Jeff
> 
> 
>>Ivelin
> 
> 



-- 

-= Ivelin =-


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

Re: XMLForm hello world in the works

[Andrew C. Oliver]

[EMAIL PROTECTED] wrote:

>Andrew,
>
>I don't know what's wrong, but here's a few things to try:
>  
>
Thanks!  Actually, I didn't mean to send, this and thought I hit stop. 
 I discovered my
problem was actually some invisible character had snuck its way into the 

processing instruction.

But I'm glad I did send it!

>1) 
>  src="HelloAction"
>logger="webapp.xmlform"/>
>logger="webapp.xmlform"/>
>  
>
>I don't  get this.  Why are you declaring two identical actions?  Can't see why
>it would hurt, but can't see how it helps either...  I would do something like
>this:
>
Yes, I must have added it twice..  

>
>  ="org.apache.cocoon.samples.xmlform.HelloAction"  logger="webapp.xmlform"/>
>
>(you will need to change the src so as to match where you compile your
>HelloAction.java)
>
>2) 
>   
>
>
>  
>  
>  
>  
>
>  
>  
>  
>   
>  
>  
>  src="context://stylesheets/xmlform/xmlform2html.xsl"/>
>  
>
>   
>
>Don't understand this, either.  Why are you repeating the "xmlform"
>transformation?  This transformation "expects" to be invoked right after the
>generation step and before either of the xslt transformations.  Invoking it
>after an xslt transformation can't be good.  But again, I can't say for sure
>this is your problem.
>  
>
I'm not I just renamed the wizard stylesheet.

>3) I would do this:
>
>
>
>  
>  
>  
>  
>
>  
>  
>  
>
>  
>  
>   
>   
>
>If this doesn't work, comment out the three transformers, change type="html"> to , and look at the results in MSIE 5.x
>(where you can see the raw XML that is produced).  Check logs.  If no errors,
>uncomment the next transformer and repeat.  This should pinpoint the error to
>the action, generator, or transformer.  It will also let you see exactly what is
>happening in each step.
>
You can also look at it in mozilla 1.0 and just right-click and view 
source. ;-)

>  
>
>I skimmed your code; nothing jumped out at me.  Do these things and post another
>message to dev group, and I'll try to be more helpful.
>  
>
I appreciate your help!  Thanks!

-Andy

>--Michael
>
>
>
>  
>  
>  "Andrew C.  
>  
>  Oliver"  To:   [EMAIL PROTECTED]
>  
>
>  org> Subject:  XMLForm hello world in the 
>works   
>  
>  
>  06/12/02 04:03 PM   
>  
>  Please respond to   
>  
>  cocoon-dev  
>  
>  
>  
>  
>  
>
>
>
>
>Hi All,
>
>I'm trying to create a HelloXMLForm example and I'm getting this:
>
>/The processing instruction target matching "[xX][mM][lL]" is not allowed./
>
>More precisely:
>
>/org.apache.cocoon.ProcessingException: Failed to execute pipeline.:
>org.xml.sax.SAXParseException: The processing instruction target
>matching "[xX][mM][lL]" is not allowed./
>
>(to see the full error you can go to
>http://www.superlinksoftware.com/cocoon/samples/bringmethis/hello.html)
>
>any thoughts on what this means?
>
>relevent sitemap entries:
>
> 
>  
>  src="HelloAction"
>logger="webapp.xmlform"/>
>logger="webapp.xmlform"/>
>  
>  
>logger="sitemap.generator.serverpages" n
>ame="serverpages" pool-grow="2" pool-max="32" pool-min="4"
>src="org.apache.cocoo
>n.generation.ServerPagesGenerator"/>
>
>  
>  
>   src="org.apache.
>cocoon.transformation.SQLTransformer"/>
>   src="org.apache.cocoon.transformation.XMLForm
>Transformer" logger="webapp.xmlform"/>
>  
>  
>  
>  
>  
>  
>  
> 
>
>
>
>   
>   
>
>
>  
>  
>  
>  
>
>  
>  
>  
>   
>  
>  
>  src="context://stylesheets/xmlform/xmlform2html.xsl"/>
>  
>
>   
>
>...
>
>here is my xml form
>
>
>
>http://xml.apache.org/cocoon/xmlform/2002";>
>
>
>  
>
>Hello
>
>
>  
>
>
>
>Last Name
>
>
>
>
>First Name
>

Re: XMLForm hello world in the works

[mratliff]

Sorry, that last transform for the pipeline given in 3) should be:
   



   
 
  mratliff@collegen
 
  et.com   To:   [EMAIL PROTECTED] 
 
   cc: 
 
  06/12/02 05:13 PMSubject:  Re: XMLForm hello world in 
the works   
  Please respond to
 
  cocoon-dev   
 
   
 
   
 





Andrew,

I don't know what's wrong, but here's a few things to try:

1) 


  

I don't  get this.  Why are you declaring two identical actions?  Can't see why
it would hurt, but can't see how it helps either...  I would do something like
this:

  

(you will need to change the src so as to match where you compile your
HelloAction.java)

2) 
   


  
  
  
  

  
  
  
   
  
  
  
  

   

Don't understand this, either.  Why are you repeating the "xmlform"
transformation?  This transformation "expects" to be invoked right after the
generation step and before either of the xslt transformations.  Invoking it
after an xslt transformation can't be good.  But again, I can't say for sure
this is your problem.

3) I would do this:



  
  
  
  

  
  
  

  
  
   
   

If this doesn't work, comment out the three transformers, change  to , and look at the results in MSIE 5.x
(where you can see the raw XML that is produced).  Check logs.  If no errors,
uncomment the next transformer and repeat.  This should pinpoint the error to
the action, generator, or transformer.  It will also let you see exactly what is
happening in each step.

I skimmed your code; nothing jumped out at me.  Do these things and post another
message to dev group, and I'll try to be more helpful.

--Michael




  "Andrew C.

  Oliver"  To:
[EMAIL PROTECTED]
   Subject:  XMLForm hello world in
the works

  06/12/02 04:03 PM

  Please respond to

  cocoon-dev







Hi All,

I'm trying to create a HelloXMLForm example and I'm getting this:

/The processing instruction target matching "[xX][mM][lL]" is not allowed./

More precisely:

/org.apache.cocoon.ProcessingException: Failed to execute pipeline.:
org.xml.sax.SAXParseException: The processing instruction target
matching "[xX][mM][lL]" is not allowed./

(to see the full error you can go to
http://www.superlinksoftware.com/cocoon/samples/bringmethis/hello.html)

any thoughts on what this means?

relevent sitemap entries:

 
  


  
  


  
  
   
   
  
  
  
  
  
  
  
 



   
   


  
  
  
  

  
  
  
   
  
  
  
  

   

...

here is my xml form



http://xml.apache.org/cocoon/xmlform/2002";>


  

Hello


  



Last Name




First Name




  Next


  



here is  my action

// Java classes
import java.util.Map;
import java.util.HashMap;
import java.util.SortedSet;
import java.util.Iterator;
import java.util.Properties;
import java.io.InputStream;
import java.io.FileInputStream;
import java.io.File;

// XML classes
// import javax.xml.transform.stream.StreamSource;
// import javax.xml.transform.TransformerException;
// import org.xml.sax.InputSource;
// import org.w3c.dom.Node;
// import org.w3c.dom.NodeList;

// Framework classes
import org.apache.avalon.framework.parameters.Parameters;
import org.apache.avalon.excalibur.pool.Poolable;
import org.apache.avalon.framework.configuration.Configuration;
import org.apache.avalon.framework.configuration.ConfigurationException;

// Cocoon classes
import org.apache.cocoon.environment.Redirector;
import org.apache.cocoon.environment.SourceResolver;
import org.apache.cocoon.acting.*;
import org.apache.cocoon.environment.Request;
import org.apache.cocoon.environment.ObjectModelHelper;
import org.apache.cocoon.e

Re: XMLForm hello world in the works

[mratliff]

Andrew,

I don't know what's wrong, but here's a few things to try:

1) 


  

I don't  get this.  Why are you declaring two identical actions?  Can't see why
it would hurt, but can't see how it helps either...  I would do something like
this:

  

(you will need to change the src so as to match where you compile your
HelloAction.java)

2) 
   


  
  
  
  

  
  
  
   
  
  
  
  

   

Don't understand this, either.  Why are you repeating the "xmlform"
transformation?  This transformation "expects" to be invoked right after the
generation step and before either of the xslt transformations.  Invoking it
after an xslt transformation can't be good.  But again, I can't say for sure
this is your problem.

3) I would do this:



  
  
  
  

  
  
  

  
  
   
   

If this doesn't work, comment out the three transformers, change  to , and look at the results in MSIE 5.x
(where you can see the raw XML that is produced).  Check logs.  If no errors,
uncomment the next transformer and repeat.  This should pinpoint the error to
the action, generator, or transformer.  It will also let you see exactly what is
happening in each step.

I skimmed your code; nothing jumped out at me.  Do these things and post another
message to dev group, and I'll try to be more helpful.

--Michael



   
 
  "Andrew C.   
 
  Oliver"  To:   [EMAIL PROTECTED] 
 
   Subject:  XMLForm hello world in the 
works   
   
 
  06/12/02 04:03 PM
 
  Please respond to
 
  cocoon-dev   
 
   
 
   
 




Hi All,

I'm trying to create a HelloXMLForm example and I'm getting this:

/The processing instruction target matching "[xX][mM][lL]" is not allowed./

More precisely:

/org.apache.cocoon.ProcessingException: Failed to execute pipeline.:
org.xml.sax.SAXParseException: The processing instruction target
matching "[xX][mM][lL]" is not allowed./

(to see the full error you can go to
http://www.superlinksoftware.com/cocoon/samples/bringmethis/hello.html)

any thoughts on what this means?

relevent sitemap entries:

 
  


  
  


  
  
   
   
  
  
  
  
  
  
  
 



   
   


  
  
  
  

  
  
  
   
  
  
  
  

   

...

here is my xml form



http://xml.apache.org/cocoon/xmlform/2002";>


  

Hello


  



Last Name




First Name




  Next


  



here is  my action

// Java classes
import java.util.Map;
import java.util.HashMap;
import java.util.SortedSet;
import java.util.Iterator;
import java.util.Properties;
import java.io.InputStream;
import java.io.FileInputStream;
import java.io.File;

// XML classes
// import javax.xml.transform.stream.StreamSource;
// import javax.xml.transform.TransformerException;
// import org.xml.sax.InputSource;
// import org.w3c.dom.Node;
// import org.w3c.dom.NodeList;

// Framework classes
import org.apache.avalon.framework.parameters.Parameters;
import org.apache.avalon.excalibur.pool.Poolable;
import org.apache.avalon.framework.configuration.Configuration;
import org.apache.avalon.framework.configuration.ConfigurationException;

// Cocoon classes
import org.apache.cocoon.environment.Redirector;
import org.apache.cocoon.environment.SourceResolver;
import org.apache.cocoon.acting.*;
import org.apache.cocoon.environment.Request;
import org.apache.cocoon.environment.ObjectModelHelper;
import org.apache.cocoon.environment.Session;
import org.apache.cocoon.environment.Context;

// Schematron classes
//import org.apache.cocoon.validation.SchemaFactory;
//import org.apache.cocoon.validation.Schema;
//import org.apache.cocoon.validation.Validator;
//import org.apache.cocoon.validation.Violation;

// 

Re: What are the problems with JDK 1.4?

[Sam]

Hi,
I've been playing with Cocoon 2 for a while now in my spare time, it's
quite a piece of work, guys! Anyhow, even using the latest source from CVS
with JDK1.3 the JDBC Pooling seems to have some strange behaviour when more
than 1 datasource is involved.

If I add another jdbc datasource to the cocoon.xconf file, (in my example
I added a mysql database, using the latest mm Mysql driver) cocoon seems to be
confused about which database to use when i go to the forms/employee database
example. If I remove the new datasource, it works fine. The same problem
exists on a page that I write that uses the new datasource - for now my
workaround was simply to do away with HSQLdb, but I thought I might mention it
- I would have thought multiple sources ought to be possible.

--- snippet from cocoon.xconf ---
  

  
  jdbc:mysql://192.168.0.111/gorb
  gorb
  f1kus


  
  jdbc:hsqldb:hsql://localhost:9002
  sa
  

  

-- console errors from tomcat (4.0.1) when navigating to forms/employee sample
URL --
DriverManager.getConnection("jdbc:mysql://192.168.0.111/gorb")
trying
driver[className=org.gjt.mm.mysql.Driver,org.gjt.mm.mysql.Driver@2bc3f5]
getConnection returning
driver[className=org.gjt.mm.mysql.Driver,org.gjt.mm.mysql.Driver@2bc3f5]
DriverManager.getConnection("jdbc:hsqldb:hsql://localhost:9002")
trying
driver[className=org.gjt.mm.mysql.Driver,org.gjt.mm.mysql.Driver@2bc3f5]
getConnection: no suitable driver
java.sql.SQLException: No suitable driver
 at java.sql.DriverManager.getConnection(DriverManager.java:537)
 at java.sql.DriverManager.getConnection(DriverManager.java:177)
 at
org.apache.avalon.excalibur.datasource.JdbcConnectionFactory.(JdbcConnectionFactory.java:98)

 at
org.apache.avalon.excalibur.datasource.ResourceLimitingJdbcDataSource.configure(ResourceLimitingJdbcDataSource.java:292)

 at
org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:191)

 at
org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.initialize(ThreadSafeComponentHandler.java:104)

 at
org.apache.avalon.excalibur.component.ExcaliburComponentSelector.addComponent(ExcaliburComponentSelector.java:507)

 at
org.apache.avalon.excalibur.component.ExcaliburComponentSelector.configure(ExcaliburComponentSelector.java:336)

 at
org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:191)

 at
org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.initialize(ThreadSafeComponentHandler.java:104)

 at
org.apache.avalon.excalibur.component.ExcaliburComponentManager.initialize(ExcaliburComponentManager.java:157)

 at org.apache.cocoon.Cocoon.initialize(Cocoon.java:274)
 at
org.apache.cocoon.servlet.CocoonServlet.createCocoon(CocoonServlet.java:1221)
 at org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:422)
 at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:852)
 at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3267)

 at org.apache.catalina.core.StandardContext.start(StandardContext.java:3384)
 at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:785)
 at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:454) at
org.apache.catalina.core.StandardHost.install(StandardHost.java:712)
 at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:647)
 at org.apache.catalina.startup.HostConfig.start(HostConfig.java:777)
 at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:463)

 at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:155)

 at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1131) at
org.apache.catalina.core.StandardHost.start(StandardHost.java:612)
 at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123) at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:307)
 at org.apache.catalina.core.StandardService.start(StandardService.java:388)
 at org.apache.catalina.core.StandardServer.start(StandardServer.java:505)
 at org.apache.catalina.startup.Catalina.start(Catalina.java:776)
 at org.apache.catalina.startup.Catalina.execute(Catalina.java:681)
 at org.apache.catalina.startup.Catalina.process(Catalina.java:179)
 at java.lang.reflect.Method.invoke(Native Method)
 at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243)
SQLException: SQLState(08001)

>

--
Sam Coward, Systems Engineer, Golden Orb Technologies
http://www.golden-orb.com


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

XMLForm hello world in the works

[Andrew C. Oliver]

Hi All,

I'm trying to create a HelloXMLForm example and I'm getting this:

/The processing instruction target matching "[xX][mM][lL]" is not allowed./

More precisely:

/org.apache.cocoon.ProcessingException: Failed to execute pipeline.: 
org.xml.sax.SAXParseException: The processing instruction target 
matching "[xX][mM][lL]" is not allowed./

(to see the full error you can go to 
http://www.superlinksoftware.com/cocoon/samples/bringmethis/hello.html)

any thoughts on what this means?  

relevent sitemap entries:

 
  


  
  


  
  
   
   
  
  
  
  
  
  
  
 



   
   


  
  
  
  

  
  
  
   
  
  
  
  

   

...

here is my xml form



http://xml.apache.org/cocoon/xmlform/2002";>


  

Hello


  



Last Name




First Name




  Next


  



here is  my action

// Java classes
import java.util.Map;
import java.util.HashMap;
import java.util.SortedSet;
import java.util.Iterator;
import java.util.Properties;
import java.io.InputStream;
import java.io.FileInputStream;
import java.io.File;

// XML classes
// import javax.xml.transform.stream.StreamSource;
// import javax.xml.transform.TransformerException;
// import org.xml.sax.InputSource;
// import org.w3c.dom.Node;
// import org.w3c.dom.NodeList;

// Framework classes
import org.apache.avalon.framework.parameters.Parameters;
import org.apache.avalon.excalibur.pool.Poolable;
import org.apache.avalon.framework.configuration.Configuration;
import org.apache.avalon.framework.configuration.ConfigurationException;

// Cocoon classes
import org.apache.cocoon.environment.Redirector;
import org.apache.cocoon.environment.SourceResolver;
import org.apache.cocoon.acting.*;
import org.apache.cocoon.environment.Request;
import org.apache.cocoon.environment.ObjectModelHelper;
import org.apache.cocoon.environment.Session;
import org.apache.cocoon.environment.Context;

// Schematron classes
//import org.apache.cocoon.validation.SchemaFactory;
//import org.apache.cocoon.validation.Schema;
//import org.apache.cocoon.validation.Validator;
//import org.apache.cocoon.validation.Violation;

// Cocoon XMLForm
import org.apache.cocoon.acting.AbstractXMLFormAction;
import org.apache.cocoon.components.xmlform.Form;
import org.apache.cocoon.components.xmlform.FormListener;


/**
 * This action demonstrates
 * a relatively complex form handling scenario.
 *
 * @author Heidi Brannan, [EMAIL PROTECTED]
 */
public class HelloAction
  extends AbstractXMLFormAction
  implements FormListener

{


  // different form views
  // participating in the wizard
  final String VIEW_HELLO = "hello";
  final String VIEW_SAYHELLO = "sayhello";

  // action commands used in the wizard
  final String CMD_START = "start";
  final String CMD_NEXT = "next";
  final String CMD_PREV = "prev";


  /**
   * The first callback method which is called
   * when an action is invoked.
   *
   * It is called before population.
   *
   *
   * @return null if the Action is prepared to continue.
   * an objectModel map which will be immediately returned by the action.
   *
   * This method is a good place to handle buttons with Cancel
   * kind of semantics. For example
   * if getCommand().equals("Cancel") return page("input");
   *
   */
  protected Map prepare()
  {

if ( getCommand() == null )
  {
return page( VIEW_HELLO );
  }
else   if ( getCommand().equals( CMD_START ) )
{
  // reset state by removing old form
  // if one exists
  Form.remove( getObjectModel(), getFormId() );
  getForm().addFormListener( this );

  return page( VIEW_HELLO );
}


// get ready for action
// if not ready return page("whereNext");
return null;
  }


  /**
   * Invoked after form population
   *
   * Semanticly similar to Struts Action.perform()
   *
   * Take appropriate action based on the command
   *
   */
  public Map perform ()
  {

// get the actual model which this Form encapsulates
// and apply additional buziness logic to the model
HelloBean  jBean = (HelloBean) getForm().getModel();
//jBean.incrementCount();

// set the page control flow parameter
// according to the validation result
if ( getCommand().equals( CMD_NEXT ) &&
  getForm().getViolations () != null )
{
  // errors, back to the same page
  return page( getFormView() );
}
else
{
  // validation passed
  // continue with control flow

  // clear validation left overs in case the user
  // did not press the Next button
  getForm().clearViolations();

  // get the user submitted command (through a submit button)
  String command = getCommand();
   

Cachability (was RE: XInclude Transformer vs CInlude Transformer)

[Conal Tuohy]

I've just been looking at "inclusion" recently and noticed that the cinclude
transformer had caching but the xinclude transformer didn't, and I wondered
if there was some arcane reason or was it just a historial accident ;-) And
BTW I think Carsten is right - the inclusion code should be united.

But actually my question is about caching of the DirectoryGenerator and
sub-classes. It seems to me that these transfomers should also be cacheable;
maybe this is just an oversight too? Or is there something tricky I haven't
forseen? ;-)

I have a pipeline based on a directory listing of xml docs; with 9 documents
it takes 2 or 3 seconds to complete - and with 100 docs it will be
impossible. But the files aren't often changed.

Anyway, I thought I might make an attempt at adding caching to the
DirectoryGenerator. It seems to me that the generator could perform the
search and traverse the file system every time a request is made, but hash
the resulting xml for the CacheValidity. Is that right? This would be my
first attempt.

I could enhance it to only traverse PART of the file system again to check
the validity, by keeping a record of the file and directory objects involved
in the last search. In the case of a directory search like "images/*.jpg",
or "docs/*.xml", the generator should only need to check the timestamp of
the "images" or "docs" directories, is that right? I've also used searches
like "images/{1}.jpg" with the ImageDirectoryGenerator, to get the image
width and height into a pipeline that converts the jpg to svg, for scaling,
etc. In this case the validity could depend on the timestamp of that single
file.

Any hints or comments would be much appreciated!

Con


> -Original Message-
> From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, 12 June 2002 19:03
> To: [EMAIL PROTECTED]
> Subject: RE: XInclude Transformer vs CInlude Transformer
>
>
>
> >
> > Carsten? Donald? Why we have two transformers?
> > :)
> >
> I don't remember the exact reason, but I think Stefano brought this up
> originally.
> The xinclude transformer implements the xinclude spec, but
> the cinclude
> transformer was invented to bring an easier and more
> intuitive notation for
> including documents. I quickly searched through the mail
> archive but didn't
> find the original mails...
>
> To be more precisly, we have three transformers doing the
> job! The session
> transformer also has an include concept which is more
> detailed than xinclude
> and cinclude as it can also do POST operations, pass parameters etc.
>
> I personally don't see a real problem in having different
> notations for the
> same job, but perhaps we can make one code bass out of it,
> let's say an
> include transformer doing xinclude, cinclude and the include
> job of the
> session transformer.
>
> Carsten
>
>
> -
> 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: XMLForms and Flowmap

[Daniel Fagerstrom]

Reinhard Poetz wrote:
> > We are looking for someone to step up and show us how these two can work
> > together in a nice way.
> >
> > Interested?
> >
> >
> > Ivelin
>
> Yes I am but my time and my java knowledge are limited (... but I'm
> learning)
>
> Anyway, I'll try it. Maybe there is somebody who has already some
> experience
> (Daniel?) who want's to join.

I'm afraid I won't have enough time to spare to do any programming, but I
will be happy to try to answer any questions that you might have.
I believe that the integration scheme that I proposed in:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102052662705449&w=2
should be fairly straight forward to implement and that it could be done
without any need to modify XMLForms or the Flowmap or even any Java
programming, it is probably enough with flowmap and sitemap writing. As I
haven't tried to implement it, and could of course missed some important
issues.

Feel free to ask if you need further clarification about my integration
proposal.

/Daniel



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

RE: Problems with my.roles going from 2.0.2 to 2.0.3

[Vadim Gritsenko]

> From: Stephan Michels [mailto:[EMAIL PROTECTED]]
> 
> 
> On Wed, 12 Jun 2002, Stuart Roebuck wrote:
> 
> > In order to resolve some problems in 2.0.2 and accommodate the
changes
> > in SourceResolvers between 2.0.2 and 2.0.3 I have moved my project
to
> > the latest 2.0.3 CVS and I'm now having problems using one of my own
> > non-sitemap components that was working fine in 2.0.2.
> 
> Cocoon uses now the SourceResolver from Excalibur:
> org.apache.excalibur.source.SourceResolver.
> 
> Is that our Problem?

Not in 2.0.3

Vadim


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

Re: Problems with my.roles going from 2.0.2 to 2.0.3

[Stephan Michels]

On Wed, 12 Jun 2002, Stuart Roebuck wrote:

> In order to resolve some problems in 2.0.2 and accommodate the changes
> in SourceResolvers between 2.0.2 and 2.0.3 I have moved my project to
> the latest 2.0.3 CVS and I'm now having problems using one of my own
> non-sitemap components that was working fine in 2.0.2.

Cocoon uses now the SourceResolver from Excalibur:
org.apache.excalibur.source.SourceResolver.

Is that our Problem?

Stephan Michels.


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

Re: Problems with my.roles going from 2.0.2 to 2.0.3

[Stuart Roebuck]

On Wednesday, June 12, 2002, at 09:50 pm, Stuart Roebuck wrote:

> In order to resolve some problems in 2.0.2 and accommodate the changes 
> in SourceResolvers between 2.0.2 and 2.0.3 I have moved my project to 
> the latest 2.0.3 CVS and I'm now having problems using one of my own 
> non-sitemap components that was working fine in 2.0.2.
>
> I've done a complete clean build of my own classes and 2.0.3.
>
> My 'my.roles' file is being found okay, if I move it I get a file not 
> found error on it.
>
> My Component is being 'composed' correctly.
>
> But the first time I use it I get:
>
>> org.apache.avalon.framework.component.ComponentException: Could not 
>> find component
>> at 
>> org.apache.avalon.excalibur.component.ExcaliburComponentManager.lookup
>> (ExcaliburComponentManager.java:341)
>> at org.apache.cocoon.components.CocoonComponentManager.lookup
>> (CocoonComponentManager.java:167)
>> at 
>> org.apache.avalon.excalibur.component.DefaultComponentFactory$ComponentManagerProxy.
>> lookup(DefaultComponentFactory.java:314)
>> at 
>> org.apache.avalon.excalibur.component.DefaultComponentFactory$ComponentManagerProxy.
>> lookup(DefaultComponentFactory.java:314)
>
> Any thoughts of anything that could have changed between 2.0.2 and 
> 2.0.3 that would require a change to my component?  Is there anything 
> more strict about registration of components or interface changes that 
> would not show up as compile errors.

I've also detected that 'configure' method of the component doesn't 
appear to being called.

Stuart.

Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck (Adolos)
  Key fingerprint = 89D9 E405 F8B1 9B22 0FA2  F2C1 9E57 5AB1 88DD 65AF
-
Stuart Roebuck  [EMAIL PROTECTED]
Systems Architect Java, XML, MacOS X, XP, 
etc.
ADOLOS   


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

Problems with my.roles going from 2.0.2 to 2.0.3

[Stuart Roebuck]

In order to resolve some problems in 2.0.2 and accommodate the changes 
in SourceResolvers between 2.0.2 and 2.0.3 I have moved my project to 
the latest 2.0.3 CVS and I'm now having problems using one of my own 
non-sitemap components that was working fine in 2.0.2.

I've done a complete clean build of my own classes and 2.0.3.

My 'my.roles' file is being found okay, if I move it I get a file not 
found error on it.

My Component is being 'composed' correctly.

But the first time I use it I get:

> org.apache.avalon.framework.component.ComponentException: Could not 
> find component
> at 
> org.apache.avalon.excalibur.component.ExcaliburComponentManager.lookup
> (ExcaliburComponentManager.java:341)
> at 
> org.apache.cocoon.components.CocoonComponentManager.lookup
> (CocoonComponentManager.java:167)
> at 
> org.apache.avalon.excalibur.component.DefaultComponentFactory$ComponentManagerProxy.
> lookup(DefaultComponentFactory.java:314)
> at 
> org.apache.avalon.excalibur.component.DefaultComponentFactory$ComponentManagerProxy.
> lookup(DefaultComponentFactory.java:314)

Any thoughts of anything that could have changed between 2.0.2 and 2.0.3 
that would require a change to my component?  Is there anything more 
strict about registration of components or interface changes that would 
not show up as compile errors.

Stuart.

Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck (Adolos)
  Key fingerprint = 89D9 E405 F8B1 9B22 0FA2  F2C1 9E57 5AB1 88DD 65AF
-
Stuart Roebuck  [EMAIL PROTECTED]
Systems Architect Java, XML, MacOS X, XP, 
etc.
ADOLOS   


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

DO NOT REPLY [Bug 4221] - Error in JaxpParser: Cannot find org.apache.cocoon.components.resolver.Resolver

[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=4221

Error in JaxpParser: Cannot find org.apache.cocoon.components.resolver.Resolver

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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

DO NOT REPLY [Bug 4221] - Error in JaxpParser: Cannot find org.apache.cocoon.components.resolver.Resolver

[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=4221

Error in JaxpParser: Cannot find org.apache.cocoon.components.resolver.Resolver

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2002-06-12 19:55 ---
>From http://www.inqmy.com/:
---
The software offered by In-Q-My Technologies GmbH, a wholly owned subsidiary of 
SAP AG, is being integrated into the mySAP Technology solution. In-Q-My 
Technologies no longer exists as a separate entity and its Web site has been 
closed.
---

In-Q-My Web Application server no longer exist, thus bug should be closed.

If there are issues with latest Cocoon and the SAP Web Application Server, new 
bug should be filed.

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

Re: AcceptSelector

[Diana Shannon]

On Wednesday, June 12, 2002, at 01:30  PM, Michael Hartle wrote:

>> How should I provide the source code so you can check it out? (I'm new
>> to cocoon-dev.)
>>
> This sounds interesting, so just go to Bugzilla and add it as a "bug" 
> for Cocoon 2, prefixing your Summary with "[PATCH]" and adding your 
> code as a zipped attachment; that way, anyone is able to check out your 
> code, it will be listed in the regular Patch mail to the cocoon-dev 
> list and if there are no objections, your addition can be added to the 
> CVS by a committer who has the time to do so.
>
> For an example of such a [PATCH] "bug" for Bugzilla, see 
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9404. To file your 
> patch, go to 
> http://nagoya.apache.org/bugzilla/enter_bug.cgi?product=Cocoon%202. You 
> will have to create an account, but this goes fast and doesn't hurt ;)

Please check out Cocoon's fine How-To, written by our very own David 
Crossley:
  http://xml.apache.org/cocoon/howto/howto-bugzilla.html

Diana


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

Re: [VOTE] Schematron validator in Anteater (and Cocoonvalidating Transformer)

[Ovidiu Predescu]

Ivelin,

I'm not Jeff, but I do have some ideas.

The Schematron validor would have a correspondent MatcherTest subclass in
Anteater. You would essentially need to implement the validate() method, in
which you call the Validator.validate() method. You either return true, if
Validator.validate() returns null, or you return false, and log the errors
using the inherited log() method.

Check out some of the matcher test classes in the
org/apache/anteater/test/matchers/ directory, like Parameter.java.

Regarding Junit reporting, I'd still like to understand a bit more what is
the idea behind this, and what would be the benefits of integrating with it.

Cheers,
Ovidiu

On 6/11/02 9:17 PM, "Ivelin Ivanov" <[EMAIL PROTECTED]> wrote:

> 
> Jeff,
> 
> The org.apache.cocoon.components.validation.Validator
> 
> interface has the following method:
> 
> List validate(Object instance)
> 
> It returns either null, when validation is successfull, or a list of
> Violation objects, each of which has an XPath address of the bad element
> and a String with the description of the problem.
> 
> How do you suggest I integrate this in Anteater?
> 
> Ideally I would like to integrate Anteater scripts with JUnit reports,
> so that the list of violations is listed in the place where unit test
> exceptions are repoported.
> 
> How is you progress with JUnit reports integration?
> 
> 
> BTW, JARV implements Relax NG validation.
> http://iso-relax.sourceforge.net/JARV/
> 
> 
> Ivelin
> 
> 
> 
> 
> 
> 
> Jeff Turner wrote:
>> Hi Ivelin,
>> 
>> On Fri, Jun 07, 2002 at 06:51:09PM -0500, Ivelin Ivanov wrote:
>> ...
>> 
>>> The ideas is to use references to schema documents of standard XML languages
>>> (like Schematron, DTD, XML Schema, Relax NG) for response validation,
>>> instead of supporting a proprietary grammar.
>> 
>> 
>> Adding a Schematron validator would be great. It would be a superset of
>> functionality provided by our existing  validator. I'd also like
>> to add a Relax NG validator at some stage.
>> 
>> 
>>> I suggest that we use the org.apache.cocoon.components.validation package
>>> which is an independent component in Cocoon's main tree and is used by
>>> XMLForm.
>>> 
>>> The Schematron implementation is already available and I think it is quite
>>> suitable for Anteater, because Schematron is a superset of Anteater's match
>>> element.
>>> To be precise it is a superset of the validating use, i.e the cases when
>>> match is used to assign value to a "result" property. Asigning values within
>>>  to other properties which are used for subsequent requests is a
>>> separate concern.
>> 
>> 
>> So..
>> 
>> Latka has it's Validator interface, consisting of:
>> 
>> public abstract void validate(Response response) throws ValidationException;
>>  // throw an exception on validation failure
>> 
>> Anteater has a MatcherTest abstract class:
>> 
>>   public void setObjectModel(HashMap objectModel);
>>   public abstract boolean validate() throws BuildException;
>>   public boolean getResult();
>> 
>> And Cocoon has another Validator interface:
>> 
>>   public abstract void validate(Response response) throws
>> ValidationException;
>>   public void setProperty(java.lang.String property, java.lang.Object value);
>>   public java.lang.Object getProperty(java.lang.String property);
>> 
>> Here are the validators currently available:
>> 
>> ByteLengthValidator (Latka)
>> CookieValidator (Latka, Anteater)
>> ContentEquals (compare contents vs. file) (Latka, Anteater)
>> MaxRequestTimeValidator (Latka)
>> RegexpValidator (Latka, Anteater, Webtest)
>> StatusCodeValidator (Latka, Anteater)
>> XPathValidator (Latka, Anteater)
>> SchematronValidator (Cocoon)
>> 
>> It would be good if we could come up with a common API that everyone
>> could implement. Eg, adopt Latka or Cocoon's Request/Response
>> abstraction, plus Anteater/Cocoon's ability to pass an 'object model'
>> (aka Avalon Context). Plus I'd like some way to record what's been done,
>> for later reporting.
>> 
>> But anyway, that's for down the road. There are few enough validators
>> currently that it's less effort just to modify the code for each testing
>> framework.
>> 
>> 
>> 
>> 
>> Schematron looks very cool. Another even easier-to-use possibility would
>> be Examplotron (http://examplotron.org/).
>> 
>> 
>> We live in dark days where the majority of Apache is unthinkingly
>> adopting XML Schema, despite it's inferiority, simply because it's from
>> the W3C. Kimbro Staken said it best:
>> http://radio.weblogs.com/0100213/2002/06/06.html#a392
>> 
>> 
>>> The violations can be then nicely integrated in the JUnit reporting
>>> package.
>> 
>> 
>> I have JUnit formatting integration minimally working here, will clean
>> up, check in and announce it tomorrow probably.
>> 
>> 
>>> If there are enough votes I'll contribute some of the work myself.
>>> Help would be certainly appreciated.
>> 
>> 
>> +1 :)
>> 
>> If any Cocoon developers are interested, and want to help or just l

Re: sitemap recursive?

[Jeremy Quinn]

On Wednesday, June 12, 2002, at 01:50 PM, Vadim Gritsenko wrote:

>> From: Jeremy Quinn [mailto:[EMAIL PROTECTED]]
>>
>> Is it safe to use the SiteMap recursively?
>
> There are no technical limitations to it.
>
>
>> (can XSLT use the cocoon:/ protocol?)
>
> (yes)
>

Cool!

Thanks Vadim,

regards Jeremy


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

DO NOT REPLY [Bug 9725] - GB2312 support in XSP

[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=9725

GB2312 support in XSP

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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

DO NOT REPLY [Bug 9725] - GB2312 support in XSP

[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=9725

GB2312 support in XSP

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

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

Re: AcceptSelector

[Michael Hartle]

Jonas Petersen wrote:



>The best would probably be to combine the caching and the precalculation
>at the beginning of the block.
>
>So what do you think about it? Is it useful? Would it make sense to
>include it into cocoon?
>
>How should I provide the source code so you can check it out? (I'm new
>to cocoon-dev.)
>
This sounds interesting, so just go to Bugzilla and add it as a "bug" 
for Cocoon 2, prefixing your Summary with "[PATCH]" and adding your code 
as a zipped attachment; that way, anyone is able to check out your code, 
it will be listed in the regular Patch mail to the cocoon-dev list and 
if there are no objections, your addition can be added to the CVS by a 
committer who has the time to do so.

For an example of such a [PATCH] "bug" for Bugzilla, see 
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9404. To file your 
patch, go to 
http://nagoya.apache.org/bugzilla/enter_bug.cgi?product=Cocoon%202. You 
will have to create an account, but this goes fast and doesn't hurt ;)

Best regards,

Michael Hartle,
Hartle & Klug GbR


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

Re: AcceptSelector

[Peter Royal]

On Wednesday 12 June 2002 01:20 pm, Jonas Petersen wrote:
> I am working on a selector that analyses the  Accept header of the
> browser and provides a way to (for example) response with the best
> fitting content(-type). It's comparable with the apache module
> 'mod_negotiation'.

awesome!

> Now a problem that I encountered:
>
> For each  the select() function gets called. There I do the
> weight calculations with the current Accept header against the
> configuration. This produces some overhead because this really needs to
> happen only once (in the beginning of the .

Already encountered. Look at the Switch Selector:
http://cvs.apache.org/viewcvs/xml-cocoon2/src/java/org/apache/cocoon/selection/SwitchSelector.java

-pete

-- 
peter royal -> [EMAIL PROTECTED]

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

DO NOT REPLY [Bug 9621] - [PATCH] ByteRangeResourceReader

[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=9621

[PATCH] ByteRangeResourceReader

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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

DO NOT REPLY [Bug 9621] - [PATCH] ByteRangeResourceReader

[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=9621

[PATCH] ByteRangeResourceReader

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-06-12 17:26 ---
Hi Stuart,
I applied your contribution into HEAD/scratchpad!

TIA

Gerhard

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

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/util ByteRange.java

[froehlich]

froehlich2002/06/12 10:25:37

  Added:   src/scratchpad/src/org/apache/cocoon/util ByteRange.java
  Log:
  applied patch from [EMAIL PROTECTED]
  added ByteRangeResourceReader
  
  Revision  ChangesPath
  1.1  
xml-cocoon2/src/scratchpad/src/org/apache/cocoon/util/ByteRange.java
  
  Index: ByteRange.java
  ===
  /*
  
   
 The Apache Software License, Version 1.1
   
  
   Copyright (C) 1999-2002 The Apache Software Foundation. All rights reserved.
  
   Redistribution and use in source and binary forms, with or without modifica-
   tion, are permitted provided that the following conditions are met:
  
   1. Redistributions of  source code must  retain the above copyright  notice,
  this list of conditions and the following disclaimer.
  
   2. Redistributions in binary form must reproduce the above copyright notice,
  this list of conditions and the following disclaimer in the documentation
  and/or other materials provided with the distribution.
  
   3. The end-user documentation included with the redistribution, if any, must
  include  the following  acknowledgment:  "This product includes  software
  developed  by the  Apache Software Foundation  (http://www.apache.org/)."
  Alternately, this  acknowledgment may  appear in the software itself,  if
  and wherever such third-party acknowledgments normally appear.
  
   4. The names "Apache Cocoon" and  "Apache Software Foundation" must  not  be
  used to  endorse or promote  products derived from  this software without
  prior written permission. For written permission, please contact
  [EMAIL PROTECTED]
  
   5. Products  derived from this software may not  be called "Apache", nor may
  "Apache" appear  in their name,  without prior written permission  of the
  Apache Software Foundation.
  
   THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
   INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
   FITNESS  FOR A PARTICULAR  PURPOSE ARE  DISCLAIMED.  IN NO  EVENT SHALL  THE
   APACHE SOFTWARE  FOUNDATION  OR ITS CONTRIBUTORS  BE LIABLE FOR  ANY DIRECT,
   INDIRECT, INCIDENTAL, SPECIAL,  EXEMPLARY, OR CONSEQUENTIAL  DAMAGES (INCLU-
   DING, BUT NOT LIMITED TO, PROCUREMENT  OF SUBSTITUTE GOODS OR SERVICES; LOSS
   OF USE, DATA, OR  PROFITS; OR BUSINESS  INTERRUPTION)  HOWEVER CAUSED AND ON
   ANY  THEORY OF LIABILITY,  WHETHER  IN CONTRACT,  STRICT LIABILITY,  OR TORT
   (INCLUDING  NEGLIGENCE OR  OTHERWISE) ARISING IN  ANY WAY OUT OF THE  USE OF
   THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  
   This software  consists of voluntary contributions made  by many individuals
   on  behalf of the Apache Software  Foundation and was  originally created by
   Stefano Mazzocchi  <[EMAIL PROTECTED]>. For more  information on the Apache
   Software Foundation, please see .
  
  */
  package org.apache.cocoon.util;
  
  import java.util.StringTokenizer;
  
  /**
   * @author mailto:[EMAIL PROTECTED]";>Stuart Roebuck
   * @version CVS $Id: ByteRange.java,v 1.1 2002/06/12 17:25:37 froehlich Exp $
   */
  public class ByteRange {
  
  
  private final long start;
  private final long end;
  
  
  public ByteRange(long start, long end) {
  this.start = start;
  this.end = end;
  }
  
  
  public ByteRange(String string) throws NumberFormatException {
  string = string.trim();
  int dashPos = string.indexOf('-');
  int length = string.length();
  if (string.indexOf(',') != -1) {
  throw new NumberFormatException("Simple ByteRange String contains a 
comma.");
  }
  if (dashPos > 0) {
  this.start = Integer.parseInt(string.substring(0, dashPos));
  } else {
  this.start = Long.MIN_VALUE;
  }
  if (dashPos < length - 1) {
  this.end = Integer.parseInt(string.substring(dashPos + 1, length));
  } else {
  this.end = Long.MAX_VALUE;
  }
  if (this.start > this.end) {
  throw new NumberFormatException("Start value is greater than end 
value.");
  }
  }
  
  
  public long getStart() {
  return this.start;
  }
  
  
  public long getEnd() {
  return this.end;
  }
  
  
  public long length() {
  return this.end - this.start + 1;
  }
  
  
  public ByteRange intersection(ByteRange range) {
  if (range.end < this.start || this.end < range.start) {
  return null;
  } else {
  long start = (this.start > range.start) ? this.start : range.start;

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/reading ByteRangeResourceReader.java

[froehlich]

froehlich2002/06/12 10:25:23

  Added:   src/scratchpad/src/org/apache/cocoon/reading
ByteRangeResourceReader.java
  Log:
  applied patch from [EMAIL PROTECTED]
  added ByteRangeResourceReader
  
  Revision  ChangesPath
  1.1  
xml-cocoon2/src/scratchpad/src/org/apache/cocoon/reading/ByteRangeResourceReader.java
  
  Index: ByteRangeResourceReader.java
  ===
  /*
  
   
 The Apache Software License, Version 1.1
   
  
   Copyright (C) 1999-2002 The Apache Software Foundation. All rights reserved.
  
   Redistribution and use in source and binary forms, with or without modifica-
   tion, are permitted provided that the following conditions are met:
  
   1. Redistributions of  source code must  retain the above copyright  notice,
  this list of conditions and the following disclaimer.
  
   2. Redistributions in binary form must reproduce the above copyright notice,
  this list of conditions and the following disclaimer in the documentation
  and/or other materials provided with the distribution.
  
   3. The end-user documentation included with the redistribution, if any, must
  include  the following  acknowledgment:  "This product includes  software
  developed  by the  Apache Software Foundation  (http://www.apache.org/)."
  Alternately, this  acknowledgment may  appear in the software itself,  if
  and wherever such third-party acknowledgments normally appear.
  
   4. The names "Apache Cocoon" and  "Apache Software Foundation" must  not  be
  used to  endorse or promote  products derived from  this software without
  prior written permission. For written permission, please contact
  [EMAIL PROTECTED]
  
   5. Products  derived from this software may not  be called "Apache", nor may
  "Apache" appear  in their name,  without prior written permission  of the
  Apache Software Foundation.
  
   THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
   INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
   FITNESS  FOR A PARTICULAR  PURPOSE ARE  DISCLAIMED.  IN NO  EVENT SHALL  THE
   APACHE SOFTWARE  FOUNDATION  OR ITS CONTRIBUTORS  BE LIABLE FOR  ANY DIRECT,
   INDIRECT, INCIDENTAL, SPECIAL,  EXEMPLARY, OR CONSEQUENTIAL  DAMAGES (INCLU-
   DING, BUT NOT LIMITED TO, PROCUREMENT  OF SUBSTITUTE GOODS OR SERVICES; LOSS
   OF USE, DATA, OR  PROFITS; OR BUSINESS  INTERRUPTION)  HOWEVER CAUSED AND ON
   ANY  THEORY OF LIABILITY,  WHETHER  IN CONTRACT,  STRICT LIABILITY,  OR TORT
   (INCLUDING  NEGLIGENCE OR  OTHERWISE) ARISING IN  ANY WAY OUT OF THE  USE OF
   THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  
   This software  consists of voluntary contributions made  by many individuals
   on  behalf of the Apache Software  Foundation and was  originally created by
   Stefano Mazzocchi  <[EMAIL PROTECTED]>. For more  information on the Apache
   Software Foundation, please see .
  
  */
  package org.apache.cocoon.reading;
  
  import org.apache.avalon.framework.parameters.Parameters;
  import org.apache.cocoon.ProcessingException;
  import org.apache.cocoon.caching.CacheValidity;
  import org.apache.cocoon.caching.Cacheable;
  import org.apache.cocoon.caching.TimeStampCacheValidity;
  import org.apache.cocoon.environment.Context;
  import org.apache.cocoon.environment.ObjectModelHelper;
  import org.apache.cocoon.environment.Request;
  import org.apache.cocoon.environment.Response;
  import org.apache.cocoon.environment.Source;
  import org.apache.cocoon.environment.SourceResolver;
  import org.apache.cocoon.environment.http.HttpResponse;
  import org.apache.cocoon.util.ByteRange;
  import org.apache.cocoon.util.HashUtil;
  import org.xml.sax.SAXException;
  
  import java.io.IOException;
  import java.io.InputStream;
  import java.util.Date;
  import java.util.Map;
  import java.util.StringTokenizer;
  
  /**
   *
   *
   * The ResourceReader component is used to serve binary data
   * in a sitemap pipeline. It makes use of HTTP Headers to determine if
   * the requested resource should be written to the OutputStream
   * or if it can signal that it hasn't changed.
   *
   * Parameters:
   *   
   * 
   *   This parameter is optional. When specified it determines how long
   *   in miliseconds the resources can be cached by any proxy or browser
   *   between Cocoon2 and the requesting visitor.
   *   
   *   
   *
   * @author mailto:[EMAIL PROTECTED]";>Giacomo Pati
   * @version CVS $Id: ByteRangeResourceReader.java,v 1.1 2002/06/12 17:25:23 
froehlich Exp $
   */
  public class ByteRangeResourceReader
extends AbstractReader
implements Cachea

AcceptSelector

[Jonas Petersen]

Hi,

I am working on a selector that analyses the  Accept header of the
browser and provides a way to (for example) response with the best
fitting content(-type). It's comparable with the apache module
'mod_negotiation'.

The main class is named 'AcceptSelector'. It is based on the abstract
class 'WeightedTypesSelector'.

The (sitemap) configuration of the AcceptSelector is made up of a list
of possible variants to check against. Each variant has a name, a
mime-type and a weight.


Example of a Accept header sent by the browser:
-
Accept: text/xml, application/xml, application/xhtml+xml,
text/html;q=0.9, image
/png, image/jpeg, image/gif;q=0.2, text/plain;q=0.8, text/css, */*;q=0.1
-

Example of a sitemap configuration:
-
   
 
 
 
   
-

The selector multiplies the weights of the mime-types in the Accept
header (q=...) with the weights of the variants in the sitemap (qs=...)
(if no weight is given a value of 1.0 is used). The variant with the
highest value gets selected. If multiple variants have the same result,
the variant that appears first gets selected.

In the above example the variant 'html' would make it, because the
mime-type 'text/html' is found in the header and the config and yields a
weight of 0.72 (0.9 * 0.8). 'wml' matches with '*/*' (0.1 * 0.9 = 0.09).
Using the mime-type '*/*' as a variant helps in providing default
variants (it behaves differently than ).

Example of a  using the AcceptSelector:
-

  

  
  


  
  


  
  

  

-

Now a problem that I encountered:

For each  the select() function gets called. There I do the
weight calculations with the current Accept header against the
configuration. This produces some overhead because this really needs to
happen only once (in the beginning of the .

I'm thinking about caching the results for each different Accept header.

Maybe it would be good to do these calculations at the beginning of the
 block. But it seems there is no temporary context/instance
within the block or a way to initialize a . Or is there? To
me this seems to be a general problem with the selectors, because if
there is lots of s then there might be lots of unnecessarily
repeated code.

The best would probably be to combine the caching and the precalculation
at the beginning of the block.

So what do you think about it? Is it useful? Would it make sense to
include it into cocoon?

How should I provide the source code so you can check it out? (I'm new
to cocoon-dev.)

regards,
Jonas

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

CachingPoint algorithm and treeprocessor

[Michael Melhem]

Hi Carsten,

Hows things, I hope all is well in your neck of the woods!

As we have been discussing earlier, I have been doing some more work
on "cache points" I believe I have something that appears to be workng!

However, there a couple of issues I would like to run by you:

Issue 1.
I have added  a new method to the interface "ProcessingPipeline.java".
Namely,  public void informBranchPoint();

In "AbstractProcessingPipeline.java" the default implementation of this
method simply does nothing. ie public void informBranchPoint() {}. It is
redifined in CachingPOINTProcessingPipeline to do something meaningful.

The above method is used within the treeprocessor to inform the chosen pipeline
implementation that we have come across a branch in the tree.  What the
pipeline does with this information is up to the particular chosen
implementation. The default caching implementation ignores it. As an example,
here is a code snippet from GenerateNode.java.

-
...
if (this.views != null) {
   //
   //
   // Inform the pipeline that we have a branch
   // point
   //
   context.getProcessingPipeline().informBranchPoint();

   String cocoonView = env.getView();
   if (cocoonView != null) {
...
-

Do you think the above proposed change to treeprocessing is acceptable in terms of
performance etc? At the moment I dont see a way around it.



Issue 2.
I was thinking of breaking up some of the methods in CachingProcessingPipeline.java
so that my modifcations can be easly moved into a sub class. This Would
Involve creating something like AbstractCachingProcessingPipeline.java,
wth CachingProcessingPipeline.java and CachingIPointProcessingPipeline.java would
implementing this. What do you think of this?


Many thanks,
Michael Melhem



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

DO NOT REPLY [Bug 9404] - [PATCH] JSP like Tag-Library Implementation

[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=9404

[PATCH] JSP like Tag-Library Implementation

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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

DO NOT REPLY [Bug 9404] - [PATCH] JSP like Tag-Library Implementation

[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=9404

[PATCH] JSP like Tag-Library Implementation

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-06-12 16:55 ---
Hi Volker,
I applied your patch into HEAD/scratchpad.

TIA for your contribution, sorry for the late review
and stay tuned.

Greets
Gerhard

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

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/transformation TagTransformer.java

[froehlich]

froehlich2002/06/12 09:53:43

  Added:   src/scratchpad/src/org/apache/cocoon/transformation
TagTransformer.java
  Log:
  applied patch from [EMAIL PROTECTED] .
  JSP like Tag-Library Implementation
  
  Revision  ChangesPath
  1.1  
xml-cocoon2/src/scratchpad/src/org/apache/cocoon/transformation/TagTransformer.java
  
  Index: TagTransformer.java
  ===
  /*
  
   
 The Apache Software License, Version 1.1
   
  
   Copyright (C) 1999-2002 The Apache Software Foundation. All rights reserved.
  
   Redistribution and use in source and binary forms, with or without modifica-
   tion, are permitted provided that the following conditions are met:
  
   1. Redistributions of  source code must  retain the above copyright  notice,
  this list of conditions and the following disclaimer.
  
   2. Redistributions in binary form must reproduce the above copyright notice,
  this list of conditions and the following disclaimer in the documentation
  and/or other materials provided with the distribution.
  
   3. The end-user documentation included with the redistribution, if any, must
  include  the following  acknowledgment:  "This product includes  software
  developed  by the  Apache Software Foundation  (http://www.apache.org/)."
  Alternately, this  acknowledgment may  appear in the software itself,  if
  and wherever such third-party acknowledgments normally appear.
  
   4. The names "Apache Cocoon" and  "Apache Software Foundation" must  not  be
  used to  endorse or promote  products derived from  this software without
  prior written permission. For written permission, please contact
  [EMAIL PROTECTED]
  
   5. Products  derived from this software may not  be called "Apache", nor may
  "Apache" appear  in their name,  without prior written permission  of the
  Apache Software Foundation.
  
   THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
   INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
   FITNESS  FOR A PARTICULAR  PURPOSE ARE  DISCLAIMED.  IN NO  EVENT SHALL  THE
   APACHE SOFTWARE  FOUNDATION  OR ITS CONTRIBUTORS  BE LIABLE FOR  ANY DIRECT,
   INDIRECT, INCIDENTAL, SPECIAL,  EXEMPLARY, OR CONSEQUENTIAL  DAMAGES (INCLU-
   DING, BUT NOT LIMITED TO, PROCUREMENT  OF SUBSTITUTE GOODS OR SERVICES; LOSS
   OF USE, DATA, OR  PROFITS; OR BUSINESS  INTERRUPTION)  HOWEVER CAUSED AND ON
   ANY  THEORY OF LIABILITY,  WHETHER  IN CONTRACT,  STRICT LIABILITY,  OR TORT
   (INCLUDING  NEGLIGENCE OR  OTHERWISE) ARISING IN  ANY WAY OUT OF THE  USE OF
   THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  
   This software  consists of voluntary contributions made  by many individuals
   on  behalf of the Apache Software  Foundation and was  originally created by
   Stefano Mazzocchi  <[EMAIL PROTECTED]>. For more  information on the Apache
   Software Foundation, please see .
  
  */
  package org.apache.cocoon.transformation;
  
  import java.beans.BeanInfo;
  import java.beans.IntrospectionException;
  import java.beans.Introspector;
  import java.beans.PropertyDescriptor;
  import java.io.IOException;
  import java.lang.reflect.Method;
  import java.util.HashMap;
  import java.util.Map;
  
  import org.apache.avalon.excalibur.collections.ArrayStack;
  import org.apache.avalon.excalibur.collections.BucketMap;
  import org.apache.avalon.excalibur.pool.Recyclable;
  import org.apache.avalon.framework.activity.Disposable;
  import org.apache.avalon.framework.component.ComponentException;
  import org.apache.avalon.framework.component.ComponentManager;
  import org.apache.avalon.framework.component.ComponentSelector;
  import org.apache.avalon.framework.component.Composable;
  import org.apache.avalon.framework.configuration.Configurable;
  import org.apache.avalon.framework.configuration.Configuration;
  import org.apache.avalon.framework.configuration.ConfigurationException;
  import org.apache.avalon.framework.parameters.Parameters;
  import org.apache.cocoon.components.sax.XMLDeserializer;
  import org.apache.cocoon.components.sax.XMLSerializer;
  import org.apache.cocoon.environment.SourceResolver;
  import org.apache.cocoon.taglib.IterationTag;
  import org.apache.cocoon.taglib.Tag;
  import org.apache.cocoon.xml.AbstractXMLProducer;
  import org.apache.cocoon.xml.XMLConsumer;
  import org.apache.cocoon.xml.XMLProducer;
  
  import org.xml.sax.Attributes;
  import org.xml.sax.SAXException;
  
  /**
   * Transformer which implements the dynamic Tag functionalty.
   * 
   * @author mailto:[EMAIL PROTECTED]";>Volker Schmitt
   */
  public class TagTransformer
  extends AbstractXMLProduce

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/jxpath JXPathCocoonContexts.java CocoonSessionHandler.java CocoonRequestHandler.java CocoonContextHandler.java

[froehlich]

froehlich2002/06/12 09:50:45

  Added:   src/scratchpad/src/org/apache/cocoon/jxpath
JXPathCocoonContexts.java CocoonSessionHandler.java
CocoonRequestHandler.java CocoonContextHandler.java
  Log:
  applied patch from [EMAIL PROTECTED] .
  JSP like Tag-Library Implementation
  
  Revision  ChangesPath
  1.1  
xml-cocoon2/src/scratchpad/src/org/apache/cocoon/jxpath/JXPathCocoonContexts.java
  
  Index: JXPathCocoonContexts.java
  ===
  /*
  
   
 The Apache Software License, Version 1.1
   
  
   Copyright (C) 1999-2002 The Apache Software Foundation. All rights reserved.
  
   Redistribution and use in source and binary forms, with or without modifica-
   tion, are permitted provided that the following conditions are met:
  
   1. Redistributions of  source code must  retain the above copyright  notice,
  this list of conditions and the following disclaimer.
  
   2. Redistributions in binary form must reproduce the above copyright notice,
  this list of conditions and the following disclaimer in the documentation
  and/or other materials provided with the distribution.
  
   3. The end-user documentation included with the redistribution, if any, must
  include  the following  acknowledgment:  "This product includes  software
  developed  by the  Apache Software Foundation  (http://www.apache.org/)."
  Alternately, this  acknowledgment may  appear in the software itself,  if
  and wherever such third-party acknowledgments normally appear.
  
   4. The names "Apache Cocoon" and  "Apache Software Foundation" must  not  be
  used to  endorse or promote  products derived from  this software without
  prior written permission. For written permission, please contact
  [EMAIL PROTECTED]
  
   5. Products  derived from this software may not  be called "Apache", nor may
  "Apache" appear  in their name,  without prior written permission  of the
  Apache Software Foundation.
  
   THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
   INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
   FITNESS  FOR A PARTICULAR  PURPOSE ARE  DISCLAIMED.  IN NO  EVENT SHALL  THE
   APACHE SOFTWARE  FOUNDATION  OR ITS CONTRIBUTORS  BE LIABLE FOR  ANY DIRECT,
   INDIRECT, INCIDENTAL, SPECIAL,  EXEMPLARY, OR CONSEQUENTIAL  DAMAGES (INCLU-
   DING, BUT NOT LIMITED TO, PROCUREMENT  OF SUBSTITUTE GOODS OR SERVICES; LOSS
   OF USE, DATA, OR  PROFITS; OR BUSINESS  INTERRUPTION)  HOWEVER CAUSED AND ON
   ANY  THEORY OF LIABILITY,  WHETHER  IN CONTRACT,  STRICT LIABILITY,  OR TORT
   (INCLUDING  NEGLIGENCE OR  OTHERWISE) ARISING IN  ANY WAY OUT OF THE  USE OF
   THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  
   This software  consists of voluntary contributions made  by many individuals
   on  behalf of the Apache Software  Foundation and was  originally created by
   Stefano Mazzocchi  <[EMAIL PROTECTED]>. For more  information on the Apache
   Software Foundation, please see .
  
  */
  
  package org.apache.cocoon.jxpath;
  
  import java.util.Map;
  
  import org.apache.avalon.excalibur.pool.Recyclable;
  import org.apache.cocoon.components.RequestLifecycleComponent;
  import org.apache.cocoon.environment.Context;
  import org.apache.cocoon.environment.ObjectModelHelper;
  import org.apache.cocoon.environment.Request;
  import org.apache.cocoon.environment.Session;
  import org.apache.cocoon.environment.SourceResolver;
  import org.apache.cocoon.environment.http.HttpContext;
  import org.apache.cocoon.environment.http.HttpRequest;
  import org.apache.cocoon.environment.http.HttpSession;
  import org.apache.commons.jxpath.JXPathContext;
  import org.apache.commons.jxpath.JXPathContextFactory;
  import org.apache.commons.jxpath.JXPathIntrospector;
  import org.apache.commons.jxpath.servlet.Constants;
  import org.apache.commons.jxpath.servlet.KeywordVariables;
  
  /**
   * Component that allocate and cache JXPathContexts bound to VariableContext,
   * Cocoon Request, Cocoon Session and Cocoon Context.
   * 
   * If you need to limit the attibute lookup to just one scope, you can use the
   * pre-definded variables "request", "session" and "application".
   * For example, the expression "$session/foo" extracts the value of the
   * session attribute named "foo".
   * 
   * Following are some implementation details.
   * There is a separate JXPathContext for each of the four scopes. These contexts are 
chained
   * according to the nesting of the scopes.  So, the parent of the "variable"
   * JXPathContext is a "request" JXPathContext, whose parent is a "session"
   * JXPathContext (that is i

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/jxpath - New directory

[froehlich]

froehlich2002/06/12 09:50:33

  xml-cocoon2/src/scratchpad/src/org/apache/cocoon/jxpath - 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/scratchpad/src/org/apache/cocoon/taglib/test IterationTestTag.java HelloWorldTag.java

[froehlich]

froehlich2002/06/12 09:50:00

  Added:   src/scratchpad/src/org/apache/cocoon/taglib/test
IterationTestTag.java HelloWorldTag.java
  Log:
  applied patch from [EMAIL PROTECTED] .
  JSP like Tag-Library Implementation
  
  Revision  ChangesPath
  1.1  
xml-cocoon2/src/scratchpad/src/org/apache/cocoon/taglib/test/IterationTestTag.java
  
  Index: IterationTestTag.java
  ===
  /*
  
   
 The Apache Software License, Version 1.1
   
  
   Copyright (C) 1999-2002 The Apache Software Foundation. All rights reserved.
  
   Redistribution and use in source and binary forms, with or without modifica-
   tion, are permitted provided that the following conditions are met:
  
   1. Redistributions of  source code must  retain the above copyright  notice,
  this list of conditions and the following disclaimer.
  
   2. Redistributions in binary form must reproduce the above copyright notice,
  this list of conditions and the following disclaimer in the documentation
  and/or other materials provided with the distribution.
  
   3. The end-user documentation included with the redistribution, if any, must
  include  the following  acknowledgment:  "This product includes  software
  developed  by the  Apache Software Foundation  (http://www.apache.org/)."
  Alternately, this  acknowledgment may  appear in the software itself,  if
  and wherever such third-party acknowledgments normally appear.
  
   4. The names "Apache Cocoon" and  "Apache Software Foundation" must  not  be
  used to  endorse or promote  products derived from  this software without
  prior written permission. For written permission, please contact
  [EMAIL PROTECTED]
  
   5. Products  derived from this software may not  be called "Apache", nor may
  "Apache" appear  in their name,  without prior written permission  of the
  Apache Software Foundation.
  
   THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
   INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
   FITNESS  FOR A PARTICULAR  PURPOSE ARE  DISCLAIMED.  IN NO  EVENT SHALL  THE
   APACHE SOFTWARE  FOUNDATION  OR ITS CONTRIBUTORS  BE LIABLE FOR  ANY DIRECT,
   INDIRECT, INCIDENTAL, SPECIAL,  EXEMPLARY, OR CONSEQUENTIAL  DAMAGES (INCLU-
   DING, BUT NOT LIMITED TO, PROCUREMENT  OF SUBSTITUTE GOODS OR SERVICES; LOSS
   OF USE, DATA, OR  PROFITS; OR BUSINESS  INTERRUPTION)  HOWEVER CAUSED AND ON
   ANY  THEORY OF LIABILITY,  WHETHER  IN CONTRACT,  STRICT LIABILITY,  OR TORT
   (INCLUDING  NEGLIGENCE OR  OTHERWISE) ARISING IN  ANY WAY OUT OF THE  USE OF
   THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  
   This software  consists of voluntary contributions made  by many individuals
   on  behalf of the Apache Software  Foundation and was  originally created by
   Stefano Mazzocchi  <[EMAIL PROTECTED]>. For more  information on the Apache
   Software Foundation, please see .
  
  */
  package org.apache.cocoon.taglib.test;
  
  import org.apache.cocoon.taglib.IterationTag;
  import org.apache.cocoon.taglib.TagSupport;
  import org.xml.sax.Attributes;
  import org.xml.sax.SAXException;
  
  /**
   * @author mailto:[EMAIL PROTECTED]";>Volker Schmitt
   */
  public class IterationTestTag extends TagSupport implements IterationTag {
  
  private int i = 0;
  private int count = 2;
  
  /*
   * @see Tag#doStartTag(String, String, String, Attributes)
   */
  public int doStartTag(String namespaceURI, String localName, String qName, 
Attributes atts) throws SAXException {
  if (count > 0)
return EVAL_BODY;
  return SKIP_BODY;
  }
  
  /*
   * @see IterationTag#doAfterBody()
   */
  public int doAfterBody() throws SAXException {
  if (++i >= count)
  return SKIP_BODY;
  return EVAL_BODY_AGAIN;
  }
  
  public void setCount(String count) {
  this.count = Integer.parseInt(count);
  }
  
  /*
   * @see Recyclable#recycle()
   */
  public void recycle() {
  i = 0;
  count = 2;
  super.recycle();
  }
  }
  
  
  
  1.1  
xml-cocoon2/src/scratchpad/src/org/apache/cocoon/taglib/test/HelloWorldTag.java
  
  Index: HelloWorldTag.java
  ===
  /*
  
   
 The Apache Software License, Version 1.1
   
  
   Copyright (C) 1999-2002 The Apache Software Foundation. All righ

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/taglib/test/acting TagtestAction.java

[froehlich]

froehlich2002/06/12 09:49:19

  Added:   src/scratchpad/src/org/apache/cocoon/taglib/test/acting
TagtestAction.java
  Log:
  applied patch from [EMAIL PROTECTED] .
  JSP like Tag-Library Implementation
  
  Revision  ChangesPath
  1.1  
xml-cocoon2/src/scratchpad/src/org/apache/cocoon/taglib/test/acting/TagtestAction.java
  
  Index: TagtestAction.java
  ===
  /*
   * (c) Copyright 2001 MyCorporation.
   * All Rights Reserved.
   */
  package org.apache.cocoon.taglib.test.acting;
  
  import java.util.ArrayList;
  import java.util.Enumeration;
  import java.util.List;
  import java.util.Map;
  
  import org.apache.avalon.framework.parameters.Parameters;
  import org.apache.cocoon.acting.ComposerAction;
  import org.apache.cocoon.environment.ObjectModelHelper;
  import org.apache.cocoon.environment.Redirector;
  import org.apache.cocoon.environment.Request;
  import org.apache.cocoon.environment.Session;
  import org.apache.cocoon.environment.SourceResolver;
  
  /**
   * @version   1.0
   * @author
   */
  public class TagtestAction extends ComposerAction
  {
  
/*
 * @see Action#act(Redirector, SourceResolver, Map, String, Parameters)
 */
public Map act(Redirector redirector, SourceResolver resolver, Map 
objectModel, String source, Parameters par)
throws Exception
{
Request request = (Request) ObjectModelHelper.getRequest(objectModel);
Session session = request.getSession();
Enumeration locales = request.getLocales();
List info = new ArrayList();

request.setAttribute("BrowserLocales", locales);

info.add(request.getRemoteAddr());
info.add(request.getRemoteHost());
info.add(request.getRemoteUser());
info.add(request.getContentType());
info.add(request.getLocale());

session.setAttribute("RequestInfo", info);

return null;
}
  
  }
  
  
  

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

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/taglib/string UpperCaseTag.java TrimTag.java TextRecordingTag.java StringTagSupport.java LowerCaseTag.java

[froehlich]

froehlich2002/06/12 09:49:13

  Added:   src/scratchpad/src/org/apache/cocoon/taglib/string
UpperCaseTag.java TrimTag.java
TextRecordingTag.java StringTagSupport.java
LowerCaseTag.java
  Log:
  applied patch from [EMAIL PROTECTED] .
  JSP like Tag-Library Implementation
  
  Revision  ChangesPath
  1.1  
xml-cocoon2/src/scratchpad/src/org/apache/cocoon/taglib/string/UpperCaseTag.java
  
  Index: UpperCaseTag.java
  ===
  /*
  
   
 The Apache Software License, Version 1.1
   
  
   Copyright (C) 1999-2002 The Apache Software Foundation. All rights reserved.
  
   Redistribution and use in source and binary forms, with or without modifica-
   tion, are permitted provided that the following conditions are met:
  
   1. Redistributions of  source code must  retain the above copyright  notice,
  this list of conditions and the following disclaimer.
  
   2. Redistributions in binary form must reproduce the above copyright notice,
  this list of conditions and the following disclaimer in the documentation
  and/or other materials provided with the distribution.
  
   3. The end-user documentation included with the redistribution, if any, must
  include  the following  acknowledgment:  "This product includes  software
  developed  by the  Apache Software Foundation  (http://www.apache.org/)."
  Alternately, this  acknowledgment may  appear in the software itself,  if
  and wherever such third-party acknowledgments normally appear.
  
   4. The names "Apache Cocoon" and  "Apache Software Foundation" must  not  be
  used to  endorse or promote  products derived from  this software without
  prior written permission. For written permission, please contact
  [EMAIL PROTECTED]
  
   5. Products  derived from this software may not  be called "Apache", nor may
  "Apache" appear  in their name,  without prior written permission  of the
  Apache Software Foundation.
  
   THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
   INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
   FITNESS  FOR A PARTICULAR  PURPOSE ARE  DISCLAIMED.  IN NO  EVENT SHALL  THE
   APACHE SOFTWARE  FOUNDATION  OR ITS CONTRIBUTORS  BE LIABLE FOR  ANY DIRECT,
   INDIRECT, INCIDENTAL, SPECIAL,  EXEMPLARY, OR CONSEQUENTIAL  DAMAGES (INCLU-
   DING, BUT NOT LIMITED TO, PROCUREMENT  OF SUBSTITUTE GOODS OR SERVICES; LOSS
   OF USE, DATA, OR  PROFITS; OR BUSINESS  INTERRUPTION)  HOWEVER CAUSED AND ON
   ANY  THEORY OF LIABILITY,  WHETHER  IN CONTRACT,  STRICT LIABILITY,  OR TORT
   (INCLUDING  NEGLIGENCE OR  OTHERWISE) ARISING IN  ANY WAY OUT OF THE  USE OF
   THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  
   This software  consists of voluntary contributions made  by many individuals
   on  behalf of the Apache Software  Foundation and was  originally created by
   Stefano Mazzocchi  <[EMAIL PROTECTED]>. For more  information on the Apache
   Software Foundation, please see .
  
  */
  package org.apache.cocoon.taglib.string;
  
  import org.apache.cocoon.taglib.TagSupport;
  import org.apache.cocoon.taglib.i18n.LocaleTag;
  
  /**
   * @author: mailto:[EMAIL PROTECTED]";>Volker Schmitt 
   */
  public class UpperCaseTag extends StringTagSupport {
  
  /*
   * @see StringTagSupport#changeString(String)
   */
  public String changeString(String str) {
  LocaleTag localeTag = (LocaleTag) TagSupport.findAncestorWithClass(this, 
LocaleTag.class);
  if (localeTag == null) {
  return str.toUpperCase();
  } else {
  return str.toUpperCase(localeTag.getLocale());
  }
  }
  
  }
  
  
  1.1  
xml-cocoon2/src/scratchpad/src/org/apache/cocoon/taglib/string/TrimTag.java
  
  Index: TrimTag.java
  ===
  /*
  
   
 The Apache Software License, Version 1.1
   
  
   Copyright (C) 1999-2002 The Apache Software Foundation. All rights reserved.
  
   Redistribution and use in source and binary forms, with or without modifica-
   tion, are permitted provided that the following conditions are met:
  
   1. Redistributions of  source code must  retain the above copyright  notice,
  this list of conditions and the following disclaimer.
  
   2. Redistributions in binary form must reproduce the above copyright notice,
  this list of conditions and the following disclaimer 

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/taglib/jxpath/core OutTag.java ForEachTag.java

[froehlich]

froehlich2002/06/12 09:49:03

  Added:   src/scratchpad/src/org/apache/cocoon/taglib/jxpath/core
OutTag.java ForEachTag.java
  Log:
  applied patch from [EMAIL PROTECTED] .
  JSP like Tag-Library Implementation
  
  Revision  ChangesPath
  1.1  
xml-cocoon2/src/scratchpad/src/org/apache/cocoon/taglib/jxpath/core/OutTag.java
  
  Index: OutTag.java
  ===
  /*
  
   
 The Apache Software License, Version 1.1
   
  
   Copyright (C) 1999-2002 The Apache Software Foundation. All rights reserved.
  
   Redistribution and use in source and binary forms, with or without modifica-
   tion, are permitted provided that the following conditions are met:
  
   1. Redistributions of  source code must  retain the above copyright  notice,
  this list of conditions and the following disclaimer.
  
   2. Redistributions in binary form must reproduce the above copyright notice,
  this list of conditions and the following disclaimer in the documentation
  and/or other materials provided with the distribution.
  
   3. The end-user documentation included with the redistribution, if any, must
  include  the following  acknowledgment:  "This product includes  software
  developed  by the  Apache Software Foundation  (http://www.apache.org/)."
  Alternately, this  acknowledgment may  appear in the software itself,  if
  and wherever such third-party acknowledgments normally appear.
  
   4. The names "Apache Cocoon" and  "Apache Software Foundation" must  not  be
  used to  endorse or promote  products derived from  this software without
  prior written permission. For written permission, please contact
  [EMAIL PROTECTED]
  
   5. Products  derived from this software may not  be called "Apache", nor may
  "Apache" appear  in their name,  without prior written permission  of the
  Apache Software Foundation.
  
   THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
   INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
   FITNESS  FOR A PARTICULAR  PURPOSE ARE  DISCLAIMED.  IN NO  EVENT SHALL  THE
   APACHE SOFTWARE  FOUNDATION  OR ITS CONTRIBUTORS  BE LIABLE FOR  ANY DIRECT,
   INDIRECT, INCIDENTAL, SPECIAL,  EXEMPLARY, OR CONSEQUENTIAL  DAMAGES (INCLU-
   DING, BUT NOT LIMITED TO, PROCUREMENT  OF SUBSTITUTE GOODS OR SERVICES; LOSS
   OF USE, DATA, OR  PROFITS; OR BUSINESS  INTERRUPTION)  HOWEVER CAUSED AND ON
   ANY  THEORY OF LIABILITY,  WHETHER  IN CONTRACT,  STRICT LIABILITY,  OR TORT
   (INCLUDING  NEGLIGENCE OR  OTHERWISE) ARISING IN  ANY WAY OUT OF THE  USE OF
   THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  
   This software  consists of voluntary contributions made  by many individuals
   on  behalf of the Apache Software  Foundation and was  originally created by
   Stefano Mazzocchi  <[EMAIL PROTECTED]>. For more  information on the Apache
   Software Foundation, please see .
  
  */
  package org.apache.cocoon.taglib.jxpath.core;
  
  import org.apache.cocoon.jxpath.JXPathCocoonContexts;
  import org.apache.cocoon.taglib.VarXMLProducerTagSupport;
  import org.apache.commons.jxpath.JXPathContext;
  import org.xml.sax.Attributes;
  import org.xml.sax.SAXException;
  
  /**
   * @author: mailto:[EMAIL PROTECTED]";>Volker Schmitt 
   */
  public class OutTag extends VarXMLProducerTagSupport {
  private String value;
  
  /*
   * @see Tag#doStartTag(String, String, String, Attributes)
   */
  public int doStartTag(String namespaceURI, String localName, String qName, 
Attributes atts) throws SAXException {
  if (value != null) {
  //JXPathContext context = 
JXPathCocoonContexts.getRequestContext(objectModel);
  Object retValue = getVariable(value);
  if (retValue != null) {
  if (var != null) {
  setVariable(var, retValue);
  //context.setValue(var, retValue);
  //setAttribute(var, retValue);
  } else {
  char[] charArray = retValue.toString().toCharArray();
  this.xmlConsumer.characters(charArray, 0, charArray.length);
  }
  }
  }
  return EVAL_BODY;
  }
  
  public void setValue(String value) {
  this.value = value;
  }
  
  /*
   * @see Recyclable#recycle()
   */
  public void recycle() {
  this.value = null;
  super.recycle();
  }
  }
  
  
  
  1.1  
xml-cocoon2/src/scratchpad/src/org/apache/cocoon/taglib/jxpath/core/ForEachTag.java
  
  Index: ForEachTag.java
  

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/taglib/i18n LocaleTag.java

[froehlich]

froehlich2002/06/12 09:48:55

  Added:   src/scratchpad/src/org/apache/cocoon/taglib/i18n
LocaleTag.java
  Log:
  applied patch from [EMAIL PROTECTED] .
  JSP like Tag-Library Implementation
  
  Revision  ChangesPath
  1.1  
xml-cocoon2/src/scratchpad/src/org/apache/cocoon/taglib/i18n/LocaleTag.java
  
  Index: LocaleTag.java
  ===
  /*
  
   
 The Apache Software License, Version 1.1
   
  
   Copyright (C) 1999-2002 The Apache Software Foundation. All rights reserved.
  
   Redistribution and use in source and binary forms, with or without modifica-
   tion, are permitted provided that the following conditions are met:
  
   1. Redistributions of  source code must  retain the above copyright  notice,
  this list of conditions and the following disclaimer.
  
   2. Redistributions in binary form must reproduce the above copyright notice,
  this list of conditions and the following disclaimer in the documentation
  and/or other materials provided with the distribution.
  
   3. The end-user documentation included with the redistribution, if any, must
  include  the following  acknowledgment:  "This product includes  software
  developed  by the  Apache Software Foundation  (http://www.apache.org/)."
  Alternately, this  acknowledgment may  appear in the software itself,  if
  and wherever such third-party acknowledgments normally appear.
  
   4. The names "Apache Cocoon" and  "Apache Software Foundation" must  not  be
  used to  endorse or promote  products derived from  this software without
  prior written permission. For written permission, please contact
  [EMAIL PROTECTED]
  
   5. Products  derived from this software may not  be called "Apache", nor may
  "Apache" appear  in their name,  without prior written permission  of the
  Apache Software Foundation.
  
   THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
   INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
   FITNESS  FOR A PARTICULAR  PURPOSE ARE  DISCLAIMED.  IN NO  EVENT SHALL  THE
   APACHE SOFTWARE  FOUNDATION  OR ITS CONTRIBUTORS  BE LIABLE FOR  ANY DIRECT,
   INDIRECT, INCIDENTAL, SPECIAL,  EXEMPLARY, OR CONSEQUENTIAL  DAMAGES (INCLU-
   DING, BUT NOT LIMITED TO, PROCUREMENT  OF SUBSTITUTE GOODS OR SERVICES; LOSS
   OF USE, DATA, OR  PROFITS; OR BUSINESS  INTERRUPTION)  HOWEVER CAUSED AND ON
   ANY  THEORY OF LIABILITY,  WHETHER  IN CONTRACT,  STRICT LIABILITY,  OR TORT
   (INCLUDING  NEGLIGENCE OR  OTHERWISE) ARISING IN  ANY WAY OUT OF THE  USE OF
   THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  
   This software  consists of voluntary contributions made  by many individuals
   on  behalf of the Apache Software  Foundation and was  originally created by
   Stefano Mazzocchi  <[EMAIL PROTECTED]>. For more  information on the Apache
   Software Foundation, please see .
  
  */
  package org.apache.cocoon.taglib.i18n;
  
  import java.util.Locale;
  
  import org.apache.cocoon.environment.ObjectModelHelper;
  import org.apache.cocoon.taglib.TagSupport;
  
  /**
   * @author: mailto:[EMAIL PROTECTED]";>Volker Schmitt 
   */
  public class LocaleTag extends TagSupport {
  private Locale locale;
  private String language;
  private String country;
  private String variant;
  
  public Locale getLocale() {
  if (locale == null) {
  locale = createLocale();
  }
  return locale;
  }
  
  public String getLanguage() {
  return language;
  }
  
  public void setLanguage(String language) {
  this.language = language;
  }
  
  public String getCountry() {
  return country;
  }
  
  public void setCountry(String country) {
  this.country = country;
  }
  
  public String getVariant() {
  return variant;
  }
  
  public void setVariant(String variant) {
  this.variant = variant;
  }
  
  /**
   *  Provides a key to retrieve a locale via findAttribute()
   */
  public void setLocaleRef(String value) {
  this.locale = (Locale) findAttribute(value);
  }
  
  protected Locale createLocale() {
  Locale locale = null;
  
  if (language == null) {
  locale = ObjectModelHelper.getRequest(objectModel).getLocale();
  } else if (country == null) {
  locale = new Locale(language, "");
  } else if (variant == null) {
  locale = new Locale(language, country);
  } else {
  locale = new Locale(language, country, variant);
  }
  
  return locale;
  

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/taglib/datetime MonthsTag.java

[froehlich]

froehlich2002/06/12 09:48:49

  Added:   src/scratchpad/src/org/apache/cocoon/taglib/datetime
MonthsTag.java
  Log:
  applied patch from [EMAIL PROTECTED] .
  JSP like Tag-Library Implementation
  
  Revision  ChangesPath
  1.1  
xml-cocoon2/src/scratchpad/src/org/apache/cocoon/taglib/datetime/MonthsTag.java
  
  Index: MonthsTag.java
  ===
  /*
  
   
 The Apache Software License, Version 1.1
   
  
   Copyright (C) 1999-2002 The Apache Software Foundation. All rights reserved.
  
   Redistribution and use in source and binary forms, with or without modifica-
   tion, are permitted provided that the following conditions are met:
  
   1. Redistributions of  source code must  retain the above copyright  notice,
  this list of conditions and the following disclaimer.
  
   2. Redistributions in binary form must reproduce the above copyright notice,
  this list of conditions and the following disclaimer in the documentation
  and/or other materials provided with the distribution.
  
   3. The end-user documentation included with the redistribution, if any, must
  include  the following  acknowledgment:  "This product includes  software
  developed  by the  Apache Software Foundation  (http://www.apache.org/)."
  Alternately, this  acknowledgment may  appear in the software itself,  if
  and wherever such third-party acknowledgments normally appear.
  
   4. The names "Apache Cocoon" and  "Apache Software Foundation" must  not  be
  used to  endorse or promote  products derived from  this software without
  prior written permission. For written permission, please contact
  [EMAIL PROTECTED]
  
   5. Products  derived from this software may not  be called "Apache", nor may
  "Apache" appear  in their name,  without prior written permission  of the
  Apache Software Foundation.
  
   THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
   INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
   FITNESS  FOR A PARTICULAR  PURPOSE ARE  DISCLAIMED.  IN NO  EVENT SHALL  THE
   APACHE SOFTWARE  FOUNDATION  OR ITS CONTRIBUTORS  BE LIABLE FOR  ANY DIRECT,
   INDIRECT, INCIDENTAL, SPECIAL,  EXEMPLARY, OR CONSEQUENTIAL  DAMAGES (INCLU-
   DING, BUT NOT LIMITED TO, PROCUREMENT  OF SUBSTITUTE GOODS OR SERVICES; LOSS
   OF USE, DATA, OR  PROFITS; OR BUSINESS  INTERRUPTION)  HOWEVER CAUSED AND ON
   ANY  THEORY OF LIABILITY,  WHETHER  IN CONTRACT,  STRICT LIABILITY,  OR TORT
   (INCLUDING  NEGLIGENCE OR  OTHERWISE) ARISING IN  ANY WAY OUT OF THE  USE OF
   THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  
   This software  consists of voluntary contributions made  by many individuals
   on  behalf of the Apache Software  Foundation and was  originally created by
   Stefano Mazzocchi  <[EMAIL PROTECTED]>. For more  information on the Apache
   Software Foundation, please see .
  
  */
  
  package org.apache.cocoon.taglib.datetime;
  
  import java.text.DateFormatSymbols;
  import java.util.Locale;
  
  import org.apache.cocoon.taglib.IterationTag;
  import org.apache.cocoon.taglib.TagSupport;
  import org.apache.cocoon.taglib.VarTagSupport;
  import org.apache.cocoon.taglib.i18n.LocaleTag;
  import org.xml.sax.Attributes;
  import org.xml.sax.SAXException;
  
  /**
   * Tag months, used to loop through all the months of the year.
   * 
   * The script variable of name var is availble only within the
   * body of the months tag.
   *
   * @author: mailto:[EMAIL PROTECTED]";>Volker Schmitt 
   */
  
  public class MonthsTag extends VarTagSupport implements IterationTag {
  private String[] short_months = null;
  private String[] long_months = null;
  private int month;
  private int month_num;
  
  /**
   * Initializes tag so it can loop through the months of the year.
   *
   * @return EVAL_BODY
   */
  public final int doStartTag(String namespaceURI, String localName, String qName, 
Attributes atts) throws SAXException {
  // Initialize variables
  month = 0;
  month_num = 1;
  
  Locale locale = null;
  LocaleTag localeTag = (LocaleTag) TagSupport.findAncestorWithClass(this, 
LocaleTag.class);
  if (localeTag != null) {
  locale = localeTag.getLocale();
  } else {
  locale = Locale.getDefault();
  }
  
  DateFormatSymbols dfs = new DateFormatSymbols(locale);
  short_months = dfs.getShortMonths();
  long_months = dfs.getMonths();
  
  // Make sure we skip any blank array elements
  while (month < long_months.length && (long_months[month] ==

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/taglib/core SourceTag.java LoopTagSupport.java LoopTagStatus.java LoopTag.java ForEachSupport.java

[froehlich]

froehlich2002/06/12 09:48:43

  Added:   src/scratchpad/src/org/apache/cocoon/taglib/core
SourceTag.java LoopTagSupport.java
LoopTagStatus.java LoopTag.java ForEachSupport.java
  Log:
  applied patch from [EMAIL PROTECTED] .
  JSP like Tag-Library Implementation
  
  Revision  ChangesPath
  1.1  
xml-cocoon2/src/scratchpad/src/org/apache/cocoon/taglib/core/SourceTag.java
  
  Index: SourceTag.java
  ===
  /*
  
   
 The Apache Software License, Version 1.1
   
  
   Copyright (C) 1999-2002 The Apache Software Foundation. All rights reserved.
  
   Redistribution and use in source and binary forms, with or without modifica-
   tion, are permitted provided that the following conditions are met:
  
   1. Redistributions of  source code must  retain the above copyright  notice,
  this list of conditions and the following disclaimer.
  
   2. Redistributions in binary form must reproduce the above copyright notice,
  this list of conditions and the following disclaimer in the documentation
  and/or other materials provided with the distribution.
  
   3. The end-user documentation included with the redistribution, if any, must
  include  the following  acknowledgment:  "This product includes  software
  developed  by the  Apache Software Foundation  (http://www.apache.org/)."
  Alternately, this  acknowledgment may  appear in the software itself,  if
  and wherever such third-party acknowledgments normally appear.
  
   4. The names "Apache Cocoon" and  "Apache Software Foundation" must  not  be
  used to  endorse or promote  products derived from  this software without
  prior written permission. For written permission, please contact
  [EMAIL PROTECTED]
  
   5. Products  derived from this software may not  be called "Apache", nor may
  "Apache" appear  in their name,  without prior written permission  of the
  Apache Software Foundation.
  
   THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
   INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
   FITNESS  FOR A PARTICULAR  PURPOSE ARE  DISCLAIMED.  IN NO  EVENT SHALL  THE
   APACHE SOFTWARE  FOUNDATION  OR ITS CONTRIBUTORS  BE LIABLE FOR  ANY DIRECT,
   INDIRECT, INCIDENTAL, SPECIAL,  EXEMPLARY, OR CONSEQUENTIAL  DAMAGES (INCLU-
   DING, BUT NOT LIMITED TO, PROCUREMENT  OF SUBSTITUTE GOODS OR SERVICES; LOSS
   OF USE, DATA, OR  PROFITS; OR BUSINESS  INTERRUPTION)  HOWEVER CAUSED AND ON
   ANY  THEORY OF LIABILITY,  WHETHER  IN CONTRACT,  STRICT LIABILITY,  OR TORT
   (INCLUDING  NEGLIGENCE OR  OTHERWISE) ARISING IN  ANY WAY OUT OF THE  USE OF
   THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  
   This software  consists of voluntary contributions made  by many individuals
   on  behalf of the Apache Software  Foundation and was  originally created by
   Stefano Mazzocchi  <[EMAIL PROTECTED]>. For more  information on the Apache
   Software Foundation, please see .
  
  */
  package org.apache.cocoon.taglib.core;
  
  import org.apache.cocoon.ProcessingException;
  import org.apache.cocoon.environment.Source;
  import org.apache.cocoon.taglib.XMLProducerTagSupport;
  import org.apache.cocoon.xml.EmbeddedXMLPipe;
  import org.xml.sax.SAXException;
  
  /**
   * @author: mailto:[EMAIL PROTECTED]";>Volker Schmitt 
   */
  public class SourceTag extends XMLProducerTagSupport {
  private String src;
  private EmbeddedXMLPipe embeddedXMLPipe = new EmbeddedXMLPipe(null);
  
  public void setSrc(String src) {
  this.src = src;
  }
  
  /*
   * @see Tag#doEndTag(String, String, String)
   */
  public int doEndTag(String namespaceURI, String localName, String qName) throws 
SAXException {
  Source source = null;
  try {
  embeddedXMLPipe.setConsumer(this.xmlConsumer);
  source = resolver.resolve(src);
  source.toSAX(embeddedXMLPipe);
  } catch (Exception e) {
  if (e instanceof ProcessingException) {
  ProcessingException pe = (ProcessingException) e;
  Throwable t = pe.getCause();
  if (t != null && t instanceof SAXException)
  throw (SAXException) t;
  }
  throw new SAXException(e.getMessage(), e);
  } finally {
  embeddedXMLPipe.setConsumer(null);
  if (source != null)
  source.recycle();
  }
  return EVAL_PAGE;
  }
  
  /*
   * @see Recyclable#recycle()
   */
  public void recycle() {
  this.src = null;
  super.recy

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/taglib XMLProducerTagSupport.java XMLProducerTag.java XMLConsumerTagSupport.java XMLConsumerTag.java VarXMLProducerTagSupport.java VarTransformerTagSupport.java VarTagSupport.java TransformerTagSupport.java TransformerTag.java TagSupport.java Tag.java IterationTag.java

[froehlich]

froehlich2002/06/12 09:48:30

  Added:   src/scratchpad/src/org/apache/cocoon/taglib
XMLProducerTagSupport.java XMLProducerTag.java
XMLConsumerTagSupport.java XMLConsumerTag.java
VarXMLProducerTagSupport.java
VarTransformerTagSupport.java VarTagSupport.java
TransformerTagSupport.java TransformerTag.java
TagSupport.java Tag.java IterationTag.java
  Log:
  applied patch from [EMAIL PROTECTED] .
  JSP like Tag-Library Implementation
  
  Revision  ChangesPath
  1.1  
xml-cocoon2/src/scratchpad/src/org/apache/cocoon/taglib/XMLProducerTagSupport.java
  
  Index: XMLProducerTagSupport.java
  ===
  /*
  
   
 The Apache Software License, Version 1.1
   
  
   Copyright (C) 1999-2002 The Apache Software Foundation. All rights reserved.
  
   Redistribution and use in source and binary forms, with or without modifica-
   tion, are permitted provided that the following conditions are met:
  
   1. Redistributions of  source code must  retain the above copyright  notice,
  this list of conditions and the following disclaimer.
  
   2. Redistributions in binary form must reproduce the above copyright notice,
  this list of conditions and the following disclaimer in the documentation
  and/or other materials provided with the distribution.
  
   3. The end-user documentation included with the redistribution, if any, must
  include  the following  acknowledgment:  "This product includes  software
  developed  by the  Apache Software Foundation  (http://www.apache.org/)."
  Alternately, this  acknowledgment may  appear in the software itself,  if
  and wherever such third-party acknowledgments normally appear.
  
   4. The names "Apache Cocoon" and  "Apache Software Foundation" must  not  be
  used to  endorse or promote  products derived from  this software without
  prior written permission. For written permission, please contact
  [EMAIL PROTECTED]
  
   5. Products  derived from this software may not  be called "Apache", nor may
  "Apache" appear  in their name,  without prior written permission  of the
  Apache Software Foundation.
  
   THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
   INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
   FITNESS  FOR A PARTICULAR  PURPOSE ARE  DISCLAIMED.  IN NO  EVENT SHALL  THE
   APACHE SOFTWARE  FOUNDATION  OR ITS CONTRIBUTORS  BE LIABLE FOR  ANY DIRECT,
   INDIRECT, INCIDENTAL, SPECIAL,  EXEMPLARY, OR CONSEQUENTIAL  DAMAGES (INCLU-
   DING, BUT NOT LIMITED TO, PROCUREMENT  OF SUBSTITUTE GOODS OR SERVICES; LOSS
   OF USE, DATA, OR  PROFITS; OR BUSINESS  INTERRUPTION)  HOWEVER CAUSED AND ON
   ANY  THEORY OF LIABILITY,  WHETHER  IN CONTRACT,  STRICT LIABILITY,  OR TORT
   (INCLUDING  NEGLIGENCE OR  OTHERWISE) ARISING IN  ANY WAY OUT OF THE  USE OF
   THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  
   This software  consists of voluntary contributions made  by many individuals
   on  behalf of the Apache Software  Foundation and was  originally created by
   Stefano Mazzocchi  <[EMAIL PROTECTED]>. For more  information on the Apache
   Software Foundation, please see .
  
  */
  package org.apache.cocoon.taglib;
  
  import org.apache.cocoon.xml.XMLConsumer;
  
  /**
   * @author: mailto:[EMAIL PROTECTED]";>Volker Schmitt 
   */
  public abstract class XMLProducerTagSupport extends TagSupport implements 
XMLProducerTag {
  
  protected XMLConsumer xmlConsumer;
  
  /*
   * @see XMLProducer#setConsumer(XMLConsumer)
   */
  public void setConsumer(XMLConsumer xmlConsumer) {
  this.xmlConsumer = xmlConsumer;
  }
  
  /*
   * @see Recyclable#recycle()
   */
  public void recycle() {
  xmlConsumer = null;
  super.recycle();
  }
  
  }
  
  
  
  1.1  
xml-cocoon2/src/scratchpad/src/org/apache/cocoon/taglib/XMLProducerTag.java
  
  Index: XMLProducerTag.java
  ===
  /*
  
   
 The Apache Software License, Version 1.1
   
  
   Copyright (C) 1999-2002 The Apache Software Foundation. All rights reserved.
  
   Redistribution and use in source and binary forms, with or without modifica-
   tion, are permitted provided that the following conditions are met:
  
   1. Redistributions of  source code must  retain the above

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/taglib/test/acting - New directory

[froehlich]

froehlich2002/06/12 09:46:10

  xml-cocoon2/src/scratchpad/src/org/apache/cocoon/taglib/test/acting - 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/scratchpad/src/org/apache/cocoon/taglib/test - New directory

[froehlich]

froehlich2002/06/12 09:46:07

  xml-cocoon2/src/scratchpad/src/org/apache/cocoon/taglib/test - 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/scratchpad/src/org/apache/cocoon/taglib/string - New directory

[froehlich]

froehlich2002/06/12 09:46:02

  xml-cocoon2/src/scratchpad/src/org/apache/cocoon/taglib/string - 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/scratchpad/src/org/apache/cocoon/taglib/jxpath/core - New directory

[froehlich]

froehlich2002/06/12 09:45:54

  xml-cocoon2/src/scratchpad/src/org/apache/cocoon/taglib/jxpath/core - 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/scratchpad/src/org/apache/cocoon/taglib/jxpath - New directory

[froehlich]

froehlich2002/06/12 09:45:47

  xml-cocoon2/src/scratchpad/src/org/apache/cocoon/taglib/jxpath - 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/scratchpad/src/org/apache/cocoon/taglib/i18n - New directory

[froehlich]

froehlich2002/06/12 09:45:45

  xml-cocoon2/src/scratchpad/src/org/apache/cocoon/taglib/i18n - 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/scratchpad/src/org/apache/cocoon/taglib/datetime - New directory

[froehlich]

froehlich2002/06/12 09:45:42

  xml-cocoon2/src/scratchpad/src/org/apache/cocoon/taglib/datetime - 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/scratchpad/src/org/apache/cocoon/taglib/core - New directory

[froehlich]

froehlich2002/06/12 09:45:38

  xml-cocoon2/src/scratchpad/src/org/apache/cocoon/taglib/core - 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/scratchpad/src/org/apache/cocoon/taglib - New directory

[froehlich]

froehlich2002/06/12 09:45:30

  xml-cocoon2/src/scratchpad/src/org/apache/cocoon/taglib - New directory

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

Re: Planning the releases

[Peter Royal]

On Wednesday 12 June 2002 06:08 am, Davanum Srinivas wrote:
> July 1 for C2.0.3
> July 15 for C2.1 beta 1

+1 to both.
-pete

-- 
peter royal -> [EMAIL PROTECTED]

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

RE: [GUMP] Build Failure - xml-cocoon2

[Vadim Gritsenko]

> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]]
> 
> Vadim Gritsenko wrote:
> >
> > I have no idea what needs to be done to fix gump build. :-/
> >
> 
> Have you ever read the Gump docs, or do you need a RTFM? ;-P

Now that you tell it... Went through the pages... Found broken link...
(on http://jakarta.apache.org/builds/gump/latest/modxref.html click on
"xml-cocoon2" -> http://xml.apache.org/cocoon/cocoon2.html)

I think that for slide it should enough to change project definition
(add  ?)...

But how to add 3rd party library - I have no idea. How to update project
definition file - same (using Apache Bug Database?). Please, where is
your RTFM?


Vadim



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

Re: progress report on XSLTC]]

[Stefano Mazzocchi]

Gianugo Rabellino wrote:
> 
> Ivelin Ivanov wrote:
> > Excelent!
> >
> > I want to try it NOW !
> >
> > For all the folks that were benchmarking Saxon, Xalan, XT, etc.
> > This is your chance to test drive the F1 car before it's out on the official
> > race track.
> >
> >
> > Gianugo, can you please provide instructions how to swap Xalan with XSLTC in
> > the config.
> 
> Sure thing. First of all the jar: get it at
> http://cvs.apache.org/~gianugo/xsltc.jar (hmmm... what about adding it
> to the CVS since it's starting to work? I'll keep it updated while Tom
> sends me their progress). Then it's as easy as changing the
> transformer-factory parameter in cocoon.xconf to
> 
>  value="org.apache.xalan.xsltc.trax.TransformerFactoryImpl"/>

There is another way.

If you look into the main sitemap, you'll find a comment in the
'map:transformers' definitions that defines the transformer type "xsltc"
(note the 'c' at the end!). If you uncomment that, you can use XSLTC and
Xalan at the same time in your application.

This is mostly useful when you have nonstatic xalan extensions that
XSLTC is not currently able to call.

Ah, you could have SAXON working at the same time as well.

You might even think of doing stuff like this:

 
 
 
 
 

and uncomment the one you like (this might be useful to perform
benchmarks on the exact same system with the exact same overheads).

The method that Gianugo suggests, instead, changes the TrAX factory and
this means that *every* xslt operation performed by Cocoon will default
to the XSLT processor that is defined there.

Hope this helps.

-- 
Stefano Mazzocchi  One must still have chaos in oneself to be
  able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche




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

What are the problems with JDK 1.4?

[Carsten Ziegeler]

Hi,

for the next release (2.0.3) we should try to fix the problems concerning
JDK 1.4. One problem, the building of the javadocs is solved now.

But it seems that there are problems with JDBC Pooling. If I compile
everything using JDK 1.4, the sql examples run well. Running this with JDK
1.4, the hsqldb is throwing an exception:

java.sql.SQLException: Connection is broken: Connection refused: connect
at org.hsqldb.Trace.getError(Trace.java:180)
at org.hsqldb.Trace.getError(Trace.java:144)
at org.hsqldb.Trace.error(Trace.java:205)
at org.hsqldb.jdbcConnection.reconnectHSQL(jdbcConnection.java:865)
at org.hsqldb.jdbcConnection.openHSQL(jdbcConnection.java:833)
at org.hsqldb.jdbcConnection.(jdbcConnection.java:678)
at org.hsqldb.jdbcDriver.connect(jdbcDriver.java:116)
at java.sql.DriverManager.getConnection(DriverManager.java:512)
at java.sql.DriverManager.getConnection(DriverManager.java:171)
at
org.apache.avalon.excalibur.datasource.JdbcConnectionFactory.(J
dbcConnectionFactory.java:98)

Is this a problem with hsqldb? Are other dbs working?

Carsten


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

Re: [GUMP] Build Failure - xml-cocoon2

[Stephan Michels]

On Wed, 12 Jun 2002, Nicola Ken Barozzi wrote:

>
> Vadim Gritsenko wrote:
> > Who knows what needs to be done to add new libraries to the GUMP build?
>
> It has been just added By Stephan B.
>
> What's missing is the Wings jars.
> I'll send a patch to Gump to put it in the builds ASAP.
>
> >
> >
> >
> >>From: Sam Ruby [mailto:[EMAIL PROTECTED]]
> >
> >
> > 
> >
> >>[javac] /home/rubys/jakarta/xml-
> >>
> >
> > cocoon2/build/cocoon/scratchpad/src/org/apache/cocoon/components/reposit
> > ory/im
> >
> >>pl/SlideSourceDescriptor.java:83: cannot resolve symbol
> >>[javac] symbol  : class CredentialsToken
> >>[javac] location: package authenticate
> >>[javac] import org.apache.slide.authenticate.CredentialsToken;
> >>[javac]  ^
> >
> >
> > 

org/apache/slide/authenticate/CredentialsToken.class

is in the src/scratchpad/lib/slide-kernel-1.0.16.jar

I got not error during the compilation.

So when does the error occurs?

Stephan Michels.


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

Re: [GUMP] Build Failure - xml-cocoon2

[Nicola Ken Barozzi]

Vadim Gritsenko wrote:
>>From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]]
>>
>>
>>Vadim Gritsenko wrote:
>>
>>>Who knows what needs to be done to add new libraries to the GUMP
>>
> build?
> 
>>It has been just added By Stephan B.
>>
>>What's missing is the Wings jars.
>>I'll send a patch to Gump to put it in the builds ASAP.
> 
> 
> Can you then document necessary steps for future generations? :)
> 
> I have no idea what needs to be done to fix gump build. :-/
> 

Have you ever read the Gump docs, or do you need a RTFM? ;-P


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

cvs commit: xml-cocoon2/src/documentation/xdocs/link training.xml

[cziegeler]

cziegeler2002/06/12 07:21:00

  Modified:src/documentation/xdocs/link training.xml
  Log:
  Added training course
  
  Revision  ChangesPath
  1.3   +6 -0  xml-cocoon2/src/documentation/xdocs/link/training.xml
  
  Index: training.xml
  ===
  RCS file: /home/cvs/xml-cocoon2/src/documentation/xdocs/link/training.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- training.xml  12 May 2002 03:41:46 -  1.2
  +++ training.xml  12 Jun 2002 14:21:00 -  1.3
  @@ -17,6 +17,12 @@
Both courses are two days each and are offered in Denver, Colorado.
It is also possible to arrange on-site training if there are sufficient 
participants.
   
  +http://www.s-und-n.de/services/training/cocoonschulungen_english.htm";>S&N 
AG
  +S&N offers Cocoon training. Two courses are available -
  +"Introducing Cocoon" (3 days) for beginners and "Unraveling Cocoon" for
  +developers (2 days). The courses are available in English or German.
  + It is also possible to arrange on-site training.
  +
   
   
 
  
  
  

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

RE: [GUMP] Build Failure - xml-cocoon2

[Vadim Gritsenko]

> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]]
> 
> 
> Vadim Gritsenko wrote:
> > Who knows what needs to be done to add new libraries to the GUMP
build?
> 
> It has been just added By Stephan B.
> 
> What's missing is the Wings jars.
> I'll send a patch to Gump to put it in the builds ASAP.

Can you then document necessary steps for future generations? :)

I have no idea what needs to be done to fix gump build. :-/


Vadim



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

RE: [GUMP] Build Failure - xml-cocoon2

[Vadim Gritsenko]

> From: Morrison, John [mailto:[EMAIL PROTECTED]]
> 
> Is GUMP supposed to be building the scratchpad?
> 
> > cocoon2/build/cocoon/scratchpad/src/org/apache/cocoon/componen
>^^
> 
> ?

compile target builds all sources.

Vadim



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

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/language/markup/xsp EsqlConnection.java

[cziegeler]

cziegeler2002/06/12 06:59:22

  Modified:src/java/org/apache/cocoon/components/language/markup/xsp
EsqlConnection.java
  Log:
  Fixed endless recursion bug
  
  Revision  ChangesPath
  1.9   +3 -3  
xml-cocoon2/src/java/org/apache/cocoon/components/language/markup/xsp/EsqlConnection.java
  
  Index: EsqlConnection.java
  ===
  RCS file: 
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/components/language/markup/xsp/EsqlConnection.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- EsqlConnection.java   16 May 2002 16:01:17 -  1.8
  +++ EsqlConnection.java   12 Jun 2002 13:59:22 -  1.9
  @@ -80,7 +80,7 @@
 }
   
 public String getUrl() {
  -if (this.url == null) 
  +if (this.url == null)
 try {
   this.url=this.connection.getMetaData().getURL();
 } catch (SQLException e) {
  @@ -199,7 +199,7 @@
 }
   
 public boolean isClosed() throws SQLException {
  -return(isClosed());
  +return(connection.isClosed());
 }
   
 public java.sql.DatabaseMetaData getMetaData() throws SQLException {
  
  
  

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

RE: [GUMP] Build Failure - xml-cocoon2

[Morrison, John]

Is GUMP supposed to be building the scratchpad?

> cocoon2/build/cocoon/scratchpad/src/org/apache/cocoon/componen
   ^^

?

> ts/repository/impl/SlideSourceDescriptor.java:83: cannot resolve symbol

J.


===
Information in this email and any attachments are confidential, and may
not be copied or used by anyone other than the addressee, nor disclosed
to any third party without our permission.  There is no intention to
create any legally binding contract or other commitment through the use
of this email.

Experian Limited (registration number 653331).  
Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF

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

Re: [GUMP] Build Failure - xml-cocoon2

[Nicola Ken Barozzi]

Vadim Gritsenko wrote:
> Who knows what needs to be done to add new libraries to the GUMP build?

It has been just added By Stephan B.

What's missing is the Wings jars.
I'll send a patch to Gump to put it in the builds ASAP.

> 
> 
> 
>>From: Sam Ruby [mailto:[EMAIL PROTECTED]]
> 
> 
> 
> 
>>[javac] /home/rubys/jakarta/xml-
>>
> 
> cocoon2/build/cocoon/scratchpad/src/org/apache/cocoon/components/reposit
> ory/im
> 
>>pl/SlideSourceDescriptor.java:83: cannot resolve symbol
>>[javac] symbol  : class CredentialsToken
>>[javac] location: package authenticate
>>[javac] import org.apache.slide.authenticate.CredentialsToken;
>>[javac]  ^
> 
> 
> 


-- 
Nicola Ken Barozzi   [EMAIL PROTECTED]
 - verba volant, scripta manent -
(discussions get forgotten, just code remains)
-


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

RE: [GUMP] Build Failure - xml-cocoon2

[Vadim Gritsenko]

Who knows what needs to be done to add new libraries to the GUMP build?

Vadim


> From: Sam Ruby [mailto:[EMAIL PROTECTED]]



> [javac] /home/rubys/jakarta/xml-
>
cocoon2/build/cocoon/scratchpad/src/org/apache/cocoon/components/reposit
ory/im
> pl/SlideSourceDescriptor.java:83: cannot resolve symbol
> [javac] symbol  : class CredentialsToken
> [javac] location: package authenticate
> [javac] import org.apache.slide.authenticate.CredentialsToken;
> [javac]  ^




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

RE: Planning the releases

[Carsten Ziegeler]

Vadim Gritsenko wrote:
> 
> > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]]
> > 
> > 
> > Vadim Gritsenko wrote:
> > >
> > > 
> > > This is the most discussed issue on the user list, it must be fixed
> > > before release. Can we have now Excalibur which works with 1.3 *and*
> > > 1.4?
> > >
> > What is needed for it?
> > 
> > The current excalibur is compiled with jdk 1.4
> > in 1.2 compatible mode. For me this works on JDK 1.4 and 1.3 without
> > problems.
> 
> You mean JDBC pool works ok now? Cool then.
> 
Ehhmmm, ok, I didn't check if the JDBC pool works... but I just tested it
and yes, it's not working with jdk1.4 but with jdk1.3 :(

> Vadim
> 
> 
> > Carsten
> 
> 
> -
> 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: Planning the releases

[Vadim Gritsenko]

> From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]]
> 
> 
> Vadim Gritsenko wrote:
> >
> > 
> > This is the most discussed issue on the user list, it must be fixed
> > before release. Can we have now Excalibur which works with 1.3 *and*
> > 1.4?
> >
> What is needed for it?
> 
> The current excalibur is compiled with jdk 1.4
> in 1.2 compatible mode. For me this works on JDK 1.4 and 1.3 without
> problems.

You mean JDBC pool works ok now? Cool then.

Vadim


> Carsten


-
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://jakarta.apache.org/builds/gump/2002-06-12/xml-cocoon2.html>


Buildfile: build.xml

init:
 [echo] --
 [echo] Apache Cocoon 20020612 [1999-2002]  
 [echo] --
 [echo] Building with Apache Ant version 1.6alpha compiled on June 12 2002
 [echo] using build file /home/rubys/jakarta/xml-cocoon2/build.xml
 [echo] --
[mkdir] Created dir: /home/rubys/jakarta/xml-cocoon2/tools/anttasks
[javac] Compiling 5 source files to /home/rubys/jakarta/xml-cocoon2/tools/anttasks

optional-tests:

bsf-warn:

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:

fop-warn:

op-warning:
 [echo] **
 [echo] *
 [echo] *  Classes of the optional package FOP are not 
 [echo] *  available. Apache Cocoon builds without them.
 [echo] *
 [echo] *  FOP is required for the fo2pdf, fo2ps and fo2pcl serializer.
 [echo] *
 [echo] *  Recovery:
 [echo] *  Get FOP from http://xml.apache.org/fop/ and place the jar in the 
lib/optional dir
 [echo] *
 [echo] ***

tidy-warn:

maybeupload-warn:

op-warning:
 [echo] **
 [echo] *
 [echo] *  Classes of the optional package MaybeUpload are not 
 [echo] *  available. Apache Cocoon builds without them.
 [echo] *
 [echo] *  MaybeUpload simplifies the handling of uploaded files.
 [echo] *
 [echo] *  Recovery:
 [echo] *  Get MaybeUpload from http://www.weft.co.uk/library/maybeupload/ and 
place the jar in the lib/optional dir
 [echo] *
 [echo] ***

lucene-warn:

deli-warn:

op-warning:
 [echo] **
 [echo] *
 [echo] *  Classes of the optional package Deli are not 
 [echo] *  available. Apache Cocoon builds without them.
 [echo] *
 [echo] *  Deli is required for ...
 [echo] *
 [echo] *  Recovery:
 [echo] *  Get Deli and place the jar in the lib/optional dir
 [echo] *
 [echo] ***

velocity-warn:

hsqldb-warn:

resolver-warn:

jisp-warn:

pizza-warn:

op-warning:
 [echo] **
 [echo] *
 [echo] *  Classes of the optional package Pizza are not 
 [echo] *  available. Apache Cocoon builds without them.
 [echo] *
 [echo] *  Pizza is the alternative Java compiler.
 [echo] *
 [echo] *  Recovery:
 [echo] *  Get the pizza package from http://pizzacompiler.sourceforge.net/ and 
place the jar in the lib/optional dir
 [echo] *
 [echo] ***

poi-warn:

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

commons-logging-warn:

optional-warnings:

prepare:
[mkdir] Created dir: /home/rubys/jakarta/xml-cocoon2/build/cocoon

generate-java-code-check:

generate-java-code:
[style] Transforming into 
/home/rubys/jakarta/xml-cocoon2/build/cocoon/src/org/apache/cocoon/components/browser
[style] Processing 
/home/rubys/jakarta/xml-cocoon2/src/java/org/

RE: SourceResolving in non-sitemap components

[Carsten Ziegeler]

Stuart Roebuck wrote:
> 
> I'm trying to get my head round SourceResolving and would be grateful 
> for clarification.
> 
> There appear to be at a number of SourceResolver classes:
> 
> > org.apache.excalibur.source.SourceResolver
This is the real source resolver.

> > org.apache.avalon.excalibur.source.SourceResolver
Forget this one, it has removed. Basically it was the same
as the first one, but then the excalibur team decided to
remove "avalon" from the package names for new components.

> > org.apache.cocoon.environment.SourceResolver
This is a convenience source resolver which is passed to the sitemap
components. It inherits from org.apache.excalibur.source.SourceResolver
and adds a usefull toSAX() method especiall for Cocoon.

org.apache.excalibur.source.SourceResolver is a real component,
so you can look it up everywhere you have a ComponentManager.
You can use this component to get Source objects by calling
resolveURI() and you have to release() them later on.


> 
> I want to use a SourceResolver in one Component but in two different 
> kinds of context.
> 
> In the first case, I would like to use a SourceResolver during 
> Configuration to obtain a ModifiableSource relative to the root context, 
> and then refer to it from time to time.  I think that I need something 
> like this...
> 
> >this.resolver = (SourceResolver) 
> > this.manager.lookup(SourceResolver.ROLE);
> > Source source = 
> this.resolver.resolveURI("context://path/to/file");
> > // Do something with source
> >
> > // After a while... (when source may have changed)
> > if (source instanceof ModifiableSource) {
> > ( (ModifiableSource) source).refresh()
> > }
> > // Do something else with source
> >
> > // Finally (not sure if this is required)
> > this.resolver.release(source);
>
Yes, exactly with the exception that the ModifiableSource interface
is deprecated. You have to use the discardValidity() method of
the Source interface instead.
 
> In the second case I would like to be able to use a SourceResolver to 
> obtain a Source relative to current context when this component is 
> called from within another sitemap component.  In these cases a 
> SourceResolver is already passed to the Action or Generator, so I can 
> pass this on to my component for use.
Yes, exactly.

HTH
Carsten 

Carsten Ziegeler Chief Architect Open Source Group, S&N AG
--
 Cocoon Consulting, Training and Projects
--
mailto:[EMAIL PROTECTED]  http://www.s-und-n.de
http://ziegeler.bei.t-online.de


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

SourceResolving in non-sitemap components

[Stuart Roebuck]

I'm trying to get my head round SourceResolving and would be grateful 
for clarification.

There appear to be at a number of SourceResolver classes:

>   org.apache.excalibur.source.SourceResolver
>   org.apache.avalon.excalibur.source.SourceResolver
>   org.apache.cocoon.environment.SourceResolver

I want to use a SourceResolver in one Component but in two different 
kinds of context.

In the first case, I would like to use a SourceResolver during 
Configuration to obtain a ModifiableSource relative to the root context, 
and then refer to it from time to time.  I think that I need something 
like this...

>this.resolver = (SourceResolver) 
> this.manager.lookup(SourceResolver.ROLE);
>   Source source = this.resolver.resolveURI("context://path/to/file");
>   // Do something with source
>
>   // After a while... (when source may have changed)
>   if (source instanceof ModifiableSource) {
>   ( (ModifiableSource) source).refresh()
>   }
>   // Do something else with source
>
>   // Finally (not sure if this is required)
>   this.resolver.release(source);

In the second case I would like to be able to use a SourceResolver to 
obtain a Source relative to current context when this component is 
called from within another sitemap component.  In these cases a 
SourceResolver is already passed to the Action or Generator, so I can 
pass this on to my component for use.

Stuart.


Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck (Adolos)
  Key fingerprint = 89D9 E405 F8B1 9B22 0FA2  F2C1 9E57 5AB1 88DD 65AF
-
Stuart Roebuck  [EMAIL PROTECTED]
Systems Architect Java, XML, MacOS X, XP, 
etc.
ADOLOS   


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

HELP! Urgently needed help on head

[Per-Olof Norén]

Hello all,
I have a problem I can´t  find a place to start looking for the solution:
My config is like the following:

win2k  (2*1,1 ghz 1 Gb RAM 50Gb Hdd)
sun jdk1.3.1_02
resin 2.0.5
freshly checked out head, compiled with "build -Dinclude.webapp.libs=yes
-Dinclude.scratchpad.libs=yes webapp"

The stacktrace of the error is below.  Does anyone have a clue what this is?
Could this concern the class-loading changes recently?

Please help,
thx in advance

Per-Olof Norén
Stockholm, Sweden


   500 Servlet Exception

|

java.lang.NoSuchMethodError
at 
org.apache.cocoon.components.ExtendedComponentSelector.configure(ExtendedComponentSelector.java:272)
at 
org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:185)
at 
org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.initialize(ThreadSafeComponentHandler.java:98)
at 
org.apache.avalon.excalibur.component.ExcaliburComponentManager.initialize(ExcaliburComponentManager.java:157)
at org.apache.cocoon.Cocoon.initialize(Cocoon.java:273)
at 
org.apache.cocoon.servlet.CocoonServlet.createCocoon(CocoonServlet.java:1237)
at org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:435)
at com.caucho.server.http.Application.createServlet(Application.java:2834)
at com.caucho.server.http.Application.loadServlet(Application.java:2793)
at com.caucho.server.http.Application.initServlets(Application.java:1827)
at com.caucho.server.http.Application.init(Application.java:1762)
at 
com.caucho.server.http.VirtualHost.restartApplication(VirtualHost.java:1649)
at com.caucho.server.http.VirtualHost.getInvocation(VirtualHost.java:1277)
at 
com.caucho.server.http.ServletServer.getInvocation(ServletServer.java:1040)
at com.caucho.server.http.ServletServer.serviceTop(ServletServer.java:935)
at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:213)
at com.caucho.server.http.HttpRequest.handleConnection(HttpRequest.java:158)
at com.caucho.server.TcpConnection.run(TcpConnection.java:140)
at java.lang.Thread.run(Thread.java:484)

|

Resin 2.0.5 (built Fri Jan 11 08:29:05 PST 2002)


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

RE: Planning the releases

[Carsten Ziegeler]

Vadim Gritsenko wrote:
> 
> 
> This is the most discussed issue on the user list, it must be fixed
> before release. Can we have now Excalibur which works with 1.3 *and*
> 1.4?
> 
What is needed for it? 

The current excalibur is compiled with jdk 1.4
in 1.2 compatible mode. For me this works on JDK 1.4 and 1.3 without
problems.

Carsten

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

RE: sitemap recursive?

[Vadim Gritsenko]

> From: Jeremy Quinn [mailto:[EMAIL PROTECTED]]
> 
> Hi All,
> 
> Is it safe to use the SiteMap recursively?

There are no technical limitations to it.
 

> ie. a Pipeline calling itself via the cocoon:/ protocol?
> 
> How? Via CInclude or XSLT document() function, etc.
> 
>   (can XSLT use the cocoon:/ protocol?)

(yes)

Vadim


> 
> thanks for any help
> 
> regards Jeremy


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

sitemap recursive?

[Jeremy Quinn]

Hi All,

Is it safe to use the SiteMap recursively?

ie. a Pipeline calling itself via the cocoon:/ protocol?

How? Via CInclude or XSLT document() function, etc.

(can XSLT use the cocoon:/ protocol?)


thanks for any help

regards Jeremy


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

RE: Planning the releases

[Vadim Gritsenko]

> From: Sylvain Wallez [mailto:[EMAIL PROTECTED]]
> 
> Nicola Ken Barozzi wrote:
> 
> > Carsten Ziegeler wrote:
> >
> >> Hi Team,
> >>
> >> I think it's time to recall the "release early release often"
> >> paradigma...
> >>
> >> As others already mentioned over the last weeks, we should try to
> >> release a 2.0.3 as soon as possible. For this we should collect the
> >> open issues, do them and release (sounds simple, doesn't it?)
> >
> >
> > ;-)
> >
> > Major thing: make the distro working and tested on Jdk 1.3 *and*
1.4.

This is the most discussed issue on the user list, it must be fixed
before release. Can we have now Excalibur which works with 1.3 *and*
1.4?


> > I haven't looked in the linkstatus 1.2 problem yet, lack of time :-/
> > What was the code snippet that was giving problems with 1.2?
> >
> >> As I'm next week on vacation near Paris :) what do you think of
> >> the 1st of July as a release date for 2.0.3?
> >
> >
> > +1

+1 provided issue above is solved.


> +1 also. Want a french guide for your vacation ? ;)
> 
> >> And if we are already talking about releases, what do we have to do
> >> for 2.1? It seems that many things are nearly finished, so we can
> >> start to think of a beta phase. I would propose the 15th of July
for
> >> the release date of 2.1 beta 1.
> >
> > +0

+0. I have not had a chance to review new interfaces/syntax additions.
After Cocoon goes beta, it won't be possible to make any changes. Hope
will have time for this till July 15th.


> >> What do you think?
> >
> >
> > I think that 2.1 features are all the ones we have now in CVS,
bsically.
> > We need to :
> > - apply patches
> > - test flowmap + docs + etc
> > - documentation to forrest format
> > - finish example refactoring
> > - finish to move scratchpad stuff in main trunk
> >
> 
> Some more issues/todo for 2.1 :
> - switch to Avalon Source everywhere (is it already done ?)
> - switch to LogEnabled
> - I have to write the extended sitemap variable substitution, i.e.
> {request:foo}. I'm late on this since my Cocoon time is currently
> devoted to reviewing a book written by people named... Carsten and
> Matthew ;-)
> - 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.

+1.
 
Vadim

> Entering beta state would then allow more people to test this baby !
> 
> Sylvain
> 
> --
> Sylvain Wallez
>   Anyware Technologies  Apache Cocoon
>   http://www.anyware-tech.com   mailto:[EMAIL PROTECTED]



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

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/source/impl FileSource.java

[cziegeler]

cziegeler2002/06/12 05:28:16

  Modified:src/java/org/apache/cocoon/components/source/impl
FileSource.java
  Log:
  Fixed FileSource
  
  Revision  ChangesPath
  1.3   +12 -10
xml-cocoon2/src/java/org/apache/cocoon/components/source/impl/FileSource.java
  
  Index: FileSource.java
  ===
  RCS file: 
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/components/source/impl/FileSource.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- FileSource.java   4 Jun 2002 07:11:27 -   1.2
  +++ FileSource.java   12 Jun 2002 12:28:16 -  1.3
  @@ -103,14 +103,12 @@
   
   private File tmpFile;
   private boolean isClosed = false;
  +private FileSource source;
   
  -public FileSourceOutputStream(File tmpFile) throws IOException {
  +public FileSourceOutputStream(File tmpFile, FileSource source) throws 
IOException {
   super(tmpFile);
   this.tmpFile = tmpFile;
  -}
  -
  -public FileSource getSource() {
  -return FileSource.this;
  +this.source = source;
   }
   
   public void close() throws IOException {
  @@ -118,11 +116,11 @@
   
   try {
   // Delete destination file
  -if (FileSource.this.file.exists()) {
  -FileSource.this.file.delete();
  +if (this.source.file.exists()) {
  +this.source.file.delete();
   }
   // Rename temp file to destination file
  -tmpFile.renameTo(FileSource.this.file);
  +tmpFile.renameTo(this.source.file);
   
   } finally {
   // Ensure temp file is deleted, ie lock is released.
  @@ -154,6 +152,10 @@
   tmpFile.delete();
   }
   }
  +
  +public FileSource getSource() {
  +return this.source;
  +}
   }
   
   /**
  @@ -200,7 +202,7 @@
   }
   
   // Return a stream that will rename the temp file on close.
  -return new FileSourceOutputStream(tmpFile);
  +return new FileSourceOutputStream(tmpFile, this);
   }
   
   /**
  
  
  

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

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/components/repository/impl slide.xconf

[cziegeler]

cziegeler2002/06/12 03:54:28

  Modified:.build.xml
   src/scratchpad/src/org/apache/cocoon/components/repository/impl
slide.xconf
  Log:
  Fixing XML in slide config and adding property to control the inclusion of the 
javadocs in the webapp
  
  Revision  ChangesPath
  1.232 +2 -1  xml-cocoon2/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/xml-cocoon2/build.xml,v
  retrieving revision 1.231
  retrieving revision 1.232
  diff -u -r1.231 -r1.232
  --- build.xml 12 Jun 2002 07:24:16 -  1.231
  +++ build.xml 12 Jun 2002 10:54:27 -  1.232
  @@ -1143,7 +1143,8 @@
 
 
 
  -  
  +  
  +
   
 
   
  
  
  
  1.2   +1 -1  
xml-cocoon2/src/scratchpad/src/org/apache/cocoon/components/repository/impl/slide.xconf
  
  Index: slide.xconf
  ===
  RCS file: 
/home/cvs/xml-cocoon2/src/scratchpad/src/org/apache/cocoon/components/repository/impl/slide.xconf,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- slide.xconf   11 Jun 2002 18:09:12 -  1.1
  +++ slide.xconf   12 Jun 2002 10:54:28 -  1.2
  @@ -13,7 +13,7 @@
 
  +  default="ownrepository">
  
   
   
  
  
  

--
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/reading ResourceReader.java

[cziegeler]

cziegeler2002/06/12 03:20:56

  Modified:src/java/org/apache/cocoon/reading ResourceReader.java
  Log:
  (Re)adding setContentLength to reader
  
  Revision  ChangesPath
  1.17  +2 -10 
xml-cocoon2/src/java/org/apache/cocoon/reading/ResourceReader.java
  
  Index: ResourceReader.java
  ===
  RCS file: 
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/reading/ResourceReader.java,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- ResourceReader.java   5 Jun 2002 06:39:13 -   1.16
  +++ ResourceReader.java   12 Jun 2002 10:20:56 -  1.17
  @@ -147,13 +147,7 @@
* possible to detect
*/
   public long getLastModified() {
  -final SourceValidity validity = this.inputSource.getValidity();
  -if (validity instanceof TimeStampValidity) {
  -return ((TimeStampValidity)validity).getTimeStamp();
  -} else if (validity instanceof FileTimeStampValidity) {
  -return ((FileTimeStampValidity)validity).getTimeStamp();
  -}
  -return 0;
  +return this.inputSource.getLastModified();
   }
   
   /**
  @@ -170,14 +164,12 @@
   response.setDateHeader("Expires", System.currentTimeMillis() + 
expires);
   }
   
  -/* FIXME: VG: getContentLength is gone.
   long contentLength = this.inputSource.getContentLength();
   if (contentLength != -1) {
   // FIXME (VG): Environment has setContentLength, and
   // Response interface has not. Strange.
   response.setHeader("Content-Length", Long.toString(contentLength));
   }
  -*/
   
   // Bug #9539: This resource reader does not support ranges
   response.setHeader("Accept-Ranges", "none");
  
  
  

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

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/components/source SlideSource.java repository.xconf

[cziegeler]

cziegeler2002/06/12 03:14:53

  Modified:lib  jars.xml
   src/java/org/apache/cocoon/components/source/impl
AvalonToCocoonSource.java CocoonToAvalonSource.java
SitemapSource.java
   src/scratchpad/src/org/apache/cocoon/components/repository/impl
SlideSource.java
   src/scratchpad/src/org/apache/cocoon/components/source
SlideSource.java repository.xconf
  Added:   lib/core avalon-excalibur-20020612.jar
  Removed: lib/core avalon-excalibur-20020603.jar
  Log:
  Switched to latest excalibur and fixed error in slide source configuration
  
  Revision  ChangesPath
  1.12  +1 -1  xml-cocoon2/lib/jars.xml
  
  Index: jars.xml
  ===
  RCS file: /home/cvs/xml-cocoon2/lib/jars.xml,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- jars.xml  5 Jun 2002 00:54:20 -   1.11
  +++ jars.xml  12 Jun 2002 10:14:51 -  1.12
  @@ -15,7 +15,7 @@
Part of jakarta-avalon, it is a set of classes and patterns that
  support high level server development.
Cocoon
  - core/avalon-excalibur-20020603.jar
  + core/avalon-excalibur-20020612.jar
http://jakarta.apache.org/avalon/excalibur/


  
  
  
  1.2   +1215 -0   xml-cocoon2/lib/core/avalon-excalibur-20020612.jar
  
<>
  
  
  1.6   +3 -11 
xml-cocoon2/src/java/org/apache/cocoon/components/source/impl/AvalonToCocoonSource.java
  
  Index: AvalonToCocoonSource.java
  ===
  RCS file: 
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/components/source/impl/AvalonToCocoonSource.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- AvalonToCocoonSource.java 4 Jun 2002 07:31:52 -   1.5
  +++ AvalonToCocoonSource.java 12 Jun 2002 10:14:53 -  1.6
  @@ -101,14 +101,7 @@
* is not possible to determine the date.
*/
   public long getLastModified() {
  -final SourceValidity validity = this.source.getValidity();
  -if (validity instanceof TimeStampValidity) {
  -return ((TimeStampValidity)validity).getTimeStamp();
  -}
  -if (validity instanceof FileTimeStampValidity) {
  -return ((FileTimeStampValidity)validity).getTimeStamp();
  -}
  -return 0;
  +return this.source.getLastModified();
   }
   
   /**
  @@ -116,8 +109,7 @@
* is not possible to determine the length.
*/
   public long getContentLength() {
  -// We have no possibility to get this!
  -return -1;
  +return this.source.getContentLength();
   }
   
   /**
  
  
  
  1.4   +52 -1 
xml-cocoon2/src/java/org/apache/cocoon/components/source/impl/CocoonToAvalonSource.java
  
  Index: CocoonToAvalonSource.java
  ===
  RCS file: 
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/components/source/impl/CocoonToAvalonSource.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- CocoonToAvalonSource.java 4 Jun 2002 07:31:52 -   1.3
  +++ CocoonToAvalonSource.java 12 Jun 2002 10:14:53 -  1.4
  @@ -52,6 +52,7 @@
   
   import java.io.IOException;
   import java.io.InputStream;
  +import java.util.Iterator;
   import org.apache.avalon.excalibur.pool.Recyclable;
   import org.apache.avalon.excalibur.xml.XMLizable;
   import org.apache.excalibur.source.*;
  @@ -157,4 +158,54 @@
   public void recycle() {
   this.source.recycle();
   }
  +
  +/**
  + * Return the content length of the content or -1 if the length is
  + * unknown
  + */
  +public long getContentLength()
  +{
  +return this.source.getContentLength();
  +}
  +
  +/**
  + * Get the last modification date of the source or 0 if it
  + * is not possible to determine the date.
  + */
  +public long getLastModified()
  +{
  +return this.source.getLastModified();
  +}
  +
  +/**
  + * Get the value of a parameter.
  + * Using this it is possible to get custom information provided by the
  + * source implementation, like an expires date, HTTP headers etc.
  + */
  +public String getParameter(String name) {
  +return null;
  +}
  +
  +/**
  + * Get the value of a parameter.
  + * Using this it is possible to get custom information provided by the
  + * source implementation, like an expires date, HTTP headers etc.
  + */
  +public long getParameterAsLong(String name) {
  +return 0;
  +}
  +
  +/**
  + * Get parameter names
  + * Using this it is possible to get custom information provided 

Re: Planning the releases

[Davanum Srinivas]

+1 for both dates.

July 1 for C2.0.3
July 15 for C2.1 beta 1

Thanks,
dims

--- Christian Haul <[EMAIL PROTECTED]> wrote:
> On 12.Jun.2002 -- 09:22 AM, Carsten Ziegeler wrote:
> > Hi Team,
> > 
> > I think it's time to recall the "release early release often" paradigma...
> > 
> > As others already mentioned over the last weeks, we should try to
> > release a 2.0.3 as soon as possible. For this we should collect the
> > open issues, do them and release (sounds simple, doesn't it?)
> > 
> > As I'm next week on vacation near Paris :) what do you think of
> > the 1st of July as a release date for 2.0.3?
> 
> +1
> 
> > And if we are already talking about releases, what do we have
> > to do for 2.1? It seems that many things are nearly finished, so
> > we can start to think of a beta phase. I would 
> > propose the 15th of July for the release date of 2.1 beta 1.
> > 
> > What do you think?
> 
> +1
> 
>   Chris.
> 
> -- 
> C h r i s t i a n   H a u l
> [EMAIL PROTECTED]
> fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 


=
Davanum Srinivas - http://xml.apache.org/~dims/

__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

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

cvs commit: xml-cocoon2/lib/core avalon-excalibur-20020612.jar

[cziegeler]

cziegeler2002/06/12 03:04:38

  Modified:lib  Tag: cocoon_2_0_3_branch jars.xml
   lib/core Tag: cocoon_2_0_3_branch
avalon-excalibur-20020612.jar
  Log:
  Fixed jar list, update excalibur
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.11.2.2  +1 -1  xml-cocoon2/lib/jars.xml
  
  Index: jars.xml
  ===
  RCS file: /home/cvs/xml-cocoon2/lib/jars.xml,v
  retrieving revision 1.11.2.1
  retrieving revision 1.11.2.2
  diff -u -r1.11.2.1 -r1.11.2.2
  --- jars.xml  9 Jun 2002 12:47:47 -   1.11.2.1
  +++ jars.xml  12 Jun 2002 10:04:37 -  1.11.2.2
  @@ -15,7 +15,7 @@
Part of jakarta-avalon, it is a set of classes and patterns that
  support high level server development.
Cocoon
  - core/avalon-excalibur-20020603.jar
  + core/avalon-excalibur-20020612.jar
http://jakarta.apache.org/avalon/excalibur/


  
  
  
  No   revision
  
  
  No   revision
  
  
  1.1.2.2   +94 -96xml-cocoon2/lib/core/Attic/avalon-excalibur-20020612.jar
  
<>
  
  

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

RE: Planning the releases

[Carsten Ziegeler]

Sylvain Wallez wrote:
> >
> >> As I'm next week on vacation near Paris :) what do you think of
> >> the 1st of July as a release date for 2.0.3?
> >
> >
> > +1
>
>
> +1 also. Want a french guide for your vacation ? ;)
>
Oui, je comprends peu francais...but a french guide (who's also paying),
well, why not :)

> >> And if we are already talking about releases, what do we have to do
> >> for 2.1? It seems that many things are nearly finished, so we can
> >> start to think of a beta phase. I would propose the 15th of July for
> >> the release date of 2.1 beta 1.
> >
> >
> > +0
> >
> >> What do you think?
> >
> >
> > I think that 2.1 features are all the ones we have now in CVS, bsically.
> > We need to :
> > - apply patches
> > - test flowmap + docs + etc
> > - documentation to forrest format
> > - finish example refactoring
> > - finish to move scratchpad stuff in main trunk
> >
>
> Some more issues/todo for 2.1 :
> - switch to Avalon Source everywhere (is it already done ?)
No, there are a few places, but with my last updates to the excalibur
source interface (adding getLastModified() ) we can switch everywhere
without problems now.

> - switch to LogEnabled
> - I have to write the extended sitemap variable substitution, i.e.
> {request:foo}. I'm late on this since my Cocoon time is currently
> devoted to reviewing a book written by people named... Carsten and
> Matthew ;-)
Tell us more about it :) (just a joke)

> - 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.
>
> Entering beta state would then allow more people to test this baby !
Yupp!

Carsten


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