cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Slootmaekers <rom...@inuron.com>
Subject Re: best wishes for 2008: 2.1 vs. 2.2
Date Sun, 30 Dec 2007 11:02:21 GMT
Grzegorz Kossakowski wrote:
> Romain Slootmaekers pisze:
>   
>> Ok, I can considered to be a novice user so I think my experiences are
>> relevant here:
>> (when reading back what I wrote below, I might sound a bit cynic and
>> chaotic, so be warned)
>>
>> - installation: since I know maven, that was not too difficult. but I
>> really don't like the fact that I get a +100MB repository just to tinker
>> a bit with cocoon 2.2. this is too much for someone who just wants to
>> play with it before you do real development. also, getting maven shoved
>> down my throat is  not my idea of a good time (maven is really an awful
>> build tool, really, the only thing you gain is that standardization
>> saves you explicit configuration). But hey, all in all I was really
>> surprised that just by following the instructions on the site, I got it
>> working (no twiddling required).
>>     
>
> Even I'm not Maven lover anymore because I think this software is just too buggy and
developers are
> not eager enough to fix these annoying bugs and it is just written in a bad programming
style in
> many places. Nevertheless, I really think Maven improves situation not only for developers
of
> Cocoon. 
Don't confuse standardisation with maven. The advantages stem from the 
fact everybody has the same project layout. A builder (be it maven or 
whatever) then just needs minimal input to do what it needs to do.
BTW, in a previous project, we rewrote what we needed from maven in +/- 
1500 lines of python. we kept the project layout of maven 90% of the 
config was IN the python code. So custumizing a project was just 
subclassing in python instead of writing an xml. a major improvement. 
XML is good for structure, but bad for behaviour, so you should not try 
to capture behaviour in it. (Anyone who ever tried a conditional in ant 
knows what I mean)

