cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Pötz <>
Subject Re: svn commit: r685792 - in /cocoon/trunk/core: cocoon-core/ cocoon-core/src/main/java/org/apache/cocoon/spring/ cocoon-core/src/main/resources/META-INF/cocoon/spring/ cocoon-servlet-service/cocoon-servlet-service-components/ cocoon-servlet-service/cocoon...
Date Fri, 15 Aug 2008 16:21:04 GMT
Grzegorz Kossakowski wrote:
> Reinhard Pötz pisze:
>> Grzegorz Kossakowski wrote:
>>> pisze:
>>>> Author: reinhard Date: Thu Aug 14 00:43:31 2008 New Revision: 685792
>>>> URL: Log: The
>>>> BlockPathPropertyPlaceholderConfigurer module is *usually* only useful
>>>> if the SSF is used
>>>> together with Cocoon. In this case you always need the SSF-components.
>>>> Hence it's best to move it
>>>> to into this module so that Cocoon 2.2 can still be run in the
>>>> 'classic' mode.
>>> Somehow agreed. It looks like nobody is going to use SSF+Blocks
>>> infrastructure without Cocoon Core, right? :-)
>>>> (I can't help myself but somehow the
>>>> BlockPathPropertyPlaceholderConfigurer seems to be a hack
>>>> anyway ...)
>>> What do you mean by that? What makes it hacky?
>> I'm still not convinced that we should expose block resources directly.
>>  But there are use cases for it
>> ( and we've already
>> introduced this contract so it probably doesn't make much sense to
>> discuss this again.
> Ah, thanks to bringing this thread back to my mind! :-)
> Yes, I agree that in 99% cases one should not expose block's resources
> but still there might be some egde-cases were it's needed.
> The real task to be done is to make people more aware of servlet:
> protocol...

Yep, and thanks to JNet the servlet protocol also works for
objects which wasn't the case when this feature was added.

Reinhard Pötz                           Managing Director, {Indoqa} GmbH

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member        

View raw message