Java version
Hi everybody, I noticed, that my compiled block has always java version 1.5. I need it with 1.4. What should I do? I build my block by mvn install. cheers Johannes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Java version
In the pom, You can define a the plugin below and just set the source and target to your needs. Cheers, Robby Pelssers build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.0/version configuration source1.5/source target1.5/target /configuration /plugin ... -Original Message- From: Johannes Hoechstaedter [mailto:[EMAIL PROTECTED] Sent: donderdag 3 juli 2008 9:59 To: users@cocoon.apache.org Subject: Java version Hi everybody, I noticed, that my compiled block has always java version 1.5. I need it with 1.4. What should I do? I build my block by mvn install. cheers Johannes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java version
Hi Robby, thank you for your quick reply, but It doesn't work. I added: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.0/version configuration source1.4/source target1.4/target /configuration /plugin to my pom.xml of myBlock, did a mvn clean install, and looked into my newly generated jar file in the target directory, but the version in the manifets file ist still the same. 1.5.0_... Could it be path issue? cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java version
I did it. I changed my environment variable JAVA_HOME to 1.4. Nevertheless I would be happy if some one knows another solution how to configure the maven build. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java version
Well, you can't say that it is solved. When I want to build my webapp, I have to switch to 1.5 again. Otherwise I get fatal errors. What I am wondering is, that cocoon hasn't a maven-compiler-plugin by default, so it doesn't need this, or? Robby Pelssers schrieb: Strange that the compiler-plugin failed to do the job... http://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compi ler-source-and-target.html Well, anyway. Glad you managed to solve your problem. Cheers, Robby -Original Message- From: Johannes Hoechstaedter [mailto:[EMAIL PROTECTED] Sent: donderdag 3 juli 2008 10:43 To: users@cocoon.apache.org Subject: Re: Java version I did it. I changed my environment variable JAVA_HOME to 1.4. Nevertheless I would be happy if some one knows another solution how to configure the maven build. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java version
;) Yes, and you can't say that it is solved twice because tomcat 5.0 with 1.4 doesn't want to start the application... cheers Johannes Hoechstaedter schrieb: Well, you can't say that it is solved. When I want to build my webapp, I have to switch to 1.5 again. Otherwise I get fatal errors. What I am wondering is, that cocoon hasn't a maven-compiler-plugin by default, so it doesn't need this, or? Robby Pelssers schrieb: Strange that the compiler-plugin failed to do the job... http://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compi ler-source-and-target.html Well, anyway. Glad you managed to solve your problem. Cheers, Robby -Original Message- From: Johannes Hoechstaedter [mailto:[EMAIL PROTECTED] Sent: donderdag 3 juli 2008 10:43 To: users@cocoon.apache.org Subject: Re: Java version I did it. I changed my environment variable JAVA_HOME to 1.4. Nevertheless I would be happy if some one knows another solution how to configure the maven build. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to access configuration files and properties after packaging
Hi everybody, in my cocoon block I have some configuration files in the resource/external directory, which I want to be accessible by the admin of the application even when I compiled the block, and put it as webapp into my Tomcat. Till now these files are packed correctly into the block jar but because of this they aren't really accessible for quick changes. I have the same problem with my property file in META-INF/cocoon/properties. All of this configuration files should be placed into webapps/webapp/WEB_INF/classes Any solutions? Thank you Johannes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java version
Hi, now here is a solution I can live with: I have edited: the maven-jar-plugin and simply added Build-Jdk1.4/Build-Jdk to the manifest. That works for me. bye - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java version
End of thred is, that I have Error creating bean with name 'de.memocomp.myBlock1.service' running my webapp on Tomcat 5.0 with java 1.4. Everything was fine with Tomact 5.5 and java 1.5. Johannes Hoechstaedter schrieb: Hi, now here is a solution I can live with: I have edited: the maven-jar-plugin and simply added Build-Jdk1.4/Build-Jdk to the manifest. That works for me. bye - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Passing a node-set from XSLT to Java
Hi Luca/All,
Sorry. On further testing, we're still not getting through the full
tree fragment to Java.
I've adapted the java method to give details of what it receives:
public String addGML(org.w3c.dom.Node myNode)
{
System.out.println(Class = +node.getClass().getName());
System.out.println(Name = +node.getNodeName());
System.out.println(Has children = +(node.hasChildNodes()?Yes:No));
System.out.println(First Child Name =
+node.getFirstChild().getNodeName());
System.out.println(First Child Text =
+node.getFirstChild().getTextContent());
}
and from this comes the following output:
Class = org.apache.xml.dtm.ref.DTMNodeProxy
Name = gml:Polygon
Has children = Yes
First Child Name = #text
The last line (which uses the getTextContent() method) throws the
following exception:
javax.xml.transform.TransformerException: java.lang.AbstractMethodError:
org.apache.xml.dtm.ref.DTMNodeProxy.getTextContent()Ljava/lang/String;
at
org.apache.xalan.extensions.ExtensionHandlerJavaClass.callFunction(ExtensionHandlerJavaClass.java:396)
...
Firstly, I was expecting the Class to be org.w3c.dom.Node, so does
anyone know how I can enable this? I was also expecting the name of the
first child to be gml:exterior instead of a #text. The XML I'm
sending is given below:
gml:Polygon gml:id=GATS1153_10
gml:exterior
gml:LinearRing
gml:posList srsDimension=2-155.42 55.58/gml:posList
/gml:LinearRing
/gml:exterior
/gml:Polygon
Is it possible I actually need to pass a tree fragment, rather than a
node-set?
As a reminder, the XSLT given below. Any help would me greatly
appreciated. In simple terms, I'm just trying to pass the above XML
from XSLT to Java, preferably as a w3c Node.
Kind regards,
Andy
The XSLT:
xsl:stylesheet ... myClass=xalan://my.package.name.MyClass
...
xsl:variable name=gmlAdder select=myClass:new()/
xsl:variable name=gml
xsl:copy-of select=@* | node()/
/xsl:variable
xsl:variable name=result select=myClass:addGML($gmlAdder,$gml)/
...
/xsl:stylesheet
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: How to access configuration files and properties after packaging
Here is one way that seems to work. Make a separate set of configuration for development and the default for production. \src\main\resources\META-INF\cocoon\properties\config.properties \src\main\resources\META-INF\cocoon\dev\properties\config.properties and run during development with mvn -Dorg.apache.cocoon.mode=dev jetty:run It is documented somewhere _if_ you can find it. I suppose the same would work in Tomcat, ect. But this has not solved all my problems. I tried it with log4j.properties. It works fine, provided the application is packaged in a .war file and run from there. But in that case, there is no rcl. To have rcl, I run the block directly but then I don't know how to configure log4j. I have the same problem with sdocbook - entity catalog resolution. It works from the war file, not from the block itself. Is there an easy way to configure these? Thanks Robin -Original Message- From: Johannes Hoechstaedter [mailto:[EMAIL PROTECTED] Sent: 03 July 2008 11:06 To: users@cocoon.apache.org Subject: How to access configuration files and properties after packaging Hi everybody, in my cocoon block I have some configuration files in the resource/external directory, which I want to be accessible by the admin of the application even when I compiled the block, and put it as webapp into my Tomcat. Till now these files are packed correctly into the block jar but because of this they aren't really accessible for quick changes. I have the same problem with my property file in META-INF/cocoon/properties. All of this configuration files should be placed into webapps/webapp/WEB_INF/classes Any solutions? Thank you Johannes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to access configuration files and properties after packaging
2008/7/3 Robin Rigby [EMAIL PROTECTED]: Here is one way that seems to work. Make a separate set of configuration for development and the default for production. \src\main\resources\META-INF\cocoon\properties\config.properties \src\main\resources\META-INF\cocoon\dev\properties\config.properties and run during development with mvn -Dorg.apache.cocoon.mode=dev jetty:run Safer, surely, to make development the default and configure the production server with the system property? Otherwise a developer who forgets the -D when testing out some code changes could completely mess up your live data... Andy. -- http://pseudoq.sourceforge.net/ Open source java Sudoku application - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to access configuration files and properties after packaging
Robin Rigby schrieb: Here is one way that seems to work. Make a separate set of configuration for development and the default for production. \src\main\resources\META-INF\cocoon\properties\config.properties \src\main\resources\META-INF\cocoon\dev\properties\config.properties and run during development with mvn -Dorg.apache.cocoon.mode=dev jetty:run It is documented somewhere _if_ you can find it. I suppose the same would work in Tomcat, ect Thank you for your answer Robin, but your configuration files are still packaged in in the jar file, or? Thats what I want to pretend. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How to access configuration files and properties after packaging
ok. Depends what the config does. In my case, there would be an ugly crash before any damage could be done. btw. I think that should have been \src\main\resources\META-INF\cocoon\properties\config.properties \src\main\resources\META-INF\cocoon\properties\dev\config.properties Robin -Original Message- From: Robin Rigby [mailto:[EMAIL PROTECTED] Sent: 03 July 2008 12:23 To: users@cocoon.apache.org Subject: RE: How to access configuration files and properties after packaging Here is one way that seems to work. Make a separate set of configuration for development and the default for production. \src\main\resources\META-INF\cocoon\properties\config.properties \src\main\resources\META-INF\cocoon\dev\properties\config.properties and run during development with mvn -Dorg.apache.cocoon.mode=dev jetty:run It is documented somewhere _if_ you can find it. I suppose the same would work in Tomcat, ect. But this has not solved all my problems. I tried it with log4j.properties. It works fine, provided the application is packaged in a .war file and run from there. But in that case, there is no rcl. To have rcl, I run the block directly but then I don't know how to configure log4j. I have the same problem with sdocbook - entity catalog resolution. It works from the war file, not from the block itself. Is there an easy way to configure these? Thanks Robin -Original Message- From: Johannes Hoechstaedter [mailto:[EMAIL PROTECTED] Sent: 03 July 2008 11:06 To: users@cocoon.apache.org Subject: How to access configuration files and properties after packaging Hi everybody, in my cocoon block I have some configuration files in the resource/external directory, which I want to be accessible by the admin of the application even when I compiled the block, and put it as webapp into my Tomcat. Till now these files are packed correctly into the block jar but because of this they aren't really accessible for quick changes. I have the same problem with my property file in META-INF/cocoon/properties. All of this configuration files should be placed into webapps/webapp/WEB_INF/classes Any solutions? Thank you Johannes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How to access configuration files and properties after packaging
Try a third set of resources, that are not packaged in the war file, in
addition to internal and external. The path to them can be configured as I
described. The sitemap does something like:
map:pipeline id=non-war-resource
map:match pattern=resource/nonwar/**
map:read src={path.to.non.war.resources}/{1} /
etc
Robin
-Original Message-
From: Johannes Hoechstaedter [mailto:[EMAIL PROTECTED]
Sent: 03 July 2008 12:45
To: users@cocoon.apache.org
Subject: Re: How to access configuration files and properties after
packaging
Robin Rigby schrieb:
Here is one way that seems to work. Make a separate set of configuration
for development and the default for production.
\src\main\resources\META-INF\cocoon\properties\config.properties
\src\main\resources\META-INF\cocoon\dev\properties\config.properties
and run during development with
mvn -Dorg.apache.cocoon.mode=dev jetty:run
It is documented somewhere _if_ you can find it. I suppose the same would
work in Tomcat, ect
Thank you for your answer Robin, but your configuration files are still
packaged in in the jar file, or? Thats what I want to pretend.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to access configuration files and properties after packaging
Your right. I don't want to configure important properties during runtime. My aim is an application which is easy configurable by the sysadmin without the need for compilation. For example when the system is down some properties or some some resources (table decriptors for example) should be changeble, by the admin, who has no maven installed or the knowledge abaout zip and jar files, which are buried deep into the system. Robin Rigby schrieb: ok. Depends what the config does. In my case, there would be an ugly crash before any damage could be done. btw. I think that should have been \src\main\resources\META-INF\cocoon\properties\config.properties \src\main\resources\META-INF\cocoon\properties\dev\config.properties Robin -Original Message- From: Robin Rigby [mailto:[EMAIL PROTECTED] Sent: 03 July 2008 12:23 To: users@cocoon.apache.org Subject: RE: How to access configuration files and properties after packaging Here is one way that seems to work. Make a separate set of configuration for development and the default for production. \src\main\resources\META-INF\cocoon\properties\config.properties \src\main\resources\META-INF\cocoon\dev\properties\config.properties and run during development with mvn -Dorg.apache.cocoon.mode=dev jetty:run It is documented somewhere _if_ you can find it. I suppose the same would work in Tomcat, ect. But this has not solved all my problems. I tried it with log4j.properties. It works fine, provided the application is packaged in a .war file and run from there. But in that case, there is no rcl. To have rcl, I run the block directly but then I don't know how to configure log4j. I have the same problem with sdocbook - entity catalog resolution. It works from the war file, not from the block itself. Is there an easy way to configure these? Thanks Robin -Original Message- From: Johannes Hoechstaedter [mailto:[EMAIL PROTECTED] Sent: 03 July 2008 11:06 To: users@cocoon.apache.org Subject: How to access configuration files and properties after packaging Hi everybody, in my cocoon block I have some configuration files in the resource/external directory, which I want to be accessible by the admin of the application even when I compiled the block, and put it as webapp into my Tomcat. Till now these files are packed correctly into the block jar but because of this they aren't really accessible for quick changes. I have the same problem with my property file in META-INF/cocoon/properties. All of this configuration files should be placed into webapps/webapp/WEB_INF/classes Any solutions? Thank you Johannes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to access configuration files and properties after packaging
How can I access the web-inf folder?
Robin Rigby schrieb:
Try a third set of resources, that are not packaged in the war file, in
addition to internal and external. The path to them can be configured as I
described. The sitemap does something like:
map:pipeline id=non-war-resource
map:match pattern=resource/nonwar/**
map:read src={path.to.non.war.resources}/{1} /
etc
Robin
-Original Message-
From: Johannes Hoechstaedter [mailto:[EMAIL PROTECTED]
Sent: 03 July 2008 12:45
To: users@cocoon.apache.org
Subject: Re: How to access configuration files and properties after
packaging
Robin Rigby schrieb:
Here is one way that seems to work. Make a separate set of configuration
for development and the default for production.
\src\main\resources\META-INF\cocoon\properties\config.properties
\src\main\resources\META-INF\cocoon\dev\properties\config.properties
and run during development with
mvn -Dorg.apache.cocoon.mode=dev jetty:run
It is documented somewhere _if_ you can find it. I suppose the same would
work in Tomcat, ect
Thank you for your answer Robin, but your configuration files are still
packaged in in the jar file, or? Thats what I want to pretend.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
XSLT Version?
Hi All, Simple question, I hope. How do I find out which version of XSLT I've got? My version of Cocoon is: 2.1.10, if it's related to that. Ultimately, I'd like to be using XSLT 2.0. Thanks, Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to access configuration files and properties after packaging
I use properties to define my database connection. I my development
environment I add my properties into block rcl.properties and I can
test blocks individually with jetty. rcl.properties file is not
included in block jar file. In my application I created cocoon/
properties/application.properties file in src/main/webapp/WEB-INF.
This file contains all properties from all application blocks. When
my application runs in tomcat I have cocoon/properties/
application.properties in my WEB-INF and I can edit it without
changing jar files.
Barbara
On 3 Jul, 2008, at 1:04 pm, Johannes Hoechstaedter wrote:
How can I access the web-inf folder?
Robin Rigby schrieb:
Try a third set of resources, that are not packaged in the war
file, in
addition to internal and external. The path to them can be
configured as I
described. The sitemap does something like:
map:pipeline id=non-war-resource
map:match pattern=resource/nonwar/**
map:read src={path.to.non.war.resources}/{1} /
etc
Robin
-Original Message-
From: Johannes Hoechstaedter [mailto:[EMAIL PROTECTED]
Sent: 03 July 2008 12:45
To: users@cocoon.apache.org
Subject: Re: How to access configuration files and properties after
packaging
Robin Rigby schrieb:
Here is one way that seems to work. Make a separate set of
configuration
for development and the default for production.
\src\main\resources\META-INF\cocoon\properties\config.properties
\src\main\resources\META-INF\cocoon\dev\properties\config.properties
and run during development with
mvn -Dorg.apache.cocoon.mode=dev jetty:run
It is documented somewhere _if_ you can find it. I suppose the
same would
work in Tomcat, ect
Thank you for your answer Robin, but your configuration files are
still packaged in in the jar file, or? Thats what I want to pretend.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: XSLT Version?
2008/7/3 Andrew Chamberlain [EMAIL PROTECTED]: Hi All, Simple question, I hope. How do I find out which version of XSLT I've got? Try using some XSLT 2-only features in a pipeline and see if you get a stack trace instead? ;-) My version of Cocoon is: 2.1.10, if it's related to that. Ultimately, I'd like to be using XSLT 2.0. Short answer is it depends :-) The default XSL transformer in the sample web app uses Xalan, which is XSLT 1.something, so that's probably what you're using. But you can change the configuration in the cocoon.xconf to make it use Saxon instead, which supports 2.0 (or just set up a second XSL transformer for Saxon and use whichever one you need in any given pipeline). Andy. -- http://pseudoq.sourceforge.net/ Open source java Sudoku creator - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Access Cocoon User-Object from outside Cocoon?
Hi, I am currently optimizing an application I have developed and am currently trying to create a Servlet, that bypasses Cocoons Pipeline-Stuff. The reason for this is that my application has an instant messenger component, that checks for new messages every 6 seconds. With 100 Users online, this creates about 70% of the server load. Since all this component does, is to check if there are new messages and if there are, to send 1 row of JavaScript back to the client, I would like to bypass Cocoon completely. Unfortunately I have to access the User Object stored in the session. Inside Cocoon this is absolutely no problem, but I am struggling to do this from outside Cocoon. Has anyone done this before and could give me a hint at how to do this? Chris [ C h r i s t o f e r D u t z ] C-Ware IT-Service Inhaber Dipl. Inf. Christofer Dutz Karlstraße. 104, 64285 Darmstadt fon: 0 61 51 / 27315 - 61 fax: 0 61 51 / 27315 - 64 mobil: 0171 / 7 444 2 33 email: [EMAIL PROTECTED] http://www.c-ware.de http://www.c-ware.de/ FA Darmstadt: 07 813 60581
Re: XSLT Version?
Hi Andy, Thanks for that. Yes - I'm using Xalan as provided with the sample webapp. I think your suggestion of setting up Saxon in parallel to Xalan is probably the best option, as I don't want to affect the other pipelines we have running. Thanks again, Andy Andy Stevens wrote: 2008/7/3 Andrew Chamberlain [EMAIL PROTECTED]: Hi All, Simple question, I hope. How do I find out which version of XSLT I've got? Try using some XSLT 2-only features in a pipeline and see if you get a stack trace instead? ;-) My version of Cocoon is: 2.1.10, if it's related to that. Ultimately, I'd like to be using XSLT 2.0. Short answer is it depends :-) The default XSL transformer in the sample web app uses Xalan, which is XSLT 1.something, so that's probably what you're using. But you can change the configuration in the cocoon.xconf to make it use Saxon instead, which supports 2.0 (or just set up a second XSL transformer for Saxon and use whichever one you need in any given pipeline). Andy. -- http://pseudoq.sourceforge.net/ Open source java Sudoku creator - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to access configuration files and properties after packaging
Hi,
that mechanism with the property file works. Thumbsup :) For a strange
reason I have the porty file in my jar file and in the expected folder,
although I have deleted it from my block.
My second question is still, how I can access some folders outside of my
jar by the pointed out
map:pipeline id=non-war-resource
map:match pattern=resource/nonwar/**
map:read src={path.to.non.war.resources}/{1} /
I got a little bit confused about the protocol. Whats context://,
resource://, ... do I need this?
Barbara Slupik schrieb:
I use properties to define my database connection. I my development
environment I add my properties into block rcl.properties and I can
test blocks individually with jetty. rcl.properties file is not
included in block jar file. In my application I created
cocoon/properties/application.properties file in
src/main/webapp/WEB-INF. This file contains all properties from all
application blocks. When my application runs in tomcat I have
cocoon/properties/application.properties in my WEB-INF and I can edit
it without changing jar files.
Barbara
On 3 Jul, 2008, at 1:04 pm, Johannes Hoechstaedter wrote:
How can I access the web-inf folder?
Robin Rigby schrieb:
Try a third set of resources, that are not packaged in the war file, in
addition to internal and external. The path to them can be
configured as I
described. The sitemap does something like:
map:pipeline id=non-war-resource
map:match pattern=resource/nonwar/**
map:read src={path.to.non.war.resources}/{1} /
etc
Robin
-Original Message-
From: Johannes Hoechstaedter [mailto:[EMAIL PROTECTED]
Sent: 03 July 2008 12:45
To: users@cocoon.apache.org
Subject: Re: How to access configuration files and properties after
packaging
Robin Rigby schrieb:
Here is one way that seems to work. Make a separate set of
configuration
for development and the default for production.
\src\main\resources\META-INF\cocoon\properties\config.properties
\src\main\resources\META-INF\cocoon\dev\properties\config.properties
and run during development with
mvn -Dorg.apache.cocoon.mode=dev jetty:run
It is documented somewhere _if_ you can find it. I suppose the
same would
work in Tomcat, ect
Thank you for your answer Robin, but your configuration files are
still packaged in in the jar file, or? Thats what I want to pretend.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Passing a node-set from XSLT to Java
Andrew Chamberlain wrote:
Hi Luca/All,
Sorry. On further testing, we're still not getting through the full
tree fragment to Java.
I've adapted the java method to give details of what it receives:
public String addGML(org.w3c.dom.Node myNode)
{
System.out.println(Class = +node.getClass().getName());
System.out.println(Name = +node.getNodeName());
System.out.println(Has children =
+(node.hasChildNodes()?Yes:No));
System.out.println(First Child Name =
+node.getFirstChild().getNodeName());
System.out.println(First Child Text =
+node.getFirstChild().getTextContent());
}
and from this comes the following output:
Class = org.apache.xml.dtm.ref.DTMNodeProxy
Name = gml:Polygon
Has children = Yes
First Child Name = #text
The last line (which uses the getTextContent() method) throws the
following exception:
javax.xml.transform.TransformerException: java.lang.AbstractMethodError:
org.apache.xml.dtm.ref.DTMNodeProxy.getTextContent()Ljava/lang/String;
at
org.apache.xalan.extensions.ExtensionHandlerJavaClass.callFunction(ExtensionHandlerJavaClass.java:396)
...
Firstly, I was expecting the Class to be org.w3c.dom.Node, so does
anyone know how I can enable this?
DTMNodeProxy is the concrete implementation class, so it makes sense
that you get that. org.w3c.dom.Node would just be one of the (possibly
many) interfaces it implements so I wouldn't expect getClass().getName()
to return it. I think what you're really wanting is node.getNodeType()
which returns one of the node type constants (see the Node javadoc).
I was also expecting the name of the
first child to be gml:exterior instead of a #text. The XML I'm
sending is given below:
gml:Polygon gml:id=GATS1153_10
gml:exterior
gml:LinearRing
gml:posList srsDimension=2-155.42 55.58/gml:posList
/gml:LinearRing
/gml:exterior
/gml:Polygon
My guess is that the first child of gml:Polygon is actually the
whitespace text node before the gml:exterior element. Pretty easy to
test by looking at the length of getChildNodes() which would be 3. To
get straight to the gml:exterior you could use getElementsByTagNameNS,
or check each child node's nodeType for ELEMENT_NODE.
Is it possible I actually need to pass a tree fragment, rather than a
node-set?
As a reminder, the XSLT given below. Any help would me greatly
appreciated. In simple terms, I'm just trying to pass the above XML
from XSLT to Java, preferably as a w3c Node.
Kind regards,
Andy
The XSLT:
xsl:stylesheet ... myClass=xalan://my.package.name.MyClass
...
xsl:variable name=gmlAdder select=myClass:new()/
xsl:variable name=gml
xsl:copy-of select=@* | node()/
/xsl:variable
xsl:variable name=result select=myClass:addGML($gmlAdder,$gml)/
...
/xsl:stylesheet
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Passing a node-set from XSLT to Java
Andrew Chamberlain wrote: The last line (which uses the getTextContent() method) throws the following exception: javax.xml.transform.TransformerException: java.lang.AbstractMethodError: org.apache.xml.dtm.ref.DTMNodeProxy.getTextContent()Ljava/lang/String; at org.apache.xalan.extensions.ExtensionHandlerJavaClass.callFunction(ExtensionHandlerJavaClass.java:396) For a better understanding, you should look at the portion of the stack trace following caused by. Firstly, I was expecting the Class to be org.w3c.dom.Node, so does anyone know how I can enable this? Rather difficult, since org.w3c.dom.Node is an interface, not a class: the object that is passed to the addGML function is an instance of org.apache.xml.dtm.ref.DTMNodeProxy, an actual class which happens to implement org.w3c.dom.Node. I was also expecting the name of the first child to be gml:exterior instead of a #text. Understandable, since your XML has newlines and blanks before gml:exterior: try stripping all this baggage before parsing. Regards, Luca Morandini www.lucamorandini.it - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XSLT Version?
Andrew Chamberlain wrote:
Hi All,
Simple question, I hope. How do I find out which version of XSLT I've
got? My version of Cocoon is: 2.1.10, if it's related to that.
Ultimately, I'd like to be using XSLT 2.0.
Thanks,
Andy
Insert something like the following into a stylesheet:
xsl:comment
xsl:textVersion is: /xsl:text
xsl:value-of select=system-property('xsl:version')/
/xsl:comment
Hope this helps,
StanD.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
