Re: [cocoon-2.2] Deprecation
Vadim Gritsenko pisze: Grzegorz Kossakowski wrote: Vadim Gritsenko pisze: 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, I tried to fix this problem but I still cannot reproduce it using Maven 2.0.6 on Linux with Java 1.6.0 installed. If you are sure that xmlParserAPIs causes a problem I can exclude it but I cannot test if it fixes this problem. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: [cocoon-2.2] Deprecation
Vadim Gritsenko pisze: Grzegorz Kossakowski wrote: Vadim Gritsenko pisze: 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... I'll do it right now. I don't know if I can look at it this week... It certainly is on my radar, together with pipeline lock bug. Ok, so if you need any help I'm willing to give a hand but I would like to focus on other things (like releasing databases bridge and working on my secret Cocoon project :P) Will do it later. It may be just missing dependency. BCEL :) It is required for XSLTC and it is indeed missing. I just tried to transform using xsltc and it works fine for me. Which Java version do you use? -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
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: [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: [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: [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: [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: [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
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: [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: [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: [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/
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
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: [cocoon-2.2] Deprecation
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. Of course we could fix that quite easily but the question is why to do that? Instead of using servlet: protocol + map:mount you should just create several separate SitemapServlet beans mounted at different paths or split your application into a few blocks if it makes sense. Anyway, general thought that servlet: protocol + creation of several SitemapServlet beans offer similar functionality to cocoon: protocol + map:mount is right. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: [cocoon-2.2] Deprecation
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? Vadim
Re: [cocoon-2.2] Deprecation
Grzegorz Kossakowski wrote: 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. Good point. 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. Yes, but what about bug fixes etc.? Given the activity over the last year I doubt that there will be any 2.1.x release. And people want to do new things with Cocoon while at the same time keep their apps running. But this is more a hypothetical discussion :) All I want to say is that we should not care too much about compatibility. We should find a clean and great solution for future Cocoon versions. 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? Hmm, no - it was me who created this stuff :) 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. No, I don't think so - keeping them separate is the key I think. We would even have to run Cocoon 2.1.x in an own class loader to avoid class clashes. Basically I think it could work like this: the global spring container contains spring stuff and cocoon 2.2 stuff. There is some bridging servlet registered which forwards to an embedded Cocoon 2.1.x which runs in an own class loader and own Avalon container. There is no direct conncetion to spring or 2.2. However people could get the global spring container inside 2.1.x and use the registered beans. Really, the more I think about this I idea the more obstacles I see but maybe I'm lacking something. Yes, maybe it's not that easy - but currently I think it should be doable without too much work and too many problems. If we come to the conclusion that this might be worth exploring I could have a look at it by the end of December. 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. Absolutely true. I also think that we should get 2.2 out first. We can delay all this deprecation etc. for one release. 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. Yepp, but unfortunately too many people rely on these side-effects :( Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [cocoon-2.2] Deprecation
Joerg Heinicke pisze: It seems we do not even know the requirements. How do you want to decide about architecture without them? My guess - since Cocoon is just a framework - you merely get the requirements from real applications built on it. Why can't we wait until the people get used to the new functionality and see how it works out to see what can be removed in the future? Waiting a little bit and let the requirements to crystallize is a good idea in general. The process of crystallization of ideas will shape replacements for the functionality we want to deprecate. At the same time we can (and should in my opinion) deprecate things without having 1-1 replacements or even ideas for them. Why can't we wait? Because cocoon: + map:mount combo is a major pain whenever one wants to touch Cocoon's core. I'm almost sure that there is no active committer that could say: I know how this stuff works or at least I could figure out everything I need to work with this code in a day. Don't you think that having big portion of such code in core will bite us in the future only if it's not biting us now? Deprecation of this stuff would hold mainly informative role spreading a clear message: We really want to remove this code and we are actively evaluating various options as replacements. I would even say that deprecation would elicit active discussion amongst our users. That would be the best outcome of the whole deprecation thing at this point because we probably could gather a lot of useful information how Cocoon is used. Yes, as several folks pointed out, deprecation is only the first step to remove any portion of code. From what I understand servlet protocol lacks some major functionality like the fall-through of sub sitemaps. This seems to be the most important convention over configuration feature. Can you explain what do you mean by fall-through of sub sitemaps? 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. I want them as testers sharing their experience. Otherwise it takes much longer to get peoples to use Cocoon 2.2 in a meaningful way (= more than starting with little applications). I don't see the point preventing people from migrating. Also we are talking about *deprecation* in 2.2 here, not removing features. So how should it affect them? There would be no impact on our users apart from the psychological aspect I spoke about earlier. Do we agree on deprecating this stuff then? -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: [cocoon-2.2] Deprecation
Carsten Ziegeler wrote: Grzegorz Kossakowski wrote: 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. Yepp, but unfortunately too many people rely on these side-effects :( Is there place where differences between servlet: and cocoon: sources are described? Or, at least, where servlet: source is described? Vadim
Re: [cocoon-2.2] Deprecation
On 07.11.2007 15:52 Uhr, Grzegorz Kossakowski wrote: 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. It seems we do not even know the requirements. How do you want to decide about architecture without them? My guess - since Cocoon is just a framework - you merely get the requirements from real applications built on it. Why can't we wait until the people get used to the new functionality and see how it works out to see what can be removed in the future? From what I understand servlet protocol lacks some major functionality like the fall-through of sub sitemaps. This seems to be the most important convention over configuration feature. 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. I want them as testers sharing their experience. Otherwise it takes much longer to get peoples to use Cocoon 2.2 in a meaningful way (= more than starting with little applications). I don't see the point preventing people from migrating. Also we are talking about *deprecation* in 2.2 here, not removing features. So how should it affect them? Joerg
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]
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/
Re: [cocoon-2.2] Deprecation
Thorsten Scherler pisze: Hmm, I must admit I am still catching up with the discussion around the cocoon:// protocol, but must admit that it is quite essential in e.g. forrest. We are making lots of use of pass-trough mounts and invocation of the project specific sitemaps from the forrest core via cocoon:// calls. Now with the servlet: protocol (as I understand it) you need to know before hand the name of the servlet you want to consult. This is not practical in forrest where a project can be called as it want. Meaning if cocoon:// is gone and no other protocol will offer the functionality then forrest has a problem. I would really like to see more detailed description of the flow in your sitemaps that use cocoon:// protocol intensively. This would really help me to understand what problems could cause hypothetical deprecation of cocoon: protocol. Answering your concrete question there is nothing that stops you from evaluating servlet's name at runtime as long as you are connected to that servlet. Connections between servlets are static at this point (actually I believe they are static) but it's not a problem to change that. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: [cocoon-2.2] Deprecation
Carsten Ziegeler pisze: Rethinking the whole topic, I guess it boils down to the question of what the best approach is (that's obvious of course). So I think we should first think about how we envision applications are built with Cocoon considering all known use cases. This includes questions like do we think sub sitemaps are a good idea? etc. Once we have agreed on this we can think about how this maps to the way people are building their applications with Cocoon today (with 2.1.x) and then think about deprecating stuff, changing stuff or leaving it as it is. Yes, I agree that we have to take a broader look at how we want applications to be developed with Cocoon. I believe I presented my own view quite thoroughly several times that can be summarized with one sentence as: I think that the best way to develop Cocoon applications is to see them as conglomerate of separated blocks having their own contexts (environments) interacting with each other through servlet: protocol. And I'm coming back to a point I mentioned at the GT which everyone ignored :(, I still think that one possible solution of a migration plan is to run a Cocoon 2.1.x installation inside 2.2. 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. 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. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: [cocoon-2.2] Deprecation
Grzegorz Kossakowski wrote: Please note, that with 2.2 there is an auto include for per sitemap components which reads configurations from some sub directories. This is a very nice feature which makes packaging very easy :) But perhaps with using blocks this is not that important. I agree with you that blocks packaging should be our main focus. However, is the technique you are talking about described somewhere? Hmm, no, I don't think so :( I think most of the relevant code is in the SitemapHelper class. I haven't looked at the implementation of the servlet: protocol, but I know the (old) implementation of the cocoon: protocol. One of the main problems are the sax events combined with the required context changes. As sax events are directly send from a cocoon: call to the parent call the context of execution has to change back and forth for each sax events. A lot of things have to change and this was always a place for interesting bugs and errors. 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. While directly sending sax events seems to provide more performance I actually would not care about this today anymore. The context switch should be done once, the result from the call should be buffered and that's it. But I think the servlet: protocol is doing this already. 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. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [cocoon-2.2] Deprecation
IIRC it wasn't the functionality of map:mount that made some people think that we should deprecate sub sitemaps but the map:components part of sitemaps which causes a lot of complicated code that we have to maintain. However, deprecating map:components shouldn't be a problem because there already exists a migration path of putting your component definitions into META-INF/cocoon/spring or META-INF/cocoon/avalon. Hmm, as long as you just have one sitemap in your block this works. But as soon as you are using sub sitemaps in your block it's not the same. If people are fine with the change that all components are visible for the whole block this is no problem. Please note, that with 2.2 there is an auto include for per sitemap components which reads configurations from some sub directories. This is a very nice feature which makes packaging very easy :) But perhaps with using blocks this is not that important. The second big thing for deprecation that we discussed in Rome was the cocoon:/ protocol and the the servlet:/ protocol instead. AFAIU the servlet:/ protocol doesn't provide all the features of the cocoon:/ protocol but that's mostly caused by getting rid of side-effects. Can somebody who knows the code and the functionality of map:components and cocoon:/ in more detail than me comment on this? I haven't looked at the implementation of the servlet: protocol, but I know the (old) implementation of the cocoon: protocol. One of the main problems are the sax events combined with the required context changes. As sax events are directly send from a cocoon: call to the parent call the context of execution has to change back and forth for each sax events. A lot of things have to change and this was always a place for interesting bugs and errors. While directly sending sax events seems to provide more performance I actually would not care about this today anymore. The context switch should be done once, the result from the call should be buffered and that's it. But I think the servlet: protocol is doing this already. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [cocoon-2.2] Deprecation
Carsten Ziegeler pisze: Hmm, as long as you just have one sitemap in your block this works. But as soon as you are using sub sitemaps in your block it's not the same. If people are fine with the change that all components are visible for the whole block this is no problem. Please note, that with 2.2 there is an auto include for per sitemap components which reads configurations from some sub directories. This is a very nice feature which makes packaging very easy :) But perhaps with using blocks this is not that important. I agree with you that blocks packaging should be our main focus. However, is the technique you are talking about described somewhere? I haven't looked at the implementation of the servlet: protocol, but I know the (old) implementation of the cocoon: protocol. One of the main problems are the sax events combined with the required context changes. As sax events are directly send from a cocoon: call to the parent call the context of execution has to change back and forth for each sax events. A lot of things have to change and this was always a place for interesting bugs and errors. 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? While directly sending sax events seems to provide more performance I actually would not care about this today anymore. The context switch should be done once, the result from the call should be buffered and that's it. But I think the servlet: protocol is doing this already. 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. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: [cocoon-2.2] Deprecation
Reinhard Poetz pisze: I think that you refer to the idea of deprecating sub-sitemaps which isn't an as good idea as it seemed from a quick glance because there is no equivalent to get the same functionality if you have to replace it with servlet-services and Spring AOP. Hence I won't suggest sub-sitemaps for deprecation. Solution does not exists *yet* but I guess we could find some replacement as soon as we know what functionality is lacking. AFAIR, Vadim mentioned following construct: map:match pattern=... map:act type=prepareSomething/ map:mount .../ map:act type=finilazeSomething/ /map:match that cannot be replaced by use of Servlet Service Framework, right? If it's the only use-case (mount surrounded by some initialization code) I guess we could easily find something equivalent. Are there any other examples? IIRC it wasn't the functionality of map:mount that made some people think that we should deprecate sub sitemaps but the map:components part of sitemaps which causes a lot of complicated code that we have to maintain. However, deprecating map:components shouldn't be a problem because there already exists a migration path of putting your component definitions into META-INF/cocoon/spring or META-INF/cocoon/avalon. Not only map:components/. Mounting + cocoon protocol makes whole core unnecessary complicated and lacking of separation. Mounting involves creation of new context, cocoon calls affect code of sitemap and pipeline handling very deeply which is a bad sign IMO. The second big thing for deprecation that we discussed in Rome was the cocoon:/ protocol and the the servlet:/ protocol instead. AFAIU the servlet:/ protocol doesn't provide all the features of the cocoon:/ protocol but that's mostly caused by getting rid of side-effects. Yep. One of design goals of servlet: protocol was to share as less of environment as possible while cocoon: protocol shares and mixes as much as possible. I firmly believe in first approach that makes everything isolated thus simple and reliable. We already have introduced quite advanced concepts like true OO in servlet service framework so we should be very careful on not creating another magic box that nobody knows and everyone is scared to fix or change. There is a random thought: if we stick to the idea that environment is not shared between caller and called service we get clustering for free. I think you could easily imagine several blocks sharing services deployed to several separate machines. Then servlet services could be used remotely. Thanks to the fact that we use only standard HTTP you could even deploy one block to several machines and use standard load balancer for balancing load of all machines serving some servlet services... WDYT? Can somebody who knows the code and the functionality of map:components and cocoon:/ in more detail than me comment on this? I know cocoon:/ protocol quite well and I can assure that with conjuration of map:mount it's very, very problematic part of Cocoon. It's also not a good idea that we are going to have two competing solution for achieving the same, yet core functionality of Cocoon. I think we should discuss these two big topics first and then we can continue with smaller things like the SimpleFormsTransformer, obsolete input modules, etc. I hope that I find some time soon to write a summary that contains a list with all those components. Yep. Thanks Reinhard for bugging us on this topic and sorry for delays. I have finally some free time that I can devote to Cocoon now. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: [cocoon-2.2] Deprecation
Grzegorz Kossakowski schrieb: Reinhard Poetz pisze: I think that you refer to the idea of deprecating sub-sitemaps which isn't an as good idea as it seemed from a quick glance because there is no equivalent to get the same functionality if you have to replace it with servlet-services and Spring AOP. Hence I won't suggest sub-sitemaps for deprecation. Solution does not exists *yet* but I guess we could find some replacement as soon as we know what functionality is lacking. AFAIR, Vadim mentioned following construct: map:match pattern=... map:act type=prepareSomething/ map:mount .../ map:act type=finilazeSomething/ /map:match that cannot be replaced by use of Servlet Service Framework, right? If it's the only use-case (mount surrounded by some initialization code) I guess we could easily find something equivalent. Are there any other examples? IIRC it wasn't the functionality of map:mount that made some people think that we should deprecate sub sitemaps but the map:components part of sitemaps which causes a lot of complicated code that we have to maintain. However, deprecating map:components shouldn't be a problem because there already exists a migration path of putting your component definitions into META-INF/cocoon/spring or META-INF/cocoon/avalon. Not only map:components/. Mounting + cocoon protocol makes whole core unnecessary complicated and lacking of separation. Mounting involves creation of new context, cocoon calls affect code of sitemap and pipeline handling very deeply which is a bad sign IMO. The second big thing for deprecation that we discussed in Rome was the cocoon:/ protocol and the the servlet:/ protocol instead. AFAIU the servlet:/ protocol doesn't provide all the features of the cocoon:/ protocol but that's mostly caused by getting rid of side-effects. Yep. One of design goals of servlet: protocol was to share as less of environment as possible while cocoon: protocol shares and mixes as much as possible. I firmly believe in first approach that makes everything isolated thus simple and reliable. We already have introduced quite advanced concepts like true OO in servlet service framework so we should be very careful on not creating another magic box that nobody knows and everyone is scared to fix or change. There is a random thought: if we stick to the idea that environment is not shared between caller and called service we get clustering for free. I think you could easily imagine several blocks sharing services deployed to several separate machines. Then servlet services could be used remotely. Thanks to the fact that we use only standard HTTP you could even deploy one block to several machines and use standard load balancer for balancing load of all machines serving some servlet services... WDYT? Can somebody who knows the code and the functionality of map:components and cocoon:/ in more detail than me comment on this? I know cocoon:/ protocol quite well and I can assure that with conjuration of map:mount it's very, very problematic part of Cocoon. It's also not a good idea that we are going to have two competing solution for achieving the same, yet core functionality of Cocoon. I think we should discuss these two big topics first and then we can continue with smaller things like the SimpleFormsTransformer, obsolete input modules, etc. I hope that I find some time soon to write a summary that contains a list with all those components. Yep. Thanks Reinhard for bugging us on this topic and sorry for delays. I have finally some free time that I can devote to Cocoon now. Rethinking the whole topic, I guess it boils down to the question of what the best approach is (that's obvious of course). So I think we should first think about how we envision applications are built with Cocoon considering all known use cases. This includes questions like do we think sub sitemaps are a good idea? etc. Once we have agreed on this we can think about how this maps to the way people are building their applications with Cocoon today (with 2.1.x) and then think about deprecating stuff, changing stuff or leaving it as it is. And I'm coming back to a point I mentioned at the GT which everyone ignored :(, I still think that one possible solution of a migration plan is to run a Cocoon 2.1.x installation inside 2.2. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [cocoon-2.2] Deprecation
On Mon, 2007-11-05 at 12:49 +0100, Grzegorz Kossakowski wrote: ... The second big thing for deprecation that we discussed in Rome was the cocoon:/ protocol and the the servlet:/ protocol instead. AFAIU the servlet:/ protocol doesn't provide all the features of the cocoon:/ protocol but that's mostly caused by getting rid of side-effects. Yep. One of design goals of servlet: protocol was to share as less of environment as possible while cocoon: protocol shares and mixes as much as possible. I firmly believe in first approach that makes everything isolated thus simple and reliable. We already have introduced quite advanced concepts like true OO in servlet service framework so we should be very careful on not creating another magic box that nobody knows and everyone is scared to fix or change. There is a random thought: if we stick to the idea that environment is not shared between caller and called service we get clustering for free. I think you could easily imagine several blocks sharing services deployed to several separate machines. Then servlet services could be used remotely. Thanks to the fact that we use only standard HTTP you could even deploy one block to several machines and use standard load balancer for balancing load of all machines serving some servlet services... WDYT? Hmm, I must admit I am still catching up with the discussion around the cocoon:// protocol, but must admit that it is quite essential in e.g. forrest. We are making lots of use of pass-trough mounts and invocation of the project specific sitemaps from the forrest core via cocoon:// calls. Now with the servlet: protocol (as I understand it) you need to know before hand the name of the servlet you want to consult. This is not practical in forrest where a project can be called as it want. Meaning if cocoon:// is gone and no other protocol will offer the functionality then forrest has a problem. salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
Re: [cocoon-2.2] Deprecation
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Grzegorz Kossakowski wrote:
Vadim, have you seen our whiteboard with the list of things people
have been wondering about when it
came to deprecation?
Seen it but I would not be able to recall it.
I remember though that it was acknowledged that some of the stuff
written on the sheet of deprecated things really had no substitutes or
migration path towards 'new stuff'. Which only means that either it
was on the list by mistake or because 'new stuff' is half baked at the
moment.
I think that you refer to the idea of deprecating sub-sitemaps which
isn't an as good idea as it seemed from a quick glance because there is
no equivalent to get the same functionality if you have to replace it
with servlet-services and Spring AOP. Hence I won't suggest sub-sitemaps
for deprecation.
IIRC it wasn't the functionality of map:mount that made some people
think that we should deprecate sub sitemaps but the map:components
part of sitemaps which causes a lot of complicated code that we have to
maintain. However, deprecating map:components shouldn't be a problem
because there already exists a migration path of putting your component
definitions into META-INF/cocoon/spring or META-INF/cocoon/avalon.
The second big thing for deprecation that we discussed in Rome was
the cocoon:/ protocol and the the servlet:/ protocol instead. AFAIU the
servlet:/ protocol doesn't provide all the features of the cocoon:/
protocol but that's mostly caused by getting rid of side-effects.
Can somebody who knows the code and the functionality of
map:components and cocoon:/ in more detail than me comment on this?
- o -
I think we should discuss these two big topics first and then we can
continue with smaller things like the SimpleFormsTransformer, obsolete
input modules, etc. I hope that I find some time soon to write a summary
that contains a list with all those components.
P.S. to Vadim: Of course we will give you a chance to comment on this :-)
More thoughts? Carsten, Daniel, Grek, ...?
--
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: [cocoon-2.2] Deprecation
On Thu, 2007-10-25 at 18:28 +0200, Reinhard Poetz wrote: Vadim Gritsenko wrote: Grzegorz Kossakowski wrote: Vadim, have you seen our whiteboard with the list of things people have been wondering about when it came to deprecation? Seen it but I would not be able to recall it. I remember though that it was acknowledged that some of the stuff written on the sheet of deprecated things really had no substitutes or migration path towards 'new stuff'. Which only means that either it was on the list by mistake or because 'new stuff' is half baked at the moment. A little bit out of context maybe but one thing on deprecation I really do not like in e.g. java classes is that the method which is deprecated does not contain a hint to the new method to use. Right now cocoon-2.2 is kind of doing this ATM. For someone that used 2.1 before and is now diving into 2.2, things like how to write a component that is based on 100% spring and not Avalon are deprecation with no hints. * Are there examples for new components? * Where can we find them? * ... Deprecation with no substitutes will cause a lot of confusion. just my 2 cents salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
Re: [cocoon-2.2] Deprecation
Reinhard Poetz wrote: Vadim Gritsenko wrote: I remember though that it was acknowledged that some of the stuff written on the sheet of deprecated things really had no substitutes or migration path towards 'new stuff'. Which only means that either it was on the list by mistake or because 'new stuff' is half baked at the moment. I think that you refer to the idea of deprecating sub-sitemaps which isn't an as good idea as it seemed from a quick glance because there is no equivalent to get the same functionality if you have to replace it with servlet-services and Spring AOP. Hence I won't suggest sub-sitemaps for deprecation. Ok. IIRC it wasn't the functionality of map:mount that made some people think that we should deprecate sub sitemaps but the map:components part of sitemaps which causes a lot of complicated code that we have to maintain. However, deprecating map:components shouldn't be a problem because there already exists a migration path of putting your component definitions into META-INF/cocoon/spring or META-INF/cocoon/avalon. Agreed, map:components section can be deprecated if there is a replacement. However I would like to clarify though where components are declared. At the moment options are: For root container, configurator:settings/ includes: foo.jar!/META-INF/cocoon/spring /WEB-INF/cocoon/spring For sitemap container, configurator:child-settings includes: [sitemap-url]/cocoon/spring [sitemap-file]:/map:sitemap/map:components/map:include-beans To the sitemap container, avalon:sitemap adds: [sitemap-file]:/map:sitemap/map:components So if I understand correctly, only /map:sitemap/map:components section in the sitemap file is to be deprecated, for both avalon and spring components, and first three options are going to be supported. Is this correct? The second big thing for deprecation that we discussed in Rome was the cocoon:/ protocol and the the servlet:/ protocol instead. AFAIU the servlet:/ protocol doesn't provide all the features of the cocoon:/ protocol but that's mostly caused by getting rid of side-effects. Yep I'd like to hear more about those nasty features :) Can somebody who knows the code and the functionality of map:components and cocoon:/ in more detail than me comment on this? - o - I think we should discuss these two big topics first and then we can continue with smaller things like the SimpleFormsTransformer, obsolete input modules, etc. I hope that I find some time soon to write a summary that contains a list with all those components. P.S. to Vadim: Of course we will give you a chance to comment on this :-) Thanks :) Vadim
