You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@cocoon.apache.org by Ivelin Ivanov <iv...@apache.org> on 2002/06/08 01:51:09 UTC

[VOTE] Schematron validator in Anteater (and Cocoon validating Transformer)


=================================
||     VERY LONG !!!           ||
=================================
||    AND INTERESTING.         ||
=================================


I am surprised that there is not much interest in the Cocoon community for
Anteater. What do people use for web apps functional test suites?
There are a few other open source test tools, but I think Anteater has great
potential. Especially for Cocoon apps.

So, let's begin:



                        - 1 -




While Anteater is still not solidified and has a relatively small user base,
I would like to suggest an architectural change, which is compatible with
Anteater's values, but will hopefully
improve it in the following areas:

1) standartization
2) learning curve
3) cross project code reuse
4) maintainance

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.
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
<match/> to other properties which are used for subsequent requests is a
separate concern.




                        - 2 -




Schematron was specificly designed for partial, multi-phase validation and
user friendly error reporting.

I'll explain how points 1-4 above are addressed by this proposal:

1) Schematron is relatively popular. There are a number of articles in
popular magazines which promote Schematron over other validating schemas.
2) Schematron is very easy to learn. Specification and tutorials are
availbel. There is also supporing discussion groups with decent response
time.
3) Schematron is used for a number of projects. For example there is a
complete RSS 1.0 validating schema available on the RSS site.
http://home.freeuk.com/leigh.dodds/rss_validator/
XMLForm is using schematron extensively as well. Slash-edit is another
example.
4) Maintainance of Schematron documents is easy. Minor local changes are
made as the underlying (validated) model changes.





                        - 3 -





5) Bonus ;)

Here is one additional reason why I posted this proposal.
Validating Schematron documents can be referenced in a transparent
transformer prior to a page serialization.
This can be useful in development and QA, to catch and report bugs in
content (HTML, WAP, XML, etc.) during navigation.

Searching for problems in a broken HTML page (or other xml markup) can be
painful.
Instead of searching for the missing tags or label or icon, the tester (or
developer) will see a meaningful error report in place of the actual page.
After testing certain pages time and again, the eye tends to ignore elements
peripheral to the currently tested feature.
If there is an underlying validating document which is applied before
display, then things may be easier. The developer (tester) has to only make
changes to it when the page structure changes.
The rest of the time this document will be a safeguard of unexpected
problems caused as side efects by the development of other features or bug
fixes or another one of the infinite other possible reasons.
The transformer applying the validating document can be, of course, turned
off in production.

Now the next interesting part. The forementioned validating documents can be
referenced just as well by Anteater regression suites as they can by a
pipeline embedded validating transformer.






                        - 4 -




As a quick thought, this is how an Anteater script may look:

<?xml version="1.0" encoding="utf-8"?>

<project name="calc-test" default="calc">

  <!-- Simulate the behavior of a user that opens a browser, starts
  the calculator example, and goes back in the processing several
  times. -->
  <target name="calc">
    <property name="calc" value="${cocoon}/samples/flow/examples/calc/"/>
    <property name="schema-doc-ns"
value="http://www.ascc.net/xml/schematron"/>
    <property name="schema-doc-url"
value="${cocoon}/samples/flow/examples/calc/sch-report.xml"/>
    <http description="Test the 'calc' JavaScript implementation">
      <httpRequest href="${calc}/">
        <match>
          <xpath select="html/body//form/@action" assign="cont1"/>
          <validate phase="page1" assign="violations">
        </match>
      </httpRequest>

      <echo>result = ${violations}</echo>
    </http>

....

Then the Schematron document would be something like:

<schema xmlns="http://www.ascc.net/xml/schematron">

    <title>Schema for the Calc example</title>

    <phase id="page1">
            <p>first page check.</p>
            <active pattern="form-present"/>
    </phase>
    ... other phases ...
    <pattern name="Test for HTML form element" id="form-present">
<rule context="/">
<assert  test="//form">
        Form element expected on this page.
      </assert>
<assert  test="//form/@action">
  Form element must have action attribute.
      </assert>
</rule>
... other rules ...
</pattern>
    ... other patterns...

   </schema>
...




Where the validate element will use the validation package to apply the
schema against the document.
The violations can be then nicely integrated in the JUnit reporting package.



If there are enough votes I'll contribute some of the work myself.
Help would be certainly appreciated.


Thanks for reading this far.


Thoughts?


-= Ivelin =-



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

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

Posted by Ivelin Ivanov <iv...@apache.org>.

Web Test Seems like a nice tool for html pages.

Since it simulates user actions, how does it deal with pages where 
clicking on a button results in JavaScript invokation which manipulates 
the form before submitting?

Does Web Test allow direct submit with custom request parameters 
specified in the scripts?


Ivelin


Michael Wechner wrote:
> 
> 
> Ivelin Ivanov wrote:
> 
>>
>> =================================
>> ||     VERY LONG !!!           ||
>> =================================
>> ||    AND INTERESTING.         ||
>> =================================
>>
>>
>> I am surprised that there is not much interest in the Cocoon community 
>> for
>> Anteater. What do people use for web apps functional test suites?
> 
> 
> 
> We are currently using WebTest (also ant based):
> http://webtest.canoo.com/webtest/manual/WebTestHome.html
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: ServletProxyGenerator

Posted by Michael Wechner <mi...@wyona.org>.


Ivelin Ivanov wrote:

>Sounds similar to the recently contributed WebServiceProxyGenerator.
>
>Check it. Maybe you can add improvements instead of writing a new component
>with overlapping functionality:
>

That's right. I will check it out.

Thanks a lot

Michael


>
>
>http://www.mail-archive.com/cocoon-dev@xml.apache.org/msg19390.html
>
>
>Ivelin
>
>
>----- Original Message -----
>From: "Michael Wechner" <mi...@wyona.org>
>To: <co...@xml.apache.org>
>Cc: <co...@xml.apache.org>
>Sent: Tuesday, July 16, 2002 10:46 AM
>Subject: ServletProxyGenerator
>
>
>>Hi
>>
>>I am currently working on a ServletProxyGenerator:
>>
>>    +--------+       +------------------------+       +---------+
>>    |        | ----> | Cocoon:                | ----> |         |
>>    | Client |       | ServletProxyGenerator: |       | Servlet |
>>    |        | <---- | HttpClient             | <---- |         |
>>    +--------+       +------------------------+       +---------+
>>
>>with the goal to connect some "legacy servlets" and being able to
>>pipe them through Cocoon.
>>
>>Actually the ServletProxyGenerator doesn't do a lot. It is just creating
>>an HttpClient (org.apache.commons.http) and "forwarding" all parameters
>>(POST) and
>>the QueryString (GET) from the original client to the HttpClient being
>>instanced within the ServletProxyGenerator.
>>
>>It is working very fine so far. I now wanted to connect some servlets
>>which need the session of the original client, which means I started to
>>transfer all Cookies into the HttpClient.
>>
>>The problem now is, that the servlet still doesn't find the session!
>>
>>Does anyone have experience with these kind of stuff: Passing cookies
>>from one client to another?
>>
>>Thanks for your help and comments
>>
>>Michael
>>
>>P.S.: If the ServletProxyGenerator is of any use for the Cocoon
>>community, then I would be happy to donate it.
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>>For additional commands, email: cocoon-dev-help@xml.apache.org
>>
>
>
>---------------------------------------------------------------------
>Please check that your question  has not already been answered in the
>FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>
>
>To unsubscribe, e-mail:     <co...@xml.apache.org>
>For additional commands, e-mail:   <co...@xml.apache.org>
>



---------------------------------------------------------------------
Please check that your question  has not already been answered in the
FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail:     <co...@xml.apache.org>
For additional commands, e-mail:   <co...@xml.apache.org>

Re: WebServiceProxy

Posted by Michael Wechner <mi...@wyona.org>.


Ivelin Ivanov wrote:

>The HttpMultiClient maintains a session by default.
>
>Interestingly the HttpClient has been a stable alpha for many months.
>There are occasionally discussions for upgrading it to 1.0, but no one has
>stepped up to do that.
>
>HttpMultiClient is the one that has the richest functionality and is
>preferred to use over the plain HttpClient.
>
>Other than the JavaDoc, I have found much use from the unit tests and the
>jakarta-commons discussion list.
>

Thanks Ivelin. I will dive into it.

Michael

