You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stuart Roebuck <st...@adolos.co.uk> on 2001/07/20 19:22:36 UTC

[C2] serverpages doesn't like auto-generated xsp?

I've been trying to produce a sitemap where the XSP for serverpages is 
generated by an XSLT transformer on an XML input file.  I want to generate 
an ESQL query tailored to the fields of a number of different database 
tables.

In other words, if you request "select-test.xml" it should return the 
content of the 'test' table, by generating ESQL to query the database 
(obtained from 'select-test.xsp') and processing it with the serverpages 
generator.

Here's a mock up of the code:

     <map:match pattern="select-*.xml">
       <map:act type="request">
         <map:parameter name="parameters" value="true" />
         <map:generate type="serverpages" src="cocoon:/select-{1}.xsp">
           <map:parameter name="id" value="{table}" />
         </map:generate>
       </map:act>
       <map:serialize type="xml" />
     </map:match>

	<map:match pattern="select-*.xsp">
	  <map:generate src="data/database_descriptions.xml" />
	  <map:transform src="transform/create_select_xsp.xslt">
	    <map:parameter name="table" value="{1}" />
       </map:transform>
       <map:serialize type="xml" />
     </map:match>

I tried this out and the XSLT appeared to generate the correct XSP, but 
the result of the "select-text.xml" request was incorrect.  If I took the 
result of a request for "select-test.xsp" and saved it to a file, then 
changed the first match to take the fixed file as the serverpages source, 
everything worked fine.  I can only imagine that the problem lies in the 
passing of the SAX stream between the components.  Could the "cocoon:/" 
protocol be loosing or getting confused by namespaces?

Stuart.

-------------------------------------------------------------------------
Stuart Roebuck                                  stuart.roebuck@adolos.com
Lead Developer                               Java, XML, MacOS X, XP, etc.
ADOLOS                                           <http://www.adolos.com/>

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


Re: [C2] Profiling, compiled XSLT & database SELECT caching; was: serverpages doesn't like auto-generated xsp?

Posted by Stuart Roebuck <st...@adolos.co.uk>.
Any hints from anyone on a good strategy for working out which pipeline 
stages are slowing things down.  I've tried to use the profiler but haven'
t got anywhere.  Trying to do code profiling on Cocoon just overloads my 
system!

Is XSLT precompiled nowadays - I don't see an option for it that there 
used to be, and I don't see any compiled code in the caches.

Finally, is there any option for delaying the frequency of actual database 
SELECTs so that repeated calls for the same information also return from 
cache?  One option that could be really useful in many cases would be to 
return from cache unless an UPDATE had been issued from Cocoon in the 
interim.  Clearly many databases will be updated from other sources but 
ours aren't!

Stuart.

On Sunday, July 22, 2001, at 02:21  pm, Berin Loritsch wrote:

