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:06:27 GMT
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 really
>>>>> rapid thanks to the rcl but all the code we have in the webapp needs
>>>>> 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.

>> 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.

Reinhard Pötz                           Managing Director, {Indoqa} GmbH

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

View raw message