cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Pötz <>
Subject Re: rapid application development with rcl
Date Fri, 04 Sep 2009 10:53:29 GMT
Thorsten Scherler wrote:
> On Fri, 2009-09-04 at 12:06 +0200, Reinhard Pötz wrote:
>> Thorsten Scherler wrote:
>>> On Thu, 2009-09-03 at 15:29 +0200, Andreas Hartmann wrote:
>>>> Thorsten Scherler schrieb:
>>>>> On Thu, 2009-09-03 at 13:23 +0200, Reinhard Pötz wrote:
>>>>>> Thorsten Scherler wrote:
>>>>>>> Hi all,
>>>>>>> our site is based on different blocks and one main webapp
>>>>>>> (cocoon-22-archetype-webapp).
>>>>>>> The problem we are facing is that developing within blocks is
>>>>>>> rapid thanks to the rcl but all the code we have in the webapp
needs to
>>>>>>> have a constant rebuild, which is a real pain.
>>>>>>> Is talking about the goals that are doing the rcl stuff, how
can we
>>>>>>> "port" this to the webapp?
>>>>>>> Any hints and tips are welcome.
>>>>>> Why do you have to put Java code into the webapp at all?
>>>>> Not talking about the java code that is the bad thing. I am talking
>>>>> about normal xsl/sitemap changes. :(
>>>> I use the webapp only as a container for the blocks, it doesn't contain 
>>>> any code at all. There is a "welcome" block which is mounted at / as an 
>>>> entry point.
>>> Definitely a clean workaround. ;) How do you deal with the fact that the
>>> mount does not provide a pass-trough attribute anymore? I mean in 2.1 I
>>> can mount different maps which are looked into and if no match can be
>>> found there they are coming back to the parent sitemap and look for the
>>> next mount/match. That is a problem that we face in forrest with the
>>> switch to 2.2.
>> That's an unsolved problem with the servlet-service framework. It
>> wouldn't be too difficult to add pass-through support per se but the
>> problem is the order of sitemap servlets that are mounted to the _same_
>> path. I see two options: One is introducing an order attribute (similar
>> to the order attribute of Spring AOP), the other option is making the
>> behavior deterministic by sorting the servlets, that point to the same
>> mount path, alphabetically by their bean names.
> Thanks Reinhard for the pin-down. The second option would need no
> maintaining of the order attribute since we sort automatic the bean
> names, however using the same approach as the Spring AOP brings some
> standard approach that is easy to explain. 
> Not really sure what to vote for. The ordering of servlets would have
> the same behavior like the properties files meaning something known for
> a 2.2 user. 

This could be the default behavior, using the order attribute could be

>>>> That works quite well, but the class loader incompatibilities (e.g. for 
>>>> session attributes) are still a real PITA (cannot cast class Foo to Foo)
>>> How did you worked around that?
>> You can put all your problematic classes (classes that are kept in the
>> session, proxied interfaces/classes) into a separate module which is not
>> loaded by the RCL.
> Jeje, maybe directly in the webapp (to come back to the topic). ;)
> Thanks for your feedback Reinhard.

Probably not because this would introduce a cyclic reference if a block
module depends on the webapp module.

Reinhard Pötz                           Managing Director, {Indoqa} GmbH

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

View raw message