> I get this as well with Tomcat 3.3m2
>
> I think that there is a problem where the classloader
> is not letting go of the class that was loaded.  I
> have
> experienced problems with it myself.
>
> Everything looks like it should work though...
>
> --- giacomo <gi...@apache.org> wrote:
>> On Sat, 21 Jul 2001, Stuart Roebuck wrote:
>>
>>> giacomo,
>>>
>>> Thanks,
>>>
>>> I've been wondering what the {../1} terminology
>> was all about recently and
>>> now I know! :-)
>>>
>>> I discovered that the problem was a combination of
>> that, and the fact that
>>> the xslt generator was removing spaces that turned
>> out to be critical for
>>> the xsp to work. A slight change to the xslt
>> solved that one.
>>>
>>> However, based purely on a general sense of
>> sluggishness, it looks to me
>>> that the caching mechanisms are not preventing the
>> re-compiling of the xsp
>>> each time through the loop.  Perhaps this is a
>> known limitation at the
>>> moment, or maybe I've not switched the right thing
>> on!
>>
>> I don't get this. Do you like to say that all xsp
>> you're requesting gets
>> recompiled every time? I don't have this behaviour
>> (and I havn't change
>> anything).
>>
>> Giacomo
>>
>>>
>>> Cheers,
>>>
>>> Stuart.
>>>
>>> On Saturday, July 21, 2001, at 09:40  am, giacomo
>> wrote:
>>>
>>>> On Fri, 20 Jul 2001, Stuart Roebuck wrote:
>>>>
>>>>> I've been trying to produce a sitemap where the
>> XSP for serverpages is
>>>>> generated by an XSLT transformer on an XML
>> input file.  I want to
>>>>> generate
>>>>> an ESQL query tailored to the fields of a
>> number of different database
>>>>> tables.
>>>>>
>>>>> In other words, if you request
>> "select-test.xml" it should return the
>>>>> content of the 'test' table, by generating ESQL
>> to query the database
>>>>> (obtained from 'select-test.xsp') and
>> processing it with the serverpages
>>>>> generator.
>>>>>
>>>>> Here's a mock up of the code:
>>>>>
>>>>>      <map:match pattern="select-*.xml">
>>>>>        <map:act type="request">
>>>>>          <map:parameter name="parameters"
>> value="true" />
>>>>>          <map:generate type="serverpages"
>> src="cocoon:/select-{1}.xsp">
>>>>
>>>> Should this be:
>>>>
>>>>        <map:generate type="serverpages"
>> src="cocoon:/select-{../1}.xsp">
>>>>
>>>> to reference the matchers match?
>>>>
>>>> Giacomo
>>>>
>>>>>            <map:parameter name="id"
>> value="{table}" />
>>>>>          </map:generate>
>>>>>        </map:act>
>>>>>        <map:serialize type="xml" />
>>>>>      </map:match>
>>>>>
>>>>> 	<map:match pattern="select-*.xsp">
>>>>> 	  <map:generate
>> src="data/database_descriptions.xml" />
>>>>> 	  <map:transform
>> src="transform/create_select_xsp.xslt">
>>>>> 	    <map:parameter name="table" value="{1}" />
>>>>>        </map:transform>
>>>>>        <map:serialize type="xml" />
>>>>>      </map:match>
>>>>>
>>>>> I tried this out and the XSLT appeared to
>> generate the correct XSP, but
>>>>> the result of the "select-text.xml" request was
>> incorrect.  If I took the
>>>>> result of a request for "select-test.xsp" and
>> saved it to a file, then
>>>>> changed the first match to take the fixed file
>> as the serverpages source,
>>>>> everything worked fine.  I can only imagine
>> that the problem lies in the
>>>>> passing of the SAX stream between the
>> components.  Could the "cocoon:/"
>>>>> protocol be loosing or getting confused by
>> namespaces?
>>>>>
>>>>> Stuart.
>>>

-------------------------------------------------------------------------
Stuart Roebuck                                  stuart.roebuck@adolos.com
Lead Developer                               Java, XML, MacOS X, XP, etc.
ADOLOS                                           <http://www.adolos.com/>

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


Re: [C2] serverpages doesn't like auto-generated xsp?

Posted by Berin Loritsch <bl...@yahoo.com>.
I get this as well with Tomcat 3.3m2

I think that there is a problem where the classloader
is not letting go of the class that was loaded.  I
have
experienced problems with it myself.

Everything looks like it should work though...

