You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Santiago Gala <sg...@hisitech.com> on 2001/08/02 10:42:14 UTC
Re: actual cvs source not running?
Dave Carlson wrote:
>Thanks for your quick reply (on Sunday!). Sure enough, there was a /WEB-INF
>lurking in the root directory of my file system. Jetspeed now runs, without
>having copied the .vm files as noted earlier. Thanks!
>
>The only error remaining is this in lieu of any content in any RSS portal
>(e.g. within Apache Jetspeed on the default home page):
>problem in SAX transform: javax.xml.transform.TransformerException:
>ProxyEmitter.startDocument(): no underlying emitter provided
>
>Any ideas?
>
I don't have this problem. I think it is due to different versions of
TRAX/JAXP around.
One think I use to do is to remove parser.jar and jaxp.jar from the
tomcat/lib directory, and put there a xerces_1_3_1.jar (that you can
remove from jetspeed distribution depending on tomcat version).
I will try to find if it is this reason when I have a machine back (I
have been travelling, I'm supposed to be back home soon.)
>
>Cheers,
> Dave
>
>----- Original Message -----
>From: "Santiago Gala" <sg...@hisitech.com>
>To: <je...@jakarta.apache.org>
>
>>Yep. You will still have this error if you are running under root, as
>>the previous runs of unpatched jetspeed will have created an empty
>>directory /WEB-INF/psml in the root of your hierarchy. I had to fight
>>quite a bit against this one, as my local machine is running under a
>>"normal" user, while the remote one was running under "root". If you
>>delete (rm -Rf /WEB-INF/psml) and run again, it should run. I needed a
>>lot of time (yesterday) to notice it.
>>
>>I wonder if we should completely erase the mkdirs call, but maybe it is
>>needed when a new user is created.
>>
>>>But I also get another error before I even get to the ClassCastException.
>>>
>The
>
>>>first error is thrown when Jetspeed cannot find screens/Error. I recall
>>>
>some
>
>>>similar problems several weeks ago, so I can get around this error by
>>>
>copying
>
>>>vm/screens/html/Error.vm to vm/screens/Error.vm
>>>
>>I copied these files, but I'm not sure it is needed after the other fix.
>>Currently I have no copy of this file and my local copy is running well.
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: actual cvs source not running?
Posted by Paul Spencer <pa...@mikon.com>.
Dave,
I have been using 3.3-m3 for a month with Jetspeed and Cocoon 1.8.3-dev.
It has been stable, but I have not exercised, or loaded, it that much.
Paul Spencer
Dave Carlson wrote:
>
> Thanks, Paul. I did briefly test tomcat 3.3-m4 and saw the different
> structure within its /lib directory. But because I'm preparing a production
> site, I was concerned about its pre-beta status. I know that it is now at
> 3.3-b1. (Although planning to deploy an alpha Jetspeed is still within my
> tolerance for chaos :-)
>
> I haven't had time to search the tomcat mail lists, but does anyone have an
> informed opinion on the general stability of tomcat 3.3 and/or 4.0 for use
> with Jetspeed?
>
> -- Dave
>
> ----- Original Message -----
> From: "Paul Spencer" <pa...@mikon.com>
> To: <je...@jakarta.apache.org>
> Sent: Thursday, August 02, 2001 12:23 PM
> Subject: Re: actual cvs source not running?
>
> > Dave,
> > Tomcat v3.3 and 4.0 have made a lot of progress in solving this
> > problem. When using Tomcat v3.2 with Jetspeed and Cocoon, I had to use
> > two instance of Tomcat. With Tomcat 3.3, all jars can be place in
> > application specific lib directories while using the same instance of
> > Tomcat.
> >
> > Paul Spencer
> >
> > Dave Carlson wrote:
> > >
> > > Thanks, I fixed this one. It was caused by a copy of the saxon.jar XSLT
> > > processor in the tomcat lib, in addition to jaxp, xerces and xalan. It
> seems
> > > that jetspeed worked on windows because the tomcat startup script used the
> > > file order on windows when assembling the CLASSPATH, which put saxon.jar
> last.
> > > Whereas the tomcat start script on Linux assembled a CLASSPATH with jars
> in
> > > alphabetical order, which put saxon.jar before xerces and xalan.
> > >
> > > I need saxon for another application running in tomcat, but due to
> classloader
> > > issues, I am forced to put saxon.jsr in the tomcat classpath instead of in
> the
> > > other application's webapps lib. saxon.jar must be in the same
> classloader as
> > > jaxp.jar (at least, that appears to be the root cause).
> > >
> > > These conflicts between different XML parsers and different versions is
> easily
> > > the biggest issue in app server deployment...
> > >
> > > Thanks,
> > > Dave
> > >
> > > ----- Original Message -----
> > > From: "Santiago Gala" <sg...@hisitech.com>
> > >
> > > > >The only error remaining is this in lieu of any content in any RSS
> portal
> > > > >(e.g. within Apache Jetspeed on the default home page):
> > > > >problem in SAX transform: javax.xml.transform.TransformerException:
> > > > >ProxyEmitter.startDocument(): no underlying emitter provided
> > > > >
> > > > >Any ideas?
> > > > >
> > > > I don't have this problem. I think it is due to different versions of
> > > > TRAX/JAXP around.
> > > >
> > > > One think I use to do is to remove parser.jar and jaxp.jar from the
> > > > tomcat/lib directory, and put there a xerces_1_3_1.jar (that you can
> > > > remove from jetspeed distribution depending on tomcat version).
> > > >
> > > > I will try to find if it is this reason when I have a machine back (I
> > > > have been travelling, I'm supposed to be back home soon.)
> > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: actual cvs source not running?
Posted by Dave Carlson <dc...@ontogenics.com>.
Thanks, Paul. I did briefly test tomcat 3.3-m4 and saw the different
structure within its /lib directory. But because I'm preparing a production
site, I was concerned about its pre-beta status. I know that it is now at
3.3-b1. (Although planning to deploy an alpha Jetspeed is still within my
tolerance for chaos :-)
I haven't had time to search the tomcat mail lists, but does anyone have an
informed opinion on the general stability of tomcat 3.3 and/or 4.0 for use
with Jetspeed?
-- Dave
----- Original Message -----
From: "Paul Spencer" <pa...@mikon.com>
To: <je...@jakarta.apache.org>
Sent: Thursday, August 02, 2001 12:23 PM
Subject: Re: actual cvs source not running?
> Dave,
> Tomcat v3.3 and 4.0 have made a lot of progress in solving this
> problem. When using Tomcat v3.2 with Jetspeed and Cocoon, I had to use
> two instance of Tomcat. With Tomcat 3.3, all jars can be place in
> application specific lib directories while using the same instance of
> Tomcat.
>
> Paul Spencer
>
> Dave Carlson wrote:
> >
> > Thanks, I fixed this one. It was caused by a copy of the saxon.jar XSLT
> > processor in the tomcat lib, in addition to jaxp, xerces and xalan. It
seems
> > that jetspeed worked on windows because the tomcat startup script used the
> > file order on windows when assembling the CLASSPATH, which put saxon.jar
last.
> > Whereas the tomcat start script on Linux assembled a CLASSPATH with jars
in
> > alphabetical order, which put saxon.jar before xerces and xalan.
> >
> > I need saxon for another application running in tomcat, but due to
classloader
> > issues, I am forced to put saxon.jsr in the tomcat classpath instead of in
the
> > other application's webapps lib. saxon.jar must be in the same
classloader as
> > jaxp.jar (at least, that appears to be the root cause).
> >
> > These conflicts between different XML parsers and different versions is
easily
> > the biggest issue in app server deployment...
> >
> > Thanks,
> > Dave
> >
> > ----- Original Message -----
> > From: "Santiago Gala" <sg...@hisitech.com>
> >
> > > >The only error remaining is this in lieu of any content in any RSS
portal
> > > >(e.g. within Apache Jetspeed on the default home page):
> > > >problem in SAX transform: javax.xml.transform.TransformerException:
> > > >ProxyEmitter.startDocument(): no underlying emitter provided
> > > >
> > > >Any ideas?
> > > >
> > > I don't have this problem. I think it is due to different versions of
> > > TRAX/JAXP around.
> > >
> > > One think I use to do is to remove parser.jar and jaxp.jar from the
> > > tomcat/lib directory, and put there a xerces_1_3_1.jar (that you can
> > > remove from jetspeed distribution depending on tomcat version).
> > >
> > > I will try to find if it is this reason when I have a machine back (I
> > > have been travelling, I'm supposed to be back home soon.)
> > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: actual cvs source not running?
Posted by Paul Spencer <pa...@mikon.com>.
Dave,
Tomcat v3.3 and 4.0 have made a lot of progress in solving this
problem. When using Tomcat v3.2 with Jetspeed and Cocoon, I had to use
two instance of Tomcat. With Tomcat 3.3, all jars can be place in
application specific lib directories while using the same instance of
Tomcat.
Paul Spencer
Dave Carlson wrote:
>
> Thanks, I fixed this one. It was caused by a copy of the saxon.jar XSLT
> processor in the tomcat lib, in addition to jaxp, xerces and xalan. It seems
> that jetspeed worked on windows because the tomcat startup script used the
> file order on windows when assembling the CLASSPATH, which put saxon.jar last.
> Whereas the tomcat start script on Linux assembled a CLASSPATH with jars in
> alphabetical order, which put saxon.jar before xerces and xalan.
>
> I need saxon for another application running in tomcat, but due to classloader
> issues, I am forced to put saxon.jsr in the tomcat classpath instead of in the
> other application's webapps lib. saxon.jar must be in the same classloader as
> jaxp.jar (at least, that appears to be the root cause).
>
> These conflicts between different XML parsers and different versions is easily
> the biggest issue in app server deployment...
>
> Thanks,
> Dave
>
> ----- Original Message -----
> From: "Santiago Gala" <sg...@hisitech.com>
>
> > >The only error remaining is this in lieu of any content in any RSS portal
> > >(e.g. within Apache Jetspeed on the default home page):
> > >problem in SAX transform: javax.xml.transform.TransformerException:
> > >ProxyEmitter.startDocument(): no underlying emitter provided
> > >
> > >Any ideas?
> > >
> > I don't have this problem. I think it is due to different versions of
> > TRAX/JAXP around.
> >
> > One think I use to do is to remove parser.jar and jaxp.jar from the
> > tomcat/lib directory, and put there a xerces_1_3_1.jar (that you can
> > remove from jetspeed distribution depending on tomcat version).
> >
> > I will try to find if it is this reason when I have a machine back (I
> > have been travelling, I'm supposed to be back home soon.)
> >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: actual cvs source not running?
Posted by Dave Carlson <dc...@ontogenics.com>.
Thanks, I fixed this one. It was caused by a copy of the saxon.jar XSLT
processor in the tomcat lib, in addition to jaxp, xerces and xalan. It seems
that jetspeed worked on windows because the tomcat startup script used the
file order on windows when assembling the CLASSPATH, which put saxon.jar last.
Whereas the tomcat start script on Linux assembled a CLASSPATH with jars in
alphabetical order, which put saxon.jar before xerces and xalan.
I need saxon for another application running in tomcat, but due to classloader
issues, I am forced to put saxon.jsr in the tomcat classpath instead of in the
other application's webapps lib. saxon.jar must be in the same classloader as
jaxp.jar (at least, that appears to be the root cause).
These conflicts between different XML parsers and different versions is easily
the biggest issue in app server deployment...
Thanks,
Dave
----- Original Message -----
From: "Santiago Gala" <sg...@hisitech.com>
> >The only error remaining is this in lieu of any content in any RSS portal
> >(e.g. within Apache Jetspeed on the default home page):
> >problem in SAX transform: javax.xml.transform.TransformerException:
> >ProxyEmitter.startDocument(): no underlying emitter provided
> >
> >Any ideas?
> >
> I don't have this problem. I think it is due to different versions of
> TRAX/JAXP around.
>
> One think I use to do is to remove parser.jar and jaxp.jar from the
> tomcat/lib directory, and put there a xerces_1_3_1.jar (that you can
> remove from jetspeed distribution depending on tomcat version).
>
> I will try to find if it is this reason when I have a machine back (I
> have been travelling, I'm supposed to be back home soon.)
>
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org