cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathaniel, Alfred" <>
Subject RE: "Springification" of C3 - proof of concept
Date Fri, 05 Aug 2011 12:33:26 GMT
Hi Igor,

It's a nice show case that C3 has reached one of its design goals to
be embeddable in other frameworks.

Whilst C2 is the 500lb gorilla squatting the driverseat, C3 is a neat
little monkey who knows how to driver but also fits onto the backseat.

I was first confused by the term "springification" which I understood
as using more Spring in C3.  In fact it is the other way around.
It should rather be called the cocoonification of Spring.

Calling C3 pipelines from frameworks such as Spring MVC is a welcome
perspective for people who are stuck to an MVC framework but want the
power of Cocoon plumbing for the rendering. 

But saying that our neat little monkey should stay on the backseat
because Spring knows so much better to drive is too restrictive.
C2 has many more use cases than just REST and MVC and C3 should be
able to drive these as well.

I think your POC is worthwhile keeping but certainly not in C3 core.
I wouldn't even put it under cocoon-samples because it gives the
wrong impression that one has to swallow Spring before tasting Cocoon.

How about calling it the cocoon-on-the-backseat module?

Cheers, Alfred.

-----Original Message-----
From: [] On Behalf Of Simone Tripodi
Sent: Donnerstag, 4. August 2011 15:08
Subject: Re: "Springification" of C3 - proof of concept

Hi Igor!!!
congrats for your committership and your dedication to this work!!! I
really appreciate you shared your results with us!

Just my *personal* POV: even if I'm NOT a SpringFramework fan (and I
won't be :P) your work shall be included in a way or another in C3.
Anyway I would prefer Spring doesn't play the main role: I mean,
having 3rd parties integrations it more than fine - we already have
indeed modules with 3rd parties integrations, like StringTemplate,
JAX-RS, Optionals (Solr, JAXB) - but IMHO Cocoon *core* components
should not be dependent by any framework, I wouldn't "force" C3 users
learning Cocoon AND Spring as a starting point, or require Spring as
knowledge base to get started with Cocoon.
I think that should sound reasonable, WDYT?

So, my suggestions, if you are happy to continue on contributing - and
I really hope you are :) - is:

 * checkout the latest C3 code from /trunk;
 * understand how it is actually organized and check what has been
already implemented (for sure you can help us on improving actual JAXB
implementation, for example)
 * starting proposing and discussing modifications/additional
components step by step, not sure everybody would agree on adding
everything as a single big commit ;)

Many thanks in advance, all the best!!!
Have a nice day,

On Tue, Aug 2, 2011 at 1:32 AM, Igor Malinin <> wrote:
> Hello. I've promised some (not so long) time ago to share my experiments
> with C3 and Spring, and now I am ready to show some interesting
> achievements.
> Here is the source code:
> What it does...
> 1) Use traditional annotated Spring Controllers
> I think it is better REST than Cocoon today. Those days when Cocoon was a
> leader in this respect has passed, and it really was the best REST framework
> from day one when nobody even used this word. But now Spring is really
> powerful and I think Cocoon should not try to invent own things but
> integrate with Spring as much as possible. In current form it "disables"
> Spring functionality and replace with own much more limited solution.
> 2) Use Cocoon Sitemap as Spring View
> Again - traditional Spring way. Also i map Cocoon to WEB-INF so that sitemap
> is hidden for direct browser access (good trick to workaround lack of
> private pipelines in C3).
> 3) Use Spring FORM tag library in SAX pipeline
> When it is very simple implementation it works quite good already, much
> better than I expect from it myself...
> 4) Integrated Validation with Spring and Hibernate Validator
> Again - traditional Spring 3 way of handling forms, together with previous
> item can be a good foundation for replacing old Cocoon forms module...
> 5) EclipseLink JPA
> Just my favorite, as it implements both JPA and JAXB...
> 6) Mapping Spring model to XML with JAXB annotations
> Just a quick hack as everything else...
> 7) JRebel compatible, just generate rebel.xml for "main" module
> Unfortunately EclipseLink JRebel plugin does not work with latest
> EclipseLink, but can be switched off easily. Otherwise I did a small fix to
> XSLT transformer, so it rechecks for modifications correctly (not included
> with sources) and it works much better than Cocoon RCL. Actually Cocoon RCL
> destroyed root spring context on first invocation and any future requests to
> EclipseLink didn't work at all.
> I think that Cocoon RCL should be dropped at all - it is unusable for
> something serious, if you do something more than totally trivial it takes
> more time to fight with it, works almost always incorrectly and saves no
> time as the result...
> Thanks.
> Discussions and critics are welcome.

The content of this e-mail is intended only for the confidential use of the person addressed.

If you are not the intended recipient, please notify the sender and delete this e-mail immediately.
Thank you.
View raw message