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. In 2.1 (as I remember it) there was no standard procedure for creating applications based on C2.1 and it was everyone's burden to figure out best practices. In C2.2 all has been much more standardized and in long term it will result in a better health of whole life-system. When someone has a problem with C2.2 I can always ask him to provide a minimal block that exposes problem/bug. When user attaches such block to JIRA issue all I have to do is to extract and call one command: mvn jetty:run I can be sure in 99.99% of cases that I will see exactly the same behavior with minimal effort of me so I can focus on figuring out what's going wrong. For user it is also trivial to create such block because it has infrastructure (archetype) already in place. > - playing with examples: yes, the miniature examples (your first block, > adding an extra block) on the site work, but that's it. the rest of them > hasn't been ported from 2.1 yet and no, they don't work out of the box, > they need minor twiddling. 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? > - configuration: this is a complete disaster. > > -- it is just too difficult to let the average web developer do it, or > change it. So whenever a junior web developer needs something, you need > the senior java guru come in, waste some time fighting various .xml > config files before the "webbie" can continue. Thing here is that yes, > you can figure it out, but what you'ld like to have is the documentation > telling you what to do. 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. > -- most of the cocoon sub projects have a site, but most of the sites > just are a bunch of nice looking, empty, maven generated, pages. > for example: > "Core modules in detail" > fe > http://cocoon.apache.org/2.2/core-modules/expression-language-impl/1.0/project-info.html > > http://cocoon.apache.org/2.2/core-modules/store-impl/1.0/project-info.html > > now where are the details ? 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. > Even when there is something there, it sometimes just does not work > (Cocoon Authentication is such an example) > The advantage is that before you have discovered it just doesn't work > with the given documentation , you have learned enough new tricks to > solve other problems. > > -- I had some legacy servlets I needed to use, it took me ages to > discover I can set them up in servlet-service.xml instead of the usual > j2ee web.xml ... no documentation about the collusion between the name > of the block and the context-path parameter :( > I must admit here that my unhappiness here is also caused by j2ee > standards that get interpreted differently by each and every application > server out there. I haven't done the effort yet of trying to run my app > with JBoss yet, but I'm certain I'll be fighting xml config files for > more than a working day. 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. > -- 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. > -- 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 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 > -- 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. > - Architectural overview ? > didn't find any. Yep, noted added to give even one simple page that would help a bit. > > So the summary is, > cocoon might be great, but loosing half a day finding out where to add 2 > lines in a .xml file (problem is always: which .xml file and which > lines) is no fun. > It might just be that the steep learning curve is just total lack of > good documentation. And i'm pretty sure 90% of the developers just can't > afford to waste so much time on trivial configuration stuff. Agreed. > I'm sorry to have written such a negative mail, since I do believe in > (what I think to be) the concept of cocoon. 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. I'm also thinking if our users couldn't be more active when it comes to documentation. I'm wondering why people all not so eager to share their findings if they finally figure out some annoying problem. I don't want to criticize anyone but I'm wondering if users sometimes do not demand too much from developers... > have fun, Certainly I have now! I'm just capturing some goodies with Wink related to Cocoon... -- Grzegorz Kossakowski --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