>
>
>
>Ivelin
>
>
>----- Original Message -----
>From: "Michael Wechner" <mi...@wyona.org>
>To: <co...@xml.apache.org>
>Sent: Monday, July 22, 2002 5:06 PM
>Subject: Re: WebServiceProxy
>
>
>>
>>Ivelin Ivanov wrote:
>>
>>>Interesting case.
>>>
>>>Appears that two sessions are crossing each other's ways.
>>>
>>>I have tried multiple browsers with multiple sessions working against the
>>>same Feedback wizard, to test for this.
>>>WSProxy uses the jakarta HttpClient library, which saves and reuses the
>>>cookies, thus the session, if started by the remote application.
>>>
>>>Maybe you will need to dump all HTTP headers to be able to track down the
>>>problem.
>>>Once you identify it, please let me know what it is, so we can discuss a
>>>possible patch.
>>>
>>I will try to locate the problem.
>>
>>Can you give me a hint where you tell the HttpClient to save
>>and reuse the cookies (or is this just default behaviour)?
>>
>>And what is the role of the HttpMultiClient?
>>
>>And do you know a URL of any "advanced" documentation of the HttpClient
>>library form jakarta,
>> or is there only the JavaDoc?
>>
>>Thanks
>>
>>Michael
>>
>>
>>>
>>>
>>>Cheers,
>>>
>>>Ivelin
>>>
>>>
>>>
>>>----- Original Message -----
>>>From: "Michael Wechner" <mi...@wyona.org>
>>>To: <co...@xml.apache.org>
>>>Sent: Sunday, July 21, 2002 10:29 PM
>>>Subject: WebServiceProxy
>>>
>>>
>>>>Hi
>>>>
>>>>I started to check the WebServiceProxy.
>>>>
>>>>I am using Linux (2.4) JDK1.3.1 and Tomcat 4.0.4-b3 and
>>>>xml-cocoon2_20020719041901.tar.gz (2.1-dev)
>>>>
>>>>I included the following pipeline into the sitemap
>>>>
>>>>    <map:match pattern="HelloWorld">
>>>>       <map:generate type="wsproxy"
>>>>src="http://localhost:8080/wyona-cms/servlet/HelloWorld" labe
>>>>l="xml"/>
>>>>       <map:serialize type="xml"/>
>>>>     </map:match>
>>>>
>>>>The HelloWorld servlet returns the following XML
>>>>
>>>><servlet class="org.wyona.cms.cocoon.generation.HelloWorld">
>>>><request method="GET"><nosession/></request></servlet>
>>>>
>>>>Because I forgot the line <?xml version="1.0"?> I received an error,
>>>>but then the problem was that "samples/webserviceproxy" didn't run
>>>>anymore, which means I received a broken pipe error.
>>>>
>>>>After I inserted the line <?xml version="1.0"?> it seemed to be alright.
>>>>
>>>>But when I started to create a session, then it broke again. I checked
>>>>the same cocoon instance with another browser, which didn't have a
>>>>
>session
>
>>>yet.
>>>
>>>>It worked. As soon as I created a session, the WebServiceProxy crashed
>>>>
>for
>
>>>this client.
>>>
>>>>Please see below the stack trace.
>>>>I guess it must have something to do with "passing the session" resp.
>>>>
>>>"passing the cookies".
>>>
>>>>But I didn't find anything within your code, where you would do
>>>>
>something
>
>>>like that.
>>>
>>>>Thanks
>>>>
>>>>Michael
>>>>



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: WebServiceProxy

Posted by Ivelin Ivanov <iv...@apache.org>.

The HttpMultiClient maintains a session by default.

Interestingly the HttpClient has been a stable alpha for many months.
There are occasionally discussions for upgrading it to 1.0, but no one has
stepped up to do that.

HttpMultiClient is the one that has the richest functionality and is
preferred to use over the plain HttpClient.

Other than the JavaDoc, I have found much use from the unit tests and the
jakarta-commons discussion list.


Ivelin


----- Original Message -----
From: "Michael Wechner" <mi...@wyona.org>
To: <co...@xml.apache.org>
Sent: Monday, July 22, 2002 5:06 PM
Subject: Re: WebServiceProxy


>
>
> Ivelin Ivanov wrote:
>
> >Interesting case.
> >
> >Appears that two sessions are crossing each other's ways.
> >
> >I have tried multiple browsers with multiple sessions working against the
> >same Feedback wizard, to test for this.
> >WSProxy uses the jakarta HttpClient library, which saves and reuses the
> >cookies, thus the session, if started by the remote application.
> >
> >Maybe you will need to dump all HTTP headers to be able to track down the
> >problem.
> >Once you identify it, please let me know what it is, so we can discuss a
> >possible patch.
> >
>
> I will try to locate the problem.
>
> Can you give me a hint where you tell the HttpClient to save
> and reuse the cookies (or is this just default behaviour)?
>
> And what is the role of the HttpMultiClient?
>
> And do you know a URL of any "advanced" documentation of the HttpClient
> library form jakarta,
>  or is there only the JavaDoc?
>
> Thanks
>
> Michael
>
>
> >
> >
> >
> >Cheers,
> >
> >Ivelin
> >
> >
> >
> >----- Original Message -----
> >From: "Michael Wechner" <mi...@wyona.org>
> >To: <co...@xml.apache.org>
> >Sent: Sunday, July 21, 2002 10:29 PM
> >Subject: WebServiceProxy
> >
> >
> >>Hi
> >>
> >>I started to check the WebServiceProxy.
> >>
> >>I am using Linux (2.4) JDK1.3.1 and Tomcat 4.0.4-b3 and
> >>xml-cocoon2_20020719041901.tar.gz (2.1-dev)
> >>
> >>I included the following pipeline into the sitemap
> >>
> >>     <map:match pattern="HelloWorld">
> >>        <map:generate type="wsproxy"
> >>src="http://localhost:8080/wyona-cms/servlet/HelloWorld" labe
> >>l="xml"/>
> >>        <map:serialize type="xml"/>
> >>      </map:match>
> >>
> >>The HelloWorld servlet returns the following XML
> >>
> >><servlet class="org.wyona.cms.cocoon.generation.HelloWorld">
> >><request method="GET"><nosession/></request></servlet>
> >>
> >>Because I forgot the line <?xml version="1.0"?> I received an error,
> >>but then the problem was that "samples/webserviceproxy" didn't run
> >>anymore, which means I received a broken pipe error.
> >>
> >>After I inserted the line <?xml version="1.0"?> it seemed to be alright.
> >>
> >>But when I started to create a session, then it broke again. I checked
> >>the same cocoon instance with another browser, which didn't have a
session
> >>
> >yet.
> >
> >>It worked. As soon as I created a session, the WebServiceProxy crashed
for
> >>
> >this client.
> >
> >>Please see below the stack trace.
> >>I guess it must have something to do with "passing the session" resp.
> >>
> >"passing the cookies".
> >
> >>But I didn't find anything within your code, where you would do
something
> >>
> >like that.
> >
> >>
> >>Thanks
> >>
> >>Michael
> >>
> >>Original exception : java.io.IOException: Broken pipe
> >>at java.net.SocketOutputStream.socketWrite(Native Method)
> >>at java.net.SocketOutputStream.write(SocketOutputStream.java:71)
> >>at
> >>
>
>org.apache.commons.httpclient.HttpConnection.write(HttpConnection.java:363)
> >
> >>at
> >>
>
>org.apache.commons.httpclient.HttpConnection.print(HttpConnection.java:433)
> >
> >>at
> >>
>
>org.apache.commons.httpclient.HttpMethodBase.writeRequestHeaders(HttpMethod
B
> >ase.java:741)
> >
> >>at
> >>
>
>org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.ja
v
> >a:693)
> >
> >>at
> >>
>
>org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:46
9
> >)
> >
> >>at
> >>
>
>org.apache.commons.httpclient.HttpMultiClient.executeMethod(HttpMultiClient
.
> >java:286)
> >
> >>at
> >>
>
>org.apache.cocoon.generation.WebServiceProxyGenerator.fetch(WebServiceProxy
G
> >enerator.java:254)
> >
> >>at
> >>
>
>org.apache.cocoon.generation.WebServiceProxyGenerator.generate(WebServicePr
o
> >xyGenerator.java:172)
> >
> >>at
> >>
>
>org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXML
P
> >ipeline(AbstractProcessingPipeline.java:501)
> >
> >>at
> >>
>
>org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipelin
e
> >.processXMLPipeline(AbstractCachingProcessingPipeline.java:204)
> >
> >>at
> >>
>
>org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(Ab
s
> >tractProcessingPipeline.java:476)
> >
> >>at
> >>
>
>org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(Ser
i
> >alizeNode.java:146)
> >
> >>at
> >>
>
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.inv
o
> >keNodes(AbstractParentProcessingNode.java:83)
> >
> >>at
> >>
>
>org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invo
k
> >e(PreparableMatchNode.java:160)
> >
> >>at
> >>
>
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.inv
o
> >keNodes(AbstractParentProcessingNode.java:107)
> >
> >>at
> >>
>
>org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(Pipe
l
> >ineNode.java:157)
> >
> >>at
> >>
>
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.inv
o
> >keNodes(AbstractParentProcessingNode.java:107)
> >
> >>at
> >>
>
>org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(Pip
e
> >linesNode.java:152)
> >
> >>at
> >>
>
>org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProces
s
> >or.java:328)
> >
> >>at
> >>
>
>org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProces
s
> >or.java:309)
> >
> >>at
> >>
>
>org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNo
d
> >e.java:131)
> >
> >>at
> >>
>
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.inv
o
> >keNodes(AbstractParentProcessingNode.java:83)
> >
> >>at
> >>
>
>org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invo
k
> >e(PreparableMatchNode.java:160)
> >
> >>at
> >>
>
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.inv
o
> >keNodes(AbstractParentProcessingNode.java:107)
> >
> >>at
> >>
>
>org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(Pipe
l
> >ineNode.java:157)
> >
> >>at
> >>
>
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.inv
o
> >keNodes(AbstractParentProcessingNode.java:107)
> >
> >>at
> >>
>
>org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(Pip
e
> >linesNode.java:152)
> >
> >>at
> >>
>
>org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProces
s
> >or.java:328)
> >
> >>at
> >>
>
>org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProces
s
> >or.java:309)
> >
> >>at
> >>
>
>org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNo
d
> >e.java:131)
> >
> >>at
> >>
>
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.inv
o
> >keNodes(AbstractParentProcessingNode.java:83)
> >
> >>at
> >>
>
>org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invo
k
> >e(PreparableMatchNode.java:160)
> >
> >>at
> >>
>
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.inv
o
> >keNodes(AbstractParentProcessingNode.java:107)
> >
> >>at
> >>
>
>org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(Pipe
l
> >ineNode.java:157)
> >
> >>at
> >>
>
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.inv
o
> >keNodes(AbstractParentProcessingNode.java:107)
> >
> >>at
> >>
>
>org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(Pip
e
> >linesNode.java:152)
> >
> >>at
> >>
>
>org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProces
s
> >or.java:328)
> >
> >>at
> >>
>
>org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProces
s
> >or.java:309)
> >
> >>at org.apache.cocoon.Cocoon.process(Cocoon.java:585)
> >>at
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:997)
> >>at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> >>at
> >>
>
>org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicatio
n
> >FilterChain.java:247)
> >
> >>at
> >>
>
>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterC
h
> >ain.java:193)
> >
> >>at
> >>
>
>org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.j
a
> >va:243)
> >
> >>at
> >>
>
>org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
5
> >66)
> >
> >>at
> >>
>
>org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> >
> >>at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> >>at
> >>
>
>org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.j
a
> >va:190)
> >
> >>at
> >>
>
>org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
5
> >66)
> >
> >>at
> >>
>
>org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> >
> >>at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> >>at
>
>>org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2347)
> >>at
> >>
>
>org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:18
0
> >)
> >
> >>at
> >>
>
>org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
5
> >66)
> >
> >>at
> >>
>
>org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve
.
> >java:170)
> >
> >>at
> >>
>
>org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
5
> >64)
> >
> >>at
> >>
>
>org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:17
0
> >)
> >
> >>at
> >>
>
>org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
5
> >64)
> >
> >>at
> >>
> >org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468)
> >
> >>at
> >>
>
>org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
5
> >64)
> >
> >>at
> >>
>
>org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> >
> >>at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> >>at
> >>
>
>org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.jav
a
> >:174)
> >
> >>at
> >>
>
>org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
5
> >66)
> >
> >>at
> >>
>
>org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> >
> >>at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> >>at
> >>
>
>org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java
:
> >1027)
> >
> >>at
> >>
>
>org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:112
5
> >)
> >
> >>at java.lang.Thread.run(Thread.java:484)
> >>
> >>
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> >>For additional commands, email: cocoon-dev-help@xml.apache.org
> >>
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> >For additional commands, email: cocoon-dev-help@xml.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: WebServiceProxy