--- giacomo <gi...@apache.org> wrote:
> On Sat, 21 Jul 2001, Stuart Roebuck wrote:
> 
> > giacomo,
> >
> > Thanks,
> >
> > I've been wondering what the {../1} terminology
> was all about recently and
> > now I know! :-)
> >
> > I discovered that the problem was a combination of
> that, and the fact that
> > the xslt generator was removing spaces that turned
> out to be critical for
> > the xsp to work. A slight change to the xslt
> solved that one.
> >
> > However, based purely on a general sense of
> sluggishness, it looks to me
> > that the caching mechanisms are not preventing the
> re-compiling of the xsp
> > each time through the loop.  Perhaps this is a
> known limitation at the
> > moment, or maybe I've not switched the right thing
> on!
> 
> I don't get this. Do you like to say that all xsp
> you're requesting gets
> recompiled every time? I don't have this behaviour
> (and I havn't change
> anything).
> 
> Giacomo
> 
> >
> > Cheers,
> >
> > Stuart.
> >
> > On Saturday, July 21, 2001, at 09:40  am, giacomo
> wrote:
> >
> > > On Fri, 20 Jul 2001, Stuart Roebuck wrote:
> > >
> > >> I've been trying to produce a sitemap where the
> XSP for serverpages is
> > >> generated by an XSLT transformer on an XML
> input file.  I want to
> > >> generate
> > >> an ESQL query tailored to the fields of a
> number of different database
> > >> tables.
> > >>
> > >> In other words, if you request
> "select-test.xml" it should return the
> > >> content of the 'test' table, by generating ESQL
> to query the database
> > >> (obtained from 'select-test.xsp') and
> processing it with the serverpages
> > >> generator.
> > >>
> > >> Here's a mock up of the code:
> > >>
> > >>      <map:match pattern="select-*.xml">
> > >>        <map:act type="request">
> > >>          <map:parameter name="parameters"
> value="true" />
> > >>          <map:generate type="serverpages"
> src="cocoon:/select-{1}.xsp">
> > >
> > > Should this be:
> > >
> > >        <map:generate type="serverpages"
> src="cocoon:/select-{../1}.xsp">
> > >
> > > to reference the matchers match?
> > >
> > > Giacomo
> > >
> > >>            <map:parameter name="id"
> value="{table}" />
> > >>          </map:generate>
> > >>        </map:act>
> > >>        <map:serialize type="xml" />
> > >>      </map:match>
> > >>
> > >> 	<map:match pattern="select-*.xsp">
> > >> 	  <map:generate
> src="data/database_descriptions.xml" />
> > >> 	  <map:transform
> src="transform/create_select_xsp.xslt">
> > >> 	    <map:parameter name="table" value="{1}" />
> > >>        </map:transform>
> > >>        <map:serialize type="xml" />
> > >>      </map:match>
> > >>
> > >> I tried this out and the XSLT appeared to
> generate the correct XSP, but
> > >> the result of the "select-text.xml" request was
> incorrect.  If I took the
> > >> result of a request for "select-test.xsp" and
> saved it to a file, then
> > >> changed the first match to take the fixed file
> as the serverpages source,
> > >> everything worked fine.  I can only imagine
> that the problem lies in the
> > >> passing of the SAX stream between the
> components.  Could the "cocoon:/"
> > >> protocol be loosing or getting confused by
> namespaces?
> > >>
> > >> Stuart.
> >
> >
> >
>
-------------------------------------------------------------------------
> > Stuart Roebuck                                 
> stuart.roebuck@adolos.com
> > Lead Developer                               Java,
> XML, MacOS X, XP, etc.
> > ADOLOS                                          
> <http://www.adolos.com/>
> >
> >
>
---------------------------------------------------------------------
> > 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
> 


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

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


Re: [C2] serverpages doesn't like auto-generated xsp?

Posted by giacomo <gi...@apache.org>.
On Sat, 21 Jul 2001, Stuart Roebuck wrote:

> giacomo,
>
> Thanks,
>
> I've been wondering what the {../1} terminology was all about recently and
> now I know! :-)
>
> I discovered that the problem was a combination of that, and the fact that
> the xslt generator was removing spaces that turned out to be critical for
> the xsp to work. A slight change to the xslt solved that one.
>
> However, based purely on a general sense of sluggishness, it looks to me
> that the caching mechanisms are not preventing the re-compiling of the xsp
> each time through the loop.  Perhaps this is a known limitation at the
> moment, or maybe I've not switched the right thing on!

