See also Updating Cocoon page on Cocoon site – Vadim

We could develop this page as two parts, "changes" and "migration tips" and put it back into that page in the official documentation. The "updating" page appears to be somewhat incomplete.--StevenCummings

If anybody likes, they can write over or modify what I put here. I don't expect this to be definitive or exhaustive, but I thought I'd write about my experiences in migrating a couple of working applications that I have from 2.0.4 to 2.1-dev. Originally, I sought out to create "CreateMinimalWebapp2.1dev", but decided that I should create this instead. If this page gets far enough along, perhaps it will contribute points to that page.

I did my testing under Tomcat 4.1.24 and Jetty 4.2.9.

Main Migration Issues:

  • "sunshine" is now "session"
    • sunshine-login action is now auth-login
    • sunshine-logout action is now auth-logout
    • sunshine-auth action is now auth-protect
    • sunshine transformer is now session
  • Use "{" and "}" for standard input modules
    • Specifically, using sunshine under 2.0.X required the prefix of request variables passed to the authentication pipeline with the string "request:". Now you just have to surround that with braces as in "{request-param:username}". This is basically the standard usage of input modules now. The session manager probably doesn't check for the prefix anymore as this scheme can be used anywhere in the sitemap.
    • Available input modules: see your cocoon.xconf file
  • Classes that have been deprecated and replaced
    • org.apache.avalon.framework.logger.AbstractLoggable is replaced by org.apache.avalon.framework.logger.AbstractLogEnabled
  • Roles that have been deprecated and replaced
    • org.apache.avalon.excalibur.xml.Parser is replaced by org.apache.excalibur.xml.sax.SAXParser
      • Additionally, it seems that because SAXParser does not extend the Component interface, that you must cast it as a Component when issuing it to the release method of your component manager. Of course you just use the new interface to cast the result of lookup.
  • Cocoon jars to include in your webapp
    • Selection of jars from cocoon.war is easier due to blocks
    • UPDATE - 2.1m3: The default cocoon.xconf file now contains XML comments that read "Start configuration from 'Blah'" and "End configuration from 'Blah'", where "Blah" is the name of the block associated with the configuration. These sections now give an excellent idea of what jars you will want to include and exclude when you are constructing your own web-application. --StevenCummings
    • Does anybody have detailed instructions on how to take the tasks from the Cocoon 2.1 build.xml and include them in your own project so that you can build just the components that you need from Cocoon for your own Cocoon-based project and web-application? --StevenCummings
  • If you are running Tomcat and Sun JDK 1.4, you must update your XML jars under $CATALINA_HOME/common/endorsed (UNIX) or %CATALINA_HOME%\common\endorsed (Win32) with the versions currently used in Cocoon Head.
    • xml-apis.jar
    • xalan.jar
    • xercesImpl.jar
    • xsltc.jar - not needed yet, because Sun does not ship XSLTC with latest JDK, but it can happen in the future

Does anybody else have any points to make here? This is really just a very shallow starting point. I welcome all who undertook the 2.0.X to 2.1-dev upgrade process to make notes here and help to build a definitive document. It seems that the structure of cocoon itself and the build process (build.xml) have changed so radically that we should collect these points to help out newer cocoon users who want to give the experimental features a shot.

Also:

  • No labels