Posted by Michael Wechner <mi...@wyona.org>.


Ivelin Ivanov wrote:

>Interesting case.
>
>Appears that two sessions are crossing each other's ways.
>
>I have tried multiple browsers with multiple sessions working against the
>same Feedback wizard, to test for this.
>WSProxy uses the jakarta HttpClient library, which saves and reuses the
>cookies, thus the session, if started by the remote application.
>
>Maybe you will need to dump all HTTP headers to be able to track down the
>problem.
>Once you identify it, please let me know what it is, so we can discuss a
>possible patch.
>

I will try to locate the problem.

Can you give me a hint where you tell the HttpClient to save
and reuse the cookies (or is this just default behaviour)?

And what is the role of the HttpMultiClient?

And do you know a URL of any "advanced" documentation of the HttpClient 
library form jakarta,
 or is there only the JavaDoc?

Thanks

Michael


>
>
>
>Cheers,
>
>Ivelin
>
>
>
>----- Original Message -----
>From: "Michael Wechner" <mi...@wyona.org>
>To: <co...@xml.apache.org>
>Sent: Sunday, July 21, 2002 10:29 PM
>Subject: WebServiceProxy
>
>
>>Hi
>>
>>I started to check the WebServiceProxy.
>>
>>I am using Linux (2.4) JDK1.3.1 and Tomcat 4.0.4-b3 and
>>xml-cocoon2_20020719041901.tar.gz (2.1-dev)
>>
>>I included the following pipeline into the sitemap
>>
>>     <map:match pattern="HelloWorld">
>>        <map:generate type="wsproxy"
>>src="http://localhost:8080/wyona-cms/servlet/HelloWorld" labe
>>l="xml"/>
>>        <map:serialize type="xml"/>
>>      </map:match>
>>
>>The HelloWorld servlet returns the following XML
>>
>><servlet class="org.wyona.cms.cocoon.generation.HelloWorld">
>><request method="GET"><nosession/></request></servlet>
>>
>>Because I forgot the line <?xml version="1.0"?> I received an error,
>>but then the problem was that "samples/webserviceproxy" didn't run
>>anymore, which means I received a broken pipe error.
>>
>>After I inserted the line <?xml version="1.0"?> it seemed to be alright.
>>
>>But when I started to create a session, then it broke again. I checked
>>the same cocoon instance with another browser, which didn't have a session
>>
>yet.
>
>>It worked. As soon as I created a session, the WebServiceProxy crashed for
>>
>this client.
>
>>Please see below the stack trace.
>>I guess it must have something to do with "passing the session" resp.
>>
>"passing the cookies".
>
>>But I didn't find anything within your code, where you would do something
>>
>like that.
>
>>
>>Thanks
>>
>>Michael
>>
>>Original exception : java.io.IOException: Broken pipe
>>at java.net.SocketOutputStream.socketWrite(Native Method)
>>at java.net.SocketOutputStream.write(SocketOutputStream.java:71)
>>at
>>
>org.apache.commons.httpclient.HttpConnection.write(HttpConnection.java:363)
>
>>at
>>
>org.apache.commons.httpclient.HttpConnection.print(HttpConnection.java:433)
>
>>at
>>
>org.apache.commons.httpclient.HttpMethodBase.writeRequestHeaders(HttpMethodB
>ase.java:741)
>
>>at
>>
>org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.jav
>a:693)
>
>>at
>>
>org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:469
>)
>
>>at
>>
>org.apache.commons.httpclient.HttpMultiClient.executeMethod(HttpMultiClient.
>java:286)
>
>>at
>>
>org.apache.cocoon.generation.WebServiceProxyGenerator.fetch(WebServiceProxyG
>enerator.java:254)
>
>>at
>>
>org.apache.cocoon.generation.WebServiceProxyGenerator.generate(WebServicePro
>xyGenerator.java:172)
>
>>at
>>
>org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLP
>ipeline(AbstractProcessingPipeline.java:501)
>
>>at
>>
>org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline
>.processXMLPipeline(AbstractCachingProcessingPipeline.java:204)
>
>>at
>>
>org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(Abs
>tractProcessingPipeline.java:476)
>
>>at
>>
>org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(Seri
>alizeNode.java:146)
>
>>at
>>
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
>keNodes(AbstractParentProcessingNode.java:83)
>
>>at
>>
>org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invok
>e(PreparableMatchNode.java:160)
>
>>at
>>
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
>keNodes(AbstractParentProcessingNode.java:107)
>
>>at
>>
>org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(Pipel
>ineNode.java:157)
>
>>at
>>
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
>keNodes(AbstractParentProcessingNode.java:107)
>
>>at
>>
>org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(Pipe
>linesNode.java:152)
>
>>at
>>
>org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
>or.java:328)
>
>>at
>>
>org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
>or.java:309)
>
>>at
>>
>org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNod
>e.java:131)
>
>>at
>>
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
>keNodes(AbstractParentProcessingNode.java:83)
>
>>at
>>
>org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invok
>e(PreparableMatchNode.java:160)
>
>>at
>>
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
>keNodes(AbstractParentProcessingNode.java:107)
>
>>at
>>
>org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(Pipel
>ineNode.java:157)
>
>>at
>>
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
>keNodes(AbstractParentProcessingNode.java:107)
>
>>at
>>
>org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(Pipe
>linesNode.java:152)
>
>>at
>>
>org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
>or.java:328)
>
>>at
>>
>org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
>or.java:309)
>
>>at
>>
>org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNod
>e.java:131)
>
>>at
>>
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
>keNodes(AbstractParentProcessingNode.java:83)
>
>>at
>>
>org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invok
>e(PreparableMatchNode.java:160)
>
>>at
>>
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
>keNodes(AbstractParentProcessingNode.java:107)
>
>>at
>>
>org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(Pipel
>ineNode.java:157)
>
>>at
>>
>org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
>keNodes(AbstractParentProcessingNode.java:107)
>
>>at
>>
>org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(Pipe
>linesNode.java:152)
>
>>at
>>
>org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
>or.java:328)
>
>>at
>>
>org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
>or.java:309)
>
>>at org.apache.cocoon.Cocoon.process(Cocoon.java:585)
>>at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:997)
>>at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>>at
>>
>org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
>FilterChain.java:247)
>
>>at
>>
>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
>ain.java:193)
>
>>at
>>
>org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
>va:243)
>
>>at
>>
>org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
>66)
>
>>at
>>
>org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
>
>>at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
>>at
>>
>org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
>va:190)
>
>>at
>>
>org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
>66)
>
>>at
>>
>org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
>
>>at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
>>at
>>org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2347)
>>at
>>
>org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180
>)
>
>>at
>>
>org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
>66)
>
>>at
>>
>org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.
>java:170)
>
>>at
>>
>org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
>64)
>
>>at
>>
>org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170
>)
>
>>at
>>
>org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
>64)
>
>>at
>>
>org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468)
>
>>at
>>
>org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
>64)
>
>>at
>>
>org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
>
>>at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
>>at
>>
>org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
>:174)
>
>>at
>>
>org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
>66)
>
>>at
>>
>org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
>
>>at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
>>at
>>
>org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:
>1027)
>
>>at
>>
>org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1125
>)
>
>>at java.lang.Thread.run(Thread.java:484)
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>>For additional commands, email: cocoon-dev-help@xml.apache.org
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: WebServiceProxy

