Re: [cocoon-2.2] Deprecation
Grzegorz Kossakowski wrote: I'm sorry that I ignored your idea at GT but I thought you were joking and even didn't try to think about it more. Me joking? No way :) (Just kidding) Don't worry about this :) Being aware that you were not joking I wonder what's the real benefit of running 2.1 in 2.2? When it comes to the implementation of the idea it would be quite easy but it of course depends on the level of integration you would like achieve. My main concern is that if you run CocoonServlet from 2.1 in 2.2 you will get your app running but such app will have hard times with collaborating with 2.2 part like Spring-based components. Yes, that's true. Now, at some point we have to break compatibility to get a cleaner architecture and an even better way of doing things. Perhaps removing sub sitemaps is one of these things, perhaps not. But on the other hand there are many applications out there using this stuff and they don't want to migrate. There is no real benefit for them. But there is benefit for them using latest and greatest Cocoon for now stuff. And this is very I think embedding 2.1 in 2.2 might make sense. It allows people to run their old applications without modifications while at the same time they can start new apps with 2.2. As Cocoon 2.2 uses Spring as the container and as the Cocoon beans are added to the Spring root container, these things are available in 2.1 through Spring as well. So people are able to call 2.2 stuff from within 2.1. It might be a thin bridge in terms of possibilities but I think going this way makes things easier. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[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: [cocoon-2.2] Deprecation
Carsten Ziegeler pisze: Yes, that's true. Now, at some point we have to break compatibility to get a cleaner architecture and an even better way of doing things. Perhaps removing sub sitemaps is one of these things, perhaps not. Before we start to think about migration path and embedding 2.1 as emergency help for existing users I really think we should agree what we are going to deprecate and remove in the future and most importantly how we envision future Cocoon's architecture so there will be no perhaps yes, perhaps no doubts any more. But on the other hand there are many applications out there using this stuff and they don't want to migrate. There is no real benefit for them. But there is benefit for them using latest and greatest Cocoon for now stuff. And this is very I think embedding 2.1 in 2.2 might make sense. It allows people to run their old applications without modifications while at the same time they can start new apps with 2.2. If people don't want to migrate I would tell them to stick to 2.1, it's stable and final release of 2.2 won't make 2.1 unusable. As Cocoon 2.2 uses Spring as the container and as the Cocoon beans are added to the Spring root container, these things are available in 2.1 through Spring as well. So people are able to call 2.2 stuff from within 2.1. It might be a thin bridge in terms of possibilities but I think going this way makes things easier. Carsten, haven't you forgotten that in 2.2 all components (even Avalon-based) are managed by Spring? I mention this because I can easily imagine clashes between the same components defined both in 2.1 and 2.2. If you want to make anything usable you must assure collaboration in both ways between 2.1 and 2.2 so all components must be shared and clashes are unavoidable IMHO. Really, the more I think about this I idea the more obstacles I see but maybe I'm lacking something. Anyway, I think that the most important point is made earlier that we must establish goals we want to achieve before we start to think about implementation. Thinking more about incompatibilities between cocoon: and servlet: protocols I'm getting an impressions that they are not such fundamentally different when it comes to their usage schemes. Of course they differ in many details but as Reinhard properly characterized differences comes from the fact that servlet: protocol just tries to avoid side-effects cocoon: protocol allows. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: [cocoon-2.2] Deprecation
Carsten Ziegeler pisze: Hmm, no, I don't think so :( I think most of the relevant code is in the SitemapHelper class. Thanks, I'll have a look. Is the context really changed for each sax events? I thought that cocoon: protocol creates some kind of derived environment for each cocoon: call and this way (some) separation is assured. Can you point me to relevant place? It's in the SitemapSource. There is a special sax event wrapper which is placed around the receiving sax handler: EnvironmentHelper.createEnvironmentAwareConsumer(consumer) So for each sax event the environment is changed back and forth. You are right. Argh, SitemapSource is even more complicated than I thought... I agree. The servlet: protocol does buffering but it does something more: it serializes and parsers XML each time servlet request is made. This really affects performance and must be changed but it's not that hard and the change would limited to only cocoon-servlet-* modules. Yepp, I think we should support the extensions of the HttpServletResponse which we discussed a long time ago and which can be found in the processor module of our whiteboard. The buffering could be a recording of sax events with the sax buffer. I was discussing very similar idea with Leszek at GT and he expressed interest in implementing such behaviour for respone/request classes used by servlet protocol. Leszek, do you still plan to implement this in a foresable future? When it comes to the request being SAX aware there is a small problem. There was a common agreement that we should implement fall-back mechanism in case that called servlet does not support SAX-aware request/response combo. The fall-back mechanism would work the way as reqest/reponse classes work now so the incoming SAX stream is serialized into request's body and produced SAX stream is serialized to response's body. However, at the same time we agreed that we would like to forward request data (including parameters, uploaded files) from original request. Then there is a clash between data coming from SAX events and uploaded files that must be included in the same request body. I don't know any good solution for this problem apart from encoding serialized SAX stream as another uploaded file. Any ideas on this? -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