I don't get this. Do you like to say that all xsp you're requesting gets
recompiled every time? I don't have this behaviour (and I havn't change
anything).

Giacomo

>
> Cheers,
>
> Stuart.
>
> On Saturday, July 21, 2001, at 09:40  am, giacomo wrote:
>
> > On Fri, 20 Jul 2001, Stuart Roebuck wrote:
> >
> >> I've been trying to produce a sitemap where the XSP for serverpages is
> >> generated by an XSLT transformer on an XML input file.  I want to
> >> generate
> >> an ESQL query tailored to the fields of a number of different database
> >> tables.
> >>
> >> In other words, if you request "select-test.xml" it should return the
> >> content of the 'test' table, by generating ESQL to query the database
> >> (obtained from 'select-test.xsp') and processing it with the serverpages
> >> generator.
> >>
> >> Here's a mock up of the code:
> >>
> >>      <map:match pattern="select-*.xml">
> >>        <map:act type="request">
> >>          <map:parameter name="parameters" value="true" />
> >>          <map:generate type="serverpages" src="cocoon:/select-{1}.xsp">
> >
> > Should this be:
> >
> >        <map:generate type="serverpages" src="cocoon:/select-{../1}.xsp">
> >
> > to reference the matchers match?
> >
> > Giacomo
> >
> >>            <map:parameter name="id" value="{table}" />
> >>          </map:generate>
> >>        </map:act>
> >>        <map:serialize type="xml" />
> >>      </map:match>
> >>
> >> 	<map:match pattern="select-*.xsp">
> >> 	  <map:generate src="data/database_descriptions.xml" />
> >> 	  <map:transform src="transform/create_select_xsp.xslt">
> >> 	    <map:parameter name="table" value="{1}" />
> >>        </map:transform>
> >>        <map:serialize type="xml" />
> >>      </map:match>
> >>
> >> I tried this out and the XSLT appeared to generate the correct XSP, but
> >> the result of the "select-text.xml" request was incorrect.  If I took the
> >> result of a request for "select-test.xsp" and saved it to a file, then
> >> changed the first match to take the fixed file as the serverpages source,
> >> everything worked fine.  I can only imagine that the problem lies in the
> >> passing of the SAX stream between the components.  Could the "cocoon:/"
> >> protocol be loosing or getting confused by namespaces?
> >>
> >> Stuart.
>
>
> -------------------------------------------------------------------------
> Stuart Roebuck                                  stuart.roebuck@adolos.com
> Lead Developer                               Java, XML, MacOS X, XP, etc.
> ADOLOS                                           <http://www.adolos.com/>
>
> ---------------------------------------------------------------------
> 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: [C2] serverpages doesn't like auto-generated xsp?

Posted by "Stuart Roebuck (BlueYonder)" <st...@mac.com>.
giacomo,

Thanks,

I've been wondering what the {../1} terminology was all about recently and 
now I know! :-)

I discovered that the problem was a combination of that, and the fact that 
the xslt generator was removing spaces that turned out to be critical for 
the xsp to work. A slight change to the xslt solved that one.

However, based purely on a general sense of sluggishness, it looks to me 
that the caching mechanisms are not preventing the re-compiling of the xsp 
each time through the loop.  Perhaps this is a known limitation at the 
moment, or maybe I've not switched the right thing on!

Cheers,

Stuart.

On Saturday, July 21, 2001, at 09:40  am, giacomo wrote:

