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
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: [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
[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.
[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.
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-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 c&p 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.
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
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
[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.
[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-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-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.
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
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
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?
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
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: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute URIs
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
I've rewritten the ServletConnection and it always expects now globally
absolute URIs. If a service-relative URI is being resolved, the
ServletSource can translate it into an absolute one.
It looks like you implying that ServletConnection should never be used
directly only ServletSource, instead. Am I guessing right?
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)
Actually I've already implemented it this way ...
WDYT?
This should fix the cache key generation problem too.
Yep, I hope so.
Plus sign doesn't look naturally for me. Are there any other options?
Citing RFC 2396:
Scheme names consist of a sequence of characters beginning with a lower
case letter and followed by any combination of lower case letters, digits,
plus ("+"), period ("."), or hyphen ("-"). For resiliency, programs
interpreting URI should treat upper case letters as equivalent to lower
case in scheme names (e.g., allow "HTTP" as well as "http").
scheme= alpha *( alpha | digit | "+" | "-" | "." )
But since I strongly discourage from using absolute URIs directly, I don't
consider it being a big issue.
Aha, ok. I forgot that absolute URIs shouldn't be used directly in general.
Then I'm fine with plus sign.
It brings interesting question: if user is not supposed to use absolute URIs
directly will their usage be limited only to making ServletSource conforming
the API of Source interface thus generating proper cache keys? I was thinking
about dynamic connections between servlets but I would like to hear your
opinion.
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".
--
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
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
Reinhard Poetz pisze:
>
> I've rewritten the ServletConnection and it always expects now globally
> absolute URIs. If a service-relative URI is being resolved, the
> ServletSource can translate it into an absolute one.
It looks like you implying that ServletConnection should never be used directly
only ServletSource,
instead. Am I guessing right?
> This should fix the cache key generation problem too.
Yep, I hope so.
>>
>> Plus sign doesn't look naturally for me. Are there any other options?
>
> Citing RFC 2396:
>
>Scheme names consist of a sequence of characters beginning with a
>lower case letter and followed by any combination of lower case
>letters, digits, plus ("+"), period ("."), or hyphen ("-"). For
>resiliency, programs interpreting URI should treat upper case letters
>as equivalent to lower case in scheme names (e.g., allow "HTTP" as
>well as "http").
>
> scheme= alpha *( alpha | digit | "+" | "-" | "." )
>
>
> But since I strongly discourage from using absolute URIs directly, I don't
> consider it being a big issue.
Aha, ok. I forgot that absolute URIs shouldn't be used directly in general.
Then I'm fine with plus
sign.
It brings interesting question: if user is not supposed to use absolute URIs
directly will their
usage be limited only to making ServletSource conforming the API of Source
interface thus generating
proper cache keys? I was thinking about dynamic connections between servlets
but I would like to
hear your opinion.
--
Grzegorz Kossakowski
Re: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute URIs
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
In the discussion of COCOON-2044 it is mentioned that non-uniqueness of cache
keys is caused by bad implementation of servlet service because it returns
relative URIs instead of absolute ones when getURI() method is called. So in
order to fix COCOON-2044 you just need essentially to implement support of
absolute URI for servlet: protocol. That's why I see it as duplicate.
I've rewritten the ServletConnection and it always expects now globally absolute
URIs. If a service-relative URI is being resolved, the ServletSource can
translate it into an absolute one.
This should fix the cache key generation problem too.
Btw, after reading the URI spec and making some experiments with the URI
class of Java, I figured out that the originally proposed "!" at the
beginning of the sub schema is not allowed, however, appending a "+" is.
This is required in order to distinguish between relative and absolute
servlet:/ URIs.
Plus sign doesn't look naturally for me. Are there any other options?
Citing RFC 2396:
Scheme names consist of a sequence of characters beginning with a
lower case letter and followed by any combination of lower case
letters, digits, plus ("+"), period ("."), or hyphen ("-"). For
resiliency, programs interpreting URI should treat upper case letters
as equivalent to lower case in scheme names (e.g., allow "HTTP" as
well as "http").
scheme= alpha *( alpha | digit | "+" | "-" | "." )
But since I strongly discourage from using absolute URIs directly, I don't
consider it being a big issue.
--
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
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: 2.1.11 release
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? -- Grzegorz Kossakowski
2.1.11 release
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. Ralph Carsten Ziegeler wrote: If I get no response from Paul (or anyone else on this), I'll revert the change for the release. I'm currently planning to prepare the distribution next monday. Carsten
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
[EMAIL PROTECTED] wrote:
> Hi All,
>
> 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.
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.
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.
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
--
Carsten Ziegeler
[EMAIL PROTECTED]
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
On Dec 27, 2007, at 10:29 AM, [EMAIL PROTECTED] wrote: 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. It is not theoretical. Binary files, as well as UTF-8 encoded files, are corrupted by filtering=on. If you pull history of the build.xml file, I'm certain you will find relevant commits (you'd have to dig into C2.0 history though). Does Cocoon need the filtering? Yes, C2.1 needs filtering. Vadim Would filtering=no solve the concerns? solprovider
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
Hi All,
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.
Does Cocoon need the filtering? Would filtering=no solve the concerns?
solprovider
On 12/27/07, Thorsten Scherler
<[EMAIL PROTECTED]> wrote:
> On Thu, 2007-12-27 at 13:06 +0100, Carsten Ziegeler wrote:
> > If I get no response from Paul (or anyone else on this), I'll revert the
> > change for the release. I'm currently planning to prepare the
> > distribution next monday.
>
> Yes, please revert the commit.
>
> The fix was to have custom components in cocoon and the build will pick
> it up. But this can be done by a custom target as well. COCOON-2074.
>
> The filtering needs to be off for binary stuff like other have been
> pointed out so it is doing more harm then good.
>
> > Carsten Ziegeler wrote:
> > > At least the resources have been copied with filtering "off" before. As
> > > the resources contain images and other binary stuff, this changes
> > > breakes definitly the build as binary files have to be copied with
> > > filtering turned off.
> > >
> > > Apart from that, I'm wondering what this change tries to fix.
> > >
> > > So Paul, please comment on this issue.
> > >
> > > Thanks
> > > Carsten
> > >
> > > Antonio Gallardo wrote:
> > >> Hi solprovider,
> > >>
> > >> I am wondering if a simple
> > >>
> > >> filtering="on" statement can replace the previous code. I recall issues
> > >> with files that become broken on the resources if we use filtering. And
> > >> also some files we don't want on the final webapp.
> > >>
> > >> Best Regards,
> > >>
> > >> Antonio Gallardo.
> > >>
> > >>
> > >> [EMAIL PROTECTED] escribió:
> > >>> Author: solprovider
> > >>> Date: Mon Dec 24 14:03:31 2007
> > >>> New Revision: 606743
> > >>>
> > >>> URL: http://svn.apache.org/viewvc?rev=606743&view=rev
> > >>> Log:
> > >>> The build process carefully adds each of the standard files in the
> > >>> webapp directory. New applications are not included in the build
> > >>> process. No files need to be excluded. This change copies the entire
> > >>> directory. (COCOON-2074)
> > >>>
> > >>> Modified:
> > >>> cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
> > >>>
> > >>> Modified: cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
> > >>> URL:
> > >>> http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml?rev=606743&r1=606742&r2=606743&view=diff
> > >>>
> > >>> ==
> > >>>
> > >>> --- cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
> > >>> (original)
> > >>> +++ cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml Mon
> > >>> Dec 24 14:03:31 2007
> > >>> @@ -25,33 +25,9 @@
> > >>>
> > >>>
> > >>>
> > >>> - > >>> tofile="${build.webapp}/welcome.xml" filtering="on"/>
> > >>> - > >>> tofile="${build.webapp}/not-found.xml" filtering="on"/>
> > >>> - > >>> tofile="${build.webapp}/welcome.xslt" filtering="on"/>
> > >>> - > >>> tofile="${build.webapp}/sitemap.xmap"/>
> > >>> -
> > >>> -
> > >>> -
> > >>> -
> > >>> -
> > >>> -
> > >>> -
> > >>> -
> > >>> -
> > >>> -
> > >>> -
> > >>> -
> > >>> -
> > >>> -
> > >>> -
> > >>> -
> > >>> -
> > >>> -
> > >>> -
> > >>> -
> > >>> -
> > >>> +
> > >>> +
> > >>> +
> > >>>
> > >>> > >>>tofile="${build.webapp.lib}/${name}-${version}.jar"/>
> Thorsten Scherler thorsten.at.apache.org
> Open Source Java consulting, training and solutions
Broken test-cases due to missing namespace declarations (was: Re: svn commit: r597535 - in /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src: main/java/org/apache/cocoon/forms/datatype/FlowJXPat
Joerg Heinicke pisze: > Grek, thanks for your work on this. I figured out the missing pieces. Great, thanks! :) > First, I did not know that DOM is slightly different than the theory of > XML. Nor I did at the firs time. ;) > 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. Isn't it? Can this be simplified? > Third, there is a missing piece though to make it work: 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 (though there is still an issue with the missing > implementation of the latter [1]) the test passed without the explicit > removal of the namespace attribute. Ah, here is the missing detail! :-) I'm very happy to hear that we have some progress on this annoying issue. > 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. I'm happy to help (or even take care of all the task) with fixing our code. 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)? What's more, it seems that jars of older Xalan versions available on Maven repository is not the same as jars in archive downloaded from Xalan site. The later is split into two jars: * xalan.jar * serializer.jar whereas jar from repository has classes from both xalan.jar and serializer.jar. -- Grzegorz Kossakowski
[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: svn commit: r597535 - in /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src: main/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionList.java test/java/org/apache/cocoon/forms/datatype
Grek, thanks for your work on this. I figured out the missing pieces. First, I did not know that DOM is slightly different than the theory of XML. On 27.12.2007 12:46 Uhr, Grzegorz Kossakowski wrote: Grzegorz Kossakowski pisze: 3. My gut feeling is that we are affected by XALANJ-2091[2] bug. I'll try to verify my feelings tomorrow. I have checked if update to Xalan 2.7.1 helps and it's not. Anyway, after taking closer look at our code it's not a surprise because we don't use DOMBuilder from Xalan but our own class. 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. Third, there is a missing piece though to make it work: 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 (though there is still an issue with the missing implementation of the latter [1]) 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. Joerg
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
On Thu, 2007-12-27 at 13:06 +0100, Carsten Ziegeler wrote:
> If I get no response from Paul (or anyone else on this), I'll revert the
> change for the release. I'm currently planning to prepare the
> distribution next monday.
Yes, please revert the commit.
The fix was to have custom components in cocoon and the build will pick
it up. But this can be done by a custom target as well. COCOON-2074.
The filtering needs to be off for binary stuff like other have been
pointed out so it is doing more harm then good.
salu2
>
> Carsten
>
> Carsten Ziegeler wrote:
> > At least the resources have been copied with filtering "off" before. As
> > the resources contain images and other binary stuff, this changes
> > breakes definitly the build as binary files have to be copied with
> > filtering turned off.
> >
> > Apart from that, I'm wondering what this change tries to fix.
> >
> > So Paul, please comment on this issue.
> >
> > Thanks
> > Carsten
> >
> > Antonio Gallardo wrote:
> >> Hi solprovider,
> >>
> >> I am wondering if a simple
> >>
> >> filtering="on" statement can replace the previous code. I recall issues
> >> with files that become broken on the resources if we use filtering. And
> >> also some files we don't want on the final webapp.
> >>
> >> Best Regards,
> >>
> >> Antonio Gallardo.
> >>
> >>
> >> [EMAIL PROTECTED] escribió:
> >>> Author: solprovider
> >>> Date: Mon Dec 24 14:03:31 2007
> >>> New Revision: 606743
> >>>
> >>> URL: http://svn.apache.org/viewvc?rev=606743&view=rev
> >>> Log:
> >>> The build process carefully adds each of the standard files in the
> >>> webapp directory. New applications are not included in the build
> >>> process. No files need to be excluded. This change copies the entire
> >>> directory. (COCOON-2074)
> >>>
> >>> Modified:
> >>> cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
> >>>
> >>> Modified: cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
> >>> URL:
> >>> http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml?rev=606743&r1=606742&r2=606743&view=diff
> >>>
> >>> ==
> >>>
> >>> --- cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
> >>> (original)
> >>> +++ cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml Mon
> >>> Dec 24 14:03:31 2007
> >>> @@ -25,33 +25,9 @@
> >>>
> >>>
> >>>
> >>> - >>> tofile="${build.webapp}/welcome.xml" filtering="on"/>
> >>> - >>> tofile="${build.webapp}/not-found.xml" filtering="on"/>
> >>> - >>> tofile="${build.webapp}/welcome.xslt" filtering="on"/>
> >>> - >>> tofile="${build.webapp}/sitemap.xmap"/>
> >>> -
> >>> -
> >>> -
> >>> -
> >>> -
> >>> -
> >>> -
> >>> -
> >>> -
> >>> -
> >>> -
> >>> -
> >>> -
> >>> -
> >>> -
> >>> -
> >>> -
> >>> -
> >>> -
> >>> -
> >>> -
> >>> +
> >>> +
> >>> +
> >>>
> >>> >>>tofile="${build.webapp.lib}/${name}-${version}.jar"/>
> >>>
> >>>
> >>
> >
> >
>
>
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
If I get no response from Paul (or anyone else on this), I'll revert the
change for the release. I'm currently planning to prepare the
distribution next monday.
Carsten
Carsten Ziegeler wrote:
> At least the resources have been copied with filtering "off" before. As
> the resources contain images and other binary stuff, this changes
> breakes definitly the build as binary files have to be copied with
> filtering turned off.
>
> Apart from that, I'm wondering what this change tries to fix.
>
> So Paul, please comment on this issue.
>
> Thanks
> Carsten
>
> Antonio Gallardo wrote:
>> Hi solprovider,
>>
>> I am wondering if a simple
>>
>> filtering="on" statement can replace the previous code. I recall issues
>> with files that become broken on the resources if we use filtering. And
>> also some files we don't want on the final webapp.
>>
>> Best Regards,
>>
>> Antonio Gallardo.
>>
>>
>> [EMAIL PROTECTED] escribió:
>>> Author: solprovider
>>> Date: Mon Dec 24 14:03:31 2007
>>> New Revision: 606743
>>>
>>> URL: http://svn.apache.org/viewvc?rev=606743&view=rev
>>> Log:
>>> The build process carefully adds each of the standard files in the
>>> webapp directory. New applications are not included in the build
>>> process. No files need to be excluded. This change copies the entire
>>> directory. (COCOON-2074)
>>>
>>> Modified:
>>> cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
>>>
>>> Modified: cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
>>> URL:
>>> http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml?rev=606743&r1=606742&r2=606743&view=diff
>>>
>>> ==
>>>
>>> --- cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
>>> (original)
>>> +++ cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml Mon
>>> Dec 24 14:03:31 2007
>>> @@ -25,33 +25,9 @@
>>>
>>>
>>>
>>> ->> tofile="${build.webapp}/welcome.xml" filtering="on"/>
>>> ->> tofile="${build.webapp}/not-found.xml" filtering="on"/>
>>> ->> tofile="${build.webapp}/welcome.xslt" filtering="on"/>
>>> ->> tofile="${build.webapp}/sitemap.xmap"/>
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> -
>>> +
>>> +
>>> +
>>>
>>> >>tofile="${build.webapp.lib}/${name}-${version}.jar"/>
>>>
>>>
>>
>
>
--
Carsten Ziegeler
[EMAIL PROTECTED]
Re: svn commit: r597535 - in /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src: main/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionList.java test/java/org/apache/cocoon/forms/datatype
Grzegorz Kossakowski pisze: > 3. My gut feeling is that we are affected by XALANJ-2091[2] bug. I'll try to > verify my feelings > tomorrow. I have checked if update to Xalan 2.7.1 helps and it's not. Anyway, after taking closer look at our code it's not a surprise because we don't use DOMBuilder from Xalan but our own class. Current problem is that I cannot debug Cocoon in Eclipse (some weird classpath issues) so I lost any chance to figure out what's wrong. :-( -- Grzegorz Kossakowski