Posted by Ivelin Ivanov <iv...@apache.org>.

Interesting case.

Appears that two sessions are crossing each other's ways.

I have tried multiple browsers with multiple sessions working against the
same Feedback wizard, to test for this.
WSProxy uses the jakarta HttpClient library, which saves and reuses the
cookies, thus the session, if started by the remote application.

Maybe you will need to dump all HTTP headers to be able to track down the
problem.
Once you identify it, please let me know what it is, so we can discuss a
possible patch.


Cheers,

Ivelin



----- Original Message -----
From: "Michael Wechner" <mi...@wyona.org>
To: <co...@xml.apache.org>
Sent: Sunday, July 21, 2002 10:29 PM
Subject: WebServiceProxy


> Hi
>
> I started to check the WebServiceProxy.
>
> I am using Linux (2.4) JDK1.3.1 and Tomcat 4.0.4-b3 and
> xml-cocoon2_20020719041901.tar.gz (2.1-dev)
>
> I included the following pipeline into the sitemap
>
>      <map:match pattern="HelloWorld">
>         <map:generate type="wsproxy"
> src="http://localhost:8080/wyona-cms/servlet/HelloWorld" labe
> l="xml"/>
>         <map:serialize type="xml"/>
>       </map:match>
>
> The HelloWorld servlet returns the following XML
>
> <servlet class="org.wyona.cms.cocoon.generation.HelloWorld">
> <request method="GET"><nosession/></request></servlet>
>
> Because I forgot the line <?xml version="1.0"?> I received an error,
> but then the problem was that "samples/webserviceproxy" didn't run
> anymore, which means I received a broken pipe error.
>
> After I inserted the line <?xml version="1.0"?> it seemed to be alright.
>
> But when I started to create a session, then it broke again. I checked
> the same cocoon instance with another browser, which didn't have a session
yet.
> It worked. As soon as I created a session, the WebServiceProxy crashed for
this client.
> Please see below the stack trace.
> I guess it must have something to do with "passing the session" resp.
"passing the cookies".
> But I didn't find anything within your code, where you would do something
like that.
>
>
> Thanks
>
> Michael
>
> Original exception : java.io.IOException: Broken pipe
> at java.net.SocketOutputStream.socketWrite(Native Method)
> at java.net.SocketOutputStream.write(SocketOutputStream.java:71)
> at
>
org.apache.commons.httpclient.HttpConnection.write(HttpConnection.java:363)
> at
>
org.apache.commons.httpclient.HttpConnection.print(HttpConnection.java:433)
> at
>
org.apache.commons.httpclient.HttpMethodBase.writeRequestHeaders(HttpMethodB
ase.java:741)
> at
>
org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.jav
a:693)
> at
>
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:469
)
> at
>
org.apache.commons.httpclient.HttpMultiClient.executeMethod(HttpMultiClient.
java:286)
> at
>
org.apache.cocoon.generation.WebServiceProxyGenerator.fetch(WebServiceProxyG
enerator.java:254)
> at
>
org.apache.cocoon.generation.WebServiceProxyGenerator.generate(WebServicePro
xyGenerator.java:172)
> at
>
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLP
ipeline(AbstractProcessingPipeline.java:501)
> at
>
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline
.processXMLPipeline(AbstractCachingProcessingPipeline.java:204)
> at
>
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(Abs
tractProcessingPipeline.java:476)
> at
>
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(Seri
alizeNode.java:146)
> at
>
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:83)
> at
>
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invok
e(PreparableMatchNode.java:160)
> at
>
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:107)
> at
>
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(Pipel
ineNode.java:157)
> at
>
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:107)
> at
>
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(Pipe
linesNode.java:152)
> at
>
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
or.java:328)
> at
>
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
or.java:309)
> at
>
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNod
e.java:131)
> at
>
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:83)
> at
>
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invok
e(PreparableMatchNode.java:160)
> at
>
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:107)
> at
>
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(Pipel
ineNode.java:157)
> at
>
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:107)
> at
>
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(Pipe
linesNode.java:152)
> at
>
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
or.java:328)
> at
>
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
or.java:309)
> at
>
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNod
e.java:131)
> at
>
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:83)
> at
>
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invok
e(PreparableMatchNode.java:160)
> at
>
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:107)
> at
>
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(Pipel
ineNode.java:157)
> at
>
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:107)
> at
>
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(Pipe
linesNode.java:152)
> at
>
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
or.java:328)
> at
>
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
or.java:309)
> at org.apache.cocoon.Cocoon.process(Cocoon.java:585)
> at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:997)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at
>
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:247)
> at
>
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:193)
> at
>
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va:243)
> at
>
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
> at
>
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at
>
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
va:190)
> at
>
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
> at
>
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at
> org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2347)
> at
>
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180
)
> at
>
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
> at
>
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.
java:170)
> at
>
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
64)
> at
>
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170
)
> at
>
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
64)
> at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468)
> at
>
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
64)
> at
>
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at
>
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
:174)
> at
>
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
> at
>
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at
>
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:
1027)
> at
>
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1125
)
> at java.lang.Thread.run(Thread.java:484)
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

WebServiceProxy

Posted by Michael Wechner <mi...@wyona.org>.

Hi

I started to check the WebServiceProxy.

I am using Linux (2.4) JDK1.3.1 and Tomcat 4.0.4-b3 and
xml-cocoon2_20020719041901.tar.gz (2.1-dev)

I included the following pipeline into the sitemap

     <map:match pattern="HelloWorld">
        <map:generate type="wsproxy" 
src="http://localhost:8080/wyona-cms/servlet/HelloWorld" labe
l="xml"/>
        <map:serialize type="xml"/>
      </map:match>

The HelloWorld servlet returns the following XML

<servlet class="org.wyona.cms.cocoon.generation.HelloWorld">
<request method="GET"><nosession/></request></servlet>

Because I forgot the line <?xml version="1.0"?> I received an error,
but then the problem was that "samples/webserviceproxy" didn't run
anymore, which means I received a broken pipe error.

After I inserted the line <?xml version="1.0"?> it seemed to be alright.

But when I started to create a session, then it broke again. I checked
the same cocoon instance with another browser, which didn't have a session yet.
It worked. As soon as I created a session, the WebServiceProxy crashed for this client.
Please see below the stack trace. 
I guess it must have something to do with "passing the session" resp. "passing the cookies".
But I didn't find anything within your code, where you would do something like that.


Thanks 

Michael

Original exception : java.io.IOException: Broken pipe
at java.net.SocketOutputStream.socketWrite(Native Method)
at java.net.SocketOutputStream.write(SocketOutputStream.java:71)
at 
org.apache.commons.httpclient.HttpConnection.write(HttpConnection.java:363)
at 
org.apache.commons.httpclient.HttpConnection.print(HttpConnection.java:433)
at 
org.apache.commons.httpclient.HttpMethodBase.writeRequestHeaders(HttpMethodBase.java:741)
at 
org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:693)
at 
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:469)
at 
org.apache.commons.httpclient.HttpMultiClient.executeMethod(HttpMultiClient.java:286)
at 
org.apache.cocoon.generation.WebServiceProxyGenerator.fetch(WebServiceProxyGenerator.java:254)
at 
org.apache.cocoon.generation.WebServiceProxyGenerator.generate(WebServiceProxyGenerator.java:172)
at 
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:501)
at 
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:204)
at 
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:476)
at 
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:146)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:83)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:160)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:107)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:157)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:107)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:152)
at 
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:328)
at 
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:309)
at 
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:131)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:83)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:160)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:107)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:157)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:107)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:152)
at 
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:328)
at 
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:309)
at 
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:131)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:83)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:160)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:107)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:157)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:107)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:152)
at 
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:328)
at 
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:309)
at org.apache.cocoon.Cocoon.process(Cocoon.java:585)
at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:997)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243)
at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:190)
at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at 
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2347)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at 
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170)
at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468)
at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at 
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:1027)
at 
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1125)
at java.lang.Thread.run(Thread.java:484)




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: ServletProxyGenerator

Posted by Michael Wechner <mi...@wyona.org>.


Ivelin Ivanov wrote:

>Sounds similar to the recently contributed WebServiceProxyGenerator.
>
>Check it. Maybe you can add improvements instead of writing a new component
>with overlapping functionality:
>

That's right. I will check it out.

Thanks a lot

Michael


>
>
>http://www.mail-archive.com/cocoon-dev@xml.apache.org/msg19390.html
>
>
>Ivelin
>
>
>----- Original Message -----
>From: "Michael Wechner" <mi...@wyona.org>
>To: <co...@xml.apache.org>
>Cc: <co...@xml.apache.org>
>Sent: Tuesday, July 16, 2002 10:46 AM
>Subject: ServletProxyGenerator
>
>
>>Hi
>>
>>I am currently working on a ServletProxyGenerator:
>>
>>    +--------+       +------------------------+       +---------+
>>    |        | ----> | Cocoon:                | ----> |         |
>>    | Client |       | ServletProxyGenerator: |       | Servlet |
>>    |        | <---- | HttpClient             | <---- |         |
>>    +--------+       +------------------------+       +---------+
>>
>>with the goal to connect some "legacy servlets" and being able to
>>pipe them through Cocoon.
>>
>>Actually the ServletProxyGenerator doesn't do a lot. It is just creating
>>an HttpClient (org.apache.commons.http) and "forwarding" all parameters
>>(POST) and
>>the QueryString (GET) from the original client to the HttpClient being
>>instanced within the ServletProxyGenerator.
>>
>>It is working very fine so far. I now wanted to connect some servlets
>>which need the session of the original client, which means I started to
>>transfer all Cookies into the HttpClient.
>>
>>The problem now is, that the servlet still doesn't find the session!
>>
>>Does anyone have experience with these kind of stuff: Passing cookies
>>from one client to another?
>>
>>Thanks for your help and comments
>>
>>Michael
>>
>>P.S.: If the ServletProxyGenerator is of any use for the Cocoon
>>community, then I would be happy to donate it.
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>>For additional commands, email: cocoon-dev-help@xml.apache.org
>>
>
>
>---------------------------------------------------------------------
>Please check that your question  has not already been answered in the
>FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>
>
>To unsubscribe, e-mail:     <co...@xml.apache.org>
>For additional commands, e-mail:   <co...@xml.apache.org>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: ServletProxyGenerator