<cut some text>
> Rest examples (samples) is available in our SVN. You just need to check out source code
of Cocoon,
> call mvn install from root directory and then go to core/cocoon-webapp and call mvn jetty:run
to see
> many, many samples working out of the box. What minor twiddling do you refer to?
>
>   
ah, I just followed the guides on the web site. maybe you can just add 
references to the source code there. or tweak your maven site generation 
to include the correct code samples there.
> I think that configuration in 2.2 is much, much better than in C2.1 but I agree it needs
more
> attention when it comes to documentation. Especially we need to explain how to fit all
puzzles.
>
> I will have something to show related to this topic very soon.
>
>   
Great
>> Details are in Daisy already. I'm not sure why these documents has been not published
on official
>> site. I will have a look at it as soon as Daisy is back (it's down currently).
>>
>> For such things it's good to report ASAP so we have a chance to fix it as it's usually
trivial to do.
>>
>>     
ah eh. great.
> I promised to Reinhard to create documentation of Servlet Service Framework a few days
ago. I was
> more passionate about bug fixes and infrastructure work but I got back to this. Currently,
I create
> a few simple applications to figure out what would user need to know in order to create
them. I made
> a lot of notes, expect them all to be dumped into some kind of documentation quite soon.
It will
> certainly cover context-path property.
>
>   
yes, yes, I'm eager to have it ;)
>> -- I would like the servlet functionality to be mapped using the site
>> map (why else have a site map) but I still have to figure out how to do
>> it. :( documentation does not cover this.
>>     
>
> I'm not sure if I understand you in detail but I fear it's not possible due to architecture
> constraints. Servlet Service Framework covers such advanced concepts like polymorphism
of servlets
> when it comes to services identified by URIs. In order to make it working we needed a
bit of static
> configuration.
>
> If you describe your use-case in detail I'm sure someone (including me) will give you
an advice.
>
>   
The use case is actually quite simple:
I want to be able to route all requests with a path of a certain regexp 
to a servlet, and the config of the routing in the sitemap, instead of 
being in the servlet service config or in the web.xml.
All request routing in 1 place. otherwise it's difficult to keep track, 
especially overlaps in regexps (a request mapped in a pipeline AND in 
the servlet service config, now what happens ? might this cause the 
'commited' Exception described below ?)

>> -- My application has a different mapping when running the "mvn
>> jetty:run" way and as a .war file in the same jetty (the servlet mapping
>> is different) :(
>> The thing here is that although strictly this might not be a cocoon
>> problem but a jetty plugin problem or a spring configuration problem,
>> the documentation is lacking. The only thing that is more or less
>> correctly documented is the jetty-plugin.
>>     
>
> Can you elaborate on this? It's the first time I hear about such an issue. I recommend
you to be
> more open when it comes to sharing your problems. You could write an e-mail describing
your troubles
> or even create a bug report.
> If you did it you would probably get a quick response because it's a close to my main
interests in
> Cocoon and I try hard to not miss any mail/report related to topics like SSF or Maven.
>
>   
I will split this out in a separate posting.
>> --I still have from time to time Exceptions:
>> java.lang.IllegalStateException: Committed
>>        at org.mortbay.jetty.Response.resetBuffer(Response.java:972)
>>        at org.mortbay.jetty.Response.reset(Response.java:921)
>>        at
>> javax.servlet.ServletResponseWrapper.reset(ServletResponseWrapper.java:193)
>>        at
>> org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:574)
>>
>>        at
>> org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:544)
>>
>>        at
>> org.apache.cocoon.servletservice.spring.ServletFactoryBean$ServiceInterceptor.invoke(ServletFactoryBean.java:230)
>>
>>        at
>> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
>>
>>        at
>> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
>>
>>        at $Proxy5.service(Unknown Source)
>>        at
>> org.apache.cocoon.servletservice.DispatcherServlet.service(DispatcherServlet.java:102)
>>
>>    As the application works, I can ignore it for know but again, I'm
>> quite clueless as to what I'm doing wrong
>>    (maybe the request is given to the pipeline after the servlet has
>> done its job, but that's just a guess)
>>     
>
> It is a bug caused by me when I committed some contribution. It has been already discussed
on dev
> list and will be addressed soon, see:
> https://issues.apache.org/jira/browse/COCOON-2150
>   

hm, yes, I found that one, but the case in which my exception happens is 
totally different. I don't have any exception in the flow, nor have I 
the 500 internal error code set earlier...
>   
>> -- half of the 2.2 documentation is none existing and using the 2.1
>> documentation is fraud with danger as it sometimes works, sometimes not.
>> Most of the misfits come of Classes that now have a different name or
>> package, but it takes ages to figure that out.
>>     
>
> Lack of migration guides like this:
> http://cocoon.apache.org/2.2/blocks/forms/1.0/1351_1_1.html
> or these:
> http://cocoon.apache.org/2.2/blocks/databases/1.0/1409_1_1.html
>
> Just asking because being curious if something like this is enough.
>   
Well I suppose it's enough if your an experienced 2.1 user. I never used 
2.1 so a diff doesn't mean a lot (unless i need to port 2.1 examples ;))

I just would like to have a reference guide of 2.2 that contains just 
that: the reference.
>   
>> - Architectural overview ?
>> didn't find any.
>>     
>
> Yep, noted added to give even one simple page that would help a bit.
>   
Yes, the early cocoon days (somewhere around 2001)  had a nice overview 
of the reactor and how it worked.
> Your criticism was very, very constructive and it brought a lot value to the discussion.
I would
> love to always see such concrete e-mails. I'm very grateful for your e-mail.
>
>   
ok, so I'll chew and spit some more when  I'm blocked.


Anyway, I think cocoon is one of the best concepts to be found in the 
Java world. It is just a shame Java webapp development (even with 
spring/ cocoon/...) medieval compared to something like Zope 
(http://zope.org/).
Just a simple example of a more advanced feature  :
- Versioning is there inside the application server, so you can debug on 
the application server in production in your own private coding session, 
without disturbing the real production users. and then just 'commit' 
your changes after you fixed it, and the next created user session will 
use the latest (fixed) code.

This was introduced in Zope somewhere in the year 2000.

I'm also pretty sure SeaSide developers are laughing their asses off 
when they see the current state of j2ee development.

But that's a different rant ;)

have fun,

Romain.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message