> On Fri, 20 Jul 2001, Stuart Roebuck wrote:
>
>> I've been trying to produce a sitemap where the XSP for serverpages is
>> generated by an XSLT transformer on an XML input file.  I want to 
>> generate
>> an ESQL query tailored to the fields of a number of different database
>> tables.
>>
>> In other words, if you request "select-test.xml" it should return the
>> content of the 'test' table, by generating ESQL to query the database
>> (obtained from 'select-test.xsp') and processing it with the serverpages
>> generator.
>>
>> Here's a mock up of the code:
>>
>>      <map:match pattern="select-*.xml">
>>        <map:act type="request">
>>          <map:parameter name="parameters" value="true" />
>>          <map:generate type="serverpages" src="cocoon:/select-{1}.xsp">
>
> Should this be:
>
>        <map:generate type="serverpages" src="cocoon:/select-{../1}.xsp">
>
> to reference the matchers match?
>
> Giacomo
>
>>            <map:parameter name="id" value="{table}" />
>>          </map:generate>
>>        </map:act>
>>        <map:serialize type="xml" />
>>      </map:match>
>>
>> 	<map:match pattern="select-*.xsp">
>> 	  <map:generate src="data/database_descriptions.xml" />
>> 	  <map:transform src="transform/create_select_xsp.xslt">
>> 	    <map:parameter name="table" value="{1}" />
>>        </map:transform>
>>        <map:serialize type="xml" />
>>      </map:match>
>>
>> I tried this out and the XSLT appeared to generate the correct XSP, but
>> the result of the "select-text.xml" request was incorrect.  If I took the
>> result of a request for "select-test.xsp" and saved it to a file, then
>> changed the first match to take the fixed file as the serverpages source,
>> everything worked fine.  I can only imagine that the problem lies in the
>> passing of the SAX stream between the components.  Could the "cocoon:/"
>> protocol be loosing or getting confused by namespaces?
>>
>> Stuart.


-------------------------------------------------------------------------
Stuart Roebuck                                  stuart.roebuck@adolos.com
Lead Developer                               Java, XML, MacOS X, XP, etc.
ADOLOS                                           <http://www.adolos.com/>

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


Re: [C2] serverpages doesn't like auto-generated xsp?

Posted by giacomo <gi...@apache.org>.
On Fri, 20 Jul 2001, Stuart Roebuck wrote:

> I've been trying to produce a sitemap where the XSP for serverpages is
> generated by an XSLT transformer on an XML input file.  I want to generate
> an ESQL query tailored to the fields of a number of different database
> tables.
>
> In other words, if you request "select-test.xml" it should return the
> content of the 'test' table, by generating ESQL to query the database
> (obtained from 'select-test.xsp') and processing it with the serverpages
> generator.
>
> Here's a mock up of the code:
>
>      <map:match pattern="select-*.xml">
>        <map:act type="request">
>          <map:parameter name="parameters" value="true" />
>          <map:generate type="serverpages" src="cocoon:/select-{1}.xsp">

Should this be:

       <map:generate type="serverpages" src="cocoon:/select-{../1}.xsp">

to reference the matchers match?

Giacomo

>            <map:parameter name="id" value="{table}" />
>          </map:generate>
>        </map:act>
>        <map:serialize type="xml" />
>      </map:match>
>
> 	<map:match pattern="select-*.xsp">
> 	  <map:generate src="data/database_descriptions.xml" />
> 	  <map:transform src="transform/create_select_xsp.xslt">
> 	    <map:parameter name="table" value="{1}" />
>        </map:transform>
>        <map:serialize type="xml" />
>      </map:match>
>
> I tried this out and the XSLT appeared to generate the correct XSP, but
> the result of the "select-text.xml" request was incorrect.  If I took the
> result of a request for "select-test.xsp" and saved it to a file, then
> changed the first match to take the fixed file as the serverpages source,
> everything worked fine.  I can only imagine that the problem lies in the
> passing of the SAX stream between the components.  Could the "cocoon:/"
> protocol be loosing or getting confused by namespaces?
>
> Stuart.
>
> -------------------------------------------------------------------------
> Stuart Roebuck                                  stuart.roebuck@adolos.com
> Lead Developer                               Java, XML, MacOS X, XP, etc.
> ADOLOS                                           <http://www.adolos.com/>
>
> ---------------------------------------------------------------------
> 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