Posted by Ivelin Ivanov <iv...@apache.org>.

Sounds similar to the recently contributed WebServiceProxyGenerator.

Check it. Maybe you can add improvements instead of writing a new component
with overlapping functionality:

http://www.mail-archive.com/cocoon-dev@xml.apache.org/msg19390.html


Ivelin


----- Original Message -----
From: "Michael Wechner" <mi...@wyona.org>
To: <co...@xml.apache.org>
Cc: <co...@xml.apache.org>
Sent: Tuesday, July 16, 2002 10:46 AM
Subject: ServletProxyGenerator


> Hi
>
> I am currently working on a ServletProxyGenerator:
>
>     +--------+       +------------------------+       +---------+
>     |        | ----> | Cocoon:                | ----> |         |
>     | Client |       | ServletProxyGenerator: |       | Servlet |
>     |        | <---- | HttpClient             | <---- |         |
>     +--------+       +------------------------+       +---------+
>
> with the goal to connect some "legacy servlets" and being able to
> pipe them through Cocoon.
>
> Actually the ServletProxyGenerator doesn't do a lot. It is just creating
> an HttpClient (org.apache.commons.http) and "forwarding" all parameters
> (POST) and
> the QueryString (GET) from the original client to the HttpClient being
> instanced within the ServletProxyGenerator.
>
> It is working very fine so far. I now wanted to connect some servlets
> which need the session of the original client, which means I started to
> transfer all Cookies into the HttpClient.
>
> The problem now is, that the servlet still doesn't find the session!
>
> Does anyone have experience with these kind of stuff: Passing cookies
> from one client to another?
>
> Thanks for your help and comments
>
> Michael
>
> P.S.: If the ServletProxyGenerator is of any use for the Cocoon
> community, then I would be happy to donate it.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


---------------------------------------------------------------------
Please check that your question  has not already been answered in the
FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail:     <co...@xml.apache.org>
For additional commands, e-mail:   <co...@xml.apache.org>

Re: ServletProxyGenerator

Posted by Ivelin Ivanov <iv...@apache.org>.

Sounds similar to the recently contributed WebServiceProxyGenerator.

Check it. Maybe you can add improvements instead of writing a new component
with overlapping functionality:

http://www.mail-archive.com/cocoon-dev@xml.apache.org/msg19390.html


Ivelin


----- Original Message -----
From: "Michael Wechner" <mi...@wyona.org>
To: <co...@xml.apache.org>
Cc: <co...@xml.apache.org>
Sent: Tuesday, July 16, 2002 10:46 AM
Subject: ServletProxyGenerator


> Hi
>
> I am currently working on a ServletProxyGenerator:
>
>     +--------+       +------------------------+       +---------+
>     |        | ----> | Cocoon:                | ----> |         |
>     | Client |       | ServletProxyGenerator: |       | Servlet |
>     |        | <---- | HttpClient             | <---- |         |
>     +--------+       +------------------------+       +---------+
>
> with the goal to connect some "legacy servlets" and being able to
> pipe them through Cocoon.
>
> Actually the ServletProxyGenerator doesn't do a lot. It is just creating
> an HttpClient (org.apache.commons.http) and "forwarding" all parameters
> (POST) and
> the QueryString (GET) from the original client to the HttpClient being
> instanced within the ServletProxyGenerator.
>
> It is working very fine so far. I now wanted to connect some servlets
> which need the session of the original client, which means I started to
> transfer all Cookies into the HttpClient.
>
> The problem now is, that the servlet still doesn't find the session!
>
> Does anyone have experience with these kind of stuff: Passing cookies
> from one client to another?
>
> Thanks for your help and comments
>
> Michael
>
> P.S.: If the ServletProxyGenerator is of any use for the Cocoon
> community, then I would be happy to donate it.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

ServletProxyGenerator

Posted by Michael Wechner <mi...@wyona.org>.

Hi

I am currently working on a ServletProxyGenerator:

    +--------+       +------------------------+       +---------+
    |        | ----> | Cocoon:                | ----> |         |
    | Client |       | ServletProxyGenerator: |       | Servlet |
    |        | <---- | HttpClient             | <---- |         |
    +--------+       +------------------------+       +---------+

with the goal to connect some "legacy servlets" and being able to
pipe them through Cocoon.

Actually the ServletProxyGenerator doesn't do a lot. It is just creating
an HttpClient (org.apache.commons.http) and "forwarding" all parameters
(POST) and
the QueryString (GET) from the original client to the HttpClient being
instanced within the ServletProxyGenerator.

It is working very fine so far. I now wanted to connect some servlets
which need the session of the original client, which means I started to
transfer all Cookies into the HttpClient.

The problem now is, that the servlet still doesn't find the session!

Does anyone have experience with these kind of stuff: Passing cookies
from one client to another?

Thanks for your help and comments

Michael

P.S.: If the ServletProxyGenerator is of any use for the Cocoon
community, then I would be happy to donate it.




---------------------------------------------------------------------
Please check that your question  has not already been answered in the
FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail:     <co...@xml.apache.org>
For additional commands, e-mail:   <co...@xml.apache.org>

ServletProxyGenerator

Posted by Michael Wechner <mi...@wyona.org>.

Hi

I am currently working on a ServletProxyGenerator:

    +--------+       +------------------------+       +---------+
    |        | ----> | Cocoon:                | ----> |         |
    | Client |       | ServletProxyGenerator: |       | Servlet |
    |        | <---- | HttpClient             | <---- |         |
    +--------+       +------------------------+       +---------+

with the goal to connect some "legacy servlets" and being able to
pipe them through Cocoon.

Actually the ServletProxyGenerator doesn't do a lot. It is just creating
an HttpClient (org.apache.commons.http) and "forwarding" all parameters
(POST) and
the QueryString (GET) from the original client to the HttpClient being
instanced within the ServletProxyGenerator.

It is working very fine so far. I now wanted to connect some servlets
which need the session of the original client, which means I started to
transfer all Cookies into the HttpClient.

The problem now is, that the servlet still doesn't find the session!

Does anyone have experience with these kind of stuff: Passing cookies
from one client to another?

Thanks for your help and comments

Michael

P.S.: If the ServletProxyGenerator is of any use for the Cocoon
community, then I would be happy to donate it.




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

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

Posted by Michael Wechner <mi...@wyona.org>.


Ivelin Ivanov wrote:

> 
> =================================
> ||     VERY LONG !!!           ||
> =================================
> ||    AND INTERESTING.         ||
> =================================
> 
> 
> I am surprised that there is not much interest in the Cocoon community for
> Anteater. What do people use for web apps functional test suites?


We are currently using WebTest (also ant based):
http://webtest.canoo.com/webtest/manual/WebTestHome.html

All the best

Michael





