Here is how I got Cocoon 2.0.1 to work with JDK 1.4.

Here is my configuration:

RH 7.2
Tomcat 4.0.3
Cocoon 2.0.1
Apache 2.0.32 beta
tomcat-connectors 4.0.4b1

The basic reason why Cocoon fails to work with JDK 1.4 is conflicting .jar
files. JDK 1.4 provides many more libraries than 1.3.xx. As cocoon 2.0.1 is
based on JDK 1.3.XX it needs additional libraries for support certain
functionality. Some of these are now available in JDK 1.4. To solve this go
through the following steps.

1. Install tomcat
2. Put the cocoon.war in the tomcat/webapps dir
3. Start tomcat
4. You should see errors in the tomcat/logs/localhost_log.XXX.txt file
regarding Cocoon.
5. Shutdown tomcat
6. cd tomcat/webapps/cocoon/WEB-INF/lib directory.
7. mv batik-libs-1.1.1.jar /usr/java/j2sdk1.4.0/jre/lib/ext
8. mv xml-apis.jar /usr/java/j2sdk1.4.0/jre/lib/ext
        Both the above file are somehow required by tomcat
        as well when deploying Cocoon but fails to pick them up
        from the tomcat/webapps/cocoon/WEB-INF/lib directory
9. Move the following files out of the tomcat tree somewhere safe:
        a. deli-0.41.jar
        b. hsqldb-1.61.jar
        c. javac.jar
        d. jena-1.3.0.jar
        e. jimi-1.0.jar
        f. jtidy-04Aug2000r7-dev.jar
        g. rdffilter.jar
        h. rhino-1.5r2.jar
        i. xalan-2.2.0.jar
        j. xt-19991105.jar
10. Start tomcat.
11. Now you should be able to get Cocoon working properly.

Some of the files that I moved out of the tomcat tree might be required
somewhere in the Cocoon tree. But I have not found such a page yet. The best
way is to go over all the pages in the sample site that Cocoon provide and
at the same time monitor the
tomcat/webapps/cocoon/WEB-INF/logs/error.log.00001 file. If you get an error
on one of the Cocoon page you can find out which class is missing by looking
at the error_log.00001 file. Just add the required .jar file back in the
tomcat/webapps/cocoon/WEB-INF/lib directory. Hence all the files that remain
conflict with the libraries present in the JDK 1.4 release.

I would appreciate such a list.

One thing is for sure though, SVG functionality is severely affected due to
working with JDK 1.4. Pages that use to show the graphics properly are
mostly failing to display SVG generated images. Surprisingly some of the
graphics do show up properly but the rest come up as plain white blobs. This
needs more in depth look to identify the exact reason.

Here is the script that will dump contents of the .jar file. This will help
you in identifying which .jar file is needed in case error_log.00001 file
shows an ERROR message indicating a missing CLASS:

cd tomcat/webapps/cocoon/WEB-INF/lib
for i in *.jar
do
        echo "==            $i                 =="
        jar tvf $i
done > jarlist.txt

You can search through the "jarlist.txt" file to identify the required class
and which ",jar" it belongs to.

When the TOMCAT is up and you can see all the pages in Cocoon go back to the
following 2 files:
1. tomcat/logs/localhost_log.XXX.txt
2. tomcat/webapps/cocoon/WEB-INF/logs/error.log.00001

They should not contain any error messages regarding any missing class file
or object.

I hope this helps. Let me know if you any more problems with.

Regards, Atul

-----Original Message-----
From: Matt Williams [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 06, 2002 9:55 AM
To: [EMAIL PROTECTED]
Subject: RE: HOWTO: jdk1.4


Yeah, I know ;-)
What i probably meant was you dont need to "hack up" the distribution
with custom libraries.
The endorsed directory is there because the new jdk includes apis which
are still under revision.
Obviously this means that the standards are likely to change, as they
quite obviously have, hence the incompatibilities in the libraries
mentioned.
I find this a great deal more realistic than waiting for an update to
the jdk, or hacking throught the configuration file of every piece of
software I wish to run which requires a newer version of, for example,
the sax api.
Deployment nightmare?

-----Original Message-----
From: Lewis, Andrew J [mailto:[EMAIL PROTECTED]] 
Sent: miércoles, 06 de marzo de 2002 14:02
To: '[EMAIL PROTECTED]'
Subject: RE: HOWTO: jdk1.4


/jre/lib/endorsed is in fact within the /jre/lib

I understand that you may like it this way, but I'll stick with other
solutions (which have been mentioned since my post). In my experience,
this sort of solution is a deployment nightmare....



> ----------
> From:         Matt Williams[SMTP:[EMAIL PROTECTED]]
> Reply To:     [EMAIL PROTECTED]
> Sent:         Tuesday, March 05, 2002 6:02 PM
> To:   [EMAIL PROTECTED]
> Subject:      RE: HOWTO: jdk1.4
>
> Hi andrew,
> Dont seem to be any required changes to the jre/lib at all. Maybe you 
> mean the jre/lib/endorsed directory. This isnt so much "grief" as 
> updating specific classes. I like it this way.
>
> Matt
>
> -----Original Message-----
> From: Lewis, Andrew J [mailto:[EMAIL PROTECTED]]
> Sent: martes, 05 de marzo de 2002 14:53
> To: '[EMAIL PROTECTED]'
> Subject: RE: HOWTO: jdk1.4
>
>
> is it just me, or did the 1.4 JDK introduce a lot of grief here 
> REQUIRING changes to the jre/lib directory? Or is there another way to

> make this work?

---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

Reply via email to