cocoon contract in london
Hi I am looking for another cocoon developer / guru to work in London on contract Rate would be £ 400 to £ 500 a day for at least 6 months Please contact if this is of interest Marcus Clemens Director Senior Consultant Mercator IT Ltd Tel: 01892 752730 Fax: 01892 750972 Email: [EMAIL PROTECTED] Address: The Studio, Eridge Park, Eridge Green, Tunbridge Wells, Kent TN3 9JS This email may contain privileged/confidential information and is for the intended addressee only. If you have received this message in error then you must not use, retain, disseminate or otherwise deal with it. Please notify the sender by return email and destroy. The views of the author may not necessarily constitute the views of Mercator IT Solutions Ltd. Nothing in this email shall bind Mercator IT Solutions Ltd in any contract or obligation. -Original Message- From: Grzegorz Kossakowski [mailto:[EMAIL PROTECTED] Sent: 09 November 2007 14:47 To: dev@cocoon.apache.org Subject: Re: Release of cocoon-databases-bridge Reinhard Poetz pisze: Grek, thanks for pushing on releasing another block I guess that you don't have a PGP key which is signed by other ASF folks. If I'm right this means that you can't create the release artifacts yourself. Yep. Did we forget that GT was a great occasion to do this work? I'd be more than happy to help you out with this step of the release procedure if you can do the rest of the work (organizing the vote, write the announcement mail, update the website, publish the artifacts to the central Maven repository). Since bridge is a very small and focused module I don't think it's demands a lot of work. Am I right that simple announcement e-mail with few sentences explaining that cocoon-databases-bridge lets one to use Spring-defined datasources in Avalon components would be enough? When it comes to the site, the only document about cocoon-databases-bridge is a migration guide that I already published: http://cocoon.apache.org/2.2/blocks/databases/1.0/1409_1_1.html Or maybe you mean publishing automatic reports like Javadocs, etc? Feel free to contact me via Skype to discuss the details. Your involvement would also be a good chance to check http://cocoon.apache.org/1199_1_1.html for clearity, completness and correctness. I'll contact you on Sunday or Monday as it turned out that I will be travelling in the weekend. I'll try to do as much as I can myself. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Flowscript debugger with JDK 5 on Leopard
Hi folks, I'm having problems running the flowscript debugger on JDK 1.5 on Leopard, and wondered if anyone else was seeing the same thing. Basically, when Cocoon (2.1.10) hits a flowscript and launches the debugger, it also launches an exception: Exception in thread AWT-EventQueue-0 java.lang.ArrayIndexOutOfBoundsException: No such child: 1 at java.awt.Container.getComponent (Container.java:280) I've tried updating to js-1.6r6 and js-1.6r7 but they exhibit the same problem. I haven't been able to test in 2.1.11-dev as my svn checkout is not up-to-date and my dev machine has no net connection at the moment. Any suggestions? Andrew.
RE: Flowscript debugger with JDK 5 on Leopard
Hi Andrew, I have the same ArrayIndexOutOfBoundsException with the current 2.1 branch under Leopard with Java 1.5. Jasha -Original Message- From: [EMAIL PROTECTED] on behalf of Andrew Savory Sent: Wed 11/14/2007 12:12 To: dev@cocoon.apache.org Subject: Flowscript debugger with JDK 5 on Leopard Hi folks, I'm having problems running the flowscript debugger on JDK 1.5 on Leopard, and wondered if anyone else was seeing the same thing. Basically, when Cocoon (2.1.10) hits a flowscript and launches the debugger, it also launches an exception: Exception in thread AWT-EventQueue-0 java.lang.ArrayIndexOutOfBoundsException: No such child: 1 at java.awt.Container.getComponent (Container.java:280) I've tried updating to js-1.6r6 and js-1.6r7 but they exhibit the same problem. I haven't been able to test in 2.1.11-dev as my svn checkout is not up-to-date and my dev machine has no net connection at the moment. Any suggestions? Andrew. winmail.dat
[jira] Subscription: COCOON-open-with-patch
Issue Subscription Filter: COCOON-open-with-patch (107 issues) Subscriber: cocoon Key Summary COCOON-2137 XSD Schemas for CForms Development https://issues.apache.org/jira/browse/COCOON-2137 COCOON-2133 Addition of allow-enlarge parameter to ImageOp resize operation https://issues.apache.org/jira/browse/COCOON-2133 COCOON-2114 fix sorting in TraversableGenerator https://issues.apache.org/jira/browse/COCOON-2114 COCOON-2109 Incorrent cleanup of expired continuations https://issues.apache.org/jira/browse/COCOON-2109 COCOON-2104 [PATCH] Add base URI fixup support to XIncludeTransformer https://issues.apache.org/jira/browse/COCOON-2104 COCOON-2100 Retrieving mimeType returned by pipeline executed from Flow https://issues.apache.org/jira/browse/COCOON-2100 COCOON-2074 Build ignores custom applications https://issues.apache.org/jira/browse/COCOON-2074 COCOON-2071 Option to turn off pooling for components (probably faster on new JVMs and simpler debugging) https://issues.apache.org/jira/browse/COCOON-2071 COCOON-2065 huge performance increase of LuceneIndexTransformer on large Lucene indexes https://issues.apache.org/jira/browse/COCOON-2065 COCOON-2063 NekoHTMLTransformer needs to set the default-encoding of the current system to work properly with UTF-8 https://issues.apache.org/jira/browse/COCOON-2063 COCOON-2052 Allow Ajax submission of forms with empty upload field https://issues.apache.org/jira/browse/COCOON-2052 COCOON-2048 ImageOp: overlay a transparent image on another one https://issues.apache.org/jira/browse/COCOON-2048 COCOON-2041 WebDAV Returns improper status on PUT https://issues.apache.org/jira/browse/COCOON-2041 COCOON-2040 Union widget does not work with booleanfield set as case widget https://issues.apache.org/jira/browse/COCOON-2040 COCOON-2037 New DynamicGroup widget https://issues.apache.org/jira/browse/COCOON-2037 COCOON-2035 NPE in the sorter of the EnhancedRepeater https://issues.apache.org/jira/browse/COCOON-2035 COCOON-2032 [PATCH] Sort order in paginated repeater https://issues.apache.org/jira/browse/COCOON-2032 COCOON-2030 submit-on-change doesn't work for a multivaluefield with list-type=checkbox https://issues.apache.org/jira/browse/COCOON-2030 COCOON-2018 Use thread context class loader to load custom binding classes https://issues.apache.org/jira/browse/COCOON-2018 COCOON-2017 More output beautification options for serializers https://issues.apache.org/jira/browse/COCOON-2017 COCOON-2015 Doctype added twice because root element (html) is inlined https://issues.apache.org/jira/browse/COCOON-2015 COCOON-2002 HTML transformer only works with latin-1 characters https://issues.apache.org/jira/browse/COCOON-2002 COCOON-1985 AbstractCachingProcessingPipeline locking with IncludeTransformer may hang pipeline https://issues.apache.org/jira/browse/COCOON-1985 COCOON-1974 Donating ContextAttributeInputModule https://issues.apache.org/jira/browse/COCOON-1974 COCOON-1973 CaptchaValidator: allow case-insensitive matching https://issues.apache.org/jira/browse/COCOON-1973 COCOON-1964 Redirects inside a block called via the blocks protocol fail https://issues.apache.org/jira/browse/COCOON-1964 COCOON-1963 Add a redirect action to the browser update handler https://issues.apache.org/jira/browse/COCOON-1963 COCOON-1960 Pipeline errors for generator/reader already set should provide more information https://issues.apache.org/jira/browse/COCOON-1960 COCOON-1949 [PATCH] load flowscript from file into specified Rhino context object https://issues.apache.org/jira/browse/COCOON-1949 COCOON-1946 [PATCH] - Javaflow Sample errors trying to enhance Javaflow classes and showing cform templates https://issues.apache.org/jira/browse/COCOON-1946 COCOON-1943 [Patch] Parameters in blocks-protocol URIs get decoded too early https://issues.apache.org/jira/browse/COCOON-1943 COCOON-1932 [PATCH] correct styling of disabled suggestion lists https://issues.apache.org/jira/browse/COCOON-1932 COCOON-1929 [PATCH] Reloading classloader in Cocoon 2.2 https://issues.apache.org/jira/browse/COCOON-1929 COCOON-1917 Request Encoding problem: multipart/form vs. url encoded https://issues.apache.org/jira/browse/COCOON-1917 COCOON-1915 Nullable value with additional String or XMLizable in JavaSelectionList https://issues.apache.org/jira/browse/COCOON-1915 COCOON-1914 Text as XMLizable in EmptySelectionList https://issues.apache.org/jira/browse/COCOON-1914 COCOON-1899 [PATCH] Cocoon XML:DB Implementation should not depend on Xindice
Re: Flowscript debugger with JDK 5 on Leopard
Andrew Savory wrote: Hi folks, I'm having problems running the flowscript debugger on JDK 1.5 on Leopard Did you try java 1.4? Vadim
Re: [cocoon-2.2] Deprecation
Grzegorz Kossakowski wrote: Vadim Gritsenko pisze: Grzegorz Kossakowski wrote: Why can't we wait? Because cocoon: + map:mount combo is a major pain whenever one wants to touch Cocoon's core. Not knowing much about servlet: protocol, but how it is different from the servlet: + map:mount? From what I can see so far, these two should be - if not identical at the moment - but close in functionality? servlet: + map:mount combo is bad idea either because contexts would not be resolved correctly. I mean: if use URL like servlet:/something in mounted sitemap Cocoon resolve it using base sitemap. Ok but what about servlet://something? In other words, are there any differences between cocoon:// (note double slash) and servlet:/? Of course we could fix that quite easily but the question is why to do that? Personally I can live without cocoon:/ (single slash), so I'm fine if it goes away. Instead of using servlet: protocol + map:mount you should just create several separate SitemapServlet beans mounted at different paths But this would not provide same functionality as map:mount. It would not give same sitemap procession logic, would not give same error handling capabilities, and would not have same container hierarchy. or split your application into a few blocks if it makes sense. This is not really feasible, not for another 2-3 years... Anyway, general thought that servlet: protocol + creation of several SitemapServlet beans offer similar functionality to cocoon: protocol + map:mount is right. Hm I don't think I agree. Vadim
lenya 2.0 release preparation - cocoon version dependency (2.1.11?)
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! Jürgen Ragaller Jürgen Ragaller null-oder-eins GmbH www.null-oder-eins.ch [EMAIL PROTECTED]
Re: [cocoon-2.2] Deprecation
Vadim Gritsenko pisze: Grzegorz Kossakowski wrote: Vadim Gritsenko pisze: servlet: + map:mount combo is bad idea either because contexts would not be resolved correctly. I mean: if use URL like servlet:/something in mounted sitemap Cocoon resolve it using base sitemap. Ok but what about servlet://something? In other words, are there any differences between cocoon:// (note double slash) and servlet:/? None apart from the fact that the environment is not shared when servlet:/ is used. Note that there is no servlet://, at least as far as I know. Of course we could fix that quite easily but the question is why to do that? Personally I can live without cocoon:/ (single slash), so I'm fine if it goes away. Instead of using servlet: protocol + map:mount you should just create several separate SitemapServlet beans mounted at different paths But this would not provide same functionality as map:mount. It would not give same sitemap procession logic, would not give same error handling capabilities, and would not have same container hierarchy. What do you mean by sitemap procession logic exactly? When it comes to error handling capabilities - agreed, this is a serious functionality loss. On the other hand, I would like to have sitemap more self-contained not relying on their position in sitemap hierarchy. In order to avoid bloating sitemaps by the same error-handling constructs you could use a shared block that would handle errors. Other sitemaps would delegate error handling by using postable source. Why do you need a container hierarchy? I'm just wondering if there is a really, really good use case for container hierarchy. Could you give examples? or split your application into a few blocks if it makes sense. This is not really feasible, not for another 2-3 years... Why? Anyway, general thought that servlet: protocol + creation of several SitemapServlet beans offer similar functionality to cocoon: protocol + map:mount is right. Hm I don't think I agree. Not a problem for now as I'm happy to continue discussion as long as there are a new arguments being revealed. Anyway, I really think we should not stop the evolution. I wonder how many people share my feelings that we badly need to cut some of the crappy code of our core if we want to move on. The first step to do this is deprecate, the second is to provide good replacements and Servlet Service Framework is a good *candidate* IMHO. The third step would to remove that code in the end but it's not going to happen in the month. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: [cocoon-2.2] Deprecation
Grzegorz Kossakowski wrote: Vadim Gritsenko pisze: Grzegorz Kossakowski wrote: Vadim Gritsenko pisze: servlet: + map:mount combo is bad idea either because contexts would not be resolved correctly. I mean: if use URL like servlet:/something in mounted sitemap Cocoon resolve it using base sitemap. Ok but what about servlet://something? In other words, are there any differences between cocoon:// (note double slash) and servlet:/? None apart from the fact that the environment is not shared when servlet:/ is used. Ok, good to know. What do you mean not shared? Does it mean request parameters of original response are not available? Note that there is no servlet://, at least as far as I know. Yep Instead of using servlet: protocol + map:mount you should just create several separate SitemapServlet beans mounted at different paths But this would not provide same functionality as map:mount. It would not give same sitemap procession logic, would not give same error handling capabilities, and would not have same container hierarchy. What do you mean by sitemap procession logic exactly? Stuff which could be done before mount; intercepting request before they drop into sub sitemap; stuff which can be done after mount if sub-sitemap returns w/out response; providing default handlers. When it comes to error handling capabilities - agreed, this is a serious functionality loss. On the other hand, I would like to have sitemap more self-contained not relying on their position in sitemap hierarchy. If it is more self-contained, it becomes less reusable. For example, same error handling can not be good for all situations. E.g., compare internal error handling vs external error handling. In order to avoid bloating sitemaps by the same error-handling constructs you could use a shared block that would handle errors. Other sitemaps would delegate error handling by using postable source. Why do you need a container hierarchy? I'm just wondering if there is a really, really good use case for container hierarchy. Could you give examples? For example, to provide isolation between different parts of application(s)... I imagine portal block might be a heavy user of this. Is it? or split your application into a few blocks if it makes sense. This is not really feasible, not for another 2-3 years... Why? Today's hardware is too slow for Cocoon + Maven 2... :( Anyway, general thought that servlet: protocol + creation of several SitemapServlet beans offer similar functionality to cocoon: protocol + map:mount is right. Hm I don't think I agree. Not a problem for now as I'm happy to continue discussion as long as there are a new arguments being revealed. Anyway, I really think we should not stop the evolution. I wonder how many people share my feelings that we badly need to cut some of the crappy code of our core if we want to move on. The first step to do this is deprecate, 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. Vadim the second is to provide good replacements and Servlet Service Framework is a good *candidate* IMHO. The third step would to remove that code in the end but it's not going to happen in the month.
RE: Flowscript debugger with JDK 5 on Leopard
It doesn't matter which version my shell has, but the JAVA_HOME for the Leopard GUI seems to matter. The JAVA_HOME for the GUI must be 1.4 to make it run, even if the shell uses 1.5. Tried playing with it, logging in and out and setting JAVA_HOME for the GUI to 1.4 seemed to be the trick. Didn't matter if I build Cocoon with 1.4 or 1.5. -Original Message- From: Vadim Gritsenko [mailto:[EMAIL PROTECTED] Sent: Wed 11/14/2007 20:39 To: dev@cocoon.apache.org Subject: Re: Flowscript debugger with JDK 5 on Leopard Andrew Savory wrote: Hi folks, I'm having problems running the flowscript debugger on JDK 1.5 on Leopard Did you try java 1.4? Vadim winmail.dat
