Re: svn commit: r562199 - in /cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl: pom.xml src/changes/changes.xml src/main/java/org/apache/cocoon/components/treeprocessor/sitemap/SerializeNode.java
Grzegorz Kossakowski wrote:
[EMAIL PROTECTED] pisze:
URL: http://svn.apache.org/viewvc?view=rev&rev=562199
Log:
Fix regression introduced in r530406, r532869.
Update changes document: RC1 is long released.
At this point I'm not sure how, but your commit breakes servletService
components (generator, transformer and serializer) usage.
The problem is - was - two fold. First, BlockCallHttpServletResponse did not had
a default status code. So when block call is complete and chosen servlet did not
set any status code - which it can do - BlockCallHttpServletResponse was
returning 0 instead of 200. Revision r562802 fixes this.
Second problem is in ServletSource - it was tripping over 0 status code returned
by BlockCallHttpServletResponse. It assumes that if status is not 200, it should
be 304 - how naive :)
if (servletConnection.getResponseCode() != HttpServletResponse.SC_OK) {
//most probably, servlet returned 304 (not modified) and we need to perform
second request to get data
Oh, and there is a third problem - I added a FIXME in revision r562800 - it
looses original request body once it decides it was a redirect. Actually I don't
think we can allow it to perform POST second time at all. Just imagine it was
somebody's credit card to be charged $999 - it won't be good at all [1] :)
Vadim
[1] Yes in such cases operation should be idempotent - in perfect world, that
is...
Re: [vote] Let our environment abtractions extend the http servlet ones
Daniel Fagerstrom wrote:
I would like o.a.c.environment.[Request|Response|Session] to extend
javax.servlet.http.Http[ServletRequest|ServletResponse|Session]
respectively.
The gain of doing so is that it will be easier to reuse Cocoon
components outside Cocoon and that it will be simpler to use Cocoon
together with other frameworks (see
http://thread.gmane.org/gmane.text.xml.cocoon.devel/59035/focus=59143
for a discussion about this).
A drawback is that some slight back incompatibility is introduced. The
most important one Request.getSession will have HttpSession as return
type instead of Session, and that user code needs to switch from Session
to HttpSession or downcast the return value to Session. Uses of
o.a.c.environment.Cookie needs to be switched to
javax.servlet.http.Cookie, (which has exactly the same API), see
http://article.gmane.org/gmane.text.xml.cocoon.devel/74322 and
http://thread.gmane.org/gmane.text.xml.cocoon.devel/74276.
I don't want this to collide with releasing 2.2, so I'll wait with
introducing the changes if there is any risk for that.
If we follow our release policies, we wouldn't be allowed to introduce this
change for any 2.2.x release and 2.3 is far away I'd guess. But since we have
released the first series of RC1 without having announced them so far, my vote
is +1.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [vote] Let our environment abtractions extend the http servlet ones
Daniel Fagerstrom skrev: I would like o.a.c.environment.[Request|Response|Session] to extend javax.servlet.http.Http[ServletRequest|ServletResponse|Session] respectively. +1 /Daniel
[vote] Let our environment abtractions extend the http servlet ones
I would like o.a.c.environment.[Request|Response|Session] to extend javax.servlet.http.Http[ServletRequest|ServletResponse|Session] respectively. The gain of doing so is that it will be easier to reuse Cocoon components outside Cocoon and that it will be simpler to use Cocoon together with other frameworks (see http://thread.gmane.org/gmane.text.xml.cocoon.devel/59035/focus=59143 for a discussion about this). A drawback is that some slight back incompatibility is introduced. The most important one Request.getSession will have HttpSession as return type instead of Session, and that user code needs to switch from Session to HttpSession or downcast the return value to Session. Uses of o.a.c.environment.Cookie needs to be switched to javax.servlet.http.Cookie, (which has exactly the same API), see http://article.gmane.org/gmane.text.xml.cocoon.devel/74322 and http://thread.gmane.org/gmane.text.xml.cocoon.devel/74276. I don't want this to collide with releasing 2.2, so I'll wait with introducing the changes if there is any risk for that. Please cast your vote! /Daniel
Re: What's the use of fillContext method
Grzegorz Kossakowski skrev: Hi, I would like to know what's real use of from o.a.c.environment.TemplateObjectModelHelper.fillContext() method? For me, this method looks like trying to work-around bad design. Basically, this method gets context bean and tries to add all its properties (may be "dynamic properties" like entries in Map) to the object model. I believe that this is really hacky and was invented because JEXL doesn't have concept of context bean, only of variables. Thus the need for mapping of context to the variables. I think that the functionality can be convenient when you have a flowscript that just access e.g. a business bean from e.g. Hibernate. Then you just use the bean as business object in the sendPage function and can access its properties directly from JEXL. My own opinion is that we should remove this method completely and let JEXL access context bean's properties this way: contextBean.some_property If someone want's "some_property" to be accessed directly, she should add it to variables. I think that's much more clean and reliable contract. Might be, but I don't think it is a strong enough reason to introduce back incompatibility. You may wonder why I want to remove it at all. My goal is to get rid of TemplateObjectModelHelper which scope is narrowed to template, only. This stops me from having unified object model across all Cocoon parts. To achieve unified architecture, I want to make Cocoon areas (like flowscript) respectively responsible for various object model entries creation to be also responsible for addition this entries to the ObjectModel. Now, the situation is rather confusing because flowscript creates context bean and inserts it to the "component object model" (the one passed to Cocoon's components) and later template creates Object Model by collecting various bits of information. I've started to alter this in r562102[1]. I'd suggest that you move the code in TemplateObjectModelHelper.getTemplateObjectModel that fills the object model with attributes (or properties) to o.a.c.components.flow.AbstactInterpreter.forwardTo. The forwardTo method should also set up a local object model context for this information so that the object model doesn't become cluttered with data from earlier (e.g. internal) forwardTo calls. By moving the setup code from JXTemplateGenerator to AbstractInterpreter.forwardTo the context properties are available for all components, not just the JXTemplateGenerator. The setup of "cocoon.parameters" must still be done in JXTemplateGenerator of course. Ths setup of the context bean property in fillNewObjectModelWithFOM seem redundant, it is already done in AbstactInterpreter.forwardTo. What's your opinion? I would only want to add that removal of fillContext is probably back-incompatible change. It would, and it seem like an unnecessary step to me. /Daniel
Re: Running Samples, Re: svn commit: r562199
Jörg Heinicke pisze: Vadim Gritsenko wrote: I got an exception [1]. Any ideas? Vadim, if you want to see minimal version of Cocoon working *now* you can rebuild it omitting "-P allblocks" option. It should work, then. You can try to track that one down as well which actually was already supposed to be fixed [2] ;-) I wanted to fix this issue but I found that I cannot reproduce it. Seems like XML parser in my configuration does not perform validation. I have Java 6 on openSUSE 10.2 with standard configuration. I'm not sure how to enable this validation :-( Vadim, since you are able to get this error it would be great if you could have a look at it. I'll post comment in COCOON-2079 explaining how to track the actual problem. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
