The latest Saxon got the same _global_ variable context scope and doesn't
allow overriding xsl:variables.
OK, I will fix that :)
Greetings,
Greg
2013/6/20 gelo1234
>
> Thank you! I will try to bring back Saxon :)
>
> Greetings,
> Greg
>
>
> This was discused before in the mailing list [1], it'
Thank you! I will try to bring back Saxon :)
Greetings,
Greg
This was discused before in the mailing list [1], it's a two step process
>
> * Add saxon dependency to pom file. [2]
>
> I think it's better to try Saxon directly if you used to work with it.
> Xalan is usually faster but as you have
2013/6/20 gelo1234
> Right, it was NOT Xalan, I used Saxon in my old config. Where could we
> change Xalan to Saxon in C3 ?
>
This was discused before in the mailing list [1], it's a two step process
* Add saxon dependency to pom file. [2]
* Create file META-INF/services/javax.xml.transform.Tra
Yes, it must be that "problem" with current Xalan.
Strange thing is that some XSLT variables are predefined like: requestURI
(?!).
So I cannot use:
in stylesheet file.xsl even though Ive got:
in sitemap.xmap. So requestURI is some GLOBAL variable ?
Greetings,
Greg
2013/6/20 Javier Pu
Right, it was NOT Xalan, I used Saxon in my old config. Where could we
change Xalan to Saxon in C3 ?
Now I've got another "strange" XSL error:
XML document structures must start and end within the same entity.
What could that mean??? :)
That Xalan is making me scratching my head against the wall
2013/6/20 gelo1234
> OK, resolved the issue. Deleted xslt/ directory :/ and now its starting.
> STRANGE!!
>
Yeah, computer's stuff. :)
>
> And also found that more detailed error info about not being able to
> compile XSLT stylesheet was in Tomcat log.
>
> It seems that with C3 cannot be inhe
Resolved the issue with NullPointerException during Tomcat deploy process.
It seems like putting too many files/directories in WEB-INF/classes/COB-INF
makes Tomcat fail to deploy C3 app.
I moved block root context from: context-path="classpath:/classes/COB-INF/
to some other place:
context-path="f
OK, resolved the issue. Deleted xslt/ directory :/ and now its starting.
STRANGE!!
And also found that more detailed error info about not being able to
compile XSLT stylesheet was in Tomcat log.
It seems that with C3 cannot be inherited. The error
said about the same being defined in 2 differen
Now Im lost. The Cocoon context doesn't work anymore. Restarting Tomcat
doesn't help. I tried to clean work directory, and still
NullPointerException.
Any idea what might be wrong ?
And how to switch off imported xslt caching ?
INFO: Starting Servlet Engine: Apache Tomcat/7.0.40
cze 20, 2013 8:43
Hi Greg,
El 20/06/2013 20:00, "gelo1234" escribió:
>
>
> It looks like XSLT also got cut in functionality in C3. I tried to rerun
old XSL stylesheets with new C3 and gave up.
>
> The error says nothing meaningful:
>
> Impossible to read
XSLT from 'javax.xml.transform.stream.StreamSource@cba24d',
It looks like XSLT also got cut in functionality in C3. I tried to rerun
old XSL stylesheets with new C3 and gave up.
The error says nothing meaningful:
Impossible to read
XSLT from 'javax.xml.transform.stream.StreamSource@cba24d', see nested
exceptionCould not compile
stylesheetjavax.xml.transfo
You meant Cocoon Spring Configurator Settings ?
Is it usable in spring config files only ... or within
sitemap.xmap also ?
Can you show the example usage of that settings in sitemap.xmap ?
Where do I define the namespace prefix for that Interpreter ?
Greetings,
Greg
2013/6/20 Thorsten Scherler
On 06/20/2013 03:42 PM, gelo1234 wrote:
> Can you provide me with some simple example of that new language
> interpreter (module) ? :)
http://svn.apache.org/viewvc/cocoon/cocoon3/trunk/cocoon-sitemap/src/main/java/org/apache/cocoon/sitemap/expression/SettingsInterpreter.java?diff_format=h&view=mar
Yes. It works!! Thank you. I thought it was just a dummy example :)
That is what I need :)
Greetings,
Greg
2013/6/20 Francesco Chicchiriccò
> On 20/06/2013 15:37, gelo1234 wrote:
>
>
> Any idea how to get HTTP Header named Host ?
>
>
> Doesn't jexl:cocoon.request.serverName work?
>
>
> or
On 20/06/2013 15:37, gelo1234 wrote:
Any idea how to get HTTP Header named Host ?
Doesn't jexl:cocoon.request.serverName work?
or any other HTTP Header value ? [1]
tried cocoon.request.header['Host'], cocoon.request.header.host
without effect
I managed to get only requestURL:
Greeting
Can you provide me with some simple example of that new language
interpreter (module) ? :)
Greetings,
Greg
2013/6/20 Thorsten Scherler
> On 06/20/2013 03:02 PM, gelo1234 wrote:
>
>
>I've got Cocoon site that hosts multiple www domains, all based on the
>>> same sitemap.xmap with >> check
Any idea how to get HTTP Header named Host ? or any other HTTP Header value
? [1]
tried cocoon.request.header['Host'], cocoon.request.header.host without
effect
I managed to get only requestURL:
Greetings,
Greg
[1]
http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html
On 06/20/2013 03:02 PM, gelo1234 wrote:
>
> I've got Cocoon site that hosts multiple www domains, all
> based on the same sitemap.xmap with src="domain_X" check-reload="yes"/>
>
> so the configuration is as follows:
>
>
>
>
> I've got Cocoon site that hosts multiple www domains, all based on the
>> same sitemap.xmap with > check-reload="yes"/>
>>
>> so the configuration is as follows:
>>
>>
>>
>>
>> > check-reload="yes"/>
>>
>>
Thanks for clarifying this.
Greetings,
Greg
2013/6/20 Thorsten Scherler
> On 06/20/2013 09:15 AM, Francesco Chicchiriccò wrote:
>
> On 20/06/2013 09:07, Francesco Chicchiriccò wrote:
>
> 4. actions in sitemap.xmap ?
>
> e.g.
>
> name="request" src="org.apache.cocoon.
On 06/20/2013 09:15 AM, Francesco Chicchiriccò wrote:
> On 20/06/2013 09:07, Francesco Chicchiriccò wrote:
>>> 4. actions in sitemap.xmap ?
>>>
>>> e.g.
>>>
>>> >> name="request" src="org.apache.cocoon.acting.RequestParamAction"/>
>>
>> No.
>
> It looks I might be wrong [1]
On 19/06/2013 21:18, gelo1234 wrote:
Sorry for the mistyping: s/cutom/custom.
One more question: I saw in examples sitemap.xmap
under
Is it possible to put straight under ?
No; if you like XSD, you can take a look at [1] to know exactly what
element is allowed at what place.
And what
On 20/06/2013 09:07, Francesco Chicchiriccò wrote:
4. actions in sitemap.xmap ?
e.g.
name="request" src="org.apache.cocoon.acting.RequestParamAction"/>
No.
It looks I might be wrong [1]: Thorsten, could you provide some more
information here?
Thanks.
[1] https://
On 19/06/2013 20:46, gelo1234 wrote:
Hi all,
I wonder if C3 still supports:
As you have already done, take [1] as general reference of what it is
possible in C3 sitemaps.
1. matchers in sitemap.xmap ?
e.g.
src="org.apache.cocoon.matching.WildcardURIMatcher"/>
src="org.apache.cocoon.match
24 matches
Mail list logo