> There are a few other open source test tools, but I think Anteater has great
> potential. Especially for Cocoon apps.
> 
> So, let's begin:
> 
> 
> 
>                         - 1 -
> 
> 
> 
> 
> While Anteater is still not solidified and has a relatively small user base,
> I would like to suggest an architectural change, which is compatible with
> Anteater's values, but will hopefully
> improve it in the following areas:
> 
> 1) standartization
> 2) learning curve
> 3) cross project code reuse
> 4) maintainance
> 
> 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.
> 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
> <match/> to other properties which are used for subsequent requests is a
> separate concern.
> 
> 
> 
> 
>                         - 2 -
> 
> 
> 
> 
> Schematron was specificly designed for partial, multi-phase validation and
> user friendly error reporting.
> 
> I'll explain how points 1-4 above are addressed by this proposal:
> 
> 1) Schematron is relatively popular. There are a number of articles in
> popular magazines which promote Schematron over other validating schemas.
> 2) Schematron is very easy to learn. Specification and tutorials are
> availbel. There is also supporing discussion groups with decent response
> time.
> 3) Schematron is used for a number of projects. For example there is a
> complete RSS 1.0 validating schema available on the RSS site.
> http://home.freeuk.com/leigh.dodds/rss_validator/
> XMLForm is using schematron extensively as well. Slash-edit is another
> example.
> 4) Maintainance of Schematron documents is easy. Minor local changes are
> made as the underlying (validated) model changes.
> 
> 
> 
> 
> 
>                         - 3 -
> 
> 
> 
> 
> 
> 5) Bonus ;)
> 
> Here is one additional reason why I posted this proposal.
> Validating Schematron documents can be referenced in a transparent
> transformer prior to a page serialization.
> This can be useful in development and QA, to catch and report bugs in
> content (HTML, WAP, XML, etc.) during navigation.
> 
> Searching for problems in a broken HTML page (or other xml markup) can be
> painful.
> Instead of searching for the missing tags or label or icon, the tester (or
> developer) will see a meaningful error report in place of the actual page.
> After testing certain pages time and again, the eye tends to ignore elements
> peripheral to the currently tested feature.
> If there is an underlying validating document which is applied before
> display, then things may be easier. The developer (tester) has to only make
> changes to it when the page structure changes.
> The rest of the time this document will be a safeguard of unexpected
> problems caused as side efects by the development of other features or bug
> fixes or another one of the infinite other possible reasons.
> The transformer applying the validating document can be, of course, turned
> off in production.
> 
> Now the next interesting part. The forementioned validating documents can be
> referenced just as well by Anteater regression suites as they can by a
> pipeline embedded validating transformer.
> 
> 
> 
> 
> 
> 
>                         - 4 -
> 
> 
> 
> 
> As a quick thought, this is how an Anteater script may look:
> 
> <?xml version="1.0" encoding="utf-8"?>
> 
> <project name="calc-test" default="calc">
> 
>   <!-- Simulate the behavior of a user that opens a browser, starts
>   the calculator example, and goes back in the processing several
>   times. -->
>   <target name="calc">
>     <property name="calc" value="${cocoon}/samples/flow/examples/calc/"/>
>     <property name="schema-doc-ns"
> value="http://www.ascc.net/xml/schematron"/>
>     <property name="schema-doc-url"
> value="${cocoon}/samples/flow/examples/calc/sch-report.xml"/>
>     <http description="Test the 'calc' JavaScript implementation">
>       <httpRequest href="${calc}/">
>         <match>
>           <xpath select="html/body//form/@action" assign="cont1"/>
>           <validate phase="page1" assign="violations">
>         </match>
>       </httpRequest>
> 
>       <echo>result = ${violations}</echo>
>     </http>
> 
> ....
> 
> Then the Schematron document would be something like:
> 
> <schema xmlns="http://www.ascc.net/xml/schematron">
> 
>     <title>Schema for the Calc example</title>
> 
>     <phase id="page1">
>             <p>first page check.</p>
>             <active pattern="form-present"/>
>     </phase>
>     ... other phases ...
>     <pattern name="Test for HTML form element" id="form-present">
> <rule context="/">
> <assert  test="//form">
>         Form element expected on this page.
>       </assert>
> <assert  test="//form/@action">
>   Form element must have action attribute.
>       </assert>
> </rule>
> ... other rules ...
> </pattern>
>     ... other patterns...
> 
>    </schema>
> ...
> 
> 
> 
> 
> Where the validate element will use the validation package to apply the
> schema against the document.
> The violations can be then nicely integrated in the JUnit reporting package.
> 
> 
> 
> If there are enough votes I'll contribute some of the work myself.
> Help would be certainly appreciated.
> 
> 
> Thanks for reading this far.
> 
> 
> Thoughts?
> 
> 
> -= Ivelin =-
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

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

