Re: [cocoon-2.2] Servlet source description (was: Deprecation)
Vadim Gritsenko pisze: > Carsten Ziegeler wrote: >> Grzegorz Kossakowski wrote: >> 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? For the most simple aspect of servlet: protocol when it acts passively fetching resources from other blocks there is no such description (or at least I couldn't find any, I hope Daniel could help with this). Anyway, as I said in passive mode behaviour of servlet: source is very simple: it creates a new request (o.a.c.servletservice.util.BlockCallHttpServletRequest class) object and servlet service (usually just a SitemapServlet) is asked to process such request. The processing works exactly the same as this request would come from browser so the whole new environment is being created, etc. Little bit more tricky is servlet: source when it acts in active mode used as postable source. Fortunately enough, this aspect has been discussed thoroughly and you can find links to the most important threads in description of COCOON-2046[1] issue where implementation of postable source was tracked. There is a third aspect of servlet: source: Object Oriented behaviour. This is already implemented and was tracked by COCOON-2038[2]. The most important mail from the discussion mentioned in that issue is[3]. I hope this helps a little. If not, don't hesitate to ask. [1] https://issues.apache.org/jira/browse/COCOON-2046 [2] https://issues.apache.org/jira/browse/COCOON-2038 [3] http://article.gmane.org/gmane.text.xml.cocoon.devel/72335 -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
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: > 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]
