[jira] Updated: (COCOON-2155) Failing test cases due to additional attributes from namespace declarations in a DOM from parser, but not from serializer
[ https://issues.apache.org/jira/browse/COCOON-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Heinicke updated COCOON-2155: -- Summary: Failing test cases due to additional attributes from namespace declarations in a DOM from parser, but not from serializer (was: Parser produces redundant element attributes (namespace declarations) in a DOM while test-cases are executed) Failing test cases due to additional attributes from namespace declarations in a DOM from parser, but not from serializer - Key: COCOON-2155 URL: https://issues.apache.org/jira/browse/COCOON-2155 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Quoting Joerg: Just an explanation: A namespace declaration is not an attribute (even if it looks so) and that's why it should not end as such. The DOM produced by Cocoon is absolutely correct, the one by parsing expected document in the test case is not since it has both the namespace declaration AND an attribute xmlns:fi - which broke our test. (http://article.gmane.org/gmane.text.xml.cocoon.devel/75975) Also see this: http://article.gmane.org/gmane.text.xml.cocoon.devel/75974 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute URIs
On Dec 26, 2007, at 4:01 PM, Grzegorz Kossakowski wrote: Reinhard Poetz pisze: Hi Reinhard, isn't it a duplicate of https://issues.apache.org/jira/browse/COCOON-2044 ? Not really. If I read that issue correctly, it talks about making cache keys unique. I refer to absolute servlet:/ URIs, e.g. servlet:com.mycompany.project.servlet.service+:/test/foo/bar Plus sign doesn't look naturally for me. Are there any other options? How about servlet:com.mycompany.project.servlet.service:!/test/foo/bar Vadim
Re: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute URIs
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
ServletSource is only available if you use the ServletService Framework
together with Cocoon. So I think that ServletConnection should become
public API too.
We could offer two types of ServletConnections:
* RelativeServletConnection that works relative to the current servlet
context * AbsoluteServletConnection that expects the servlet service name
(= the name of the Spring bean)
I was wondering why ServletConnection can't be clever enough to figure it out
if it's passed a relative URI or absolute one? Why we need separate classes?
It's not a big deal for me, just curious.
the reason was that I didn't like the code when it did both. But let's discuss
this when the code is committed.
Actually I've already implemented it this way ...
WDYT?
The biggest mystery for me is why I don't see commit messages mentioning this
great stuff being checked in into our repository.
Keeping this code in a secret is just not fair! ;-)
I have to test it more extensivly, but I plan to commit it soon.
For me fixing the cache key generation problem is only a positive side
effect of my current work. I need absolute servlet URIs for a special
generator (or maybe a source, don't know yet) whose output depends on the
available servlet services which makes it impossible to define them as
connections beforehand.
Probably it's very similar to what you call dynamic connections.
Yep, I guess so. I was thinking about dynamic servlet discovery based on some
conditions. For example, I would like to see a generator that lets me to list
all servlet giving 200 response when they asked for resource
/org.grek.app.skin.provider. This way I could easily list all skins
available for my new, shiny application. Is it something similar to your
goals?
yes
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute URIs
Reinhard Poetz pisze: ServletSource is only available if you use the ServletService Framework together with Cocoon. So I think that ServletConnection should become public API too. We could offer two types of ServletConnections: * RelativeServletConnection that works relative to the current servlet context * AbsoluteServletConnection that expects the servlet service name (= the name of the Spring bean) I was wondering why ServletConnection can't be clever enough to figure it out if it's passed a relative URI or absolute one? Why we need separate classes? It's not a big deal for me, just curious. Actually I've already implemented it this way ... WDYT? The biggest mystery for me is why I don't see commit messages mentioning this great stuff being checked in into our repository. Keeping this code in a secret is just not fair! ;-) For me fixing the cache key generation problem is only a positive side effect of my current work. I need absolute servlet URIs for a special generator (or maybe a source, don't know yet) whose output depends on the available servlet services which makes it impossible to define them as connections beforehand. Probably it's very similar to what you call dynamic connections. Yep, I guess so. I was thinking about dynamic servlet discovery based on some conditions. For example, I would like to see a generator that lets me to list all servlet giving 200 response when they asked for resource /org.grek.app.skin.provider. This way I could easily list all skins available for my new, shiny application. Is it something similar to your goals? -- Grzegorz Kossakowski
Re: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute URIs
Vadim Gritsenko wrote:
On Dec 26, 2007, at 4:01 PM, Grzegorz Kossakowski wrote:
Plus sign doesn't look naturally for me. Are there any other options?
How about
servlet:com.mycompany.project.servlet.service:!/test/foo/bar
Hmmm, I'm not perfectly happy with this solution either. In this case the path
is enriched with information that actually belongs to the sub-protocol part of
the URI.
However, I guess that there is no really good solution in this case. Currently I
slightly prefer the + variant, though that's no strong opinion.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: 2.1.11 release
I committed the changes to 2.1.x. I'll try to get trunk done on 1/1/08 Ralph Goers wrote: If I can't get it done in the next 24 hrs go ahead and do that. However, I'd really like my changes in 2.1.11 also. It has been an outstanding defect for several years. Grzegorz Kossakowski wrote: Ralph Goers pisze: I'm currently trying to get the XPathXMLFileModule into trunk. I was holding off committing until I had that working. However, I will be heading off to Seattle very early tomorrow until New Year's Eve so if I don't get it committed today it won't be included in your build - which is a very bad thing since several JXPath based input modules don't work right now (i.e - I'd have to vote -1 on the release until I get this fixed). I may just commit what I have for 2.1 and get trunk done when I get back. Unfortunately, I am very busy getting things ready for my grandkids birthday party so I have no idea if I'll get this completed today. What about reverting my change in 2.1.x branch that broke JXPath-based modules and introducing a new method in JXPathHelper just to make xmodule:flow-attr working properly? It's really not my favorite choice but it was me who broke XMLModule and I don't want to block a release. In trunk I opt for cleaner API at price of breaking back-compatibility. WDYT?
Re: Broken test-cases due to missing namespace declarations
On 27.12.2007 15:00 Uhr, Grzegorz Kossakowski wrote: Second, that's not quite correct. Xalan 2.7.1 fixes the issue. Our DOMBuilder is only a wrapper. It does not replace the Xalan DOMBuilder at all. I'm not sure if it's only me but this wrapper is not as simple as I would like to see it. From just look at the code of our wrapper it is quite hard to figure out that it uses DOMBuilder from Xalan. It does not just wrap Xalan's DOMBuilder. It kind of does the same but has a different approach: Both build a DOM from SAX events but while Xalan's does it directly Cocoon's DOMBuilder utilizes a TransformerHandler and a DOMResult for it. Additionally listening capability is added and XMLPipe implemented. Also Xalan's DOMBuilder is more a internal class, it's not part of public API. It's a public class but unless you want to tie your code to Xalan there is no way to instantiate the class. That's what you usually do using SAXTransformerFactory as Cocoon's DOMBuilder does or DocumentBuilderFactory. The names matches more or less by coincidence. The fix for XALANJ-2091 is triggered by startPrefixMapping(). With FlowJXPathSelectionList.generateSaxFragment() as in the test case without the actual CForms framework code startPrefixMapping() is never called. After I added startPrefixMapping() at the very beginning of FlowJXPathSelectionList.generateSaxFragment() and endPrefixMapping() at the end of it the test passed without the explicit removal of the namespace attribute. The question is if we really want to change all places where this applies and add start/endPrefixMapping(). In theory that's the correct way to do it. Another possibility to fix the tests would be to serialize the XML from the actual test run and reparse it in the same way as the documents we compare to. I opt for fixing our code by adding start/endPrefixMapping() as it seems to be the cleanest possible solution. Apart from that I think that SAX spec. enfornces on us to use these methods if we want to produce proper (representing well-formed XML) stream of SAX events. Our code is not really broken. Usually we call startPrefixMapping() in startDocument() methods of transformers or something like this. It's only broken for the test cases since we just have a look at the component to test without its framework. From a component POV adding start/endPrefixMapping() is the correct solution to encapsulate it. The question I asked was only if these components will ever run outside of their current framework. Personally I prefer the correct approach as well. The only problem I can see now is that Xalan 2.7.1 is _not_ available on Maven central repository. Do you have an idea how to quickly add it to repository? Should we ask Xalan people to upload it or should we go for standard procedure (creating issue in Maven jira and attaching artifacts)? I have no idea what the different ways mean in regard of getting things done correctly and as fast as possible. I only got the jar from Antonio's commit to 2.1 and put it into my local repository by copying 2.7.0's POM. Joerg
Gabriel Gruber/Workflow is out of office.
I will be out of the office starting 27.12.2007 and will not return until 07.01.2008. Ich bin bis zum 06.01.2008 auf Urlaub und ab 07.01.2008 wieder für Sie erreichbar. Bei technischen Fragen zum System Webdesk wenden Sie sich bitte vertrauensvoll an Hrn. Stastny. Bei Fragen zu laufenden Projekten wenden Sie sich bitte an Hrn. Povysil! In dringenden Fällen versuchen Sie es auf meinem Handy: +43 - 676 - 3939435! mit freundlichen Grüssen Gabriel Gruber
Re: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute URIs
On 27.12.2007 21:51 Uhr, Reinhard Poetz wrote: How about servlet:com.mycompany.project.servlet.service:!/test/foo/bar Hmmm, I'm not perfectly happy with this solution either. In this case the path is enriched with information that actually belongs to the sub-protocol part of the URI. However, I guess that there is no really good solution in this case. Currently I slightly prefer the + variant, though that's no strong opinion. Could anybody please sum up what the actual problem is and what the proposals are to solve it? So far I only got that there is an issue with cache key which can be solved by absolutizing URIs. Now there is this relative vs. absolute URI thing. What for do we need the +? What's the scheme for relative URIs? Joerg
[jira] Updated: (COCOON-2155) Failing test cases due to additional attributes from namespace declarations in a DOM from parser, but not from serializer
[ https://issues.apache.org/jira/browse/COCOON-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-2155: - Attachment: COCOON-2155-cocoon-core.patch Added missing namespace prefix declarations in CIncludeTransformerTestCase. Failing test cases due to additional attributes from namespace declarations in a DOM from parser, but not from serializer - Key: COCOON-2155 URL: https://issues.apache.org/jira/browse/COCOON-2155 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Attachments: COCOON-2155-cocoon-core.patch, COCOON-2155-parent-pom.patch Quoting Joerg: Just an explanation: A namespace declaration is not an attribute (even if it looks so) and that's why it should not end as such. The DOM produced by Cocoon is absolutely correct, the one by parsing expected document in the test case is not since it has both the namespace declaration AND an attribute xmlns:fi - which broke our test. (http://article.gmane.org/gmane.text.xml.cocoon.devel/75975) Also see this: http://article.gmane.org/gmane.text.xml.cocoon.devel/75974 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2155) Failing test cases due to additional attributes from namespace declarations in a DOM from parser, but not from serializer
[ https://issues.apache.org/jira/browse/COCOON-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-2155: - Attachment: COCOON-2155-parent-pom.patch I have taken a closer look at our test-cases after upgrading (locally) to Xalan 2.7.1. Fix of bug in Xalan revealed that we had some test-cases slightly broken. I fixed all of them I could found so all test-cases passed again. Unfortunately, I cannot commit these fixes because there Xalan 2.7.1 is not available on Maven repository at the moment. Therefore I decided to attach my fixes as patches to this issue. First patch consist only of change to parent pom to be applied when Xalan 2.1.7 is available on Maven repository. Failing test cases due to additional attributes from namespace declarations in a DOM from parser, but not from serializer - Key: COCOON-2155 URL: https://issues.apache.org/jira/browse/COCOON-2155 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Attachments: COCOON-2155-cocoon-core.patch, COCOON-2155-parent-pom.patch Quoting Joerg: Just an explanation: A namespace declaration is not an attribute (even if it looks so) and that's why it should not end as such. The DOM produced by Cocoon is absolutely correct, the one by parsing expected document in the test case is not since it has both the namespace declaration AND an attribute xmlns:fi - which broke our test. (http://article.gmane.org/gmane.text.xml.cocoon.devel/75975) Also see this: http://article.gmane.org/gmane.text.xml.cocoon.devel/75974 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2155) Failing test cases due to additional attributes from namespace declarations in a DOM from parser, but not from serializer
[ https://issues.apache.org/jira/browse/COCOON-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-2155: - Attachment: COCOON-2155-cocoon-forms-impl.patch Added missing start/endPrefixMapping calls in a code generating XML in Forms. Also removed work-arounds for a bug in Xalan that is fixed in 2.7.1 version. Failing test cases due to additional attributes from namespace declarations in a DOM from parser, but not from serializer - Key: COCOON-2155 URL: https://issues.apache.org/jira/browse/COCOON-2155 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Attachments: COCOON-2155-cocoon-core.patch, COCOON-2155-cocoon-forms-impl.patch, COCOON-2155-parent-pom.patch Quoting Joerg: Just an explanation: A namespace declaration is not an attribute (even if it looks so) and that's why it should not end as such. The DOM produced by Cocoon is absolutely correct, the one by parsing expected document in the test case is not since it has both the namespace declaration AND an attribute xmlns:fi - which broke our test. (http://article.gmane.org/gmane.text.xml.cocoon.devel/75975) Also see this: http://article.gmane.org/gmane.text.xml.cocoon.devel/75974 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2155) Failing test cases due to additional attributes from namespace declarations in a DOM from parser, but not from serializer
[ https://issues.apache.org/jira/browse/COCOON-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-2155: - Attachment: COCOON-2155-cocoon-template-impl.patch Added missing namespace prefix declarations. Failing test cases due to additional attributes from namespace declarations in a DOM from parser, but not from serializer - Key: COCOON-2155 URL: https://issues.apache.org/jira/browse/COCOON-2155 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Attachments: COCOON-2155-cocoon-core.patch, COCOON-2155-cocoon-forms-impl.patch, COCOON-2155-cocoon-template-impl.patch, COCOON-2155-parent-pom.patch Quoting Joerg: Just an explanation: A namespace declaration is not an attribute (even if it looks so) and that's why it should not end as such. The DOM produced by Cocoon is absolutely correct, the one by parsing expected document in the test case is not since it has both the namespace declaration AND an attribute xmlns:fi - which broke our test. (http://article.gmane.org/gmane.text.xml.cocoon.devel/75975) Also see this: http://article.gmane.org/gmane.text.xml.cocoon.devel/75974 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Broken test-cases due to missing namespace declarations
Joerg Heinicke pisze: It does not just wrap Xalan's DOMBuilder. It kind of does the same but has a different approach: Both build a DOM from SAX events but while Xalan's does it directly Cocoon's DOMBuilder utilizes a TransformerHandler and a DOMResult for it. Additionally listening capability is added and XMLPipe implemented. Also Xalan's DOMBuilder is more a internal class, it's not part of public API. It's a public class but unless you want to tie your code to Xalan there is no way to instantiate the class. That's what you usually do using SAXTransformerFactory as Cocoon's DOMBuilder does or DocumentBuilderFactory. The names matches more or less by coincidence. Thanks for explanation Joerg! Even I play with Cocoon for some time I don't know low-level details of Xalan but I think it only proves value of Cocoon that hides all these nasty details. :) Our code is not really broken. Usually we call startPrefixMapping() in startDocument() methods of transformers or something like this. It's only broken for the test cases since we just have a look at the component to test without its framework. From a component POV adding start/endPrefixMapping() is the correct solution to encapsulate it. The question I asked was only if these components will ever run outside of their current framework. Personally I prefer the correct approach as well. I see. Then, agreed with you. Anyway, I have taken effort of tweaking our components and test-cases so all of them pass now. You probably already noticed attached patches to COCOON-2155 issue. I would like to see them committed as soon as we can upgrade to Xalan 2.7.1. I have no idea what the different ways mean in regard of getting things done correctly and as fast as possible. I only got the jar from Antonio's commit to 2.1 and put it into my local repository by copying 2.7.0's POM. So the question should be addressed to Antonio: Where the jar of Xalan you committed into 2.1.x branch comes from? :) -- Grzegorz Kossakowski
Re: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute URIs
Joerg Heinicke pisze: Could anybody please sum up what the actual problem is and what the proposals are to solve it? So far I only got that there is an issue with cache key which can be solved by absolutizing URIs. Now there is this relative vs. absolute URI thing. What for do we need the +? What's the scheme for relative URIs? Yeah, sure. Little bit background on caching issue: Currently ServletSource.getURI() method returns relative URIs that look like this: servlet:[connection_name:]/path Where connect_name is name of connection to another servlet that is defined locally in a given servlet. If it's omitted then it means that URI references to the current servlet. The conclusion is that URIs of that form are relative to the servlet they are resolved in. E.g. servlet A can connect to servlet C with connection name foo, and servlet B can connect to servlet D with connection name foo as well. Then in servlet A URI: servlet:foo:/path point to completely different resource than the same URI in servlet B. We came to conclusion that the best way to absolutize URIs is to replace connection name (that is local to the given servlet) with servlet ID (more precisely, Spring bean ID) that is unique in whole application. Then if we absolutize URI from example above being in servlet A it would look like: servlet:servlet_C:/path and in servlet B the same URI would look like: servlet:servlet_D:/path The only problem is that we have no way to check if given URI contains connection name or servlet ID. Therefore the idea to add special sign that would remove the ambiguousness appeared. Current proposal are: a) add a plus sign after servlet ID (by Reinhard) b) add a exclamation mark at the very beginning of the path (by Vadim) My personal preference is a plus sign but as Reinhard already pointed out it does not matter that much because we usually won't be using absolute URIs directly. -- o0o -- Now it's the time to give some description of static connection list problem. Currently one can define list of connection of a given servlet statically in XML config. If you compile a block there is no chance to add new connections to other servlets. Now, imagine situation that you have some application making charts and you create separate block (and servlet) for each datasource provider. For example, you create block that extracts some data from database and second one that extracts some data from mailbox. If you want to pull this data, you need to connect to these two blocks of course so you add them to your local connection list. Now you can compile your application and everything will be working fine. But what if you want to define another datasource for your charts, for example data from some web service? Of course you develop a new block that downloads and transforms interesting data but you need a way to inform your appliction that there is a third block. The most obvious way is to add connection to the third block but this involves recompilation of your application! The solution that I and Reinhard (and probably others) have in mind is to let servlet use absolute URIs so you don't need to define connections statically to other block. There would be also some discovery mechanism of available blocks, probably a generator, that would return you a list of blocks fulfilling particular needs. The list would contain servlet ID of each servlet (block) so you could reference them later on. I hope this helps you a little bit. -- Grzegorz Kossakowski
[jira] Commented: (COCOON-2155) Failing test cases due to additional attributes from namespace declarations in a DOM from parser, but not from serializer
[
https://issues.apache.org/jira/browse/COCOON-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554637
]
Jörg Heinicke commented on COCOON-2155:
---
Some cp errors:
Index:
src/main/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionList.java
===
--- src/main/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionList.java
(revision 606943)
+++ src/main/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionList.java
(working copy)
@@ -116,6 +116,7 @@
}
// Start the selection-list
+contentHandler.startPrefixMapping(FormsConstants.INSTANCE_PREFIX,
FormsConstants.INSTANCE_PREFIX);
contentHandler.startElement(FormsConstants.INSTANCE_NS,
SELECTION_LIST_EL, FormsConstants.INSTANCE_PREFIX_COLON + SELECTION_LIST_EL,
XMLUtils.EMPTY_ATTRIBUTES);
if( this.nullable ) {
final AttributesImpl voidAttrs = new AttributesImpl( );
The second INSTANCE_PREFIX must be INSTANCE_NS.
Index: src/main/java/org/apache/cocoon/forms/datatype/EnumSelectionList.java
===
--- src/main/java/org/apache/cocoon/forms/datatype/EnumSelectionList.java
(revision 606943)
+++ src/main/java/org/apache/cocoon/forms/datatype/EnumSelectionList.java
(working copy)
@@ -96,6 +96,8 @@
Locale locale)
throws SAXException {
try {
+contentHandler.startPrefixMapping(FormsConstants.INSTANCE_PREFIX,
FormsConstants.INSTANCE_NS);
+contentHandler.startPrefixMapping(FormsConstants.I18N_PREFIX,
FormsConstants.INSTANCE_NS);
contentHandler.startElement(FormsConstants.INSTANCE_NS,
SELECTION_LIST_EL, FormsConstants.INSTANCE_PREFIX_COLON + SELECTION_LIST_EL,
XMLUtils.EMPTY_ATTRIBUTES);
// Create void element
if (nullable) {
The second INSTANCE_NS must be I18N_NS.
Regarding adding namespace declarations to the XML documents in cocoon-core and
cocoon-template: This should not be necessary as they are really superfluous. I
know though that Cocoon leaves superfluous namespace declarations in the
documents. Instead of relying on the behavior that the actual Cocoon components
always produce these superfluous namespace declarations it is probably better
to remove them. This should be possible using RedundantNamespacesFilter.
Failing test cases due to additional attributes from namespace declarations
in a DOM from parser, but not from serializer
-
Key: COCOON-2155
URL: https://issues.apache.org/jira/browse/COCOON-2155
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Affects Versions: 2.2-dev (Current SVN)
Reporter: Grzegorz Kossakowski
Attachments: COCOON-2155-cocoon-core.patch,
COCOON-2155-cocoon-forms-impl.patch, COCOON-2155-cocoon-template-impl.patch,
COCOON-2155-parent-pom.patch
Quoting Joerg:
Just an explanation: A namespace declaration is not an attribute (even
if it looks so) and that's why it should not end as such. The DOM
produced by Cocoon is absolutely correct, the one by parsing expected
document in the test case is not since it has both the namespace
declaration AND an attribute xmlns:fi - which broke our test.
(http://article.gmane.org/gmane.text.xml.cocoon.devel/75975)
Also see this: http://article.gmane.org/gmane.text.xml.cocoon.devel/75974
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Thanks Ralph [Was: 2.1.11 release]
Ralph Goers wrote: I committed the changes to 2.1.x. I'll try to get trunk done on 1/1/08 Thanks for that extra effort Ralph, in the midst of your preparations. Your ASF friends wish you well. -David
[jira] Commented: (COCOON-1831) Finish blocks-fw implementation
[ https://issues.apache.org/jira/browse/COCOON-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554654 ] Rice Yeh commented on COCOON-1831: -- Iteration over the whole call stack is my way to implement 'overriding' effect in values like parameters. For values' overriding, please see http://www.mail-archive.com/dev@cocoon.apache.org/msg52250.html. Finish blocks-fw implementation --- Key: COCOON-1831 URL: https://issues.apache.org/jira/browse/COCOON-1831 Project: Cocoon Issue Type: New Feature Components: - Servlet service framework Reporter: Reinhard Poetz Assignee: Reinhard Poetz Attachments: cocoon-servlet-service-impl.patch, cocoon-servlet-service-impl.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1574) Memory Leak with XMLFileModule
[ https://issues.apache.org/jira/browse/COCOON-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554656 ] Ralph Goers commented on COCOON-1574: - I have checked in XPathXMLFileModule which can be used as a replacement for XMLFileModule. It differs from XMLFileModule by 1. It caches a DocumentInfo instead of a DocumentHelper. DocumentInfo contains the Document, its Validity, the url, the resolver and the expression cache. The expression cache is a ReferenceMap containing soft references. 2. DocumentInfo objects are cached in an externally configurable cache. The default implementation uses ehcache. 3. The soruce url can contain variables which will be resolved each time the input module is used. The cache key used is the url after resolving variables. 4. Both the cacheable and reloadable parameters can be specified as variables which will be resolved each time the module is called. 5. The amount of code run in a synchronized block is much smaller. XPathXMLFileModule performs about the same as XMLFileModule under light load. Under heavy load it experiences much more consistent behavior than XMLFileModule. In testing XMLFileModule showed a very large standard deviation in response time with a very large maximum response compared to the minimum. XPathXMLFileModule has a much smaller standard deviation and a smaller maximum response time. 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-dev (Current SVN) Environment: Operating System: Windows XP Platform: PC Reporter: Ron Blaschke Assignee: Ralph Goers 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: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute URIs
Thanks for the explanation, except I'm still not clear what a connection name is. See below for my 2 cents. Grzegorz Kossakowski wrote: The only problem is that we have no way to check if given URI contains connection name or servlet ID. Therefore the idea to add special sign that would remove the ambiguousness appeared. Current proposal are: a) add a plus sign after servlet ID (by Reinhard) b) add a exclamation mark at the very beginning of the path (by Vadim) My personal preference is a plus sign but as Reinhard already pointed out it does not matter that much because we usually won't be using absolute URIs directly. Yuck, yuck, yuck. (If you get the impression I don't like a or b you are on track). c) Use a different scheme to identify one vs the other. d) Use a different pattern. i.e conventional urls look like http://authority/path where authority can be a variety of things such as server[:port], [EMAIL PROTECTED]:port] and server can be a domain name or an ip address. In this case, you could do something like servlet://[EMAIL PROTECTED]/path which, if I understood you correctly. could be abbreviated to servlet://connection/path. For servlet id you could use the same syntax with servlet://[EMAIL PROTECTED]/path. Of course, since I don't really know what a connection is I have no idea if this makes sense, but it could certainly be abbreviated to servlet://@servlet_id/path. Or use servlet://[connection][:id]/path, although servlet://:Servlet_C/path still looks a little odd. + and : characters in uri's just plain look strange, even if they are allowed, unless they are used in a similar fashion to existing schemes. Also, not having the // in the uri makes one wonder just what the token before the first slash is. Everybody knows that whatever follows the double slashes is not part of the path so it is less confusing. -- o0o -- Now it's the time to give some description of static connection list problem. Currently one can define list of connection of a given servlet statically in XML config. If you compile a block there is no chance to add new connections to other servlets. Now, imagine situation that you have some application making charts and you create separate block (and servlet) for each datasource provider. For example, you create block that extracts some data from database and second one that extracts some data from mailbox. If you want to pull this data, you need to connect to these two blocks of course so you add them to your local connection list. Now you can compile your application and everything will be working fine. But what if you want to define another datasource for your charts, for example data from some web service? Of course you develop a new block that downloads and transforms interesting data but you need a way to inform your appliction that there is a third block. The most obvious way is to add connection to the third block but this involves recompilation of your application! The solution that I and Reinhard (and probably others) have in mind is to let servlet use absolute URIs so you don't need to define connections statically to other block. There would be also some discovery mechanism of available blocks, probably a generator, that would return you a list of blocks fulfilling particular needs. The list would contain servlet ID of each servlet (block) so you could reference them later on. I hope this helps you a little bit. I still don't quite get this connection thing. What I don't get is why this can't just be servlet://[EMAIL PROTECTED]/path? Or better yet, why shouldn't my application just reference a bean id and wire it to the block service in its Spring configuration (think Spring remoting)? Please reply, even though I'll be on a plane in a few hours. I'm sure I'll find time to look at email while I'm out of town. Ralph
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
On 12/27/07, Carsten Ziegeler [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Cocoon-2.1 keeps applications (samples) in the webapp directory. Newbies would expect to add applications to that directory. The build process chooses specific files and directories to copy so new applications are not copied to the build directory. The patch removed the list of specific files to copy the entire webapp directory. I closed my Cocoon jiras because a release candidate for Cocoon-2.1.11 is being prepared. Antonio asked whether ant:copy had the intelligence to understand binary files should not be affected by text replacement. I have not studied ant to discover if the program is sane. This change passed my testing in May. The jira from June survived without comments. None of the comments in this thread mention real problems. The discussion is that nobody trusts ant to work properly so this patch should be reverted because theoretical problems may result if the ant developers are poor programmers. Nobody on the Cocoon project wants to spend five minutes testing. I will test more after somebody spends one minute to define the test expected to fail because of this patch. The potential bug seems to require binary files containing strings on ant's filter list. As Vadim has responded again: filtering should not be done on all files, otherwise they get corrupted. And this means whenever you copy a complete directory tree, you have to copy these files without filtering and if you need filtering for specific files, you need to do this in a second pass. This has been repeatedly said in this thread, so it would be great if you could come up with a solution that honours this. And this is independent from the fact, that currently copying all the files with filtering on does not corrupt them - it is a potential cause of error we would like to avoid. Ant allowing text filtering to affect binary files should be posted as a data-damaging bug. If this functionality is that bad, the Cocoon project is correct to not trust ant. Apart from that, I'm still wondering what your patch is trying to achieve? I really hope that you are not putting your own webapp into a Cocoon src directory and then hope for the cocoon build to pick up your files? You claim that newbies want to put their stuff directly into the Cocoon src/webapp directory? I never heard of this and actually I would strongly suggest against doing so. The old way of copying the webapp files actually prevented people from doing this - and I really prefer to keep it this way. There are several much better ways of building own applications. I believe software should be easy. The easiest and most common method of learning a new platform is to copy the demonstration application. Cocoon's demonstration application is samples. Copy samples to myfirstapp. Build. myfirstapp application does not work or even exist. Cocoon seems difficult and loses a customer. Why would you want to discourage putting applications in the src/webapp directory. Cocoon clearly recommends that as the proper directory. That is where the demonstration application is located. That is the only directory named app. Where else would anybody expect applications to be placed? Regarding your Jira issue: just because noone commented on it over the last months does not mean that this one got happily accepted by everyone. I guess it's just an oversight, I - for instance - didn't notice this issue until you changed the code. Nobody does. Don't worry about it. And, our build system is a very very fragile piece of code that caused way too many problems over the past (one of the reasons why we changed this for 2.2) - so it's in general not a good idea to change this fragile piece just before a release. Carsten I committed/closed my Cocoon jiras as soon as I learned a Cocoon release was planned. This may be the final release of Cocoon-2.1 so every change must be committed or discarded. solprovider
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
[EMAIL PROTECTED] wrote: I committed/closed my Cocoon jiras as soon as I learned a Cocoon release was planned. This may be the final release of Cocoon-2.1 so every change must be committed or discarded. I wouldn't get your hopes up on this one. 2.2 is sufficiently different enough that I would not be surprised to see a 2.1.12 release even after 2.2.0. Ralph