Posted by Ivelin Ivanov <iv...@apache.org>.

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" <iv...@apache.org> 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 <xpath> 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
>>>><match/> 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.
>>>
>>>
>>><snip schematron goodness/>
>>>
>>>Schematron looks very cool. Another even easier-to-use possibility would
>>>be Examplotron (http://examplotron.org/).
>>>
>>><rant>
>>>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
>>></rant>
>>>
>>>>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 lurk,
>>>the relevant list to join is:
>>>
>>>http://lists.sourceforge.net/lists/listinfo/aft-devel
>>>
>>>And the project page is:
>>>
>>>http://www.sourceforge.net/projects/aft/
>>>
>>>
>>>--Jeff
>>>
>>>
>>>
>>>>-= Ivelin =-
>>>
> 
> 



-- 

-= Ivelin =-


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

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

Posted by Ovidiu Predescu <ov...@apache.org>.

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" <iv...@apache.org> 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 <xpath> 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
>>> <match/> 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.
>> 
>> 
>> <snip schematron goodness/>
>> 
>> Schematron looks very cool. Another even easier-to-use possibility would
>> be Examplotron (http://examplotron.org/).
>> 
>> <rant>
>> 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
>> </rant>
>> 
>>> 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 lurk,
>> the relevant list to join is:
>> 
>> http://lists.sourceforge.net/lists/listinfo/aft-devel
>> 
>> And the project page is:
>> 
>> http://www.sourceforge.net/projects/aft/
>> 
>> 
>> --Jeff
>> 
>> 
>>> -= Ivelin =-


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

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

Posted by Ivelin Ivanov <iv...@apache.org>.

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 <xpath> 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
>><match/> 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.
> 
> 
> <snip schematron goodness/>
> 
> Schematron looks very cool. Another even easier-to-use possibility would
> be Examplotron (http://examplotron.org/).
> 
> <rant>
> 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
> </rant>
> 
>>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 lurk,
> the relevant list to join is:
> 
> http://lists.sourceforge.net/lists/listinfo/aft-devel
> 
> And the project page is:
> 
> http://www.sourceforge.net/projects/aft/
> 
> 
> --Jeff
> 
> 
>>-= Ivelin =-
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 
> 



-- 

-= Ivelin =-


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

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

Posted by Jeff Turner <je...@socialchange.net.au>.

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 <xpath> 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
> <match/> 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.

<snip schematron goodness/>

Schematron looks very cool. Another even easier-to-use possibility would
be Examplotron (http://examplotron.org/).

<rant>
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
</rant>

> 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 lurk,
the relevant list to join is:

http://lists.sourceforge.net/lists/listinfo/aft-devel

And the project page is:

http://www.sourceforge.net/projects/aft/

--Jeff

> 
> -= Ivelin =-

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [VOTE] Schematron validator in Anteater (andCocoonvalidatingTransformer)

Posted by Ovidiu Predescu <ov...@apache.org>.

On 6/9/02 11:17 PM, "Nicola Ken Barozzi" <ni...@apache.org> wrote:

> From: "Ovidiu Predescu" <ov...@apache.org>
> To: <co...@xml.apache.org>; <af...@lists.sourceforge.net>
> Sent: Monday, June 10, 2002 4:14 AM
> Subject: Re: [VOTE] Schematron validator in Anteater
> (andCocoonvalidatingTransformer)
> 
> 
>> On 6/9/02 2:36 PM, "Nicola Ken Barozzi" <ni...@apache.org> wrote:
>> 
>>> From: "Ovidiu Predescu" <ov...@apache.org>
>>>> If you want to reuse functionality across multiple ant files, just
> define
>>>> the common functionality in targets in a common file, and call them
> using
>>>> the <ant> target.
>>> 
>>> Which really slows down things sometimes and precludes the Ant
> dependency
>>> mechanism.
>> 
>> Why does it slow down things? Another build file should just parse and add
>> the targets to the pool of already existing targets. And since you're
>> calling the task directly, yes, you are avoiding the dependency mechanism,
>> but in this case this exactly what you want.
> 
> I referred to "reuse functionality across multiple ant files".
> Since it's a generic statemement, I gave a generic answer ;-)

;)

> <ant> is not the root of all evil, but shoudn't be used just to "call build
> functions", but call sub builds.

<ant> is the only way you can load and execute test scripts dynamically at
runtime. Even with an xinclude facility, it would be very difficult to load
arbitrary build files, since xinclude would be executed at parse time, while
<ant> is evaluated at runtime.

To understand what I mean, take a look at test/anteater/all-tests.xml in
Cocoon. The main target determines, at runtime, what are all the test files,
and executes them accordingly. I don't think this would be possible with an
xinclude target, since <xinclude> would have to refer to known URLs at parse
time.

>>> I'm writing a simple xinclude system to patch Ant.
>>> Any suggestion on what to use to manage xinclude tags?
>> 
>> What would be the semantics of xinclude in the context of Ant? Suppose you
>> xinclude a target fragment inside the <project> element; this should
> create
>> a new target. But I imagine you could also xinclude a fragment inside a
>> target: this should only add whatever tasks are referred to that target.
>> 
>> If this is the semantics, then I'd say the xinclude element cannot be a
>> regular task. What you instead need is a special element which
> transparently
>> substitutes at _parse_ time XML fragments from other sources in the
> parsing
>> stream.
> 
> I would make a XIncludeProjectHelper, so I would intervene in the parsing
> stage.
> 
> What I would like to know, are there any separate xinclude implementations
> already?

I don't know, better ask on ant-dev about it. Also check the Sourceforge
Antcontrib project, they have a bunch of tasks which are not part of Ant.

Cheers,
Ovidiu


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [VOTE] Schematron validator in Anteater (andCocoonvalidatingTransformer)

Posted by Nicola Ken Barozzi <ni...@apache.org>.

From: "Ovidiu Predescu" <ov...@apache.org>
To: <co...@xml.apache.org>; <af...@lists.sourceforge.net>
Sent: Monday, June 10, 2002 4:14 AM
Subject: Re: [VOTE] Schematron validator in Anteater
(andCocoonvalidatingTransformer)


> On 6/9/02 2:36 PM, "Nicola Ken Barozzi" <ni...@apache.org> wrote:
>
> > From: "Ovidiu Predescu" <ov...@apache.org>
> >> If you want to reuse functionality across multiple ant files, just
define
> >> the common functionality in targets in a common file, and call them
using
> >> the <ant> target.
> >
> > Which really slows down things sometimes and precludes the Ant
dependency
> > mechanism.
>
> Why does it slow down things? Another build file should just parse and add
> the targets to the pool of already existing targets. And since you're
> calling the task directly, yes, you are avoiding the dependency mechanism,
> but in this case this exactly what you want.

I referred to "reuse functionality across multiple ant files".
Since it's a generic statemement, I gave a generic answer ;-)

<ant> is not the root of all evil, but shoudn't be used just to "call build
functions", but call sub builds.

> > I'm writing a simple xinclude system to patch Ant.
> > Any suggestion on what to use to manage xinclude tags?
>
> What would be the semantics of xinclude in the context of Ant? Suppose you
> xinclude a target fragment inside the <project> element; this should
create
> a new target. But I imagine you could also xinclude a fragment inside a
> target: this should only add whatever tasks are referred to that target.
>
> If this is the semantics, then I'd say the xinclude element cannot be a
> regular task. What you instead need is a special element which
transparently
> substitutes at _parse_ time XML fragments from other sources in the
parsing
> stream.

I would make a XIncludeProjectHelper, so I would intervene in the parsing
stage.

What I would like to know, are there any separate xinclude implementations
already?

--
Nicola Ken Barozzi                   nicolaken@apache.org
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

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

Posted by Ovidiu Predescu <ov...@apache.org>.

On 6/9/02 2:36 PM, "Nicola Ken Barozzi" <ni...@apache.org> wrote:

> From: "Ovidiu Predescu" <ov...@apache.org>
> 
>> On 6/7/02 9:48 PM, "Ivelin Ivanov" <iv...@apache.org> wrote:
>>> I have also asked a question about reusing steps among test cases.
>>> How do you suggest this can be done?
>> 
>> Just group the different test cases in two different targets. In a common
>> test target, just do the login, then call the two targets sequentially,
> and
>> then do the logout. If you want the two steps to happen in parallel, you
> can
>> use Ant's <parallel> element.
>> 
>> Something like this:
>> 
>> <target name="test1">
>>   // Do the steps for test case 1
>> </target>
>> 
>> <target name="test2">
>>   // Do the steps for test case 2
>> </target>
>> 
>> <target name="full-test">
>>   <http>
>>     // Do the login here
>> 
>>     <antcall target="test1"/>
>>     <antcall target="test2"/>
>> 
>>     // Do the logout here
>>   </http>
>> </target>
>> 
>> The <target> element acts as a function here, and you make use of
> <antcall>
>> to invoke it.
>> 
>> If you want to reuse functionality across multiple ant files, just define
>> the common functionality in targets in a common file, and call them using
>> the <ant> target.
> 
> Which really slows down things sometimes and precludes the Ant dependency
> mechanism.

Why does it slow down things? Another build file should just parse and add
the targets to the pool of already existing targets. And since you're
calling the task directly, yes, you are avoiding the dependency mechanism,
but in this case this exactly what you want.

> I'm writing a simple xinclude system to patch Ant.
> Any suggestion on what to use to manage xinclude tags?

What would be the semantics of xinclude in the context of Ant? Suppose you
xinclude a target fragment inside the <project> element; this should create
a new target. But I imagine you could also xinclude a fragment inside a
target: this should only add whatever tasks are referred to that target.

If this is the semantics, then I'd say the xinclude element cannot be a
regular task. What you instead need is a special element which transparently
substitutes at _parse_ time XML fragments from other sources in the parsing
stream.

Regards,
Ovidiu

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

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

Posted by Nicola Ken Barozzi <ni...@apache.org>.

From: "Ovidiu Predescu" <ov...@apache.org>

> On 6/7/02 9:48 PM, "Ivelin Ivanov" <iv...@apache.org> wrote:
> > I have also asked a question about reusing steps among test cases.
> > How do you suggest this can be done?
>
> Just group the different test cases in two different targets. In a common
> test target, just do the login, then call the two targets sequentially,
and
> then do the logout. If you want the two steps to happen in parallel, you
can
> use Ant's <parallel> element.
>
> Something like this:
>
> <target name="test1">
>   // Do the steps for test case 1
> </target>
>
> <target name="test2">
>   // Do the steps for test case 2
> </target>
>
> <target name="full-test">
>   <http>
>     // Do the login here
>
>     <antcall target="test1"/>
>     <antcall target="test2"/>
>
>     // Do the logout here
>   </http>
> </target>
>
> The <target> element acts as a function here, and you make use of
<antcall>
> to invoke it.
>
> If you want to reuse functionality across multiple ant files, just define
> the common functionality in targets in a common file, and call them using
> the <ant> target.

Which really slows down things sometimes and precludes the Ant dependency
mechanism.

I'm writing a simple xinclude system to patch Ant.
Any suggestion on what to use to manage xinclude tags?

--
Nicola Ken Barozzi                   nicolaken@apache.org
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

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

Posted by Ovidiu Predescu <ov...@apache.org>.

On 6/7/02 9:48 PM, "Ivelin Ivanov" <iv...@apache.org> wrote:

> 
> I will be interested to contribute some code.
> The validator package is totally independent of Avalon.

OK, this is good.

> It only needs commons-jxpath.jar
> 
> The package is org.apache.cocoon.components.validation
> 
> I guess I can just zip up the files in the package for anteater.

Anteater currently uses Jaxen, is it possible for the validation code to use
Jaxen instead of JXPath?

> I would like us to work out the exact syntax before starting, though.

I think the syntax you proposed is reasonable for a start.

> How do we plan to generate junit reports.
> Right now I don't see a nice way to interrupt a test, if there was a
> validation error, and jump straight to the junit reporting.

How does Junit catch the interrupt? We can probably use the same mechanism
to catch the interrupt, and execute the reporting code.

> I have also asked a question about reusing steps among test cases.
> How do you suggest this can be done?

Just group the different test cases in two different targets. In a common
test target, just do the login, then call the two targets sequentially, and
then do the logout. If you want the two steps to happen in parallel, you can
use Ant's <parallel> element.

Something like this:

<target name="test1">
  // Do the steps for test case 1
</target>

<target name="test2">
  // Do the steps for test case 2
</target>

<target name="full-test">
  <http>
    // Do the login here

    <antcall target="test1"/>
    <antcall target="test2"/>

    // Do the logout here
  </http>
</target>

The <target> element acts as a function here, and you make use of <antcall>
to invoke it.

If you want to reuse functionality across multiple ant files, just define
the common functionality in targets in a common file, and call them using
the <ant> target.

Does this answer your question?

> Once we work out the architectural problems, I'll move to coding.
> 
> My sf.net login is "ivelin"

OK, you're in!

Ovidiu

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

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

Posted by Ivelin Ivanov <iv...@apache.org>.

I will be interested to contribute some code.
The validator package is totally independent of Avalon.
It only needs commons-jxpath.jar

The package is org.apache.cocoon.components.validation

I guess I can just zip up the files in the package for anteater.

I would like us to work out the exact syntax before starting, though.

How do we plan to generate junit reports.
Right now I don't see a nice way to interrupt a test, if there was a
validation error, and jump straight to the junit reporting.

I have also asked a question about reusing steps among test cases.
How do you suggest this can be done?

Once we work out the architectural problems, I'll move to coding.

My sf.net login is "ivelin"




Ivelin



----- Original Message -----
From: "Ovidiu Predescu" <ov...@apache.org>
To: "Ivelin Ivanov" <iv...@apache.org>; <af...@lists.sourceforge.net>;
<co...@xml.apache.org>
Sent: Friday, June 07, 2002 10:18 PM
Subject: Re: [VOTE] Schematron validator in Anteater (and Cocoonvalidating
Transformer)


> Ivelin,
>
> This sounds very interesting, are you interested in adding this feature to
> Anteater and writing some documentation for it? If you're interested, I
can
> make you a committer to the project, so you can develop more easily. Just
> let me know your SourceForge account.
>
> The way I'd see this added is through an additional package in CVS. As I'm
> not familiar with the internals of the validator, I can't comment much on
> how this can be integrated. Is the validator implemented as a component
> using Avalon? If so you'd need to change it to match the Ant style of
> writing extensions. If exactly the same code from Cocoon can be reused
> unmodified in Anteater, then perhaps the best option is to build a jar
file
> in Cocoon, and just drop it in Anteater's lib/ directory.
>
> Cheers,
> Ovidiu
>
> On 6/7/02 4:51 PM, "Ivelin Ivanov" <iv...@apache.org> wrote:
>
> >
> >
> > =================================
> > ||     VERY LONG !!!           ||
> > =================================
> > ||    AND INTERESTING.         ||
> > =================================
> >
> >
> > I am surprised that there is not much interest in the Cocoon community
for
> > Anteater. What do people use for web apps functional test suites?
> > There are a few other open source test tools, but I think Anteater has
great
> > potential. Especially for Cocoon apps.
> >
> > So, let's begin:
> >
> >
> >
> >                       - 1 -
> >
> >
> >
> >
> > While Anteater is still not solidified and has a relatively small user
base,
> > I would like to suggest an architectural change, which is compatible
with
> > Anteater's values, but will hopefully
> > improve it in the following areas:
> >
> > 1) standartization
> > 2) learning curve
> > 3) cross project code reuse
> > 4) maintainance
> >
> > 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.
> > 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
> > <match/> to other properties which are used for subsequent requests is a
> > separate concern.
> >
> >
> >
> >
> >                       - 2 -
> >
> >
> >
> >
> > Schematron was specificly designed for partial, multi-phase validation
and
> > user friendly error reporting.
> >
> > I'll explain how points 1-4 above are addressed by this proposal:
> >
> > 1) Schematron is relatively popular. There are a number of articles in
> > popular magazines which promote Schematron over other validating
schemas.
> > 2) Schematron is very easy to learn. Specification and tutorials are
> > availbel. There is also supporing discussion groups with decent response
> > time.
> > 3) Schematron is used for a number of projects. For example there is a
> > complete RSS 1.0 validating schema available on the RSS site.
> > http://home.freeuk.com/leigh.dodds/rss_validator/
> > XMLForm is using schematron extensively as well. Slash-edit is another
> > example.
> > 4) Maintainance of Schematron documents is easy. Minor local changes are
> > made as the underlying (validated) model changes.
> >
> >
> >
> >
> >
> >                       - 3 -
> >
> >
> >
> >
> >
> > 5) Bonus ;)
> >
> > Here is one additional reason why I posted this proposal.
> > Validating Schematron documents can be referenced in a transparent
> > transformer prior to a page serialization.
> > This can be useful in development and QA, to catch and report bugs in
> > content (HTML, WAP, XML, etc.) during navigation.
> >
> > Searching for problems in a broken HTML page (or other xml markup) can
be
> > painful.
> > Instead of searching for the missing tags or label or icon, the tester
(or
> > developer) will see a meaningful error report in place of the actual
page.
> > After testing certain pages time and again, the eye tends to ignore
elements
> > peripheral to the currently tested feature.
> > If there is an underlying validating document which is applied before
> > display, then things may be easier. The developer (tester) has to only
make
> > changes to it when the page structure changes.
> > The rest of the time this document will be a safeguard of unexpected
> > problems caused as side efects by the development of other features or
bug
> > fixes or another one of the infinite other possible reasons.
> > The transformer applying the validating document can be, of course,
turned
> > off in production.
> >
> > Now the next interesting part. The forementioned validating documents
can be
> > referenced just as well by Anteater regression suites as they can by a
> > pipeline embedded validating transformer.
> >
> >
> >
> >
> >
> >
> >                       - 4 -
> >
> >
> >
> >
> > As a quick thought, this is how an Anteater script may look:
> >
> > <?xml version="1.0" encoding="utf-8"?>
> >
> > <project name="calc-test" default="calc">
> >
> > <!-- Simulate the behavior of a user that opens a browser, starts
> > the calculator example, and goes back in the processing several
> > times. -->
> > <target name="calc">
> >   <property name="calc" value="${cocoon}/samples/flow/examples/calc/"/>
> >   <property name="schema-doc-ns"
> > value="http://www.ascc.net/xml/schematron"/>
> >   <property name="schema-doc-url"
> > value="${cocoon}/samples/flow/examples/calc/sch-report.xml"/>
> >   <http description="Test the 'calc' JavaScript implementation">
> >     <httpRequest href="${calc}/">
> >       <match>
> >         <xpath select="html/body//form/@action" assign="cont1"/>
> >         <validate phase="page1" assign="violations">
> >       </match>
> >     </httpRequest>
> >
> >     <echo>result = ${violations}</echo>
> >   </http>
> >
> > ....
> >
> > Then the Schematron document would be something like:
> >
> > <schema xmlns="http://www.ascc.net/xml/schematron">
> >
> >   <title>Schema for the Calc example</title>
> >
> >   <phase id="page1">
> >           <p>first page check.</p>
> >           <active pattern="form-present"/>
> >   </phase>
> >   ... other phases ...
> >   <pattern name="Test for HTML form element" id="form-present">
> > <rule context="/">
> > <assert  test="//form">
> >       Form element expected on this page.
> >     </assert>
> > <assert  test="//form/@action">
> > Form element must have action attribute.
> >     </assert>
> > </rule>
> > ... other rules ...
> > </pattern>
> >   ... other patterns...
> >
> >  </schema>
> > ...
> >
> >
> >
> >
> > Where the validate element will use the validation package to apply the
> > schema against the document.
> > The violations can be then nicely integrated in the JUnit reporting
package.
> >
> >
> >
> > If there are enough votes I'll contribute some of the work myself.
> > Help would be certainly appreciated.
> >
> >
> > Thanks for reading this far.
> >
> >
> > Thoughts?
> >
> >
> > -= Ivelin =-
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

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

