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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
