cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: rapid application development with rcl
Date Fri, 04 Sep 2009 10:28:52 GMT
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 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
> >>>>> "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. 

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

Thorsten Scherler <>
Open Source Java <consulting, training and solutions>

Sociedad Andaluza para el Desarrollo de la Sociedad 
de la Información, S.A.U. (SADESI)

View raw message