Posted by Ovidiu Predescu <ov...@apache.org>.

Ivelin,

This sounds very interesting, are you interested in adding this feature to
Anteater and writing some documentation for it? If you're interested, I can
make you a committer to the project, so you can develop more easily. Just
let me know your SourceForge account.

The way I'd see this added is through an additional package in CVS. As I'm
not familiar with the internals of the validator, I can't comment much on
how this can be integrated. Is the validator implemented as a component
using Avalon? If so you'd need to change it to match the Ant style of
writing extensions. If exactly the same code from Cocoon can be reused
unmodified in Anteater, then perhaps the best option is to build a jar file
in Cocoon, and just drop it in Anteater's lib/ directory.

Cheers,
Ovidiu

On 6/7/02 4:51 PM, "Ivelin Ivanov" <iv...@apache.org> wrote:

> 
> 
> =================================
> ||     VERY LONG !!!           ||
> =================================
> ||    AND INTERESTING.         ||
> =================================
> 
> 
> I am surprised that there is not much interest in the Cocoon community for
> Anteater. What do people use for web apps functional test suites?
> There are a few other open source test tools, but I think Anteater has great
> potential. Especially for Cocoon apps.
> 
> So, let's begin:
> 
> 
> 
>                       - 1 -
> 
> 
> 
> 
> While Anteater is still not solidified and has a relatively small user base,
> I would like to suggest an architectural change, which is compatible with
> Anteater's values, but will hopefully
> improve it in the following areas:
> 
> 1) standartization
> 2) learning curve
> 3) cross project code reuse
> 4) maintainance
> 
> 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.
> 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
> <match/> to other properties which are used for subsequent requests is a
> separate concern.
> 
> 
> 
> 
>                       - 2 -
> 
> 
> 
> 
> Schematron was specificly designed for partial, multi-phase validation and
> user friendly error reporting.
> 
> I'll explain how points 1-4 above are addressed by this proposal:
> 
> 1) Schematron is relatively popular. There are a number of articles in
> popular magazines which promote Schematron over other validating schemas.
> 2) Schematron is very easy to learn. Specification and tutorials are
> availbel. There is also supporing discussion groups with decent response
> time.
> 3) Schematron is used for a number of projects. For example there is a
> complete RSS 1.0 validating schema available on the RSS site.
> http://home.freeuk.com/leigh.dodds/rss_validator/
> XMLForm is using schematron extensively as well. Slash-edit is another
> example.
> 4) Maintainance of Schematron documents is easy. Minor local changes are
> made as the underlying (validated) model changes.
> 
> 
> 
> 
> 
>                       - 3 -
> 
> 
> 
> 
> 
> 5) Bonus ;)
> 
> Here is one additional reason why I posted this proposal.
> Validating Schematron documents can be referenced in a transparent
> transformer prior to a page serialization.
> This can be useful in development and QA, to catch and report bugs in
> content (HTML, WAP, XML, etc.) during navigation.
> 
> Searching for problems in a broken HTML page (or other xml markup) can be
> painful.
> Instead of searching for the missing tags or label or icon, the tester (or
> developer) will see a meaningful error report in place of the actual page.
> After testing certain pages time and again, the eye tends to ignore elements
> peripheral to the currently tested feature.
> If there is an underlying validating document which is applied before
> display, then things may be easier. The developer (tester) has to only make
> changes to it when the page structure changes.
> The rest of the time this document will be a safeguard of unexpected
> problems caused as side efects by the development of other features or bug
> fixes or another one of the infinite other possible reasons.
> The transformer applying the validating document can be, of course, turned
> off in production.
> 
> Now the next interesting part. The forementioned validating documents can be
> referenced just as well by Anteater regression suites as they can by a
> pipeline embedded validating transformer.
> 
> 
> 
> 
> 
> 
>                       - 4 -
> 
> 
> 
> 
> As a quick thought, this is how an Anteater script may look:
> 
> <?xml version="1.0" encoding="utf-8"?>
> 
> <project name="calc-test" default="calc">
> 
> <!-- Simulate the behavior of a user that opens a browser, starts
> the calculator example, and goes back in the processing several
> times. -->
> <target name="calc">
>   <property name="calc" value="${cocoon}/samples/flow/examples/calc/"/>
>   <property name="schema-doc-ns"
> value="http://www.ascc.net/xml/schematron"/>
>   <property name="schema-doc-url"
> value="${cocoon}/samples/flow/examples/calc/sch-report.xml"/>
>   <http description="Test the 'calc' JavaScript implementation">
>     <httpRequest href="${calc}/">
>       <match>
>         <xpath select="html/body//form/@action" assign="cont1"/>
>         <validate phase="page1" assign="violations">
>       </match>
>     </httpRequest>
> 
>     <echo>result = ${violations}</echo>
>   </http>
> 
> ....
> 
> Then the Schematron document would be something like:
> 
> <schema xmlns="http://www.ascc.net/xml/schematron">
> 
>   <title>Schema for the Calc example</title>
> 
>   <phase id="page1">
>           <p>first page check.</p>
>           <active pattern="form-present"/>
>   </phase>
>   ... other phases ...
>   <pattern name="Test for HTML form element" id="form-present">
> <rule context="/">
> <assert  test="//form">
>       Form element expected on this page.
>     </assert>
> <assert  test="//form/@action">
> Form element must have action attribute.
>     </assert>
> </rule>
> ... other rules ...
> </pattern>
>   ... other patterns...
> 
>  </schema>
> ...
> 
> 
> 
> 
> Where the validate element will use the validation package to apply the
> schema against the document.
> The violations can be then nicely integrated in the JUnit reporting package.
> 
> 
> 
> If there are enough votes I'll contribute some of the work myself.
> Help would be certainly appreciated.
> 
> 
> Thanks for reading this far.
> 
> 
> Thoughts?
> 
> 
> -= Ivelin =-


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org