> 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]>

Reply via email to