Re: [cocoon-2.2] Deprecation
Vadim Gritsenko wrote: The first step IMHO should be to make sure core Cocoon 2.1 functionality is working. Take a look at Core Samples. Once all of them are working I'd be more comfortable discussing all other steps. This one bothers me most... http://localhost:/samples/core/aggregation/aggregate3 Failing XSLTC is also a problem but not as critical. There is also some XML APIs conflict in XInclude sample... http://localhost:/samples/core/aggregation/test.html Vadim
Re: Request for editing rights
Stephane Bonhomme pisze: Hello devs, Hello. May I have the editing right on the cocoon site plese, would like to add myself as freelance providing services on Cocoon, What's your user name in Daisy? -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Request for editing rights
Hello devs, May I have the editing right on the cocoon site plese, would like to add myself as freelance providing services on Cocoon, Thanks in advance. -- Stéphane Bonhomme -- Exselt Services Formations, Conseil et Réalisations en Ingénierie Documentaire, Technologies Web et Logiciels Libres [EMAIL PROTECTED] - http://www.exselt.com 04 57 39 30 78/ 06 88 57 27 08
[jira] Updated: (COCOON-2146) Using EventAware cache implementation breaks persistent cache restore on restart
[ https://issues.apache.org/jira/browse/COCOON-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ellis Pritchard updated COCOON-2146: Attachment: patch.txt Patch file for EventRegistryDataWrapper.java and AbstractDoubleMapEventRegistry.java to restore cache serializability and thus recovery. Using EventAware cache implementation breaks persistent cache restore on restart Key: COCOON-2146 URL: https://issues.apache.org/jira/browse/COCOON-2146 Project: Cocoon Issue Type: Bug Components: Blocks: Event Cache Affects Versions: 2.1.10, 2.1.11-dev (Current SVN) Reporter: Ellis Pritchard Priority: Minor Attachments: patch.txt In revision 412307 (Cocoon 2.1.10), AbstractDoubleMapEventRegistry and EventRegistryDataWrapper were changed (without an informative SVN comment!) to use the commons MultiValueMap instead of the MultiHashMap; I presume this was done in good faith because the latter map is deprecated and will be removed from Apache commons-collections 4.0 However, as a result, the persistent cache cannot be restored if the EventAware cache implementation is used, since MultiValueMap is not Serializable! The old MultiHashMap was... Depending on whether StoreEventRegistryImpl or DefaultEventRegistryImpl is used, either the event cache index is never written (ehcache doesn't store non-serializable objects on disk), or a java.io.NotSerializableException is thrown (and caught, causing a full cache-clear) when attempting to restore the event cache index. This is Major for us, since we use Event-based caching alot, and this is causing the *entire* cache to no-longer persist across restarts (it's been like that for 8 months, since I upgraded Cocoon to 2.1.10 in the last week I was working here, and now I'm back, they've actually noticed!!) Work-around at the moment is to down-grade AbstractDoubleMapEventRegistry and EventRegistryDataWrapper to the 2.1.9 versions (pre-412307), which works so long as Apache-commons 3.x is still in use. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2146) Using EventAware cache implementation breaks persistent cache restore on restart
[ https://issues.apache.org/jira/browse/COCOON-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2146: Assignee: Grzegorz Kossakowski Using EventAware cache implementation breaks persistent cache restore on restart Key: COCOON-2146 URL: https://issues.apache.org/jira/browse/COCOON-2146 Project: Cocoon Issue Type: Bug Components: Blocks: Event Cache Affects Versions: 2.1.10, 2.1.11-dev (Current SVN) Reporter: Ellis Pritchard Assignee: Grzegorz Kossakowski Priority: Minor Attachments: patch.txt In revision 412307 (Cocoon 2.1.10), AbstractDoubleMapEventRegistry and EventRegistryDataWrapper were changed (without an informative SVN comment!) to use the commons MultiValueMap instead of the MultiHashMap; I presume this was done in good faith because the latter map is deprecated and will be removed from Apache commons-collections 4.0 However, as a result, the persistent cache cannot be restored if the EventAware cache implementation is used, since MultiValueMap is not Serializable! The old MultiHashMap was... Depending on whether StoreEventRegistryImpl or DefaultEventRegistryImpl is used, either the event cache index is never written (ehcache doesn't store non-serializable objects on disk), or a java.io.NotSerializableException is thrown (and caught, causing a full cache-clear) when attempting to restore the event cache index. This is Major for us, since we use Event-based caching alot, and this is causing the *entire* cache to no-longer persist across restarts (it's been like that for 8 months, since I upgraded Cocoon to 2.1.10 in the last week I was working here, and now I'm back, they've actually noticed!!) Work-around at the moment is to down-grade AbstractDoubleMapEventRegistry and EventRegistryDataWrapper to the 2.1.9 versions (pre-412307), which works so long as Apache-commons 3.x is still in use. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [cocoon-2.2] Deprecation
Grzegorz Kossakowski wrote: Vadim Gritsenko pisze: Vadim Gritsenko wrote: The first step IMHO should be to make sure core Cocoon 2.1 functionality is working. Take a look at Core Samples. Once all of them are working I'd be more comfortable discussing all other steps. This one bothers me most... http://localhost:/samples/core/aggregation/aggregate3 Take a look at sitemap snippet: map:match pattern=aggregate3 map:generate src=aggregate.xml/ map:transform type=include map:parameter name=parallel value=true/ !-- this setting makes a sample failing -- /map:transform map:transform src=stylesheets/news.xsl/ map:serialize/ /map:match If you change it to false everything will work fine. I have no idea how o.a.c.transformation.IncludeTransformer works so I'm not sure why it makes our processing logic to fail. To be honest, I didn't even know that such transformer exists up to now. Why do we need 3 different transformers doing exactly the same? cinclude is old code, ready to be deprecated. include is new code, with new features (like parallel includes), and xinclude is based on a standard. If you can add xinclude into include transformer, feel free to deprecate xinclude. As it only fails in parallel mode I wouldn't consider it as critical problem but certainly it's wise to create a bug report in JIRA so the problem is not lost. It is critical. It also probably means that cron jobs will fail too. Failing XSLTC is also a problem but not as critical. What's the error when it fails? Can you give me a pointer to a sample exhibiting this problem? add type=xsltc to any transform. Something about missing class. There is also some XML APIs conflict in XInclude sample... http://localhost:/samples/core/aggregation/test.html Hmmm? This one works fine for me. This is the stacktrace I've got: HTTP ERROR: 500 javax.xml.transform.dom.DOMResult.getNextSibling()Lorg/w3c/dom/Node; RequestURI=/samples/core/aggregation/test.html Caused by: java.lang.NoSuchMethodError: javax.xml.transform.dom.DOMResult.getNextSibling()Lorg/w3c/dom/Node; at org.apache.xalan.transformer.TransformerIdentityImpl.createResultContentHandler(TransformerIdentityImpl.java:199) at org.apache.xalan.transformer.TransformerIdentityImpl.setDocumentLocator(TransformerIdentityImpl.java:880) at org.apache.cocoon.xml.AbstractXMLPipe.setDocumentLocator(AbstractXMLPipe.java:39) at org.apache.xerces.parsers.AbstractSAXParser.startDocument(Unknown Source) at org.apache.xerces.impl.dtd.XMLDTDValidator.startDocument(Unknown Source) at org.apache.xerces.impl.XMLDocumentScannerImpl.startEntity(Unknown Source) at org.apache.xerces.impl.XMLVersionDetector.startDocumentParsing(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.cocoon.core.xml.impl.JaxpSAXParser.parse(JaxpSAXParser.java:196) at org.apache.cocoon.core.xml.avalon.DefaultSAXParser.parse(DefaultSAXParser.java:47) at org.apache.excalibur.xmlizer.DefaultXMLizer.toSAX(DefaultXMLizer.java:127) at org.apache.cocoon.components.source.util.SourceUtil.toSAX(SourceUtil.java:180) at org.apache.cocoon.components.source.util.SourceUtil.toDOM(SourceUtil.java:318) at org.apache.cocoon.components.xpointer.XPointerContext.getDocument(XPointerContext.java:66) at org.apache.cocoon.components.xpointer.XPointerPart.process(XPointerPart.java:43) at org.apache.cocoon.components.xpointer.XPointer.process(XPointer.java:45) at org.apache.cocoon.transformation.XIncludeTransformer$XIncludePipe.processXIncludeElement(XIncludeTransformer.java:477) at org.apache.cocoon.transformation.XIncludeTransformer$XIncludePipe.startElement(XIncludeTransformer.java:243) at org.apache.cocoon.xml.AbstractXMLPipe.startElement(AbstractXMLPipe.java:94) at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:72) at $Proxy13.startElement(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) at
Re: lenya 2.0 release preparation - cocoon version dependency (2.1.11?)
On Nov 15, 2007 9:41 AM, Carsten Ziegeler [EMAIL PROTECTED] wrote: ...I think it makes sense to do a 2.1.11 release as a maintenance release, especially if Lenya wants to use this version. However, the only problem I see right now is the question of the qualitify. Which means, how many people are using latest svn and/or have tested it?... If Lenya is using it successfully, and if our automated tests pass (I can run them on Linux and MacOSX when the time comes) I'd be ok with making a release. There have been some small changes since 2.1.10, and little is happening in the 2.1 branch, so it might be good to do a release of that. -Bertrand
Re: [cocoon-2.2] Deprecation
Vadim Gritsenko pisze: Vadim Gritsenko wrote: The first step IMHO should be to make sure core Cocoon 2.1 functionality is working. Take a look at Core Samples. Once all of them are working I'd be more comfortable discussing all other steps. This one bothers me most... http://localhost:/samples/core/aggregation/aggregate3 Take a look at sitemap snippet: map:match pattern=aggregate3 map:generate src=aggregate.xml/ map:transform type=include map:parameter name=parallel value=true/ !-- this setting makes a sample failing -- /map:transform map:transform src=stylesheets/news.xsl/ map:serialize/ /map:match If you change it to false everything will work fine. I have no idea how o.a.c.transformation.IncludeTransformer works so I'm not sure why it makes our processing logic to fail. To be honest, I didn't even know that such transformer exists up to now. Why do we need 3 different transformers doing exactly the same? As it only fails in parallel mode I wouldn't consider it as critical problem but certainly it's wise to create a bug report in JIRA so the problem is not lost. Failing XSLTC is also a problem but not as critical. What's the error when it fails? Can you give me a pointer to a sample exhibiting this problem? There is also some XML APIs conflict in XInclude sample... http://localhost:/samples/core/aggregation/test.html Hmmm? This one works fine for me. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: lenya 2.0 release preparation - cocoon version dependency (2.1.11?)
Juergen Ragaller wrote: Hi Cocoon devs The Lenya community is preparing for a lenya 2.0 release. A considerable part of our testing was done against the 2.1.x trunk of cocoon as the 2.1.x cocoon trunk has been very stable for quite some time. We just talked about declaring either a 2.1.10 or SVN-Version 595020 dependency. The most desirable way for us would be to ship lenya with a 2.1.11 dependency. Reading the cocoon dev list, I'm very much aware, that you're working on a 2.2 release. Do you plan to release 2.1.11 as well in the near future? Thanks a lot for an orientation about the topic ...and for this nice software! We have no real plans or another 2.1.x release, although we talked briefly about it over the last year several times. I think it makes sense to do a 2.1.11 release as a maintenance release, especially if Lenya wants to use this version. However, the only problem I see right now is the question of the qualitify. Which means, how many people are using latest svn and/or have tested it? If I get enough positive feedback about the current state I'm happy to prepare a release of 2.1.11 in December. WDYT? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [cocoon-2.2] Deprecation
Vadim Gritsenko pisze: And this is contents of the WEB-INF/lib/ folder... xalan-2.7.0.jar xercesImpl-2.8.1.jar xml-apis-1.3.02.jar xml-resolver-1.2.jar xmlParserAPIs-2.0.2.jar Seems like there should be only one of jar - xml-apis-1.3.02.jar or xmlParserAPIs-2.0.2.jar - not both of them. Vadim, could you execute mvn project-info-reports:dependencies (in cocoon-webapp) and take a look at target/reports to figure out from where they are coming? -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: lenya 2.0 release preparation - cocoon version dependency (2.1.11?)
Grzegorz Kossakowski wrote: Florian, I completely forgot about this. Since your report looks to be perfect (screenshots, sample files etc.) it should be really appreciated by fixing it. I won't make any promises but since it also affects 2.2 and there is about a month left to planned(?) release of Cocoon 2.1.11 I may have a free time to dig into it You're still my personal hero :-) Perhaps as Xmas present :-P Greetings, Florian
Re: [cocoon-2.2] Deprecation
Vadim Gritsenko wrote: Grzegorz Kossakowski wrote: Vadim Gritsenko pisze: There is also some XML APIs conflict in XInclude sample... http://localhost:/samples/core/aggregation/test.html Hmmm? This one works fine for me. This is the stacktrace I've got: HTTP ERROR: 500 javax.xml.transform.dom.DOMResult.getNextSibling()Lorg/w3c/dom/Node; RequestURI=/samples/core/aggregation/test.html Caused by: java.lang.NoSuchMethodError: javax.xml.transform.dom.DOMResult.getNextSibling()Lorg/w3c/dom/Node; ... And this is contents of the WEB-INF/lib/ folder... xalan-2.7.0.jar xercesImpl-2.8.1.jar xml-apis-1.3.02.jar xml-resolver-1.2.jar xmlParserAPIs-2.0.2.jar Seems like there should be only one of jar - xml-apis-1.3.02.jar or xmlParserAPIs-2.0.2.jar - not both of them. Vadim
Re: lenya 2.0 release preparation - cocoon version dependency (2.1.11?)
Carsten Ziegeler pisze: Juergen Ragaller wrote: Hi Cocoon devs The Lenya community is preparing for a lenya 2.0 release. A considerable part of our testing was done against the 2.1.x trunk of cocoon as the 2.1.x cocoon trunk has been very stable for quite some time. We just talked about declaring either a 2.1.10 or SVN-Version 595020 dependency. The most desirable way for us would be to ship lenya with a 2.1.11 dependency. Reading the cocoon dev list, I'm very much aware, that you're working on a 2.2 release. Do you plan to release 2.1.11 as well in the near future? Thanks a lot for an orientation about the topic ...and for this nice software! We have no real plans or another 2.1.x release, although we talked briefly about it over the last year several times. I think it makes sense to do a 2.1.11 release as a maintenance release, especially if Lenya wants to use this version. However, the only problem I see right now is the question of the qualitify. Which means, how many people are using latest svn and/or have tested it? I guess the number of peopling using HEAD of 2.1.x is pretty high. I estimation bases on several talks with people during GT, they all have been using 2.1.x. If I get enough positive feedback about the current state I'm happy to prepare a release of 2.1.11 in December. Thanks for offer Carsten, I will help with testing (based only on samples, though). When we at 2.1.x, I have been wondering about freezing this branch. In a fact, it's already almost dead but lots of people are still using 2.1.x. Therefore I would like to hear your opinions on calling bug-squash effort. I mean: I would prepare an announcement at our site and announcement to the user list calling our users to vote for issues they would love to have fixed. The rules of the game would be simple: everyone is free to present favourites on users list and encourage others to vote on their issues. Then, if there is a decent number of volunteers, everyone could pick up an issue from the top of the most voted issues list and fix it? Of course issues having a patch already could go in first. After 2.1.11 I would like to close 2.1.x branch completely. WDYT? -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: [cocoon-2.2] Deprecation
Grzegorz Kossakowski wrote: Vadim Gritsenko pisze: And this is contents of the WEB-INF/lib/ folder... xalan-2.7.0.jar xercesImpl-2.8.1.jar xml-apis-1.3.02.jar xml-resolver-1.2.jar xmlParserAPIs-2.0.2.jar Seems like there should be only one of jar - xml-apis-1.3.02.jar or xmlParserAPIs-2.0.2.jar - not both of them. Vadim, could you execute mvn project-info-reports:dependencies (in cocoon-webapp) and take a look at target/reports to figure out from where they are coming? Here we go... * batik:batik-ext:jar * xml-apis:xmlParserAPIs:jar Vadim
Logging, Re: [jira] Created: (COCOON-2147) Log4j configuration is loaded to late with Spring Configurator
Carsten Ziegeler (JIRA) wrote: Log4j configuration is loaded to late with Spring Configurator ... There might be different solutions for this: a) Provide a configuration servlet/servlet listener (Spring provides one as well, but that's only usuable inside an expanded war file) b) Create an XML tag for spring configuration (like we do for the settings). This will ensure that logging is setup before beans are setup I'd prefer either a or b. b is even better since you don't have to touch web.xml. Speaking of logging, I think latest jetty maven plugin (or something else?) broke all the logging and now everything is dumped to the console, and log file is empty. It started doing this for me day or two ago. Vadim
Re: [cocoon-2.2] Deprecation
Vadim Gritsenko pisze: cinclude is old code, ready to be deprecated. include is new code, with new features (like parallel includes), and xinclude is based on a standard. If you can add xinclude into include transformer, feel free to deprecate xinclude. Thanks for explanation. I'm not sure if I'm going to have a free time to merge XInclude and Include transformers but could we at least deprecate CInclude? I hope nobody is going to have any objections. As it only fails in parallel mode I wouldn't consider it as critical problem but certainly it's wise to create a bug report in JIRA so the problem is not lost. It is critical. It also probably means that cron jobs will fail too. :-) We seem to have different understanding of critical. I think that critical issues are those for which there is no real work-around present. For this one (at least at this stage when we don't know if cron jobs fail) there is an easy one: turn parallelism off. On the other hand, it's a major loss of function so the best is to describe it as major problem. Nevertheless, it's the best to fix the issue instead of seeking for right words describing importance, isn't it? :) Vadim, are you willing to spend time on this? If you don't I could have a look over the weekend. add type=xsltc to any transform. Something about missing class. Will do it later. It may be just missing dependency. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: lenya 2.0 release preparation - cocoon version dependency (2.1.11?)
Bertrand Delacretaz wrote: If Lenya is using it successfully, and if our automated tests pass (I can run them on Linux and MacOSX when the time comes) I'd be ok with making a release. There have been some small changes since 2.1.10, and little is happening in the 2.1 branch, so it might be good to do a release of that. BTW, does anyone want to adopt this orphaned issue? : https://issues.apache.org/jira/browse/COCOON-2126 Hoping against hope :-) Florian
Re: [cocoon-2.2] Deprecation
Grzegorz Kossakowski wrote: Vadim Gritsenko pisze: Grzegorz Kossakowski wrote: Vadim Gritsenko pisze: Vadim, could you execute mvn project-info-reports:dependencies (in cocoon-webapp) and take a look at target/reports to figure out from where they are coming? Here we go... * batik:batik-ext:jar * xml-apis:xmlParserAPIs:jar So it's easy to fix as soon as we establish which version Cocoon should use, any idea if it should be 1.3.x or 2.0.x ? It should be xml-apis 1.3.x. IIUC, xmlParserAPIs 2.0 is some old stuff. Vadim
Re: lenya 2.0 release preparation - cocoon version dependency (2.1.11?)
Dev at weitling pisze: Bertrand Delacretaz wrote: If Lenya is using it successfully, and if our automated tests pass (I can run them on Linux and MacOSX when the time comes) I'd be ok with making a release. There have been some small changes since 2.1.10, and little is happening in the 2.1 branch, so it might be good to do a release of that. BTW, does anyone want to adopt this orphaned issue? : https://issues.apache.org/jira/browse/COCOON-2126 Hoping against hope :-) Florian, I completely forgot about this. Since your report looks to be perfect (screenshots, sample files etc.) it should be really appreciated by fixing it. I won't make any promises but since it also affects 2.2 and there is about a month left to planned(?) release of Cocoon 2.1.11 I may have a free time to dig into it. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: Logging, Re: [jira] Created: (COCOON-2147) Log4j configuration is loaded to late with Spring Configurator
Vadim Gritsenko wrote: Carsten Ziegeler (JIRA) wrote: Log4j configuration is loaded to late with Spring Configurator ... There might be different solutions for this: a) Provide a configuration servlet/servlet listener (Spring provides one as well, but that's only usuable inside an expanded war file) b) Create an XML tag for spring configuration (like we do for the settings). This will ensure that logging is setup before beans are setup I'd prefer either a or b. b is even better since you don't have to touch web.xml. Yes, but with b) still this can be too late as you don't catch logging statements from Spring happening before our logging tag is read. Personally I could live with that. Thinking about this, I have the feeling that it's not Cocoon's task to configure logging. It's not our concern, it should more be the concern of Spring as the core framework underneath everything. But the interesting part is that even Spring has only partial support for that. And I'm wondering why noone has complained about this yet. Speaking of logging, I think latest jetty maven plugin (or something else?) broke all the logging and now everything is dumped to the console, and log file is empty. It started doing this for me day or two ago. Strange, I think this happened a year ago with another jetty release as well. It was afaik some changes in class loading hierarchy and provided jars from jetty. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [cocoon-2.2] Deprecation
Grzegorz Kossakowski wrote: Vadim Gritsenko pisze: cinclude is old code, ready to be deprecated. include is new code, with new features (like parallel includes), and xinclude is based on a standard. If you can add xinclude into include transformer, feel free to deprecate xinclude. Thanks for explanation. I'm not sure if I'm going to have a free time to merge XInclude and Include transformers but could we at least deprecate CInclude? I hope nobody is going to have any objections. Feel free to start separate thread about it... As it only fails in parallel mode I wouldn't consider it as critical problem but certainly it's wise to create a bug report in JIRA so the problem is not lost. It is critical. It also probably means that cron jobs will fail too. :-) We seem to have different understanding of critical. I think that critical issues are those for which there is no real work-around present. For this one (at least at this stage when we don't know if cron jobs fail) there is an easy one: turn parallelism off. On the other hand, it's a major loss of function so the best is to describe it as major problem. Nevertheless, it's the best to fix the issue instead of seeking for right words describing importance, isn't it? :) Vadim, are you willing to spend time on this? If you don't I could have a look over the weekend. I don't know if I can look at it this week... It certainly is on my radar, together with pipeline lock bug. add type=xsltc to any transform. Something about missing class. Will do it later. It may be just missing dependency. BCEL :) It is required for XSLTC and it is indeed missing. Vadim
Re: Logging, Re: [jira] Created: (COCOON-2147) Log4j configuration is loaded to late with Spring Configurator
Vadim Gritsenko wrote: Carsten Ziegeler (JIRA) wrote: Log4j configuration is loaded to late with Spring Configurator ... There might be different solutions for this: a) Provide a configuration servlet/servlet listener (Spring provides one as well, but that's only usuable inside an expanded war file) b) Create an XML tag for spring configuration (like we do for the settings). This will ensure that logging is setup before beans are setup I'd prefer either a or b. b is even better since you don't have to touch web.xml. Speaking of logging, I think latest jetty maven plugin (or something else?) broke all the logging and now everything is dumped to the console, and log file is empty. It started doing this for me day or two ago. By default log4j loads the log4j.properties from the classpath. Perhaps this is enough? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [cocoon-2.2] Deprecation
Vadim Gritsenko pisze: Grzegorz Kossakowski wrote: Vadim Gritsenko pisze: Vadim, could you execute mvn project-info-reports:dependencies (in cocoon-webapp) and take a look at target/reports to figure out from where they are coming? Here we go... * batik:batik-ext:jar * xml-apis:xmlParserAPIs:jar So it's easy to fix as soon as we establish which version Cocoon should use, any idea if it should be 1.3.x or 2.0.x ? -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
[jira] Created: (COCOON-2147) Log4j configuration is loaded to late with Spring Configurator
Log4j configuration is loaded to late with Spring Configurator -- Key: COCOON-2147 URL: https://issues.apache.org/jira/browse/COCOON-2147 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Carsten Ziegeler The spring configurator provides a bean for configuring log4j through a spring bean. This bean is initialized as soon as spring is finding the definition and starts up the container. Obviously this is too late as all log messages happening before this init are send somewhere else. There might be different solutions for this: a) Provide a configuration servlet/servlet listener (Spring provides one as well, but that's only usuable inside an expanded war file) b) Create an XML tag for spring configuration (like we do for the settings). This will ensure that logging is setup before beans are setup c) Remove the logging configuration at all and leave it up to the users to configure everything properly (more or less Spring does the same) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2147) Log4j configuration is loaded too late with Spring Configurator
[ https://issues.apache.org/jira/browse/COCOON-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated COCOON-2147: - Summary: Log4j configuration is loaded too late with Spring Configurator (was: Log4j configuration is loaded to late with Spring Configurator) Log4j configuration is loaded too late with Spring Configurator --- Key: COCOON-2147 URL: https://issues.apache.org/jira/browse/COCOON-2147 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Carsten Ziegeler The spring configurator provides a bean for configuring log4j through a spring bean. This bean is initialized as soon as spring is finding the definition and starts up the container. Obviously this is too late as all log messages happening before this init are send somewhere else. There might be different solutions for this: a) Provide a configuration servlet/servlet listener (Spring provides one as well, but that's only usuable inside an expanded war file) b) Create an XML tag for spring configuration (like we do for the settings). This will ensure that logging is setup before beans are setup c) Remove the logging configuration at all and leave it up to the users to configure everything properly (more or less Spring does the same) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r595367 - in /cocoon/trunk/blocks/cocoon-welcome/src/main/resources/COB-INF: ./ resource/external/ resource/external/images/ resource/external/styles/ resource/internal/ stylesheets/
[EMAIL PROTECTED] pisze: Author: vgritsenko Date: Thu Nov 15 09:16:37 2007 New Revision: 595367 URL: http://svn.apache.org/viewvc?rev=595367view=rev Log: new style for samples page header Looks much better! Thanks Vadim for doing this! :) -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
