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]
Release of cocoon-databases-bridge
Hello, I would like to release first milestone of cocoon-databases-bridge module upcoming days. I hope that nobody objects? It's going to be my first release so I will probably need some assistance. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: Apache Cocoon 2.2-RC2 Released
Sylvain Wallez pisze: > Reinhard Poetz wrote: >> The Apache Cocoon Community is proud to announce the second release >> candidate of Cocoon 2.2. > > Good job folks! And let's hope that 2.2 final will be here for Christmas! Yep. Many thanks to Reinhard for making a release and others for a hard work! I strongly believe in 2.2 final coming for Christmas, maybe even earlier. :) -- Grzegorz Kossakowski
Re: Abstract classes for Spring-based components
Thorsten Scherler pisze:
> Which is a perfect valid question. Actually I still need Avalon ATM for
> a port of the dispatcher.
> http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.internal.dispatcher/
I see. So the general should be that if you develop Spring-based component and
need a ServiceManager
you should obtain it by using DI as for any other component. That's important
note that should be
included in a page describing how to develop Spring-based components.
> The dispatcher is till now a forrest plugin, but for my current customer
> project I need the plugin as cocoon 2.2 block.
>
> Till now I just need a proof of concept port without totally dropping
> all avalon code. To make it work quickly I am using the service manager
> till I find out which replacement classes/methods we can use for e.g.
> source resolving etc.
I see. It's perfectly valid approach.
>> Yes, I agree. This is a really good task for 2.3 that should appear
>> shortly IMO.
>>
>
> Ah, ok 2.3 is for the complete move. Makes me thing whether 3.0 would
> not be the better name (since avalon would not be supported anymore).
I would see 2.3 as release introducing all Avalon-free abstract classes for
components and
deprecating Avalon-based ones. Then in 3.0 we could remove them from the core
as well as move
support for Avalon to separate module or even drop completely.
> I mean
>
> public interface Generator extends XMLProducer, SitemapModelComponent {
>
> String ROLE = Generator.class.getName();
>
> /**
> * Generate the XML and stream it into the pipeline
> */
> void generate()
> throws IOException, SAXException, ProcessingException;
> }
>
> Where the void generate() will produce SAX events, right? The interface
> we need to change for sure is SitemapModelComponent since it uses
> org.apache.avalon.framework.parameters.Parameters.
Ah, yes. Nevertheless, it's not a problem to replace Paramters by something
else, this class is
quite straightforward.
> Bottom line for me is that it would be very helpful to see some abstract
> classes one can extend for new components that are 100% spring. I agree
> that it is easy and I hopefully will find time to submit some examples
> in the near future.
Great, thanks for discussing these things!
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: Preparing Cocoon 2.2-final
Hanne Moa pisze: > > How about a samples block, or marking what will and won't work in the > samples for 2.1.10 on 2.2? Yes, that is quite important. I think it would be very nice if someone could iterate over all samples of all released (or planned for a release) blocks and report what's not working. Then we could decide if we are going to fix them or mark as not working at the time. -- 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
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/
