Thanks Vadim, You are right. I did not quite get it in your last email.
One more thing though why do I have to copy xml-apis and batik to JRE/LIB/EXT dir to make Cocoon work. I probed around the Cocoon and Tomcat log but could not get the real reason why both these jar files are not picked up from the COCOON/WEB-INF/LIB directory but the rest of them are. I would appreciate some clues on that or at least a place to go look at. Thanks. -----Original Message----- From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 06, 2002 7:36 PM To: [EMAIL PROTECTED] Subject: RE: HOWTO: jdk1.4 > From: Bhide, Atul [mailto:[EMAIL PROTECTED]] > > I did look at it and it is plain out of date when it comes to JDK 1.4. It > says that XALAN is REQUIRED by Cocoon CORE but when it comes to JDK 1.4 you > can break the deployment if you do not remove xalan from the installation. You are misinterpreting this... Xalan *is* required for Cocoon, independent of JDK you are using. It just happened that Xalan is bundled with the JDK1.4, so you could try and remove second copy of it. Vadim > If we can modify the table to add columns for various versions of JAVA > floating around it will make a difference. > > The deployment also fails if the xml-apis & batik are not moved to more > global position. If they remain in the cocoon/WEB-INF/lib directory TOMCAT > breaks while deploying COCOON, and the only inference I get from this is > that some other application is also trying to load it but some how does not > get to the WEB-INF/lib directory. > > Regards, Atul > > -----Original Message----- > From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, March 06, 2002 6:30 PM > To: [EMAIL PROTECTED] > Subject: RE: HOWTO: jdk1.4 > > > > From: Bhide, Atul [mailto:[EMAIL PROTECTED]] > > > > 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. > > ... ahem .... > > Atul, > > Take a look at the http://xml.apache.org/cocoon/installing/jars.html. It > might be not 100% comprehensive, but still a good reading though. > > > > 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. > > IIRC, the issue was patched in the Batik CVS. > > Vadim > > > > 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]>
