Re: JSP integration
Andrew Stevens skrev: Date: Wed, 18 Jul 2007 23:42:34 -0400 From: [EMAIL PROTECTED] With the current servlet service framework I just don't know how to integrate JSPs - what this thread was actually about. Isn't the standard way of integrating JSP to just call it through a RequestDispatcher that you get from ServletContext.getRequestDispatcher(String path)? I have rarely worked with all that stuff and am not familiar with it. When reading the corresponding section in the servlet spec it sounds reasonable though. I only wonder what the downsides of this approach are. Or: Why was the default implementation JSPEngineImpl [1] implemented differently (though there is an implementation with the approach you describe [2])? Joerg [1] http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/blocks/jsp/java/org/apache/cocoon/components/jsp/JSPEngineImpl.java?revision=433543view=markup [2] http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/blocks/jsp/java/org/apache/cocoon/components/jsp/JSPEngineImplNamedDispatcherInclude.java?revision=433543view=markup Not quite - the implementation in [2] accesses the JSP engine through getNamedDispatcher, not getRequestDispatcher; if you're wanting to call /cocoon/foobar.jsp it looks up the configured name (getNamedDispatcher(*.jsp) by default, which is what Tomcat uses, but it's called JSP 1.2 Processor on Websphere 5 and probably something else on other containers) and before calling include (or forward, depending on configuration) sets the appropriate attributes in the request object, described in the servlet spec, to make the engine think it's been called by a 'jsp:include page=/cocoon/foobar.jsp' (or jsp:forward). What Daniel described would be an implementation that just calls getRequestDispatcher(/cocoon/foobar.jsp), and calls include/forward on that. There isn't an existing implementation which does that, but it's what I was describing in my earlier post (http://marc.info/?l=xml-cocoon-devm=118437354213375w=2). The biggest problem with it is that if JSPs are mapped to go through the Cocoon servlet (like the default Cocoon 2.1.x web.xml does), then getRequestDispatcher will return a reference to Cocoon. So Cocoon passes the request to Cocoon for processing, which passes it to Cocoon for processing, which passes it to ... well, you get the picture. Eventually you get a java.lang.StackOverflowError and a 500 Server Error gets returned to the browser :-( Which is probably why the existing Cocoon implementations all use some other way to call the container's JSP engine. You only get the infinite loop if you insist on mounting the Cocoon servlet and the JSP at the same path if you use different paths the problem disappear. Also if you want to use a named dispatcher, we could make the named dispatcher in the ServletServiceContext fall back to the original servlet context, for names that the servlet service isn't connected to. /Daniel
[jira] Commented: (COCOON-2093) Servlet Service Transformer fail with error Invalid byte 2 of 2-byte UTF-8 sequence.
[ https://issues.apache.org/jira/browse/COCOON-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514163 ] Vladimir S Bronnikov commented on COCOON-2093: -- I find following: Class org.apache.cocoon.servletservice.postable.components.ServletServiceTransformer copy XML from input to output using IOUtils.copy (see string number 87). This method use object OutputStreamWriter for writing characters. But this method have no parameter for encoding output stream. Then object OutputStreamWriter set default system encoding (may differ from UTF-8). I correct source code of ServletServiceTransformer and replace copy method on: IOUtils.copy(new StringReader(xml), servletSource.getOutputStream(),UTF-8); Then on output we have output stream with UTF-8 encoding. Is this a decision? May you correct source code? Servlet Service Transformer fail with error Invalid byte 2 of 2-byte UTF-8 sequence. Key: COCOON-2093 URL: https://issues.apache.org/jira/browse/COCOON-2093 Project: Cocoon Issue Type: Bug Components: * Cocoon Core, - Components: Sitemap, - Servlet service framework Reporter: Vladimir S Bronnikov Fix For: 2.2-dev (Current SVN) Attachments: servletservice.zip Hello! I create two cocoon block such as in this article: Modularize Cocoon apps (Using blocks) (http://cocoon.zones.apache.org/dev-docs/2.2/1291_1_1.html) in section Use a pipeline fragment. Only difference is that file demo/welcome.xml contain russian symbols (but in UTF-8 encoding - 100%). After point my browser at http://localhost:/myBlock1/callingTransformationService I see this exception: Caused by: org.xml.sax.SAXParseException: Invalid byte 2 of 2-byte UTF-8 sequence. at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.cocoon.core.xml.impl.JaxpSAXParser.parse(JaxpSAXParser.java:196) at org.apache.cocoon.core.xml.impl.JaxpSAXParser.parse(JaxpSAXParser.java:204) at org.apache.cocoon.core.xml.avalon.DefaultSAXParser.parse(DefaultSAXParser.java:54) at org.apache.cocoon.components.source.util.SourceUtil.parse(SourceUtil.java:238) at org.apache.cocoon.generation.FileGenerator.generate(FileGenerator.java:109) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ... What's wrong? Where can I set correct encoding (UTF-8)? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2093) Servlet Service Transformer fail with error Invalid byte 2 of 2-byte UTF-8 sequence.
[ https://issues.apache.org/jira/browse/COCOON-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2093: Assignee: Grzegorz Kossakowski Servlet Service Transformer fail with error Invalid byte 2 of 2-byte UTF-8 sequence. Key: COCOON-2093 URL: https://issues.apache.org/jira/browse/COCOON-2093 Project: Cocoon Issue Type: Bug Components: * Cocoon Core, - Components: Sitemap, - Servlet service framework Reporter: Vladimir S Bronnikov Assignee: Grzegorz Kossakowski Fix For: 2.2-dev (Current SVN) Attachments: servletservice.zip Hello! I create two cocoon block such as in this article: Modularize Cocoon apps (Using blocks) (http://cocoon.zones.apache.org/dev-docs/2.2/1291_1_1.html) in section Use a pipeline fragment. Only difference is that file demo/welcome.xml contain russian symbols (but in UTF-8 encoding - 100%). After point my browser at http://localhost:/myBlock1/callingTransformationService I see this exception: Caused by: org.xml.sax.SAXParseException: Invalid byte 2 of 2-byte UTF-8 sequence. at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.cocoon.core.xml.impl.JaxpSAXParser.parse(JaxpSAXParser.java:196) at org.apache.cocoon.core.xml.impl.JaxpSAXParser.parse(JaxpSAXParser.java:204) at org.apache.cocoon.core.xml.avalon.DefaultSAXParser.parse(DefaultSAXParser.java:54) at org.apache.cocoon.components.source.util.SourceUtil.parse(SourceUtil.java:238) at org.apache.cocoon.generation.FileGenerator.generate(FileGenerator.java:109) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ... What's wrong? Where can I set correct encoding (UTF-8)? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2093) Servlet Service Transformer fail with error Invalid byte 2 of 2-byte UTF-8 sequence.
[ https://issues.apache.org/jira/browse/COCOON-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-2093: - I'm not sure if it should always be a UTF-8 or at least if it's not defined somewhere in Cocoon as constant. Anyway I changed it according your suggestion in r557964. Thanks for your report. Closing the issue, reopen is something is still wrong. Servlet Service Transformer fail with error Invalid byte 2 of 2-byte UTF-8 sequence. Key: COCOON-2093 URL: https://issues.apache.org/jira/browse/COCOON-2093 Project: Cocoon Issue Type: Bug Components: * Cocoon Core, - Components: Sitemap, - Servlet service framework Reporter: Vladimir S Bronnikov Assignee: Grzegorz Kossakowski Fix For: 2.2-dev (Current SVN) Attachments: servletservice.zip Hello! I create two cocoon block such as in this article: Modularize Cocoon apps (Using blocks) (http://cocoon.zones.apache.org/dev-docs/2.2/1291_1_1.html) in section Use a pipeline fragment. Only difference is that file demo/welcome.xml contain russian symbols (but in UTF-8 encoding - 100%). After point my browser at http://localhost:/myBlock1/callingTransformationService I see this exception: Caused by: org.xml.sax.SAXParseException: Invalid byte 2 of 2-byte UTF-8 sequence. at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.cocoon.core.xml.impl.JaxpSAXParser.parse(JaxpSAXParser.java:196) at org.apache.cocoon.core.xml.impl.JaxpSAXParser.parse(JaxpSAXParser.java:204) at org.apache.cocoon.core.xml.avalon.DefaultSAXParser.parse(DefaultSAXParser.java:54) at org.apache.cocoon.components.source.util.SourceUtil.parse(SourceUtil.java:238) at org.apache.cocoon.generation.FileGenerator.generate(FileGenerator.java:109) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ... What's wrong? Where can I set correct encoding (UTF-8)? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2093) Servlet Service Transformer fail with error Invalid byte 2 of 2-byte UTF-8 sequence.
[ https://issues.apache.org/jira/browse/COCOON-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-2093. Resolution: Fixed Servlet Service Transformer fail with error Invalid byte 2 of 2-byte UTF-8 sequence. Key: COCOON-2093 URL: https://issues.apache.org/jira/browse/COCOON-2093 Project: Cocoon Issue Type: Bug Components: * Cocoon Core, - Components: Sitemap, - Servlet service framework Reporter: Vladimir S Bronnikov Assignee: Grzegorz Kossakowski Fix For: 2.2-dev (Current SVN) Attachments: servletservice.zip Hello! I create two cocoon block such as in this article: Modularize Cocoon apps (Using blocks) (http://cocoon.zones.apache.org/dev-docs/2.2/1291_1_1.html) in section Use a pipeline fragment. Only difference is that file demo/welcome.xml contain russian symbols (but in UTF-8 encoding - 100%). After point my browser at http://localhost:/myBlock1/callingTransformationService I see this exception: Caused by: org.xml.sax.SAXParseException: Invalid byte 2 of 2-byte UTF-8 sequence. at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.cocoon.core.xml.impl.JaxpSAXParser.parse(JaxpSAXParser.java:196) at org.apache.cocoon.core.xml.impl.JaxpSAXParser.parse(JaxpSAXParser.java:204) at org.apache.cocoon.core.xml.avalon.DefaultSAXParser.parse(DefaultSAXParser.java:54) at org.apache.cocoon.components.source.util.SourceUtil.parse(SourceUtil.java:238) at org.apache.cocoon.generation.FileGenerator.generate(FileGenerator.java:109) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ... What's wrong? Where can I set correct encoding (UTF-8)? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r557982 - /cocoon/trunk/pom.xml
[EMAIL PROTECTED] pisze: Author: cziegeler Date: Fri Jul 20 05:42:51 2007 New Revision: 557982 URL: http://svn.apache.org/viewvc?view=revrev=557982 Log: Use latest soureceresolver release. Modified: cocoon/trunk/pom.xml Carsten, does it fix problems mentioned in ZipSourceTestCase[1] (FIXME comment)? If answer is positive, would you mind to update it too? [1] http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-core/src/test/java/org/apache/cocoon/components/source/impl/ZipSourceTestCase.java?view=markup -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: svn commit: r557982 - /cocoon/trunk/pom.xml
Grzegorz Kossakowski wrote: [EMAIL PROTECTED] pisze: Author: cziegeler Date: Fri Jul 20 05:42:51 2007 New Revision: 557982 URL: http://svn.apache.org/viewvc?view=revrev=557982 Log: Use latest soureceresolver release. Modified: cocoon/trunk/pom.xml Carsten, does it fix problems mentioned in ZipSourceTestCase[1] (FIXME comment)? If answer is positive, would you mind to update it too? Thanks for the reminder, yes it *should* fix it - I could only test on macosx. If someone on another plattform could check the updated test case as well would be great. Carsten [1] http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-core/src/test/java/org/apache/cocoon/components/source/impl/ZipSourceTestCase.java?view=markup -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [jira] Updated: (COCOON-2059) ajax/common.js makes use of deprecated dojo.animation.Timer
I Joerg,
I wonder if the issue should be closed only for 2.1.11, since the 2.2 is
not released yet.
Best Regards,
Antonio Gallardo.
Jörg Heinicke (JIRA) escribió:
[
https://issues.apache.org/jira/browse/COCOON-2059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jörg Heinicke updated COCOON-2059:
--
Fix Version/s: 2.2-dev (Current SVN)
ajax/common.js makes use of deprecated dojo.animation.Timer
---
Key: COCOON-2059
URL: https://issues.apache.org/jira/browse/COCOON-2059
Project: Cocoon
Issue Type: Bug
Components: Blocks: Ajax
Affects Versions: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN)
Reporter: Alexander Klimetschek
Assignee: Grzegorz Kossakowski
Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN)
Following code uses deprecated stuff from dojo 0.4.1:
periodicalUpdate: function(delay, href, target, insertion) {
dojo.require(dojo.animation.Timer);
var timer = new dojo.animation.Timer(delay);
timer.onTick = function() {
Dojo in debug mode says: DEPRECATED: dojo.animation.Timer is now
dojo.lang.timing.Timer 0.5
To fix that, one should simply use:
periodicalUpdate: function(delay, href, target, insertion) {
dojo.require(dojo.lang.timing.Timer);
var timer = new dojo.lang.timing.Timer(delay);
[jira] Commented: (COCOON-2058) Ambiguous rule match for fi:styling/@submit-on-change
[
https://issues.apache.org/jira/browse/COCOON-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514223
]
Antonio Gallardo commented on COCOON-2058:
--
I am wondering if is a good idea to add priorities to xslt rules for the
default cform rendering. I am thinking for the users that overwrote this rules.
wdyt?
Ambiguous rule match for fi:styling/@submit-on-change
---
Key: COCOON-2058
URL: https://issues.apache.org/jira/browse/COCOON-2058
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Reporter: Ralph Collett
Priority: Minor
Ambiguous rule match for fi:styling/@submit-on-change between
fi:styling/@submit-on-change and fi:styling/@* in forms-field-styling.xsl
rules when using Saxon. Priority of fi:styling/@submit-on-change should be
set to 1 (as in the fi:styling/@type rule).
--- Starting at line 151 of forms-field-styling.xsl ---
xsl:template match=fi:styling/@* mode=styling
xsl:copy-of select=./
/xsl:template
xsl:template match=fi:styling/@submit-on-change mode=styling
xsl:if test=. = 'true'
xsl:attribute name=onchangeforms_submitForm(this)/xsl:attribute
/xsl:if
/xsl:template
xsl:template match=fi:styling/@list-type | fi:styling/@list-orientation |
fi:styling/@listbox-size | fi:styling/@format |
fi:styling/@layout
mode=styling
!--+
| Ignore marker attributes so they don't go into the resuling HTML.
+--
/xsl:template
xsl:template match=fi:styling/@type mode=styling priority=1
!--+
| Do we have a duplicate semantic usage of @type?
| @type is only a marker for the stylesheet in general, but some of
the
| types must/should be in the HTML output too.
+--
xsl:variable name=validHTMLTypes
select='text hidden checkbox radio password image reset
submit'/
xsl:if test=normalize-space(.) and
contains(concat(' ', $validHTMLTypes, ' '), concat(' ', .,
' '))
xsl:copy-of select=./
/xsl:if
/xsl:template
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [heads-up] cocoon-template is little broken in trunk
Grzegorz Kossakowski schrieb: Hello, I merged my changes related to ObjectModel refactoring (report on it soon) and just found out that something is broken when jx-macros.xml from cocoon-forms-impl is evaluated. It means that most of your CForms will _not_ work with current trunk. I'm researching the problem and will report when everything is fixed. Do your latest commits fix this? Felix
[jira] Closed: (COCOON-2082) Get rid of Avalon dependencies in cocoon-expression-language code
[ https://issues.apache.org/jira/browse/COCOON-2082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-2082. Resolution: Fixed Goal has been accomplished. Closing the issue. Get rid of Avalon dependencies in cocoon-expression-language code - Key: COCOON-2082 URL: https://issues.apache.org/jira/browse/COCOON-2082 Project: Cocoon Issue Type: Task Components: * Cocoon Core, - Components: Avalon, Blocks: Templating Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Assignee: Grzegorz Kossakowski Fix For: 2.2-dev (Current SVN) The task consists of making DefaultExpressionFactory a Spring bean and minor tweaking in rest of classes. Block cocoon-template must be updated accordingly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [heads-up] cocoon-template is little broken in trunk
Felix Knecht pisze: Grzegorz Kossakowski schrieb: Hello, I merged my changes related to ObjectModel refactoring (report on it soon) and just found out that something is broken when jx-macros.xml from cocoon-forms-impl is evaluated. It means that most of your CForms will _not_ work with current trunk. I'm researching the problem and will report when everything is fixed. Do your latest commits fix this? Nope, but they are close to fix things. Now it's matter of NPE in cleanupLocalContext() of ObjectModelImpl. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
[jira] Reopened: (COCOON-2073) Upgrade to dojo 0.4.3 (security fixes!)
[ https://issues.apache.org/jira/browse/COCOON-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo reopened COCOON-2073: -- At least in 2.1.11-dev this seems to not being fixed (for Linux?). Add the next line to a any page with dojo and it sends back 0.4.1: dojo.debug(The current version of dojo is: , dojo.version.toString()); Upgrade to dojo 0.4.3 (security fixes!) --- Key: COCOON-2073 URL: https://issues.apache.org/jira/browse/COCOON-2073 Project: Cocoon Issue Type: Improvement Components: Blocks: Ajax Affects Versions: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Alexander Klimetschek Assignee: Grzegorz Kossakowski Current ajax block includes dojo 0.4.1. The current release of dojo is 0.4.3 - in 0.4.2 minor improvements were made but 0.4.3 includes security fixes for cross-site scripting attacks and the guys at dojo strongly recommend upgrading. As far as I can see, there should be no compatibility issues with Cocoon's dojo widgets. http://dojotoolkit.org/releaseNotes/0.4.3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Missing feature in XIncludeTransformer
Hello, I noticed that Cocoon's XIncludeTransformer seems to be missing the base URI fixup support specified in the W3C's XInclude spec [1] (Careful, this is distinct from supporting xml:base to resolve relative xi:include hrefs against). In short, it says that the base URIs of documents do not change when passed through an XInclude parser. This means that xml:base attributes with the value of the current base URI should be added to the top level included elements. To see an example, the xmllint parser (part of libxml2) will perform this attribute insertion when you enable XInclude processing. I think this feature is important because otherwise, relative URIs (i.e. links) in an included document will break if the included document is not located in the same directory. Adding the xml:base attribute to the result gives later content handlers the ability to resolve relative URIs against the base. (In particular, I'm thinking of using XPath 2.0's resolve-uri function). Any thoughts? Is this a feature we need to see? I think this is the cleanest and most general solution for resolving relative URIs in included documents -- not to mention it's required by the XInclude spec. Pending discussion here, I've created a patch that adds this support that I can submit to JIRA. -- Andrew Cave [1] http://www.w3.org/TR/xinclude/#base - The Base URI Fixup section of the W3C's XInclude specification
Re: CocoonGT2007 - When?
On 7/17/07, Reinhard Poetz [EMAIL PROTECTED] wrote: Hi Gianugo, are there already some concrete plans, when the GT will take place this year? I would be very interested to know it asap, because a project will start around the suggested dates of end of September or beginning of October and if possible I want to avoid timing collisions as far as possible. Hey Reinhard, sorry to keep you (and everyone else) waiting. We are busy crossing t's and dotting i's, but I plan to send the dates, CFPs and other info RSN. For now, here is the sneak peek: mark October 3th and 4th down. :-) Ciao, -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [jira] Updated: (COCOON-2059) ajax/common.js makes use of deprecated dojo.animation.Timer
On 20.07.2007 11:28, Antonio Gallardo wrote: I wonder if the issue should be closed only for 2.1.11, since the 2.2 is not released yet. 2.1.11 is neither. That's also why it is named -dev. We always used to handle it that way. On release the -dev suffix gets removed. This system has only one caveat: If there is a bug found in a dev version and fixed before the next release we end up with the same version in both affects version and fix version after the renaming [1]. It then reads like bug affects 2.1.9, but at the same time bug is fixed in 2.1.9. Joerg [1] http://marc.info/?t=11679544253r=1w=4
Re: [jira] Updated: (COCOON-2059) ajax/common.js makes use of deprecated dojo.animation.Timer
I did not explained myself pretty well. It is supposed that all the fixes from a previous version are included in all future releases. Hence, an issue fixed in 2.1.11 is assumed to be fixed in 2.2. or not? Best Regards, Antonio Gallardo. Joerg Heinicke escribió: On 20.07.2007 11:28, Antonio Gallardo wrote: I wonder if the issue should be closed only for 2.1.11, since the 2.2 is not released yet. 2.1.11 is neither. That's also why it is named -dev. We always used to handle it that way. On release the -dev suffix gets removed. This system has only one caveat: If there is a bug found in a dev version and fixed before the next release we end up with the same version in both affects version and fix version after the renaming [1]. It then reads like bug affects 2.1.9, but at the same time bug is fixed in 2.1.9. Joerg [1] http://marc.info/?t=11679544253r=1w=4
Re: [jira] Updated: (COCOON-2059) ajax/common.js makes use of deprecated dojo.animation.Timer
On 20.07.2007 22:04, Antonio Gallardo wrote: I did not explained myself pretty well. It is supposed that all the fixes from a previous version are included in all future releases. Hence, an issue fixed in 2.1.11 is assumed to be fixed in 2.2. or not? Ah, that's different :-) No, we don't set all future versions, only the first one it is fixed in - but per branch. Maybe we have 2.2 before 2.1.11. Is the issue supposed to be not fixed in 2.2 then? So setting both versions adds additional and useful information. I think we have always handled it the per-branch way. Joerg
