Re: [RESULT] [VOTE] Apache Cocoon Servlet Service Implementation 1.3.1
On 28 June 2012 09:11, Francesco Chicchiriccò ilgro...@apache.org wrote: Hi all, after 72 hours, the vote for Cocoon Servlet Service Implementation 1.3.1 [1] *passes* with 4 PMC + 0 non-PMC votes. You mean 3 PMC votes ;) +1 (PMC / binding) * Francesco Chicchiriccò * Robby Pelssers * Javier Puerto +1 (non binding) none 0 none -1 none Thanks to everyone participating. I will now copy this release to Cocoon' dist directory and promote the artifacts to the central Maven repository. Best regards. [1] http://markmail.org/message/zmuofhq7quyfa3ne -- Francesco Chicchiriccò ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Memberhttp://people.apache.org/~ilgrosso/
Re: Any issue with Nexus - Central Repo sync?
It works for me™ On 14 June 2012 14:56, Francesco Chicchiriccò ilgro...@apache.org wrote: Hi, something strange is happening: a few days ago we voted and released some artifacts at Cocoon: as a result the following artifacts are available at releases repository since last Mon 11 Jun: https://repository.apache.org/content/repositories/releases/org/apache/cocoon/cocoon-serializers-charsets/1.0.2/ https://repository.apache.org/content/repositories/releases/org/apache/cocoon/cocoon-block-deployment/1.2.1/ https://repository.apache.org/content/repositories/releases/org/apache/cocoon/cocoon-it-fw/1.0.0/ https://repository.apache.org/content/repositories/releases/org/apache/cocoon/cocoon-configuration-api/1.0.4/ https://repository.apache.org/content/repositories/releases/org/apache/cocoon/cocoon-rcl-spring-reloader/1.0.2/ https://repository.apache.org/content/repositories/releases/org/apache/cocoon/cocoon-rcl-webapp-wrapper/1.0.2/ while central repo is still missing (404 for all): http://repo1.maven.org/maven2/org/apache/cocoon/cocoon-serializers-charsets/1.0.2/ http://repo1.maven.org/maven2/org/apache/cocoon/cocoon-block-deployment/1.2.1/ http://repo1.maven.org/maven2/org/apache/cocoon/cocoon-it-fw/1.0.0/ http://repo1.maven.org/maven2/org/apache/cocoon/cocoon-configuration-api/1.0.4/ http://repo1.maven.org/maven2/org/apache/cocoon/cocoon-rcl-spring-reloader/1.0.2/ http://repo1.maven.org/maven2/org/apache/cocoon/cocoon-rcl-webapp-wrapper/1.0.2/ Did I miss something? Thanks. Regards. -- Francesco Chicchiriccò ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Memberhttp://people.apache.org/~ilgrosso/
Re: Any issue with Nexus - Central Repo sync?
On 14 June 2012 16:16, Francesco Chicchiriccò ilgro...@apache.org wrote: On 14/06/2012 15:59, Jasha Joachimsthal wrote: It works for me™ Well, you're right: direct link provided below work as expected while the parent directory listing does not; e.g. http://repo1.maven.org/maven2/org/apache/cocoon/cocoon-rcl-webapp-wrapper/1.0.2/is working but http://repo1.maven.org/maven2/org/apache/cocoon/cocoon-rcl-webapp-wrapper/does not show 1.0.2 Any clue? It works on my machine™ http://repo1.maven.org/maven2/org/apache/cocoon/cocoon-rcl-webapp-wrapper/ Index of /maven2/org/apache/cocoon/cocoon-rcl-webapp-wrapper/ ../ 1.0.0/ 30-Jun-2011 14:53 - 1.0.0-M1/ 30-Jun-2011 14:53 - 1.0.0-M2/ 30-Jun-2011 14:53 - 1.0.0-M3/ 30-Jun-2011 14:53 - 1.0.2/ 11-Jun-2012 14:55 - maven-metadata.xml 11-Jun-2012 14:55 503 maven-metadata.xml.md5 11-Jun-2012 14:55 32 maven-metadata.xml.sha1 11-Jun-2012 14:55 40 On 14 June 2012 14:56, Francesco Chicchiriccò ilgro...@apache.org wrote: Hi, something strange is happening: a few days ago we voted and released some artifacts at Cocoon: as a result the following artifacts are available at releases repository since last Mon 11 Jun: https://repository.apache.org/content/repositories/releases/org/apache/cocoon/cocoon-serializers-charsets/1.0.2/ https://repository.apache.org/content/repositories/releases/org/apache/cocoon/cocoon-block-deployment/1.2.1/ https://repository.apache.org/content/repositories/releases/org/apache/cocoon/cocoon-it-fw/1.0.0/ https://repository.apache.org/content/repositories/releases/org/apache/cocoon/cocoon-configuration-api/1.0.4/ https://repository.apache.org/content/repositories/releases/org/apache/cocoon/cocoon-rcl-spring-reloader/1.0.2/ https://repository.apache.org/content/repositories/releases/org/apache/cocoon/cocoon-rcl-webapp-wrapper/1.0.2/ while central repo is still missing (404 for all): http://repo1.maven.org/maven2/org/apache/cocoon/cocoon-serializers-charsets/1.0.2/ http://repo1.maven.org/maven2/org/apache/cocoon/cocoon-block-deployment/1.2.1/ http://repo1.maven.org/maven2/org/apache/cocoon/cocoon-it-fw/1.0.0/ http://repo1.maven.org/maven2/org/apache/cocoon/cocoon-configuration-api/1.0.4/ http://repo1.maven.org/maven2/org/apache/cocoon/cocoon-rcl-spring-reloader/1.0.2/ http://repo1.maven.org/maven2/org/apache/cocoon/cocoon-rcl-webapp-wrapper/1.0.2/ Did I miss something? Thanks. Regards. -- Francesco Chicchiriccò ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Memberhttp://people.apache.org/~ilgrosso/
Re: [VOTE] Apache Cocoon parent 9
Op 5 jun. 2012, om 10:59 heeft Francesco Chicchiriccò het volgende geschreven: I've created a Cocoon parent 9 release, with the following artifacts up for a vote: SVN source tag (r1346276): https://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2/cocoon/cocoon-9/ List of changes: https://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2/cocoon/cocoon-9/src/changes/changes.xml Maven staging repo: https://repository.apache.org/content/repositories/orgapachecocoon-186/ Source release (checksums and signatures are available at the same location): https://repository.apache.org/content/repositories/orgapachecocoon-186/org/apache/cocoon/cocoon/9/cocoon-9-source-release.zip PGP release keys (signed using 273DF287): http://www.apache.org/dist/cocoon/KEYS Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Francesco Chicchiriccò ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/ +1 Jasha signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [VOTE] Javier Puerto as cocoon committer
+1 On 28 May 2012 10:26, Thorsten Scherler thors...@apache.org wrote: Hello all, I propose Javier Puerto as a new Cocoon committer and PMC member. I am working with Javier since over 5 years now in different teams for different clients. Our projects include all version of cocoon and he contributed many qualified patches over the years. He is an ASF committer in Apache Droids and I think he would make a great addition to our team. He contributes now on a regular base and lately as well started to dig into many issues that are critical for the c3 release. That shows that his interest in Cocoon is longer-term. This vote ends one week from today, i.e. midnight UTC on Sunday 2012-06-04 Please cast your votes. -- Thorsten Scherlerthorsten.at.apache.**org http://thorsten.at.apache.org codeBusters S.L. - web based systems consulting, training and solutions http://www.codebusters.es/
Re: [VOTE] Javier Puerto as cocoon committer
+1 On 28 May 2012 10:26, Thorsten Scherler thors...@apache.org wrote: Hello all, I propose Javier Puerto as a new Cocoon committer and PMC member. I am working with Javier since over 5 years now in different teams for different clients. Our projects include all version of cocoon and he contributed many qualified patches over the years. He is an ASF committer in Apache Droids and I think he would make a great addition to our team. He contributes now on a regular base and lately as well started to dig into many issues that are critical for the c3 release. That shows that his interest in Cocoon is longer-term. This vote ends one week from today, i.e. midnight UTC on Sunday 2012-06-04 Please cast your votes. -- Thorsten Scherlerthorsten.at.apache.**org http://thorsten.at.apache.org codeBusters S.L. - web based systems consulting, training and solutions http://www.codebusters.es/
Re: could not download XercesImpl from maven repo
It looks like 2.10.1 has never existed (or I am looking in the wrong places). There's no svn tag [1] or binary download [2] for 2.10.1. [1] https://svn.apache.org/repos/asf/xerces/java/tags/ [2] http://archive.apache.org/dist/xerces/j/binaries/ On 21 May 2012 23:46, Robby Pelssers robby.pelss...@nxp.com wrote: Hi all, ** ** I had to change XercesImpl version from ** ** dependency groupIdxerces/groupId artifactIdxercesImpl/artifactId version2.10.1/version /dependency to dependency groupIdxerces/groupId artifactIdxercesImpl/artifactId version2.10.0/version /dependency ** ** In order to get things working. I used the archetypes to get started by the way. Anyone else had similar issues? ** ** Robby
Re: Cocoon at Codeplex?
On 6 May 2012 07:42, Francesco Chicchiriccò ilgro...@apache.org wrote: Matter for legal? http://cocoon.codeplex.com/ -- Francesco Chicchiriccò Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/ Apache Cocoon and Cocoon are trademarks of the ASF: http://www.apache.org/foundation/marks/list/ Although they're not aiming to be a (Java) XML processing framework, it is a framework that can work with web services. If you want advice what steps to take you can open a ticket in https://issues.apache.org/jira/browse/LEGAL Jasha
Re: Problems with JIRA workflow
Looks like you need to create a ticket in https://issues.apache.org/jira/browse/INFRA then. On 4 May 2012 13:07, Francesco Chicchiriccò ilgro...@apache.org wrote: After some more investigation, it seems that you need global admin permission for modifying any workflow [1]: unfortunately, no one of us have these: could you help, please? We are stuck with an almost unusable JIRA... Thanks. Regards. [1] http://confluence.atlassian.com/display/JIRA/Configuring+Workflow#ConfiguringWorkflow-Editingaworkflow On 02/05/2012 20:48, Andreas Veithen wrote: I think Joe replied to the wrong mail. His answer makes sense for another question asked today. On Wed, May 2, 2012 at 8:46 PM, Francesco Chicchiriccòilgro...@apache.org ilgro...@apache.org wrote: Joe Schaefer joe_schae...@yahoo.com joe_schae...@yahoo.com wrote: Look at the anakia2markdown.xslt file inhttps://svn.apache.org/repos/infra/websites/cms/conversion-utilities Uh? Sorry, I don't get it :-S From: Francesco Chicchiriccò ilgro...@apache.org ilgro...@apache.org To: infrastruct...@apache.org Cc: dev@cocoon.apache.org Sent: Wednesday, May 2, 2012 11:27 AM Subject: Problems with JIRA workflow Hello, since a while we have some trouble with JIRA workflow either on COCOON and COCOON3. In fact, the selected workflow Cocoon Workflow does not seem the one we used to have: I tried to see if there is a menu entry for changing this but I wasn't able to find it, even though I should have all needed permissions. Could you help? Regards. -- Francesco Chicchiriccò Apache Cocoon PMC and Apache Syncope PPMC Memberhttp://people.apache.org/~ilgrosso/
Re: an issue with Cocoon source package release vote
Hi, The 2.1 releases all contains jar files from other open source projects because it was built with Ant but without Ivy. What I read in Jukka's reply is that there is no consensus yet for binary dependencies in source releases, which is exactly the case for the 2.1 releases. As long as this is not forbidden I'd keep the old releases as they are. Jasha Joachimsthal Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522 4466 US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll free) www.onehippo.com 2012/4/10 Cédric Damioli cedric.dami...@anyware-services.com Hi, I suppose that if we ever manage to release a 2.1.12 package, this will affect us as well. Is the way Forrest propose to solve the issue officially approved ? IMHO, if so, it won't be that hard to modify the Ant build file to produce separate packages with and without external dependencies. Regards, Cédric Le 10/04/2012 09:51, Simone Tripodi a écrit : Good morning David, if an action is required to fix the release, so +1. Cocoon 2.X people: are you following? :) -Simo http://people.apache.org/~simonetripodi/http://simonetripodi.livejournal.com/http://twitter.com/simonetripodihttp://www.99soft.org/ On Thu, Apr 5, 2012 at 7:40 AM, David Crossley cross...@apache.org cross...@apache.org wrote: Please see the following thread at Apache Forrest which explains the problem with conducting our release vote on a package that contained not only our project sources but also contained other binary files. That thread links to an important discussion at Apache Incubator, etc. Subject: [Proposal] re-release 0.9 with proper source code packagehttp://s.apache.org/mCW There would be a similar situation for the Cocoon-2.1.11 release vote. -David -- http://www.anyware-services.com www.anyware-services.com http://www.twitter.com/anywareservices http://www.facebook.com/AnywareServices http://eepurl.com/eyrpk Inscrivez-vous à notre newsletter http://eepurl.com/eyrpk*Cédric Damioli* Directeur technique cedric.dami...@anyware-services.com Tel : +33(0)5 62 19 19 07 Mob : +33(0)6 87 03 61 63 Fax : +33(0)5 61 75 84 12 Adresse : Innopole 13 - 254 avenue de l'Occitane - 31676 LABEGE CEDEX - France Ametys: Smart Web CMS http://www.ametys.org www.ametys.org Ce message et toutes les pièces jointes (le Message) sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute modification, édition, utilisation ou diffusion non autorisée est interdite. Anyware Services décline toute responsabilité au titre de ce Message s'il a été altéré, déformé, falsifié ou édité, diffusé sans autorisation. facebook.pngtwitter.pnganyware-services.pngnewsletter.pngruntime_favico.gif
Re: [DISCUSS] online APIs doc
On 20 March 2012 08:46, Simone Tripodi simonetrip...@apache.org wrote: Hi all guys, after many users request - last just received on user@ - I would suggest to deploy APIs doc on SVN to make them available online. If no objections will be shown in the next 72h, I'll proceed on deploying the C3 - guess I'll need help on deploying the C2.X versions. +1 Jasha
Re: c3 - I18nTransformer and xhtml markup in properties
2012/3/2 Francesco Chicchiriccò ilgro...@apache.org On 01/03/2012 18:41, Thorsten Scherler wrote: Hi all, we are using the i18n transformer in our app but now we need to add xhtml tags in the resource bundle. However I tried with message.test2 = This is h2message.test3/h2 message.test3 = This is lt;h2gt;message.test4lt;/h2gt; but the problem is that is does not get parsed correctly. Can it be that our c3 transformer does not support that ATM? Hi Thorsten, I think that the usage you report above was never tried with C3 I18NTransformer; anyway, do you think it's correct to include markup in a language catalog? Would this mean that markup is language-dependent? In JSTL resource bundle tags (spring:message, fmt:message) you often have options to not XML-escape the properties. It's cleaner to separate the markup from the message, but sometimes it can be a PITA when to comes to an introduction text with a list or some bold for 1 word in a sentence which order can depend on the language. Jasha
Re: cocoon-sample home page
The build was broken after your check-ins, can you fix it? https://builds.apache.org/view/A-F/view/Cocoon/job/Cocoon-trunk/ Jasha On 6 January 2012 09:53, Robby Pelssers robby.pelss...@nxp.com wrote: Ok. ** ** I just tested and adding the snippet below resolved most issues besides the menu was overlaying the content. I googled and older versions of IE don’t handle well the combination of position:fixed and using float so I removed the fixed position for now. ** ** Robby ** ** *From:* Jasha Joachimsthal [mailto:j.joachimst...@onehippo.com] *Sent:* Thursday, January 05, 2012 10:55 PM *To:* dev@cocoon.apache.org *Subject:* Re: cocoon-sample home page ** ** @Robby can you add !--[if lt IE 9] script src=//html5shiv.googlecode.com/svn/trunk/html5.js/script ![endif]-- in the head so IE8 and older recognize the html5 elements? Jasha Joachimsthal Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522 4466 US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll free) www.onehippo.com On 5 January 2012 21:17, Peter Hunsberger peter.hunsber...@gmail.com wrote: I like the look, what's the non HTML 5 / CSS 3 fallback do or look like?** ** Peter Hunsberger On Thu, Jan 5, 2012 at 2:01 PM, Robby Pelssers robby.pelss...@nxp.com wrote: Hi guys, I took a stab at giving the sample home page a more modern look using htm5 /css3. I was wondering what you think about it so far and if I can commit my changes. Robby ** ** ** **
Re: cocoon-sample home page
The RAT Maven plugin complains about licenses: https://builds.apache.org/view/A-F/view/Cocoon/job/Cocoon-trunk/134/console message : Failed to execute goal org.codehaus.mojo:rat-maven-plugin:1.0-alpha-3:check (default) on project cocoon-archetype-sample: Too many unapproved licenses: 74 Jasha On 6 January 2012 11:13, Robby Pelssers robby.pelss...@nxp.com wrote: I rechecked and found that 1 href was wrong. ** ** a href=object-model/request-parameters?a=1amp;b=2amp;c=3 ** ** I copied that over verbatim so that probably can’t have broken the build. ** ** This is fixed now but I wonder if anything else could have broken the build. ** ** Robby ** ** *From:* Jasha Joachimsthal [mailto:j.joachimst...@onehippo.com] *Sent:* Friday, January 06, 2012 10:45 AM *To:* dev@cocoon.apache.org *Subject:* Re: cocoon-sample home page ** ** The build was broken after your check-ins, can you fix it? https://builds.apache.org/view/A-F/view/Cocoon/job/Cocoon-trunk/ Jasha ** ** On 6 January 2012 09:53, Robby Pelssers robby.pelss...@nxp.com wrote:*** * Ok. I just tested and adding the snippet below resolved most issues besides the menu was overlaying the content. I googled and older versions of IE don’t handle well the combination of position:fixed and using float so I removed the fixed position for now. Robby *From:* Jasha Joachimsthal [mailto:j.joachimst...@onehippo.com] *Sent:* Thursday, January 05, 2012 10:55 PM *To:* dev@cocoon.apache.org *Subject:* Re: cocoon-sample home page @Robby can you add !--[if lt IE 9] script src=//html5shiv.googlecode.com/svn/trunk/html5.js/script ![endif]-- in the head so IE8 and older recognize the html5 elements? Jasha Joachimsthal Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522 4466 US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll free) www.onehippo.com On 5 January 2012 21:17, Peter Hunsberger peter.hunsber...@gmail.com wrote: I like the look, what's the non HTML 5 / CSS 3 fallback do or look like?** ** Peter Hunsberger ** ** On Thu, Jan 5, 2012 at 2:01 PM, Robby Pelssers robby.pelss...@nxp.com wrote: Hi guys, I took a stab at giving the sample home page a more modern look using htm5 /css3. I was wondering what you think about it so far and if I can commit my changes. Robby ** **
Re: cocoon-parent pom breaking build
On 6 January 2012 11:55, Robby Pelssers robby.pelss...@nxp.com wrote: Ok. So you’re saying every single file needs the ASL header? Or do we have a list of which files should have that header? In general each source code and configuration file should have the correct license header. The command jenkins performs is: mvn clean install -B -U -e -fae -V -T3 -P it -P archetypes ** ** Curious to find out if that plugin is able to handle different filetypes correct as I will need to use different types of commenting for java, css, xml etc. Eclipse has a license plugin and IntelliJ offers similar functionality to automagically add licenses in new files (or update files that don't have the proper license). ** ** Robby ** ** *From:* Francesco Chicchiriccò [mailto:ilgro...@apache.org] *Sent:* Friday, January 06, 2012 11:52 AM *To:* dev@cocoon.apache.org *Subject:* Re: cocoon-parent pom breaking build ** ** On 06/01/2012 11:41, Robby Pelssers wrote: Hi guys, I think the cocoon-parent pom is causing issues. But as I am using maven3 it might be wise that I don’t touch that file as it might break with others still using maven 2. Can someone using maven 2 take a look if he finds errors in that pom? Robby, the build is broken by cocoon-sample, because rat plugin finds too many approved licenses, i.e. there are new files without the needed ASL header. Look at https://builds.apache.org/job/Cocoon-trunk/135/console (towards the end) for details. Regards. -- Francesco Chicchiriccò ** ** Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
Re: cocoon-parent pom breaking build
Remember we don't make mistakes, we have happy little accidents (Bob Ross) ;) Something to read http://www.apache.org/legal/src-headers.html On 6 January 2012 11:59, Robby Pelssers robby.pelss...@nxp.com wrote: I only added the style.css without a license. That is fixed now. ** ** Sorry for the inconvenience people. Was not fully aware of this. ** ** Robby ** ** *From:* Robby Pelssers [mailto:robby.pelss...@nxp.com] *Sent:* Friday, January 06, 2012 11:56 AM *To:* dev@cocoon.apache.org *Subject:* RE: cocoon-parent pom breaking build ** ** Ok. So you’re saying every single file needs the ASL header? Or do we have a list of which files should have that header? ** ** Curious to find out if that plugin is able to handle different filetypes correct as I will need to use different types of commenting for java, css, xml etc. ** ** Robby ** ** *From:* Francesco Chicchiriccò [mailto:ilgro...@apache.org] *Sent:* Friday, January 06, 2012 11:52 AM *To:* dev@cocoon.apache.org *Subject:* Re: cocoon-parent pom breaking build ** ** On 06/01/2012 11:41, Robby Pelssers wrote: Hi guys, I think the cocoon-parent pom is causing issues. But as I am using maven3 it might be wise that I don’t touch that file as it might break with others still using maven 2. Can someone using maven 2 take a look if he finds errors in that pom? Robby, the build is broken by cocoon-sample, because rat plugin finds too many approved licenses, i.e. there are new files without the needed ASL header. Look at https://builds.apache.org/job/Cocoon-trunk/135/console (towards the end) for details. ** ** Regards. -- Francesco Chicchiriccò ** ** Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
Re: HTML5 serializer
Hey Robby,
which Cocoon version are you using for your project? In C2.1 and C2.2
there's not only a XMLSerializer but also an HTMLSerializer and
XHTMLSerializer for their specific needs. So why not create your own
HTML5Serializer?
In HTML5 the specification teams tried to specify what browsers were
already doing instead of making a new theoretical specification. HTML5
should be backwards compatible with previous (X)HTML versions. This is the
reason why some old elements are not deprecated but considered obsolete
(remember marquee, it was so cool on Geocities).
The doctype doesn't really matter, browsers generally ignore the PUBLIC
part in the doctype (apart from some hacks in IE going into quirks mode).
A good presentation about HTML5 is http://vimeo.com/15755349.
Jasha Joachimsthal
Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522 4466
US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll free)
www.onehippo.com
On 6 January 2012 15:48, Robby Pelssers robby.pelss...@nxp.com wrote:
Hi all,
** **
I’ve been looking at how to add a HTML5 serializer to the project.
** **
So far my investigations have led to add following code to
org.apache.cocoon.sax.component.XMLSerializer
** **
public static XMLSerializer createHTML5Serializer() {
XMLSerializer serializer = new XMLSerializer();
** **
serializer.setContentType(TEXT_HTML_UTF_8);
serializer.setDoctypePublic(XSLT-compat);
serializer.setEncoding(UTF_8);
serializer.setMethod(HTML);
** **
return serializer;
}
** **
** **
Using the HTML5 serializer in a test to print the output:
** **
@Test
public void testHTML5Serializer() throws Exception {
ByteArrayOutputStream baos = new ByteArrayOutputStream();
** **
newNonCachingPipeline()
.setStarter(
new XMLGenerator(htmlheadtitleserializer
test/title/headbodyptest/p/body/html)
)
.setFinisher(XMLSerializer.createHTML5Serializer())
.withEmptyConfiguration()
.setup(baos)
.execute();
** **
String data = new String(baos.toByteArray());
System.out.println(data);
}
** **
Would print
** **
!DOCTYPE html PUBLIC XSLT-compat
html
head
META http-equiv=Content-Type content=text/html; charset=UTF-8
titleserializer test/title
/head
body
ptest/p
/body
/html
** **
** **
I read a number of articles describing the issues with serializing html5
and so far this was the best I could come up with which is not 100%
conforming due to
**· **Non matching doctype although it will not break in the
browser à should be !DOCTYPE html
**· **The charset should be meta charset=”UTF-8”/ according to
html5 spec
** **
** **
http://www.contentwithstyle.co.uk/content/xslt-and-html-5-problems/
http://www.w3schools.com/html5/tag_meta.asp
** **
** **
Does anyone have more knowledge on this subject?
** **
Robby
** **
** **
Re: cocoon-sample home page
Moving to HTML5 is good, as long as slightly older browsers (not only IE8 but also the feature phones) can render the page. For IE8 you only have to add a js to be able to apply styling to new elements as section, nav etc. If you use one of the new input methods, like type=number, the browser will default to type=text if it doesn't know the type. A different thing is the support of audio, video and canvas, but I guess we're not going to use them on a short notice. Makes me think of a nice Cocoon HTML5 sample to render svg... Jasha Joachimsthal Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522 4466 US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll free) www.onehippo.com On 6 January 2012 16:41, Robby Pelssers robby.pelss...@nxp.com wrote: I think it would be reasonable enough if we tested against the latest versions of IE, Chrome and Firefox and skip using features that are not yet supported by all 3 of them. But the extra check I baked in on Jasha’s advice is a no brainer and resolves most issues for older versions of IE.* *** ** ** WDYT? Robby ** ** *From:* Antonio Gallardo [mailto:agalla...@agssa.net] *Sent:* Friday, January 06, 2012 4:36 PM *To:* dev@cocoon.apache.org *Subject:* Re: cocoon-sample home page ** ** Hi Peter, I was wondering if we should care much about it. I found a link with the result of the most common used browsers: http://html5test.com/results.html Perhaps we can move to HTML5 and use a bare minimum of it. :) Best Regards, Antonio Gallardo. On 05/01/12 14:17, Peter Hunsberger wrote: I like the look, what's the non HTML 5 / CSS 3 fallback do or look like? * *** Peter Hunsberger On Thu, Jan 5, 2012 at 2:01 PM, Robby Pelssers robby.pelss...@nxp.com wrote: Hi guys, I took a stab at giving the sample home page a more modern look using htm5 /css3. I was wondering what you think about it so far and if I can commit my changes. Robby ** ** ** **
Re: HTML5 serializer
Ok, then create an HTML5Serializer that extends the current Serializer. An
other solution would be to add a boolean that will output differently for
html5 but I'd prefer extension above a number of if statements.
Jasha
On 6 January 2012 16:56, Robby Pelssers robby.pelss...@nxp.com wrote:
I am using Cocoon2.2 but am planning to switch to C3 in the upcoming
months. And in my mail I was actually referring to C3.You are right
about what you write but I’d prefer to have a Serializer which follows the
spec so I can just copy the output and validate it without errors and too
many warnings at http://validator.w3.org/
** **
Robby
** **
*From:* Jasha Joachimsthal [mailto:j.joachimst...@onehippo.com]
*Sent:* Friday, January 06, 2012 4:51 PM
*To:* dev@cocoon.apache.org
*Subject:* Re: HTML5 serializer
** **
Hey Robby,
** **
which Cocoon version are you using for your project? In C2.1 and C2.2
there's not only a XMLSerializer but also an HTMLSerializer and
XHTMLSerializer for their specific needs. So why not create your own
HTML5Serializer?
** **
In HTML5 the specification teams tried to specify what browsers were
already doing instead of making a new theoretical specification. HTML5
should be backwards compatible with previous (X)HTML versions. This is the
reason why some old elements are not deprecated but considered obsolete
(remember marquee, it was so cool on Geocities).
The doctype doesn't really matter, browsers generally ignore the PUBLIC
part in the doctype (apart from some hacks in IE going into quirks mode).
A good presentation about HTML5 is http://vimeo.com/15755349.
Jasha Joachimsthal
Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522 4466
US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll
free)
www.onehippo.com
On 6 January 2012 15:48, Robby Pelssers robby.pelss...@nxp.com wrote:***
*
Hi all,
I’ve been looking at how to add a HTML5 serializer to the project.
So far my investigations have led to add following code to
org.apache.cocoon.sax.component.XMLSerializer
public static XMLSerializer createHTML5Serializer() {
XMLSerializer serializer = new XMLSerializer();
serializer.setContentType(TEXT_HTML_UTF_8);
serializer.setDoctypePublic(XSLT-compat);
serializer.setEncoding(UTF_8);
serializer.setMethod(HTML);
return serializer;
}
Using the HTML5 serializer in a test to print the output:
@Test
public void testHTML5Serializer() throws Exception {
ByteArrayOutputStream baos = new ByteArrayOutputStream();
newNonCachingPipeline()
.setStarter(
new XMLGenerator(htmlheadtitleserializer
test/title/headbodyptest/p/body/html)
)
.setFinisher(XMLSerializer.createHTML5Serializer())
.withEmptyConfiguration()
.setup(baos)
.execute();
String data = new String(baos.toByteArray());
System.out.println(data);
}
Would print
!DOCTYPE html PUBLIC XSLT-compat
html
head
META http-equiv=Content-Type content=text/html; charset=UTF-8
titleserializer test/title
/head
body
ptest/p
/body
/html
I read a number of articles describing the issues with serializing html5
and so far this was the best I could come up with which is not 100%
conforming due to
· Non matching doctype although it will not break in the browser
à should be !DOCTYPE html
· The charset should be meta charset=”UTF-8”/ according to
html5 spec
http://www.contentwithstyle.co.uk/content/xslt-and-html-5-problems/
http://www.w3schools.com/html5/tag_meta.asp
Does anyone have more knowledge on this subject?
Robby
** **
Re: cocoon-sample home page
@Robby can you add !--[if lt IE 9] script src=//html5shiv.googlecode.com/svn/trunk/html5.js/script ![endif]-- in the head so IE8 and older recognize the html5 elements? Jasha Joachimsthal Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522 4466 US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll free) www.onehippo.com On 5 January 2012 21:17, Peter Hunsberger peter.hunsber...@gmail.comwrote: I like the look, what's the non HTML 5 / CSS 3 fallback do or look like? Peter Hunsberger On Thu, Jan 5, 2012 at 2:01 PM, Robby Pelssers robby.pelss...@nxp.comwrote: Hi guys, ** ** I took a stab at giving the sample home page a more modern look using htm5 /css3. I was wondering what you think about it so far and if I can commit my changes. ** ** Robby
Re: JIRA unification proposal
Merging those projects is good, but only if we clean up COCOON. There is a long list of issues with patches (there used to be a weekly mail with them) and an even longer list of unresolved issues. If we keep these issues open, it will be harder to see what we're working on and what we're dragging with us for years. IMO we can close the 2.1 and 2.2 issues that were created in 2010 or earlier with resolution won't fix. They can always be reopened (or re-created) when someone is actually going to work on them. Jasha Joachimsthal Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522 4466 US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll free) www.onehippo.com 2012/1/3 Francesco Chicchiriccò ilgro...@apache.org Hi devs, as you all know, you currently have two separate projects on Apache JIRA, COCOON and COCOON3. Since there is currently a plan for restructuring the SVN tree [1], what if we unify these two projects on JIRA as well? AFAIK, this should involve: 1. create new versions and components on COCOON 2. move all tickets from COCOON3 to COCOON 3. close COCOON3 WDYT? Regards. [1] http://old.nabble.com/Re%3A--C3--Import-subprojects-proposal--WAS%3A-Re%3A--c3--Log4j-injection-in-target-of-blocks--td32880500.html -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Memberhttp://people.apache.org/~ilgrosso/
Re: JIRA unification proposal
2012/1/3 Francesco Chicchiriccò ilgro...@apache.org On 03/01/2012 12:41, Simone Tripodi wrote: Hi all, and Happy New Year!! ...but yeah IMO we need to have a apply-patches phase prior to the merge, to get the outstanding patches for 2.x closed and we have a cleaner list. I am +1 on this, sounds like a more than reasonable plan! I am +1 for this as well, provided that this apply-patches phase is somehow time-constraint... +1 for the time-constraint. Like I mentioned before we can always reopen closed issues when they are being picked up later. Regards. -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
[jira] [Assigned] (COCOON-2257) Missing modCount attribute in JCR sample content
[ https://issues.apache.org/jira/browse/COCOON-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal reassigned COCOON-2257: -- Assignee: (was: Jasha Joachimsthal) Missing modCount attribute in JCR sample content Key: COCOON-2257 URL: https://issues.apache.org/jira/browse/COCOON-2257 Project: Cocoon Issue Type: Bug Components: Blocks: JCR Affects Versions: 2.1.11 Reporter: Jasha Joachimsthal Priority: Minor Fix For: 2.1.12-dev (Current SVN) The JCR sample content was probably written before the JCR-1.0 spec was released. In the final release a modCount attribute was expected in org.apache.jackrabbit.core.state.xml.XMLPersistenceManager. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (COCOON-2295) integrating FOP-1.0 into Cocoon-2.1.12-dev
[ https://issues.apache.org/jira/browse/COCOON-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal reassigned COCOON-2295: -- Assignee: (was: Jasha Joachimsthal) integrating FOP-1.0 into Cocoon-2.1.12-dev -- Key: COCOON-2295 URL: https://issues.apache.org/jira/browse/COCOON-2295 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Affects Versions: 2.1.12-dev (Current SVN) Reporter: ron van den branden Attachments: jars.patch, jars.xml Here are instructions for updating the current FOP-0.95 serializer in Cocoon-2.1.12-dev (see https://issues.apache.org/jira/browse/COCOON-2289): 1. checkout http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X 2. download (and build) FOP-1.0 from http://xmlgraphics.apache.org/fop/download.html 3. update jars in %COCOON_HOME%\lib\*: -replace %COCOON_HOME%\lib\optional\batik-all-1.6.jar with %FOP_HOME%\lib\batik-all-1.7.jar -replace %COCOON_HOME%\lib\optional\fop-0.95.jar with %FOP_HOME%\build\fop.jar -replace %COCOON_HOME%\lib\optional\xmlgraphics-commons-1.3.1.jar with %FOP_HOME%\lib\xmlgraphics-commons-1.4.jar -copy %FOP_HOME%\lib\xml-apis-ext-1.3.04.jar to %COCOON_HOME%\lib\endorsed -copy %FOP_HOME%\lib\serializer-2.7.0.jar to %COCOON_HOME%\lib\optional 4. update references to these jars in %COCOON_HOME%\lib\jars.xml (see attached file) 5. build Cocoon -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Compatibility Check Windows 7 Movares DIV-consultants
On 28 September 2011 13:23, Peter Hunsberger peter.hunsber...@gmail.comwrote: On Wed, Sep 28, 2011 at 1:14 AM, Jasha Joachimsthal j.joachimst...@onehippo.com wrote: Hi Jurgen, In short: Cocoon is not an application but a framework http://cocoon.apache.org/1363_1_1.html Jasha Joachimsthal On 27 September 2011 18:00, Derksen JEC (Jurgen) jurgen.derk...@movares.nl wrote: Dear Sir / Madam To understand the compatibility of RPC READER 3.5 Suspect this must be spam of some kind, as far as I know RPC Reader has nothing to do with Cocoon...? Second time one of these has show up, last time it was a different product. It looks like spam to me too, but we do have an RPC reader: http://cocoon.apache.org/2.1/userdocs/optional/axisrpc-reader.html Jasha
Re: Compatibility Check Windows 7 Movares DIV-consultants
Hi Jurgen, In short: Cocoon is not an application but a framework http://cocoon.apache.org/1363_1_1.html Jasha Joachimsthal Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522 4466 US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll free) www.onehippo.com On 27 September 2011 18:00, Derksen JEC (Jurgen) jurgen.derk...@movares.nlwrote: Dear Sir / Madam To understand the compatibility of ** ** RPC READER 3.5 ** ** on the Microsoft Windows 7 platform, I would like to receive some information regarding the following questions: 1. Is the application compatible with Windows 7 Enterprise? 2. Is the application compatible with Windows 7 Enterprise SP1? 3. Is the application compatible with Windows 7 Enterprise (SP1) 64-bit installation? 4. Is the application compatible with Remote Desktop Services (RDS) on Windows Server 2008 R2? 5. Is there a 64-bit version of the application available? 6. if so, what version? 7. If not, it is planned and possibly when? 8. If the application is compatible, then you recommend this application to 32 bit or 64 bit install (in case of any available 32-bit plugins, add-ons, drivers, etc.)? Thank you in advance for your help. With kind regards, Jurgen Derksen Movares Nederland B.V. Leidseveer 10 Postbus 2855 3500 GW Utrecht Tel 030-265 3144 jurgen.derk...@movares.nl www.movares.nl ** ** -- Deze e-mail en de inhoud daarvan is vertrouwelijk. Indien dit bericht niet voor u bestemd is, verzoeken wij u deze e-mail direct aan ons te retourneren en daarna te vernietigen. In dit geval is het ook niet toegestaan deze e-mail en de inhoud daarvan te gebruiken, kopieren of openbaar te maken aan derden. Onze onderneming sluit elke aansprakelijkheid uit in verband met het niet juist, onvolledig of niet tijdig overkomen van de informatie in deze e-mail. Movares Nederland B.V. / Utrecht / Kamer van Koophandel 30124367. This e-mail and its contents are confidential and may be legally privileged. If this e-mail is not intended for you, please contact us immediately by reply e-mail and destroy the e-mail. In this case, please do not use, copy or disclose the e-mail and its contents to anyone. Our company is liable neither for the proper and complete transmission of the information in this e-mail nor for any delay in its receipt. Movares Nederland B.V. / Utrecht / Chamber of Commerce 30124367. image001.gif
Re: Cocoon GetTogether?
On 19 July 2011 10:15, Thorsten Scherler scher...@gmail.com wrote: On Tue, 2011-07-19 at 08:42 +0200, Francesco Chicchiriccò wrote: On 19/07/2011 00:21, Torsten Curdt wrote: And that leads me to ask, what are the possibilities of a Cocoon GetTogether this year? next year? (The sooner the better, as far as I'm concerned!) AFAIK the last GT was in 2005? The hackathon sounded very productive. Last GT was in 2007, in Rome (I've found this old post from Jeroen Reijn [1], since the cocoongt.org domain seems to have passed to other hands... GT have always been great events but do we have enough people that would bother to come? ...and especially sponsors that see it worthwhile? Hum, unfortunately I must agree with Torsten's doubts... Maybe we can rediscuss this proposal in a few months, WDYT? There is http://barcampspain.com/ at 8 of October. I will be there and we could do some c3 work if people like to come to the south of spain. salu2 [1] http://blog.jeroenreijn.com/2007/09/cocoon-gt-2007-update.html There will also be a hackathon after GotoCon Amsterdam in the Hippo Office on October 15 :) http://wiki.apache.org/apachecon/AmsterdamHackathon2011 Jasha Joachimsthal Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522 4466 US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll free) www.onehippo.com
Re: Jira notifications
On 15 July 2011 17:34, Reinhard Pötz reinh...@apache.org wrote: Does anybody know why we don't see any JIRA notifications on the dev list anymore? -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch For security reasons infra cancelled all Jira subscriptions for (public) mailing lists. They did that around Feb 16 and notified the committers about it. Jasha Joachimsthal Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522 4466 US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll free) www.onehippo.com
Re: Improved C3 infrastructure
On 30 June 2011 17:25, Simone Tripodi simonetrip...@apache.org wrote: Hi all guys, we now have new terrific toys available for C3 :) * Sonar - https://analysis.apache.org/dashboard/index/org.apache.cocoon.root:cocoon-root * Nexus - https://repository.apache.org/content/repositories/snapshots/org/apache/cocoon/ * Jenkins - https://builds.apache.org/job/Cocoon-trunk/ See http://www.apache.org/dev/publishing-maven-artifacts.html for more infos how to configure your settings.xml to deploy on Nexus (the Jenkins job should do it for us). I already uploaded the beta-1-snapshot just to test it. Parent POM already updated, have fun!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ Well done! Trying to raise the quality percentages and lower the issues of Sonar can be addictive :) Jasha Joachimsthal Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522 4466 US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll free) www.onehippo.com
Re: Cocoon 3
On 23 June 2011 20:11, Simone Tripodi simonetrip...@apache.org wrote: Hi Michel, Thanks for your interest!!! We're releasing the Cocoon3 alpha-3, you can start playing with alpha-2 APIs in the meanwhile just to get familiar with the new approach. Check the C3[1] website to get started. And I suppose you saw svn, not cvs activities... ;) The code has been in SVN for a while, but the commit mailing list address is still c...@cocoon.apache.org Jasha Joachimsthal Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522 4466 US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll free) www.onehippo.com All the best, have a nice day!!! Simo [1] http://cocoon.apache.org/3.0/ http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Thu, Jun 23, 2011 at 7:33 PM, Michael Müller michael.muel...@mueller-bruehl.de wrote: Hello together, The latest entry for cocoon on the website I found, is dated from 2008. But in the current past, I recognised some cvs activities. Will V3 be available soon? Best, Michael
Re: [C3] replacing the logging framework
On 26 April 2011 13:24, Reinhard Pötz reinh...@apache.org wrote: On 04/23/2011 04:56 PM, Simone Tripodi wrote: Hi all guys, Reinhard, Francesco and I had a quick chat on tweeter about replacing the logging framework in C3 and we all agreed on migrating to SLF4J + Logback. IMHO it is an operation simple enough that can be completed before proceeding to next release, what does someone else think about it? If there isn't any objection, I can take easily take care of it, just let me know! I guess you're right with the pipeline and sitemap modules, but I expect it to be more difficult for the servlet module. The question _for now_ is whether we have to replace the logging framework there at all and keep the Spring configurator's log4j integration instead. Changing the servlet module to use the slf4j/log4j binding could be done later. But I'm not sure if this plan works as expected ... I think we've been waiting for the alpha-3 release long enough. Why not ship it as is and then do the logging framework changes in an alpha-4 release? Jasha Joachimsthal j.joachimst...@onehippo.com - ja...@apache.org Hippo Europe • Amsterdam • Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 522 4466 USA • Boston • 1 Broadway • Cambridge, MA 02142 • +1 877 414 4776 (toll free) www.onehippo.com • www.onehippo.org • i...@onehippo.com
[jira] Commented: (COCOON-2306) StripNameSpacesTransformer does not strip attribute namespaces
[ https://issues.apache.org/jira/browse/COCOON-2306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12932886#action_12932886 ] Jasha Joachimsthal commented on COCOON-2306: I already fixed this in the 2.1 branch. See COCOON-2228 StripNameSpacesTransformer does not strip attribute namespaces -- Key: COCOON-2306 URL: https://issues.apache.org/jira/browse/COCOON-2306 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.11 Reporter: Nico Verwer Attachments: StripNameSpacesTransformer.patch The StripNameSpacesTransformer strips namespaces only from elements, but not from attributes. This leads to an inconsistent SAX stream if the input has attributes with namespaces. The patch fixes this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2306) StripNameSpacesTransformer does not strip attribute namespaces
[ https://issues.apache.org/jira/browse/COCOON-2306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal closed COCOON-2306. -- Resolution: Duplicate Fix Version/s: 2.1.12-dev (Current SVN) Assignee: Jasha Joachimsthal StripNameSpacesTransformer does not strip attribute namespaces -- Key: COCOON-2306 URL: https://issues.apache.org/jira/browse/COCOON-2306 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.11 Reporter: Nico Verwer Assignee: Jasha Joachimsthal Fix For: 2.1.12-dev (Current SVN) Attachments: StripNameSpacesTransformer.patch The StripNameSpacesTransformer strips namespaces only from elements, but not from attributes. This leads to an inconsistent SAX stream if the input has attributes with namespaces. The patch fixes this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (COCOON-2295) integrating FOP-1.0 into Cocoon-2.1.12-dev
(AbstractCachingProcessingPipeline.java:355) ... 63 more Caused by: javax.xml.transform.TransformerException: java.lang.NullPointerException at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2405) at org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:1376) at org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:395) at org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:178) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2400) at org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(TransformerImpl.java:2270) at org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1356) at org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:3447) at org.apache.xalan.transformer.TransformerHandlerImpl.endDocument(TransformerHandlerImpl.java:408) at org.apache.cocoon.xml.AbstractXMLPipe.endDocument(AbstractXMLPipe.java:56) at org.apache.cocoon.transformation.TraxTransformer.endDocument(TraxTransformer.java:586) ... 80 more Caused by: java.lang.NullPointerException at org.apache.batik.dom.util.SAXDocumentFactory.startElement(Unknown Source) at org.apache.cocoon.components.EnvironmentChanger.startElement(EnvironmentStack.java:140) at org.apache.cocoon.components.sax.XMLTeePipe.startElement(XMLTeePipe.java:87) at org.apache.xml.serializer.ToXMLSAXHandler.closeStartTag(ToXMLSAXHandler.java:206) at org.apache.xml.serializer.ToSAXHandler.flushPending(ToSAXHandler.java:279) at org.apache.xml.serializer.ToXMLSAXHandler.startPrefixMapping(ToXMLSAXHandler.java:350) at org.apache.xml.serializer.ToXMLSAXHandler.startPrefixMapping(ToXMLSAXHandler.java:320) at org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:1317) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2400) ... 90 more Jasha Joachimsthal j.joachimst...@onehippo.com - ja...@apache.org Hippo Europe • Amsterdam Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 522 4466 USA • San Fransisco 185 H Street Suite B • Petaluma CA 94952-5100 • +1 (707) 773 4646 Canada• Montréal 5369 Boulevard St-Laurent #430 • Montréal QC H2T 1S5 • +1 (514) 316 8966 www.onehippo.com • www.onehippo.org • i...@onehippo.com On 22 September 2010 08:56, Jeremias Maerki d...@jeremias-maerki.ch wrote: Can you post the stacktrace? I may be able to help. On 27.08.2010 08:46:26 Jasha Joachimsthal wrote: With FOP 0.95 there is no problem (committed that change already in 2.1.12-dev). With FOP 1.0 and Batik 1.7 the samples in the Batik block fail if you use the SvgSerializer (nasty NPE). Jasha On 26 August 2010 11:58, Laurent Medioni lmedi...@odyssey-group.com wrote: Hi, What is your issue as we have this setup running (but in 2.1.11 with backported FOPNGSerlializer...) Thanks, Laurent -Original Message- From: Jasha Joachimsthal (JIRA) [mailto:j...@apache.org] Sent: mardi, 24. août 2010 08:22 To: dev@cocoon.apache.org Subject: [jira] Commented: (COCOON-2295) integrating FOP-1.0 into Cocoon-2.1.12-dev [ https://issues.apache.org/jira/browse/COCOON-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901743#action_12901743 ] Jasha Joachimsthal commented on COCOON-2295: Can't make the Batik block to work for JPEG/PNG serialization so won't apply this patch. integrating FOP-1.0 into Cocoon-2.1.12-dev -- Key: COCOON-2295 URL: https://issues.apache.org/jira/browse/COCOON-2295 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Affects Versions: 2.1.12-dev (Current SVN) Reporter: ron van den branden Assignee: Jasha Joachimsthal Attachments: jars.patch, jars.xml Here are instructions for updating the current FOP-0.95 serializer in Cocoon-2.1.12-dev (see https://issues.apache.org/jira/browse/COCOON-2289): 1. checkout http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X 2. download (and build) FOP-1.0 from http://xmlgraphics.apache.org/fop/download.html 3. update jars in %COCOON_HOME%\lib\*: -replace %COCOON_HOME%\lib\optional\batik-all-1.6.jar with %FOP_HOME%\lib\batik-all-1.7.jar -replace %COCOON_HOME%\lib\optional\fop-0.95.jar with %FOP_HOME%\build\fop.jar -replace %COCOON_HOME%\lib\optional\xmlgraphics-commons-1.3.1.jar with %FOP_HOME%\lib\xmlgraphics-commons-1.4.jar
Re: [jira] Commented: (COCOON-2295) integrating FOP-1.0 into Cocoon-2.1.12-dev
With FOP 0.95 there is no problem (committed that change already in 2.1.12-dev). With FOP 1.0 and Batik 1.7 the samples in the Batik block fail if you use the SvgSerializer (nasty NPE). Jasha On 26 August 2010 11:58, Laurent Medioni lmedi...@odyssey-group.com wrote: Hi, What is your issue as we have this setup running (but in 2.1.11 with backported FOPNGSerlializer...) Thanks, Laurent -Original Message- From: Jasha Joachimsthal (JIRA) [mailto:j...@apache.org] Sent: mardi, 24. août 2010 08:22 To: dev@cocoon.apache.org Subject: [jira] Commented: (COCOON-2295) integrating FOP-1.0 into Cocoon-2.1.12-dev [ https://issues.apache.org/jira/browse/COCOON-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901743#action_12901743] Jasha Joachimsthal commented on COCOON-2295: Can't make the Batik block to work for JPEG/PNG serialization so won't apply this patch. integrating FOP-1.0 into Cocoon-2.1.12-dev -- Key: COCOON-2295 URL: https://issues.apache.org/jira/browse/COCOON-2295 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Affects Versions: 2.1.12-dev (Current SVN) Reporter: ron van den branden Assignee: Jasha Joachimsthal Attachments: jars.patch, jars.xml Here are instructions for updating the current FOP-0.95 serializer in Cocoon-2.1.12-dev (see https://issues.apache.org/jira/browse/COCOON-2289): 1. checkout http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X 2. download (and build) FOP-1.0 from http://xmlgraphics.apache.org/fop/download.html 3. update jars in %COCOON_HOME%\lib\*: -replace %COCOON_HOME%\lib\optional\batik-all-1.6.jar with %FOP_HOME%\lib\batik-all-1.7.jar -replace %COCOON_HOME%\lib\optional\fop-0.95.jar with %FOP_HOME%\build\fop.jar -replace %COCOON_HOME%\lib\optional\xmlgraphics-commons-1.3.1.jar with %FOP_HOME%\lib\xmlgraphics-commons-1.4.jar -replace %COCOON_HOME%\lib\optional\xmlgraphics-commons-1.3.1.jar with %FOP_HOME%\lib\xmlgraphics-commons-1.4.jar -copy %FOP_HOME%\lib\xml-apis-ext-1.3.04.jar to %COCOON_HOME%\lib\endorsed -copy %FOP_HOME%\lib\serializer-2.7.0.jar to %COCOON_HOME%\lib\optional 4. update references to these jars in %COCOON_HOME%\lib\jars.xml (see attached file) 5. build Cocoon -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. • This email and any files transmitted with it are CONFIDENTIAL and intended solely for the use of the individual or entity to which they are addressed. • Any unauthorized copying, disclosure, or distribution of the material within this email is strictly forbidden. • Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of Odyssey Financial Technologies SA unless otherwise specifically stated. • An electronic message is not binding on its sender. Any message referring to a binding engagement must be confirmed in writing and duly signed. • If you have received this email in error, please notify the sender immediately and delete the original.
[jira] Commented: (COCOON-2295) integrating FOP-1.0 into Cocoon-2.1.12-dev
[ https://issues.apache.org/jira/browse/COCOON-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901743#action_12901743 ] Jasha Joachimsthal commented on COCOON-2295: Can't make the Batik block to work for JPEG/PNG serialization so won't apply this patch. integrating FOP-1.0 into Cocoon-2.1.12-dev -- Key: COCOON-2295 URL: https://issues.apache.org/jira/browse/COCOON-2295 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Affects Versions: 2.1.12-dev (Current SVN) Reporter: ron van den branden Assignee: Jasha Joachimsthal Attachments: jars.patch, jars.xml Here are instructions for updating the current FOP-0.95 serializer in Cocoon-2.1.12-dev (see https://issues.apache.org/jira/browse/COCOON-2289): 1. checkout http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X 2. download (and build) FOP-1.0 from http://xmlgraphics.apache.org/fop/download.html 3. update jars in %COCOON_HOME%\lib\*: -replace %COCOON_HOME%\lib\optional\batik-all-1.6.jar with %FOP_HOME%\lib\batik-all-1.7.jar -replace %COCOON_HOME%\lib\optional\fop-0.95.jar with %FOP_HOME%\build\fop.jar -replace %COCOON_HOME%\lib\optional\xmlgraphics-commons-1.3.1.jar with %FOP_HOME%\lib\xmlgraphics-commons-1.4.jar -replace %COCOON_HOME%\lib\optional\xmlgraphics-commons-1.3.1.jar with %FOP_HOME%\lib\xmlgraphics-commons-1.4.jar -copy %FOP_HOME%\lib\xml-apis-ext-1.3.04.jar to %COCOON_HOME%\lib\endorsed -copy %FOP_HOME%\lib\serializer-2.7.0.jar to %COCOON_HOME%\lib\optional 4. update references to these jars in %COCOON_HOME%\lib\jars.xml (see attached file) 5. build Cocoon -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2295) integrating FOP-1.0 into Cocoon-2.1.12-dev
[ https://issues.apache.org/jira/browse/COCOON-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12892707#action_12892707 ] Jasha Joachimsthal commented on COCOON-2295: Strange, at http://cocoon.zones.apache.org/demos/21branch/samples/blocks/batik/welcome they do work. I'll have a look at it, but not immediately. integrating FOP-1.0 into Cocoon-2.1.12-dev -- Key: COCOON-2295 URL: https://issues.apache.org/jira/browse/COCOON-2295 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Affects Versions: 2.1.12-dev (Current SVN) Reporter: ron van den branden Assignee: Jasha Joachimsthal Attachments: jars.patch, jars.xml Here are instructions for updating the current FOP-0.95 serializer in Cocoon-2.1.12-dev (see https://issues.apache.org/jira/browse/COCOON-2289): 1. checkout http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X 2. download (and build) FOP-1.0 from http://xmlgraphics.apache.org/fop/download.html 3. update jars in %COCOON_HOME%\lib\*: -replace %COCOON_HOME%\lib\optional\batik-all-1.6.jar with %FOP_HOME%\lib\batik-all-1.7.jar -replace %COCOON_HOME%\lib\optional\fop-0.95.jar with %FOP_HOME%\build\fop.jar -replace %COCOON_HOME%\lib\optional\xmlgraphics-commons-1.3.1.jar with %FOP_HOME%\lib\xmlgraphics-commons-1.4.jar -replace %COCOON_HOME%\lib\optional\xmlgraphics-commons-1.3.1.jar with %FOP_HOME%\lib\xmlgraphics-commons-1.4.jar -copy %FOP_HOME%\lib\xml-apis-ext-1.3.04.jar to %COCOON_HOME%\lib\endorsed -copy %FOP_HOME%\lib\serializer-2.7.0.jar to %COCOON_HOME%\lib\optional 4. update references to these jars in %COCOON_HOME%\lib\jars.xml (see attached file) 5. build Cocoon -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2295) integrating FOP-1.0 into Cocoon-2.1.12-dev
[ https://issues.apache.org/jira/browse/COCOON-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal updated COCOON-2295: --- Comment: was deleted (was: Strange, at http://cocoon.zones.apache.org/demos/21branch/samples/blocks/batik/welcome they do work. I'll have a look at it, but not immediately.) integrating FOP-1.0 into Cocoon-2.1.12-dev -- Key: COCOON-2295 URL: https://issues.apache.org/jira/browse/COCOON-2295 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Affects Versions: 2.1.12-dev (Current SVN) Reporter: ron van den branden Assignee: Jasha Joachimsthal Attachments: jars.patch, jars.xml Here are instructions for updating the current FOP-0.95 serializer in Cocoon-2.1.12-dev (see https://issues.apache.org/jira/browse/COCOON-2289): 1. checkout http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X 2. download (and build) FOP-1.0 from http://xmlgraphics.apache.org/fop/download.html 3. update jars in %COCOON_HOME%\lib\*: -replace %COCOON_HOME%\lib\optional\batik-all-1.6.jar with %FOP_HOME%\lib\batik-all-1.7.jar -replace %COCOON_HOME%\lib\optional\fop-0.95.jar with %FOP_HOME%\build\fop.jar -replace %COCOON_HOME%\lib\optional\xmlgraphics-commons-1.3.1.jar with %FOP_HOME%\lib\xmlgraphics-commons-1.4.jar -replace %COCOON_HOME%\lib\optional\xmlgraphics-commons-1.3.1.jar with %FOP_HOME%\lib\xmlgraphics-commons-1.4.jar -copy %FOP_HOME%\lib\xml-apis-ext-1.3.04.jar to %COCOON_HOME%\lib\endorsed -copy %FOP_HOME%\lib\serializer-2.7.0.jar to %COCOON_HOME%\lib\optional 4. update references to these jars in %COCOON_HOME%\lib\jars.xml (see attached file) 5. build Cocoon -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2295) integrating FOP-1.0 into Cocoon-2.1.12-dev
[ https://issues.apache.org/jira/browse/COCOON-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal reassigned COCOON-2295: -- Assignee: Jasha Joachimsthal integrating FOP-1.0 into Cocoon-2.1.12-dev -- Key: COCOON-2295 URL: https://issues.apache.org/jira/browse/COCOON-2295 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Affects Versions: 2.1.12-dev (Current SVN) Reporter: ron van den branden Assignee: Jasha Joachimsthal Attachments: jars.patch, jars.xml Here are instructions for updating the current FOP-0.95 serializer in Cocoon-2.1.12-dev (see https://issues.apache.org/jira/browse/COCOON-2289): 1. checkout http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X 2. download (and build) FOP-1.0 from http://xmlgraphics.apache.org/fop/download.html 3. update jars in %COCOON_HOME%\lib\*: -replace %COCOON_HOME%\lib\optional\batik-all-1.6.jar with %FOP_HOME%\lib\batik-all-1.7.jar -replace %COCOON_HOME%\lib\optional\fop-0.95.jar with %FOP_HOME%\build\fop.jar -replace %COCOON_HOME%\lib\optional\xmlgraphics-commons-1.3.1.jar with %FOP_HOME%\lib\xmlgraphics-commons-1.4.jar -replace %COCOON_HOME%\lib\optional\xmlgraphics-commons-1.3.1.jar with %FOP_HOME%\lib\xmlgraphics-commons-1.4.jar -copy %FOP_HOME%\lib\xml-apis-ext-1.3.04.jar to %COCOON_HOME%\lib\endorsed -copy %FOP_HOME%\lib\serializer-2.7.0.jar to %COCOON_HOME%\lib\optional 4. update references to these jars in %COCOON_HOME%\lib\jars.xml (see attached file) 5. build Cocoon -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2295) integrating FOP-1.0 into Cocoon-2.1.12-dev
[ https://issues.apache.org/jira/browse/COCOON-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12892416#action_12892416 ] Jasha Joachimsthal commented on COCOON-2295: The FOP upgrade works fine for the FOP block but it breaks the SVGSerializer in the Batik block. See the JPEG and PNG examples at http://localhost:/samples/blocks/batik/welcome (local build) integrating FOP-1.0 into Cocoon-2.1.12-dev -- Key: COCOON-2295 URL: https://issues.apache.org/jira/browse/COCOON-2295 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Affects Versions: 2.1.12-dev (Current SVN) Reporter: ron van den branden Assignee: Jasha Joachimsthal Attachments: jars.patch, jars.xml Here are instructions for updating the current FOP-0.95 serializer in Cocoon-2.1.12-dev (see https://issues.apache.org/jira/browse/COCOON-2289): 1. checkout http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X 2. download (and build) FOP-1.0 from http://xmlgraphics.apache.org/fop/download.html 3. update jars in %COCOON_HOME%\lib\*: -replace %COCOON_HOME%\lib\optional\batik-all-1.6.jar with %FOP_HOME%\lib\batik-all-1.7.jar -replace %COCOON_HOME%\lib\optional\fop-0.95.jar with %FOP_HOME%\build\fop.jar -replace %COCOON_HOME%\lib\optional\xmlgraphics-commons-1.3.1.jar with %FOP_HOME%\lib\xmlgraphics-commons-1.4.jar -replace %COCOON_HOME%\lib\optional\xmlgraphics-commons-1.3.1.jar with %FOP_HOME%\lib\xmlgraphics-commons-1.4.jar -copy %FOP_HOME%\lib\xml-apis-ext-1.3.04.jar to %COCOON_HOME%\lib\endorsed -copy %FOP_HOME%\lib\serializer-2.7.0.jar to %COCOON_HOME%\lib\optional 4. update references to these jars in %COCOON_HOME%\lib\jars.xml (see attached file) 5. build Cocoon -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
WebDAVTransformer: errormessage in config does not match code
In oac,transformation.WebDAVTransformer there's this block of code:
if (m_target.startsWith(WEBDAV_SCHEME)) {
m_target = HTTP_SCHEME + m_target.substring(WEBDAV_SCHEME.length());
}
else {
throw new SAXException(Illegal value for target, must be an http:// or
webdav:// URL);
}
Which means that even if your target attribute starts with http:// you get
an error message saying Illegal value for target, must be an http:// or
webdav:// URL. Shall I change the error message or add an extra check if
the target starts with http:// ?
Jasha Joachimsthal
j.joachimst...@onehippo.com - ja...@apache.org
www.onehippo.com
Amsterdam - Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466
San Francisco - Hippo USA Inc. 185 H Street, suite B, Petaluma CA 94952 +1
(707) 7734646
[jira] Assigned: (COCOON-2259) Memory leak in PoolableProxyHandler
[ https://issues.apache.org/jira/browse/COCOON-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal reassigned COCOON-2259: -- Assignee: Jasha Joachimsthal Memory leak in PoolableProxyHandler --- Key: COCOON-2259 URL: https://issues.apache.org/jira/browse/COCOON-2259 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2, 2.2-dev (Current SVN) Reporter: Alexander Daniel Assignee: Jasha Joachimsthal Attachments: patchForIssue2259.txt I reproduced the problem with following pipeline and by adding log output to PoolableProxyHandler [1] map:pipeline id=cocoonTest type=noncaching map:match pattern=cocoonProtocol map:generate src=cocoon://sub/ map:serialize type=xhtml/ /map:match map:match pattern=sub map:generate src=welcome/welcome.xml/ map:transform src=welcome/welcome.xslt/ map:serialize type=xhtml/ /map:match /map:pipeline Changing the line this.attributeName = PoolableProxyHandler.class.getName() + '/' + this.handler.hashCode(); to this.attributeName = PoolableProxyHandler.class.getName() + '/' + this.hashCode(); fixes the memory leak. Why? The PoolableFactoryBean [2] handler is a singleton for every pipeline component, i.e. one instance for noncaching pipeline, one instance for xalan transformer, ... Therefore the attributeName is the same for every component of the same type but Spring requires an unique value for the destruction callback handler. In the example sitemap above two noncaching pipeline instances are needed for processing the request. Both call registerDestructionCallback with the same attributeName. Because the attributeName is the same the callback is only called once and the other component remains in ThreadLocal. [1] http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/PoolableProxyHandler.java [2] http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/PoolableFactoryBean.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2259) Memory leak in PoolableProxyHandler
[ https://issues.apache.org/jira/browse/COCOON-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal closed COCOON-2259. -- Fix Version/s: 2.2-dev (Current SVN) Resolution: Fixed Applied the patch. Thanks for submitting it. Memory leak in PoolableProxyHandler --- Key: COCOON-2259 URL: https://issues.apache.org/jira/browse/COCOON-2259 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2, 2.2-dev (Current SVN) Reporter: Alexander Daniel Assignee: Jasha Joachimsthal Fix For: 2.2-dev (Current SVN) Attachments: patchForIssue2259.txt I reproduced the problem with following pipeline and by adding log output to PoolableProxyHandler [1] map:pipeline id=cocoonTest type=noncaching map:match pattern=cocoonProtocol map:generate src=cocoon://sub/ map:serialize type=xhtml/ /map:match map:match pattern=sub map:generate src=welcome/welcome.xml/ map:transform src=welcome/welcome.xslt/ map:serialize type=xhtml/ /map:match /map:pipeline Changing the line this.attributeName = PoolableProxyHandler.class.getName() + '/' + this.handler.hashCode(); to this.attributeName = PoolableProxyHandler.class.getName() + '/' + this.hashCode(); fixes the memory leak. Why? The PoolableFactoryBean [2] handler is a singleton for every pipeline component, i.e. one instance for noncaching pipeline, one instance for xalan transformer, ... Therefore the attributeName is the same for every component of the same type but Spring requires an unique value for the destruction callback handler. In the example sitemap above two noncaching pipeline instances are needed for processing the request. Both call registerDestructionCallback with the same attributeName. Because the attributeName is the same the callback is only called once and the other component remains in ThreadLocal. [1] http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/PoolableProxyHandler.java [2] http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/PoolableFactoryBean.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2289) [2.1] Backport FOPNGSerializer
[ https://issues.apache.org/jira/browse/COCOON-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal closed COCOON-2289. -- Fix version (Component): Parent values: Blocks: FOP(10237). Affects version (Component): Parent values: Blocks: FOP(10166). Resolution: Fixed [2.1] Backport FOPNGSerializer -- Key: COCOON-2289 URL: https://issues.apache.org/jira/browse/COCOON-2289 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Reporter: Cédric Damioli Assignee: Jasha Joachimsthal Fix For: 2.1.12-dev (Current SVN) Cocoon 2.1 still don't have official support for FOP 0.9x, while Cocoon 2.2 does This compatibility is only a matter of FOPSerializer (called FOPNGSerializer in the Cocoon 2.2 fop-ng block) I won't put a patch here because it would only be a copy of the FOPNGSerializer.java from Cocoon-2.2, but it would be great if someone could backport the fop-ng block -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-2104) [PATCH] Add base URI fixup support to XIncludeTransformer
[ https://issues.apache.org/jira/browse/COCOON-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal reassigned COCOON-2104: -- Assignee: Jasha Joachimsthal (was: Jörg Heinicke) [PATCH] Add base URI fixup support to XIncludeTransformer - Key: COCOON-2104 URL: https://issues.apache.org/jira/browse/COCOON-2104 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.11, 2.2 Reporter: Andrew Cave Assignee: Jasha Joachimsthal Priority: Minor Attachments: baseFixup-2.1-r561455.diff, baseFixup-2.2-r561499.diff As discussed at [1], the XIncludeTransformer fails to perform the base URI fixup specified in the W3C's XInclude spec [2]. The spec says that the base URIs of elements do not change when passed through a conformant XInclude processor. Meaning, xml:base attributes must be added to the result set. The reason being that relative URIs in the included document should not break; this provides a mechanism to resolve them properly. This patch results in the XIncludeTransformer adding xml:base attributes to top-level included elements. It does this only when the the base URI of the included element differs from the base URI of the parent element (meaning: for almost every case except where the included document is the current document). The XIncludeTransformer's JUnit test is also updated by this patch to reflect the fact that the resulting XML file (xinclude-result-1.xml) has an xml:base attribute added. [1] http://www.mail-archive.com/dev@cocoon.apache.org/msg52803.html [2] http://www.w3.org/TR/xinclude/#base - The Base URI Fixup section of the W3C's XInclude specification -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-2104) [PATCH] Add base URI fixup support to XIncludeTransformer
[ https://issues.apache.org/jira/browse/COCOON-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal closed COCOON-2104. -- Fix version (Component): Parent values: Components: Pipeline(10228). Affects version (Component): Parent values: Components: Pipeline(10157). Fix Version/s: 2.1.12-dev (Current SVN) 2.2-dev (Current SVN) Resolution: Fixed Thanks Andrew for the patches [PATCH] Add base URI fixup support to XIncludeTransformer - Key: COCOON-2104 URL: https://issues.apache.org/jira/browse/COCOON-2104 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.11, 2.2 Reporter: Andrew Cave Assignee: Jasha Joachimsthal Priority: Minor Fix For: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Attachments: baseFixup-2.1-r561455.diff, baseFixup-2.2-r561499.diff As discussed at [1], the XIncludeTransformer fails to perform the base URI fixup specified in the W3C's XInclude spec [2]. The spec says that the base URIs of elements do not change when passed through a conformant XInclude processor. Meaning, xml:base attributes must be added to the result set. The reason being that relative URIs in the included document should not break; this provides a mechanism to resolve them properly. This patch results in the XIncludeTransformer adding xml:base attributes to top-level included elements. It does this only when the the base URI of the included element differs from the base URI of the parent element (meaning: for almost every case except where the included document is the current document). The XIncludeTransformer's JUnit test is also updated by this patch to reflect the fact that the resulting XML file (xinclude-result-1.xml) has an xml:base attribute added. [1] http://www.mail-archive.com/dev@cocoon.apache.org/msg52803.html [2] http://www.w3.org/TR/xinclude/#base - The Base URI Fixup section of the W3C's XInclude specification -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-2289) [2.1] Backport FOPNGSerializer
[ https://issues.apache.org/jira/browse/COCOON-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal updated COCOON-2289: --- Status: On Hold (was: Open) I backported o.a.c.blocks.fop.FOPNGSerlializer from C2.2 to o.a.c.serialization.FOPSerializer in C2.1. Upgraded to FOP 0.95 and added xmlcommons-graphics. In the samples it only involved moving 1 line in the xsl-fo. If this is ok, I'll close the issue. [2.1] Backport FOPNGSerializer -- Key: COCOON-2289 URL: https://issues.apache.org/jira/browse/COCOON-2289 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Reporter: Cédric Damioli Assignee: Jasha Joachimsthal Fix For: 2.1.12-dev (Current SVN) Cocoon 2.1 still don't have official support for FOP 0.9x, while Cocoon 2.2 does This compatibility is only a matter of FOPSerializer (called FOPNGSerializer in the Cocoon 2.2 fop-ng block) I won't put a patch here because it would only be a copy of the FOPNGSerializer.java from Cocoon-2.2, but it would be great if someone could backport the fop-ng block -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-2041) WebDAV Returns improper status on PUT
[
https://issues.apache.org/jira/browse/COCOON-2041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jasha Joachimsthal closed COCOON-2041.
--
Fix Version/s: 2.1.12-dev (Current SVN)
2.2-dev (Current SVN)
Resolution: Fixed
SourceRepositoryImpl now returns a 204 instead of 200 after a PUT on an
existing resource. Thanks for spotting the bug.
WebDAV Returns improper status on PUT
-
Key: COCOON-2041
URL: https://issues.apache.org/jira/browse/COCOON-2041
Project: Cocoon
Issue Type: Bug
Components: Blocks: WebDAV
Affects Versions: 2.1.11
Reporter: Edward Riede
Fix For: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN)
on PUT, server returns the status 200 OK, when the proper response seems to
204 No Content
int the put method in webdav.js::: this:
try {
var status = repository.save(src,dest);
sendStatus(status);
}
can be changed to this:
try {
var status = repository.save(src,dest);
if(status == 200 ) status = 204;
sendStatus(status);
}
This fixed the issue in my application. However this seems a little hackish
and I haven't tested it well.
The org.apache.cocoon.components.repository.SourceRepository object might be
changed instead.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-2041) WebDAV Returns improper status on PUT
[
https://issues.apache.org/jira/browse/COCOON-2041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jasha Joachimsthal reassigned COCOON-2041:
--
Assignee: Jasha Joachimsthal
WebDAV Returns improper status on PUT
-
Key: COCOON-2041
URL: https://issues.apache.org/jira/browse/COCOON-2041
Project: Cocoon
Issue Type: Bug
Components: Blocks: WebDAV
Affects Versions: 2.1.11
Reporter: Edward Riede
Assignee: Jasha Joachimsthal
Fix For: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN)
on PUT, server returns the status 200 OK, when the proper response seems to
204 No Content
int the put method in webdav.js::: this:
try {
var status = repository.save(src,dest);
sendStatus(status);
}
can be changed to this:
try {
var status = repository.save(src,dest);
if(status == 200 ) status = 204;
sendStatus(status);
}
This fixed the issue in my application. However this seems a little hackish
and I haven't tested it well.
The org.apache.cocoon.components.repository.SourceRepository object might be
changed instead.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-2289) [2.1] Backport FOPNGSerializer
[ https://issues.apache.org/jira/browse/COCOON-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal reassigned COCOON-2289: -- Assignee: Jasha Joachimsthal [2.1] Backport FOPNGSerializer -- Key: COCOON-2289 URL: https://issues.apache.org/jira/browse/COCOON-2289 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Reporter: Cédric Damioli Assignee: Jasha Joachimsthal Fix For: 2.1.12-dev (Current SVN) Cocoon 2.1 still don't have official support for FOP 0.9x, while Cocoon 2.2 does This compatibility is only a matter of FOPSerializer (called FOPNGSerializer in the Cocoon 2.2 fop-ng block) I won't put a patch here because it would only be a copy of the FOPNGSerializer.java from Cocoon-2.2, but it would be great if someone could backport the fop-ng block -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2289) [2.1] Backport FOPNGSerializer
[ https://issues.apache.org/jira/browse/COCOON-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12855293#action_12855293 ] Jasha Joachimsthal commented on COCOON-2289: I'll try to move to fop 0.95 this weekend. [2.1] Backport FOPNGSerializer -- Key: COCOON-2289 URL: https://issues.apache.org/jira/browse/COCOON-2289 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Reporter: Cédric Damioli Assignee: Jasha Joachimsthal Fix For: 2.1.12-dev (Current SVN) Cocoon 2.1 still don't have official support for FOP 0.9x, while Cocoon 2.2 does This compatibility is only a matter of FOPSerializer (called FOPNGSerializer in the Cocoon 2.2 fop-ng block) I won't put a patch here because it would only be a copy of the FOPNGSerializer.java from Cocoon-2.2, but it would be great if someone could backport the fop-ng block -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2289) [2.1] Backport FOPNGSerializer
[ https://issues.apache.org/jira/browse/COCOON-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854420#action_12854420 ] Jasha Joachimsthal commented on COCOON-2289: The 2.1 branch is more or less in maintenance mode. If you start a new project, use Cocoon 2.2 which does contain the new FOP block. [2.1] Backport FOPNGSerializer -- Key: COCOON-2289 URL: https://issues.apache.org/jira/browse/COCOON-2289 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Reporter: Cédric Damioli Fix For: 2.1.12-dev (Current SVN) Cocoon 2.1 still don't have official support for FOP 0.9x, while Cocoon 2.2 does This compatibility is only a matter of FOPSerializer (called FOPNGSerializer in the Cocoon 2.2 fop-ng block) I won't put a patch here because it would only be a copy of the FOPNGSerializer.java from Cocoon-2.2, but it would be great if someone could backport the fop-ng block -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2289) [2.1] Backport FOPNGSerializer
[ https://issues.apache.org/jira/browse/COCOON-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854460#action_12854460 ] Jasha Joachimsthal commented on COCOON-2289: I know there are still a lot of 2.1 projects, I've been working on one the whole day. :-) IMHO, no new Cocoon 2.1 project would be happy with FOP 0.20 made me think he was starting a new Cocoon project. [2.1] Backport FOPNGSerializer -- Key: COCOON-2289 URL: https://issues.apache.org/jira/browse/COCOON-2289 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Reporter: Cédric Damioli Fix For: 2.1.12-dev (Current SVN) Cocoon 2.1 still don't have official support for FOP 0.9x, while Cocoon 2.2 does This compatibility is only a matter of FOPSerializer (called FOPNGSerializer in the Cocoon 2.2 fop-ng block) I won't put a patch here because it would only be a copy of the FOPNGSerializer.java from Cocoon-2.2, but it would be great if someone could backport the fop-ng block -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2289) [2.1] Backport FOPNGSerializer
[ https://issues.apache.org/jira/browse/COCOON-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854533#action_12854533 ] Jasha Joachimsthal commented on COCOON-2289: Please do, I'm not the only one with an opinion. [2.1] Backport FOPNGSerializer -- Key: COCOON-2289 URL: https://issues.apache.org/jira/browse/COCOON-2289 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Reporter: Cédric Damioli Fix For: 2.1.12-dev (Current SVN) Cocoon 2.1 still don't have official support for FOP 0.9x, while Cocoon 2.2 does This compatibility is only a matter of FOPSerializer (called FOPNGSerializer in the Cocoon 2.2 fop-ng block) I won't put a patch here because it would only be a copy of the FOPNGSerializer.java from Cocoon-2.2, but it would be great if someone could backport the fop-ng block -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2289) [2.1] Backport FOPNGSerializer
[ https://issues.apache.org/jira/browse/COCOON-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854571#action_12854571 ] Jasha Joachimsthal commented on COCOON-2289: BTW, I'm happy to see you put effort in improving Cocoon [2.1] Backport FOPNGSerializer -- Key: COCOON-2289 URL: https://issues.apache.org/jira/browse/COCOON-2289 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Reporter: Cédric Damioli Fix For: 2.1.12-dev (Current SVN) Cocoon 2.1 still don't have official support for FOP 0.9x, while Cocoon 2.2 does This compatibility is only a matter of FOPSerializer (called FOPNGSerializer in the Cocoon 2.2 fop-ng block) I won't put a patch here because it would only be a copy of the FOPNGSerializer.java from Cocoon-2.2, but it would be great if someone could backport the fop-ng block -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2288) Allow usage of SLF4J for traces
[ https://issues.apache.org/jira/browse/COCOON-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12853882#action_12853882 ] Jasha Joachimsthal commented on COCOON-2288: Cédric, which version of slf4j-api.jar did you use? Allow usage of SLF4J for traces --- Key: COCOON-2288 URL: https://issues.apache.org/jira/browse/COCOON-2288 Project: Cocoon Issue Type: New Feature Components: * Cocoon Core Reporter: Cédric Damioli Fix For: 2.1.12-dev (Current SVN) Attachments: SLF4JLogger.java, SLF4JLoggerManager.java Attached are two classes allowing to use SLF4J as logging facade inside Cocoon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2289) [2.1] Backport FOPNGSerializer
[ https://issues.apache.org/jira/browse/COCOON-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854067#action_12854067 ] Jasha Joachimsthal commented on COCOON-2289: It goes a bit further than just copying the FOPNGSerializer.java. Especially the conflicting fop dependency. In 2.2 this is easier because of the modular maven setup. The bluid process of 2.1 is more complex. [2.1] Backport FOPNGSerializer -- Key: COCOON-2289 URL: https://issues.apache.org/jira/browse/COCOON-2289 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Reporter: Cédric Damioli Fix For: 2.1.12-dev (Current SVN) Cocoon 2.1 still don't have official support for FOP 0.9x, while Cocoon 2.2 does This compatibility is only a matter of FOPSerializer (called FOPNGSerializer in the Cocoon 2.2 fop-ng block) I won't put a patch here because it would only be a copy of the FOPNGSerializer.java from Cocoon-2.2, but it would be great if someone could backport the fop-ng block -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2289) [2.1] Backport FOPNGSerializer
[ https://issues.apache.org/jira/browse/COCOON-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854117#action_12854117 ] Jasha Joachimsthal commented on COCOON-2289: I tried adding them both but that resulted in compilation errors. [2.1] Backport FOPNGSerializer -- Key: COCOON-2289 URL: https://issues.apache.org/jira/browse/COCOON-2289 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Reporter: Cédric Damioli Fix For: 2.1.12-dev (Current SVN) Cocoon 2.1 still don't have official support for FOP 0.9x, while Cocoon 2.2 does This compatibility is only a matter of FOPSerializer (called FOPNGSerializer in the Cocoon 2.2 fop-ng block) I won't put a patch here because it would only be a copy of the FOPNGSerializer.java from Cocoon-2.2, but it would be great if someone could backport the fop-ng block -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2278) Make SOAPHelper use https, not just http
[ https://issues.apache.org/jira/browse/COCOON-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal reassigned COCOON-2278: -- Assignee: Jasha Joachimsthal Make SOAPHelper use https, not just http Key: COCOON-2278 URL: https://issues.apache.org/jira/browse/COCOON-2278 Project: Cocoon Issue Type: Improvement Components: Blocks: XSP Affects Versions: 2.1.11 Reporter: Nico Verwer Assignee: Jasha Joachimsthal Attachments: SOAPHelper.patch The current SOAPHelper class in the XSP block only speaks http to webservices. With a small addition, it respects the protocol specified by, e.g., a WSDL file. Many webservices use https, which works with this patch for the SOAPHelper. Other protocols work if there is a protocol factory configured. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2278) Make SOAPHelper use https, not just http
[ https://issues.apache.org/jira/browse/COCOON-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal closed COCOON-2278. -- Resolution: Fixed Fix Version/s: 2.1.12-dev (Current SVN) Thanks Nico for the patch. Note: in HttpClient 3 HttpConnection(proxyHost, proxyPort, host, virtualHost, port, protocol); will be deprecated, use HttpConnection(proxyHost, proxyPort, host, port, protocol); (which is unavailable in HttpClient 2). Make SOAPHelper use https, not just http Key: COCOON-2278 URL: https://issues.apache.org/jira/browse/COCOON-2278 Project: Cocoon Issue Type: Improvement Components: Blocks: XSP Affects Versions: 2.1.11 Reporter: Nico Verwer Assignee: Jasha Joachimsthal Fix For: 2.1.12-dev (Current SVN) Attachments: SOAPHelper.patch The current SOAPHelper class in the XSP block only speaks http to webservices. With a small addition, it respects the protocol specified by, e.g., a WSDL file. Many webservices use https, which works with this patch for the SOAPHelper. Other protocols work if there is a protocol factory configured. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2250) Wrong error message in Element.java (jx:element)
[ https://issues.apache.org/jira/browse/COCOON-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal closed COCOON-2250. -- Resolution: Fixed Affects version (Component): Parent values: Blocks: Template(10171). Fix version (Component): Parent values: Blocks: Template(10243). Thanks for spotting the incorrect message. I've committed the fix. Wrong error message in Element.java (jx:element) Key: COCOON-2250 URL: https://issues.apache.org/jira/browse/COCOON-2250 Project: Cocoon Issue Type: Bug Components: Blocks: Templating Affects Versions: 2.2-dev (Current SVN) Reporter: Benjamin Boksa Priority: Minor Fix For: 2.2-dev (Current SVN) Attachments: Element.java.patch the error-message says prefix 'namespace' instead of prefix 'uri', a patch that fixes that is attached. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: New release of the xml subproject
2009/12/14 Reinhard Pötz reinh...@apache.org: Carsten Ziegeler wrote: Hi, I just fixed COCOON-2274 (https://issues.apache.org/jira/browse/COCOON-2274) which adds the license and notice files into the jar and fixes some OSGi header information. I would like to do a new release. Any comments/objections? I was thinking the same when I saw Jukka's issue. Go ahead! Maybe a bit late (lagging with my emails) but there's no fix version in Jira for this issue. Jasha
[jira] Commented: (COCOON-2270) Cocoon fails to find files when deployed into a directory containing a '#' character
[
https://issues.apache.org/jira/browse/COCOON-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12773532#action_12773532
]
Jasha Joachimsthal commented on COCOON-2270:
Characters like # and ? are special. The sourceresolver tries to create a uri
of your path and therefore stops at the # character.
Cocoon fails to find files when deployed into a directory containing a '#'
character
Key: COCOON-2270
URL: https://issues.apache.org/jira/browse/COCOON-2270
Project: Cocoon
Issue Type: Bug
Components: - Components: Sitemap
Affects Versions: 2.1.11
Reporter: Christopher Schultz
I have been using Cocoon 2.1.10 and 2.1.11 for quite some time with a handful
of modest pipelines using XSLTs on the local disk.
Recently, I've been building a development server to be shared among several
developers on our team. In order to share HTTP ports and URL spaces, we've
chosen to use URL spaces like /[username]/[appname] rather than simply
/[appname] as we've used in the past.
We use Apache Tomcat 5.5 as our app server, and the proper way to deploy a
web application with a / in its context name is to use either a WAR file such
as [username]#[appname].war, or a directory with the same name (minus the
.war, of course).
When we do this, we find that Cocoon gets tripped-up, apparently confused by
the # symbol in the path name. It can't find our templates on the disk
(maybe?) and it's also failing to find its own exception2html.xslt file.
Cocoon has been deployed into this directory:
/home/cschultz/projects/cocoon/app/webapps/cschultz#chadis
Our top-level sitemap has the default exception handler configuration:
map:handle-errors
map:select type=exception
map:when test=not-found
map:generate type=exception/
map:transform src=stylesheets/system/exception2html.xslt
map:parameter name=contextPath value={request:contextPath}/
map:parameter name=realPath value={realpath:}/
map:parameter name=pageTitle value=Resource not found/
/map:transform
map:serialize status-code=404/
/map:when
map:when test=invalid-continuation
map:generate type=exception/
map:transform src=stylesheets/system/exception2html.xslt
map:parameter name=contextPath value={request:contextPath}/
map:parameter name=realPath value={realpath:}/
map:parameter name=pageTitle value=Invalid Continuation/
/map:transform
map:serialize status-code=404/
/map:when
map:otherwise
map:generate type=exception/
map:transform src=stylesheets/system/exception2html.xslt
map:parameter name=contextPath value={request:contextPath}/
map:parameter name=realPath value={realpath:}/
/map:transform
map:serialize status-code=500/
/map:otherwise
/map:select
/map:handle-errors
When we try to execute our transformers, we get the following error:
Message:
/home/cschultz/.webapps/cocoon/8225/webapps/stylesheets/system/exception2html.xslt
(No such file or directory)
If you notice, this path is not correct. It should be:
/home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/stylesheets/system/exception2html.xslt
Note that the path element after webapps has been removed.
I have tried changing the path to the exception stylesheet in the top-level
sitemap to:
map:transform
src=/home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/stylesheets/system/exception2html.xslt
But this results in the following error:
Message: /home/cschultz/.webapps/cocoon/8225/webapps/cschultz (No such file
or directory)
Note the path is truncated at the '#' symbol.
Finally, I tried changing the path to:
map:transform
src=/home/cschultz/.webapps/cocoon/8225/webapps/cschultz%23chadis/stylesheets/system/exception2html.xslt
Message: Did not find the stylesheet root!
Description: org.apache.cocoon.ProcessingException: Unable to get transformer
handler for
file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/stylesheets/system/exception2html.xslt
at map:serialize -
file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/sitemap.xmap:736:45
at map:transform -
file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/sitemap.xmap:731:133
at map:generate type=exception -
file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis/sitemap.xmap:730:43
full exception chain stacktrace
org.apache.cocoon.ProcessingException: Unable to get transformer handler for
file:///home/cschultz/.webapps/cocoon/8225/webapps/cschultz#chadis
[jira] Reopened: (COCOON-2228) StripNameSpacesTransformer does not strip namespace prefix of attributes
[ https://issues.apache.org/jira/browse/COCOON-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal reopened COCOON-2228: Patch only worked with 1 attribute. StripNameSpacesTransformer does not strip namespace prefix of attributes Key: COCOON-2228 URL: https://issues.apache.org/jira/browse/COCOON-2228 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.11 Reporter: Jasha Joachimsthal Assignee: Jasha Joachimsthal Priority: Minor Fix For: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Attachments: StripNameSpacesTransformer-Attributes.diff -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2228) StripNameSpacesTransformer does not strip namespace prefix of attributes
[ https://issues.apache.org/jira/browse/COCOON-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal closed COCOON-2228. -- Resolution: Fixed StripNameSpacesTransformer does not strip namespace prefix of attributes Key: COCOON-2228 URL: https://issues.apache.org/jira/browse/COCOON-2228 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.11 Reporter: Jasha Joachimsthal Assignee: Jasha Joachimsthal Priority: Minor Fix For: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Attachments: StripNameSpacesTransformer-Attributes.diff -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [c3 monitoring] Cache overview
2009/7/27 Dariusz Łuksza dariusz.luk...@gmail.com On Mon, Jul 27, 2009 at 4:18 PM, Reinhard Pötzreinh...@apache.org wrote: Dariusz Łuksza wrote: 2009/7/24 Dariusz Łuksza dariusz.luk...@gmail.com: Thanks for that tip I'll look on this ASAP ;) For our needs every pipeline should have an id parameter, from one hand it is very good solution because we get simple way how to divide and present cache entry's on JMX and on the other hand I'm not quite sure that we can require that parameter for every pipeline and user even if he don't use monitoring module What do you think ? There is also third solution ... pipeline id parameter can be optional and we'll publish on JMX _only_ that cache entry's that belongs to pipeline that have set id parameter. This approach gives us additional configuration options and can reduce amount of data published on JMX. IMHO this is the best solution right now. +1 And here it is: https://issues.apache.org/jira/secure/attachment/12414657/cache-overview-part3-cache-entrys.patch What operation (besides: getValue() and getSize()), would be useful for every cache entry ? getCacheKey() (mostly to print it for debugging). Jasha -- Best regards Blog: http://luksza.org LinkedIn: http://www.linkedin.com/in/dariuszluksza
[jira] Issue Comment Edited: (COCOON-2257) Missing modCount attribute in JCR sample content
[ https://issues.apache.org/jira/browse/COCOON-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12705424#action_12705424 ] Jasha Joachimsthal edited comment on COCOON-2257 at 5/3/09 8:14 AM: Added modCount to sample content. Sample is still not working 100% but at least Cocoon is able to run. was (Author: jashajoachimsthal): Added modCount to sample content. Sample is still not working 100% Missing modCount attribute in JCR sample content Key: COCOON-2257 URL: https://issues.apache.org/jira/browse/COCOON-2257 Project: Cocoon Issue Type: Bug Components: Blocks: JCR Affects Versions: 2.1.11 Reporter: Jasha Joachimsthal Assignee: Jasha Joachimsthal Priority: Minor Fix For: 2.1.12-dev (Current SVN) The JCR sample content was probably written before the JCR-1.0 spec was released. In the final release a modCount attribute was expected in org.apache.jackrabbit.core.state.xml.XMLPersistenceManager. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2257) Missing modCount attribute in JCR sample content
[ https://issues.apache.org/jira/browse/COCOON-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12705424#action_12705424 ] Jasha Joachimsthal commented on COCOON-2257: Added modCount to sample content. Sample is still not working 100% Missing modCount attribute in JCR sample content Key: COCOON-2257 URL: https://issues.apache.org/jira/browse/COCOON-2257 Project: Cocoon Issue Type: Bug Components: Blocks: JCR Affects Versions: 2.1.11 Reporter: Jasha Joachimsthal Assignee: Jasha Joachimsthal Priority: Minor Fix For: 2.1.12-dev (Current SVN) The JCR sample content was probably written before the JCR-1.0 spec was released. In the final release a modCount attribute was expected in org.apache.jackrabbit.core.state.xml.XMLPersistenceManager. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2257) Missing modCount attribute in JCR sample content
Missing modCount attribute in JCR sample content Key: COCOON-2257 URL: https://issues.apache.org/jira/browse/COCOON-2257 Project: Cocoon Issue Type: Bug Components: Blocks: JCR Affects Versions: 2.1.11 Reporter: Jasha Joachimsthal Assignee: Jasha Joachimsthal Priority: Minor Fix For: 2.1.12-dev (Current SVN) The JCR sample content was probably written before the JCR-1.0 spec was released. In the final release a modCount attribute was expected in org.apache.jackrabbit.core.state.xml.XMLPersistenceManager. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Already in Amsterdam
I'm attending that one too :-) Jasha 2009/3/23 Jeroen Reijn j.re...@onehippo.com I'm going to attend the Maven meetup. Let's hope there is something interesting too see :-) Jeroen Grzegorz Kossakowski wrote: Jeroen Reijn pisze: I will attend the meetups this evening and tomorrow evening. And perhaps be at there tomorrow morning. I have not been that devoted to the project the last couple of months, but am interesting in meeting some old friends :-) Hi Jeroen, Which Meetup are planning to attend today?
RE: Problem with Cocoon Streaming of an internal pipeline is not possible with a reader
-Original Message- From: Sandy_Java [mailto:[EMAIL PROTECTED] Sent: donderdag 9 oktober 2008 11:08 To: dev@cocoon.apache.org Subject: Problem with Cocoon Streaming of an internal pipeline is not possible with a reader Hello Friends, I am new to this Forum. I was searching for some help to work with Apache Cocoon frame work. Amazingly, I found this forum. Please find the description below. I have an error working with Cocoon frame work. I am trying to get a .HTM file from the Database and trying to display it on the browser. In my sitemap.xmp, I am using map:read to do achieve this as follows. map:read mime-type=file_type src=blob:/DataSource/Table_Name/Column_name[PK='pk']/ File types '.gif', '.txt' and '.html'are displaying properly. But a '.htm' file is not displayed and shows the following error. org.apache.cocoon.ProcessingException: Streaming of an internal pipeline is not possible with a reader I am totally new to Cocoon framework and also XSLT. Any help would be greatly appreciable. Please help me. Thanks in Advance. Regards, Sandeep. Hi Sandeep, This is more a question for the Cocoon user list. You can't use an internal pipeline with a reader because it doesn't generate a SAX events. You have to use a pipeline that uses a generator (0+ transformers) and a serializer if you want to use it as starting point for a different pipeline. Jasha Joachimsthal [EMAIL PROTECTED] - [EMAIL PROTECTED] www.onehippo.com Amsterdam - Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466 San Francisco - Hippo USA Inc. 101 H Street, suite Q Petaluma CA 94952-3329 +1 (707) 773-4646
RE: 2.2 samples down
-Original Message- From: Grzegorz Kossakowski [mailto:[EMAIL PROTECTED] Sent: woensdag 1 oktober 2008 23:43 To: dev@cocoon.apache.org Subject: Re: 2.2 samples down Grzegorz Kossakowski pisze: Jasha Joachimsthal pisze: Hi there, the samples of 2.2 are (still) down [1]. Does anyone know how to bring them up again? [1] http://cocoon.zones.apache.org/demos/trunk/ Logs[2] do not reveal anything trivial so I guess this might be caused by my last activity on zone related to upgrade of Maven to 2.0.9 and Java to 1.5. [2] http://cocoon.zones.apache.org/logs/cocoon-demos/trunk/ I may have a look today's night or tomorrow. Found the cause - Maven starts jetty using wrong (default) port number, see the last line of the log[3]: 2008-10-01 16:11:14.548::INFO: Started [EMAIL PROTECTED]: After quick testing at my local computer it looks like settings from MAVEN_OPTS environment variable are not propagated to jetty:run plug-in. In order to test it try: cd core/cocoon-webapp export MAVEN_OPTS=-Djetty.port=8123 mvn jetty:run and check at which port jetty listens. If it's not 8123 then we have found a bug and we should report it to Maven team. If anyone confirms this problem I'll introduce temporary fix so our demos are online again. [3] http://cocoon.zones.apache.org/logs/cocoon-demos/trunk/stderr.log PS. If someone else could take care of it I would be grateful. I don't have any reliable internet connection in my new flat now. I just tried to start up the My first block with mvn -Djetty.port=8123 jetty:run but it still uses port . Only when I comment the connectors part in the pom.xml it listens to port 8123. So I think the configuration in the pom overrides the commandline port. Jasha Joachimsthal [EMAIL PROTECTED] - [EMAIL PROTECTED] www.onehippo.com Amsterdam - Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466 San Francisco - Hippo USA Inc. 101 H Street, suite Q Petaluma CA 94952-3329 +1 (707) 773-4646
RE: 2.2 samples down
-Original Message- From: Grzegorz Kossakowski [mailto:[EMAIL PROTECTED] Sent: donderdag 2 oktober 2008 11:21 To: dev@cocoon.apache.org Subject: Re: 2.2 samples down Jasha Joachimsthal wrote: I just tried to start up the My first block with mvn -Djetty.port=8123 jetty:run but it still uses port . This is weird. For me this worked yesterday. Only when setting jetty.port using MAVEN_OPTS Maven ignored that setting. Only when I comment the connectors part in the pom.xml it listens to port 8123. So I think the configuration in the pom overrides the commandline port. Which should be the opposite way. What version of Maven and jetty plugin do you use? Maven 2.0.9, jetty-plugin 6.1.7, Java 5 in Windows XP Jasha
2.2 samples down
Hi there, the samples of 2.2 are (still) down [1]. Does anyone know how to bring them up again? [1] http://cocoon.zones.apache.org/demos/trunk/ Jasha Joachimsthal [EMAIL PROTECTED] - [EMAIL PROTECTED] www.onehippo.com http://www.onehippo.com/ Amsterdam - Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466 San Francisco - Hippo USA Inc. 101 H Street, suite Q Petaluma CA 94952-3329 +1 (707) 773-4646
[jira] Assigned: (COCOON-2228) StripNameSpacesTransformer does not strip namespace prefix of attributes
[ https://issues.apache.org/jira/browse/COCOON-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal reassigned COCOON-2228: -- Assignee: Jasha Joachimsthal StripNameSpacesTransformer does not strip namespace prefix of attributes Key: COCOON-2228 URL: https://issues.apache.org/jira/browse/COCOON-2228 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.11 Reporter: Jasha Joachimsthal Assignee: Jasha Joachimsthal Priority: Minor Fix For: 2.1.12-dev (Current SVN) Attachments: StripNameSpacesTransformer-Attributes.diff -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: Jira karma
-Original Message- From: David Crossley [mailto:[EMAIL PROTECTED] Sent: dinsdag 26 augustus 2008 2:45 To: dev@cocoon.apache.org Subject: Re: Jira karma Jasha Joachimsthal wrote: could someone please give me more karma in Jira so I can assign issues to myself en resolve them? Done. Thanks :) I can bulk assign issues if you want :-) Also added Luca, Steven, David, Andreas. -David
Component versioning in JIRA
Good morning, I tried to close two issues but couldn't find the right fix version for the mail-block and the pipeline component. Shouldn't there be a 1.1.0 fix version? Jasha Joachimsthal www.onehippo.com http://www.onehippo.com/ Amsterdam - Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466 San Francisco - Hippo USA Inc. 101 H Street, suite Q Petaluma CA 94952-3329 +1 (707) 773-4646
[jira] Closed: (COCOON-2213) Change check on mime-type to enable custom encoding of the body
[ https://issues.apache.org/jira/browse/COCOON-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal closed COCOON-2213. -- Resolution: Fixed Affects version (Component): Parent values: Blocks: Mail(10170). Level 1 values: 1.0.0(10394). Fix version (Component): Parent values: Blocks: Mail(10242). Level 1 values: 1.1.0-SNAPSHOT(10401). Change check on mime-type to enable custom encoding of the body --- Key: COCOON-2213 URL: https://issues.apache.org/jira/browse/COCOON-2213 Project: Cocoon Issue Type: Improvement Components: Blocks: Mail Affects Versions: 2.1.11, 2.2-dev (Current SVN) Reporter: Jasha Joachimsthal Assignee: Alfred Nathaniel Priority: Minor Fix For: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Attachments: SendMailTransformer-plaintext.patch, SendMailTransformer_mime-type.patch Since the patch in COCOON-1622 was applied, a check is done on the mime-type for the output format. It checks if the value is equal to either text/plain or text/html. It may be necessary to explicitly set a charset in the mime-type. This means the check for the mime type should not equals but startsWith. COCOON-1622 seems to be only applied in the 2.1 branch, not in 2.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2228) StripNameSpacesTransformer does not strip namespace prefix of attributes
[ https://issues.apache.org/jira/browse/COCOON-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal closed COCOON-2228. -- Resolution: Fixed Fix Version/s: 2.2-dev (Current SVN) Affects version (Component): Parent values: Components: Pipeline(10157). Level 1 values: 1.0.0(10382). Fix version (Component): Parent values: Components: Pipeline(10228). Level 1 values: 1.1.0-SNAPSHOT(10403). StripNameSpacesTransformer does not strip namespace prefix of attributes Key: COCOON-2228 URL: https://issues.apache.org/jira/browse/COCOON-2228 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.11 Reporter: Jasha Joachimsthal Assignee: Jasha Joachimsthal Priority: Minor Fix For: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Attachments: StripNameSpacesTransformer-Attributes.diff -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Jira karma
Hi there, could someone please give me more karma in Jira so I can assign issues to myself en resolve them? Thanks, Jasha
[jira] Updated: (COCOON-2213) Change check on mime-type to enable custom encoding of the body
[ https://issues.apache.org/jira/browse/COCOON-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal updated COCOON-2213: --- Attachment: SendMailTransformer-plaintext.patch Seems like one code changes breaks setting a charset on plain/text mails. I couldn't find your change in one of the patches for this issue or COCOON-1622. Created a patch to revert this. Change check on mime-type to enable custom encoding of the body --- Key: COCOON-2213 URL: https://issues.apache.org/jira/browse/COCOON-2213 Project: Cocoon Issue Type: Improvement Components: Blocks: Mail Affects Versions: 2.1.11 Reporter: Jasha Joachimsthal Assignee: Alfred Nathaniel Priority: Minor Fix For: 2.1.12-dev (Current SVN) Attachments: SendMailTransformer-plaintext.patch, SendMailTransformer_mime-type.patch Since the patch in COCOON-1622 was applied, a check is done on the mime-type for the output format. It checks if the value is equal to either text/plain or text/html. It may be necessary to explicitly set a charset in the mime-type. This means the check for the mime type should not equals but startsWith. COCOON-1622 seems to be only applied in the 2.1 branch, not in 2.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2213) Change check on mime-type to enable custom encoding of the body
[ https://issues.apache.org/jira/browse/COCOON-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal updated COCOON-2213: --- Fix Version/s: 2.2-dev (Current SVN) Affects Version/s: 2.2-dev (Current SVN) Change check on mime-type to enable custom encoding of the body --- Key: COCOON-2213 URL: https://issues.apache.org/jira/browse/COCOON-2213 Project: Cocoon Issue Type: Improvement Components: Blocks: Mail Affects Versions: 2.1.11, 2.2-dev (Current SVN) Reporter: Jasha Joachimsthal Assignee: Alfred Nathaniel Priority: Minor Fix For: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Attachments: SendMailTransformer-plaintext.patch, SendMailTransformer_mime-type.patch Since the patch in COCOON-1622 was applied, a check is done on the mime-type for the output format. It checks if the value is equal to either text/plain or text/html. It may be necessary to explicitly set a charset in the mime-type. This means the check for the mime type should not equals but startsWith. COCOON-1622 seems to be only applied in the 2.1 branch, not in 2.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: [vote] Cocoon 3.0
-Original Message- From: Reinhard Pötz [mailto:[EMAIL PROTECTED] Sent: woensdag 6 augustus 2008 13:20 To: dev@cocoon.apache.org Subject: [vote] Cocoon 3.0 Following the result of our recent discussion about the future of Corona, I propose Corona to become Cocoon 3. This means that any reference on Corona in source files, package names, artifact ids, group ids or anywhere else will be dropped and the standard Cocoon namespace org.apache.cocoon will be used. +1 Jasha Joachimsthal www.onehippo.com Amsterdam - Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466 San Francisco - Hippo USA Inc. 101 H Street, suite Q Petaluma CA 94952-3329 +1 (707) 773-4646
RE: [vote] Java 1.5 as minimal requirement for trunk
-Original Message- From: Grzegorz Kossakowski [mailto:[EMAIL PROTECTED] Sent: dinsdag 5 augustus 2008 15:08 To: Cocoon's dev mailing list Subject: [vote] Java 1.5 as minimal requirement for trunk Hello, As discussed in thread Cocoon-jms-sample requires Java = 1.5[1] there are more and more problems with keeping Java 1.4 compatibility in trunk. After a while it turned out that everybody agrees on the need for dropping Java 1.4 compatibility and in that case, switching to Java 1.5 as minimal required version seems to be the best solution. In order to do that, we need a formal vote that I'm calling now. Please cast your votes: +1 Jasha Joachimsthal www.onehippo.com Amsterdam - Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466 San Francisco - Hippo USA Inc. 101 H Street, suite Q Petaluma CA 94952-3329 +1 (707) 773-4646
RE: [Vote] Jasha Joachimsthal as new Cocoon committer
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Savory Sent: dinsdag 5 augustus 2008 6:09 To: dev@cocoon.apache.org Subject: Re: [Vote] Jasha Joachimsthal as new Cocoon committer Hi, 2008/7/29 Andrew Savory [EMAIL PROTECTED]: It's my pleasure to propose Jasha Joachimsthal as a new committer on the Apache Cocoon project. During the time period there were no negative votes, and more than 3 positive votes. So Jasha, welcome as a new Apache Cocoon committer! Hi there, I'm still smiling behind my desk and that's not only because of the champagne. Thank you all for embracing me as a new committer. Something about myself for those who haven't met me yet. I'm 29 years old and live in Utrecht (Netherlands). I studied Business IT at Twente University for a few years. In my previous job at a tour operator one of my tasks was to maintain websites (written in PHP and ASP, wish I knew Cocoon back then). In 2006 I started at Hippo which meant my first contact with Cocoon. Before I finished my coffee Arjé subscribed me to the cocoon-users and cocoon-dev lists, forgetting to subscribe me to Hippo mailinglists ;) Once I got to know Cocoon better I really liked it. Transforming any datasource into any format can be very handy and that's what Cocoon is good at. However the learning curve of Cocoon is a bit steep. You have to learn the pipeline concept and in most cases XSLT. A new colleague lately said I've never seen so much XML on one single day. Explaining stuff to colleagues, giving courses to external developers and replying to the Cocoon mailing lists still surprise me how much I've learnt about Cocoon. As Andrew already mentioned I did Cocoon talks at the past GetTogether in Rome and ApacheCon 2007 in Amsterdam (with Jeroen Reijn). It's always nice to be at such conferences, meeting the people behind the emails on the lists. I hoop to see you in the future! Jasha Joachimsthal www.onehippo.com Amsterdam - Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466 San Francisco - Hippo USA Inc. 101 H Street, suite Q Petaluma CA 94952-3329 +1 (707) 773-4646
RE: Find a new name for Corona (was: [proposal] Corona: A Cocoon subproject)
-Original Message- From: Reinhard Pötz [mailto:[EMAIL PROTECTED] Sent: woensdag 30 juli 2008 7:46 To: dev@cocoon.apache.org Subject: Find a new name for Corona (was: [proposal] Corona: A Cocoon subproject) The USA spelling might be better: Fiber. ok, that's much better IMO. Provided that we are allowed to have a subproject without Cocoon in the name, the current list of suggested names includes: . Apache Cocoon Fiber . Apache Cocoon Silk . Apache Fiber . Apache Silk Any other suggestions? Fiber returns many IT related hits in search engines. While Silk gives almost none (except [1], who did that graphical design?). So if you're developing with/for Corona and you're looking for information or help, Silk may be better. You may get lost in all results for Fiber which are unrelated to this project. Just my €0.02. [1] http://www.silkproject.org/ Jasha Joachimsthal www.onehippo.com Amsterdam - Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466 San Francisco - Hippo USA Inc. 101 H Street, suite Q Petaluma CA 94952-3329 +1 (707) 773-4646
RE: Webdav and link-rewrite
-Original Message- From: Reinhard Pötz [mailto:[EMAIL PROTECTED] Sent: woensdag 30 juli 2008 13:29 To: dev@cocoon.apache.org Subject: Webdav and link-rewrite Apart from the link-rewrite block he will also migrate the webdav block. Any thoughts or recommendations on this? The plan is that all Avalon components are migrated to Spring and that Jackrabbit is used as webdav server. I remember Jasha and Jereon have started to work on this in Rome last year. Any comments from you? Jeroen has looked further at the WebDAV block after the Rome GT. The problem was the imcompatibility between HttpClient 2 (used in Slide) and HttpClient 3 (used in the WebDAV block). Jeroen still has an open Jira issue for this [1], but he's enjoying a well deserved holiday now. Ard, do you know how far the WebDAV implementation in Jackrabbit is? [1] https://issues.apache.org/jira/browse/COCOON-2153 Jasha Joachimsthal www.onehippo.com Amsterdam - Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466 San Francisco - Hippo USA Inc. 101 H Street, suite Q Petaluma CA 94952-3329 +1 (707) 773-4646
[jira] Created: (COCOON-2228) StripNameSpacesTransformer does not strip namespace prefix of attributes
StripNameSpacesTransformer does not strip namespace prefix of attributes Key: COCOON-2228 URL: https://issues.apache.org/jira/browse/COCOON-2228 Project: Cocoon Issue Type: Bug Components: Blocks: (Undefined) Affects Versions: 2.1.11 Reporter: Jasha Joachimsthal Priority: Minor Fix For: 2.1.12-dev (Current SVN) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2228) StripNameSpacesTransformer does not strip namespace prefix of attributes
[ https://issues.apache.org/jira/browse/COCOON-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal updated COCOON-2228: --- Component/s: (was: Blocks: (Undefined)) * Cocoon Core StripNameSpacesTransformer does not strip namespace prefix of attributes Key: COCOON-2228 URL: https://issues.apache.org/jira/browse/COCOON-2228 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.11 Reporter: Jasha Joachimsthal Priority: Minor Fix For: 2.1.12-dev (Current SVN) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2228) StripNameSpacesTransformer does not strip namespace prefix of attributes
[ https://issues.apache.org/jira/browse/COCOON-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal updated COCOON-2228: --- Attachment: StripNameSpacesTransformer-Attributes.diff Added stripping of attributes StripNameSpacesTransformer does not strip namespace prefix of attributes Key: COCOON-2228 URL: https://issues.apache.org/jira/browse/COCOON-2228 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.11 Reporter: Jasha Joachimsthal Priority: Minor Fix For: 2.1.12-dev (Current SVN) Attachments: StripNameSpacesTransformer-Attributes.diff -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2213) Change check on mime-type to enable custom encoding of the body
Change check on mime-type to enable custom encoding of the body --- Key: COCOON-2213 URL: https://issues.apache.org/jira/browse/COCOON-2213 Project: Cocoon Issue Type: Improvement Components: Blocks: Mail Affects Versions: 2.1.11 Reporter: Jasha Joachimsthal Priority: Minor Fix For: 2.1.12-dev (Current SVN) Since the patch in COCOON-1622 was applied, a check is done on the mime-type for the output format. It checks if the value is equal to either text/plain or text/html. It may be necessary to explicitly set a charset in the mime-type. This means the check for the mime type should not equals but startsWith. COCOON-1622 seems to be only applied in the 2.1 branch, not in 2.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2213) Change check on mime-type to enable custom encoding of the body
[ https://issues.apache.org/jira/browse/COCOON-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal updated COCOON-2213: --- Attachment: SendMailTransformer_mime-type.patch Patch with changed mime-type check Change check on mime-type to enable custom encoding of the body --- Key: COCOON-2213 URL: https://issues.apache.org/jira/browse/COCOON-2213 Project: Cocoon Issue Type: Improvement Components: Blocks: Mail Affects Versions: 2.1.11 Reporter: Jasha Joachimsthal Priority: Minor Fix For: 2.1.12-dev (Current SVN) Attachments: SendMailTransformer_mime-type.patch Since the patch in COCOON-1622 was applied, a check is done on the mime-type for the output format. It checks if the value is equal to either text/plain or text/html. It may be necessary to explicitly set a charset in the mime-type. This means the check for the mime type should not equals but startsWith. COCOON-1622 seems to be only applied in the 2.1 branch, not in 2.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2213) Change check on mime-type to enable custom encoding of the body
[ https://issues.apache.org/jira/browse/COCOON-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12605907#action_12605907 ] Jasha Joachimsthal commented on COCOON-2213: Useful in cases like email:body mime-type=text/html;charset=UTF-8 /email:body email:body mime-type=text/plain;charset=UTF-8 /email:body Change check on mime-type to enable custom encoding of the body --- Key: COCOON-2213 URL: https://issues.apache.org/jira/browse/COCOON-2213 Project: Cocoon Issue Type: Improvement Components: Blocks: Mail Affects Versions: 2.1.11 Reporter: Jasha Joachimsthal Priority: Minor Fix For: 2.1.12-dev (Current SVN) Attachments: SendMailTransformer_mime-type.patch Since the patch in COCOON-1622 was applied, a check is done on the mime-type for the output format. It checks if the value is equal to either text/plain or text/html. It may be necessary to explicitly set a charset in the mime-type. This means the check for the mime type should not equals but startsWith. COCOON-1622 seems to be only applied in the 2.1 branch, not in 2.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: [VOTE] Drop JDK1.3 support for Cocoon 2.1.11 and newer versions
You get my non-binding +1 Jasha Joachimsthal www.onehippo.com Amsterdam - Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466 San Francisco - Hippo USA Inc. 101 H Street, suite Q Petaluma CA 94952-3329 +1 (707) 773-4646 -Original Message- From: Jeroen Reijn [mailto:[EMAIL PROTECTED] Sent: woensdag 28 mei 2008 9:03 To: Cocoon dev list Subject: [VOTE] Drop JDK1.3 support for Cocoon 2.1.11 and newer versions Hi all, I recently ran across problems while trying to upload cocoon 2.1.11 jars to the maven1 repository[1]. Building Cocoon with JDK 1.3 failed due to multiple errors. Therefor I would like to suggest setting the minimum JDK to 1.4 for cocoon 2.1.11 and newer versions. A bit more then a year ago we had the same vote for 2.1.10. See [2] for more info. We decided then that we should release 2.1.10 as soon as possible and move on to Cocoon 2.2 where we already had a higher JDK version as a minimum. I think it's a good idea to do a revote, since there might even be a 2.1.12. Please cast your votes! Regards, Jeroen [1]http://marc.info/?l=xml-cocoon-devm=121145897400703w=2 [2]http://marc.info/?l=xml-cocoon-devm=116605422600969w=2
[jira] Reopened: (COCOON-1574) Memory Leak with XMLFileModule
[ https://issues.apache.org/jira/browse/COCOON-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasha Joachimsthal reopened COCOON-1574: JXPathHelper.getAttribute() now always returns an Object of type String instead of any Object which breaks implementations that do not expect a String. Memory Leak with XMLFileModule -- Key: COCOON-1574 URL: https://issues.apache.org/jira/browse/COCOON-1574 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2 Environment: Operating System: Windows XP Platform: PC Reporter: Ron Blaschke Assignee: Ralph Goers Fix For: 2.1.11 I'm currently looking into a memory leak issue at Apache Forrest. Forrest's site currently needs to be built with -Xmx128m because of this. I believe the issue is originated at Cocoon's LinkRewriterTransformer or XMLFileModule. A memory profiler shows lots (30MB+) of DOM DocumentImpls (150+ objects), which get referenced by XMLFileModule.DocumentHelper. Their URIs are linkmap-xxx. LinkRewriterTransformer#createTransformedLink(String) uses a InputModuleHelper, which seems to reference a XMLFileModule. ... newLink = (String) modHelper.getAttribute(this.objectModel, ^ ... The XMLFileModule keeps the visited documents in a map, which is where they build up. Just for testing, I changed XMLFileModule#getDocumentHelper(Configuration) from this.documents.put(src, new DocumentHelper(reload, cache, src, this)); to return new DocumentHelper(reload, cache, src, this); Thus, a new DocumentHelper is created every time, instead of caching them. The result: No more memory problems, Apache Forrest's site builds again with -Xmx32. Ron -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (COCOON-1574) Memory Leak with XMLFileModule
[ https://issues.apache.org/jira/browse/COCOON-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12599018#action_12599018 ] jashajoachimsthal edited comment on COCOON-1574 at 5/22/08 7:03 AM: - AbstractJXPathModule.getAttribute() now always returns an Object of type String instead of any Object which breaks implementations that do not expect a String. was (Author: jashajoachimsthal): JXPathHelper.getAttribute() now always returns an Object of type String instead of any Object which breaks implementations that do not expect a String. Memory Leak with XMLFileModule -- Key: COCOON-1574 URL: https://issues.apache.org/jira/browse/COCOON-1574 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2 Environment: Operating System: Windows XP Platform: PC Reporter: Ron Blaschke Assignee: Ralph Goers Fix For: 2.1.11 I'm currently looking into a memory leak issue at Apache Forrest. Forrest's site currently needs to be built with -Xmx128m because of this. I believe the issue is originated at Cocoon's LinkRewriterTransformer or XMLFileModule. A memory profiler shows lots (30MB+) of DOM DocumentImpls (150+ objects), which get referenced by XMLFileModule.DocumentHelper. Their URIs are linkmap-xxx. LinkRewriterTransformer#createTransformedLink(String) uses a InputModuleHelper, which seems to reference a XMLFileModule. ... newLink = (String) modHelper.getAttribute(this.objectModel, ^ ... The XMLFileModule keeps the visited documents in a map, which is where they build up. Just for testing, I changed XMLFileModule#getDocumentHelper(Configuration) from this.documents.put(src, new DocumentHelper(reload, cache, src, this)); to return new DocumentHelper(reload, cache, src, this); Thus, a new DocumentHelper is created every time, instead of caching them. The result: No more memory problems, Apache Forrest's site builds again with -Xmx32. Ron -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: Cocoon website urls
-Original Message- From: Grzegorz Kossakowski [mailto:[EMAIL PROTECTED] Sent: Fri 11/16/2007 20:51 To: dev@cocoon.apache.org Subject: Re: Cocoon website urls Carsten Ziegeler pisze: I know that this has been discussed in the past, but nevertheless do we really think that urls like http://cocoon.apache.org/2.2/1290_1_1.html are suited for a top web framework of the 21st century? 1290_1_1 has absolutely no meaning. So what can be done about it? I support you Carsten on this. I talked about this with Reinhard and, AFAIR, he told me that the main reason was to have links immutable. I think we could loosen our requirement for having immutable links to just provide permanent redirection for changed titles. I must admit I haven't evaluated if it's technically easy to achieve but at least such idea is rather conforms HTTP spec. The worst thing is that our current version of Daisy does not support titles as names of published documents. Am I right Reinhard? -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/ What about a mixture of the unchangeable id's and the title. Like http://cocoon.apache.org/2.2/1290_1_1/Your_first_XML_pipeline_(publishing).html and that can be changed into http://cocoon.apache.org/2.2/1290_1_1/The_new_title_of_the_page.html Shouldn't be that hard to match in Cocoon on the 1290_1_1 ;) Jasha winmail.dat
RE: Flowscript debugger with JDK 5 on Leopard
Hi Andrew, I have the same ArrayIndexOutOfBoundsException with the current 2.1 branch under Leopard with Java 1.5. Jasha -Original Message- From: [EMAIL PROTECTED] on behalf of Andrew Savory Sent: Wed 11/14/2007 12:12 To: dev@cocoon.apache.org Subject: Flowscript debugger with JDK 5 on Leopard Hi folks, I'm having problems running the flowscript debugger on JDK 1.5 on Leopard, and wondered if anyone else was seeing the same thing. Basically, when Cocoon (2.1.10) hits a flowscript and launches the debugger, it also launches an exception: Exception in thread AWT-EventQueue-0 java.lang.ArrayIndexOutOfBoundsException: No such child: 1 at java.awt.Container.getComponent (Container.java:280) I've tried updating to js-1.6r6 and js-1.6r7 but they exhibit the same problem. I haven't been able to test in 2.1.11-dev as my svn checkout is not up-to-date and my dev machine has no net connection at the moment. Any suggestions? Andrew. winmail.dat
RE: Flowscript debugger with JDK 5 on Leopard
It doesn't matter which version my shell has, but the JAVA_HOME for the Leopard GUI seems to matter. The JAVA_HOME for the GUI must be 1.4 to make it run, even if the shell uses 1.5. Tried playing with it, logging in and out and setting JAVA_HOME for the GUI to 1.4 seemed to be the trick. Didn't matter if I build Cocoon with 1.4 or 1.5. -Original Message- From: Vadim Gritsenko [mailto:[EMAIL PROTECTED] Sent: Wed 11/14/2007 20:39 To: dev@cocoon.apache.org Subject: Re: Flowscript debugger with JDK 5 on Leopard Andrew Savory wrote: Hi folks, I'm having problems running the flowscript debugger on JDK 1.5 on Leopard Did you try java 1.4? Vadim winmail.dat
RE: XHTML Serializer bug?
-Original Message- From: Insight 49, LLC [mailto:[EMAIL PROTECTED] Sent: dinsdag 9 oktober 2007 3:42 To: dev@cocoon.apache.org Subject: Re: XHTML Serializer bug? Vadim Gritsenko wrote: Dan Hertz wrote: I hope someone can help me debug my HTML Serializer issue: I've trying to generate strict XHTML code where all tags are closed (eg: image/, meta/). If I set the sitemap serializer to org.apache.cocoon.serialization.XMLSerializer, the tags get closed, but my Javascripts don't load. If I set it to org.apache.cocoon.serialization.HTMLSerializer, then my Javascripts load fine, but the tags aren't closed. Did you try org.apache.cocoon.components.serializers.XHTMLSerializer? Vadim Thanks for your XHTMLSerializer suggestion. It closes the elements nicely, but changes my quotes ( ) to quot; That's why my scripts aren't running! (ah-ha!) Funny thing is...even if I wrap my script sections in 