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 Michael Steindl <Mi...@SERprocess.com> on 2001/07/24 12:48:48 UTC
actual cvs source not running?
hi there,
having a tremendous problem with the actual cvs files:
after building the jetspeed.war I'm receiving the following stack-trace:
any idear??
=====================================================>
Horrible Exception: java.lang.ClassCastException: java.lang.String
at
org.apache.jetspeed.services.rundata.DefaultJetspeedRunData.getProfile(Defau
ltJetspeedRunData.java:237)
at
org.apache.jetspeed.modules.actions.JetspeedSessionValidator.doPerform(Jetsp
eedSessionValidator.java:127)
at org.apache.turbine.modules.Action.perform(Action.java:87)
at org.apache.turbine.modules.ActionLoader.exec(ActionLoader.java:122)
at org.apache.turbine.Turbine.doGet(Turbine.java:405)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.
java:566)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatch
er.java:355)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher
.java:292)
at
org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:398)
at org.apache.jsp.index_jsp._jspService(index_jsp.java:58)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja
va:200)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:379)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:453)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:254)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:194)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va:255)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
va:225)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2252)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164
)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:446)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
64)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
:163)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:
875)
at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:952)
at java.lang.Thread.run(Thread.java:484)
====================================================
cheers,
michael.
---------------------------------------------------------------------
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 Raphaël Luta <ra...@networks.groupvu.com>.
Santiago Gala wrote:
>
> Better than this, (I got it), I'm committing a change to the
> CastorPsmlManagerService.
>
> The problem was funny: "/WEB-INF/psml" is *not* absolute under Windows
> (as per java specification, an absolute path in Windows needs the drive
> letter), but it *is* absolute under Unix, so the test:
>
> if( !rootDir.isAbsolute()) was giving different results in both platforms.
> I have chaged it to if( !rootDir.exists() ) so that now, if the root
> does not exist, is taken as context-relative, else it is created.
>
> I'll be commiting right now. It can take a while, as I'm using GPRS + my
> mobile phone from my parent's house in the beach, and the connection is
> flaky.
>
Thanks Santiago :)
It's lucky we don't all use the same setup... ;P
--
Raphael Luta - raphael.luta@networks.groupvu.com
Vivendi Universal Networks - Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: cvs access for Paul Spencer
Posted by Stan Pinte <st...@wanadoo.be>.
At 19:00 30/07/2001 -0700, you wrote:
>I've been working with Paul Spencer on the Jetspeed documentation, and I
>think he's doing a great job of it.
>I'd like to recommend him as a Jetspeed committer, so he continue with his
>work on making frequent and valuable contributions to the documentation.
>I believe Paul is committed to working on Jetspeed, and will be an excellent
>addition to the team.
>
>+1
I also read the doc, which proved to be very useful.
As someone not yet involved, I vote symbolically.
+1
>---------------------------------------------------------------------
>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Stanislas Pinte
Computer Consultant
Sales Director
Alto Software
20 Pl St Jacques
B-4000 Liège
Tel+Fax: +32 -(0)4 221 35 08
GSM: +32 -(0)478 57 61 80
web: http://www.altosw.be
email: stan@altosw.be
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
Re: actual cvs source not running?
Posted by Santiago Gala <sg...@hisitech.com>.
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 Dave Carlson <dc...@ontogenics.com>.
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?
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
Re: cvs access for Paul Spencer
Posted by Raphaël Luta <ra...@networks.groupvu.com>.
David Sean Taylor wrote:
> I've been working with Paul Spencer on the Jetspeed documentation, and I
> think he's doing a great job of it.
> I'd like to recommend him as a Jetspeed committer, so he continue with his
> work on making frequent and valuable contributions to the documentation.
> I believe Paul is committed to working on Jetspeed, and will be an excellent
> addition to the team.
>
> +1
>
+1
--
Raphael Luta - raphael.luta@networks.groupvu.com
Vivendi Universal Networks - Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: cvs access for Paul Spencer
Posted by Santiago Gala <sg...@hisitech.com>.
David Sean Taylor wrote:
>I've been working with Paul Spencer on the Jetspeed documentation, and I
>think he's doing a great job of it.
>I'd like to recommend him as a Jetspeed committer, so he continue with his
>work on making frequent and valuable contributions to the documentation.
>I believe Paul is committed to working on Jetspeed, and will be an excellent
>addition to the team.
>
>+1
>
I was missing. +1 here.
Sorry, I was moving.
>
>
>
>---------------------------------------------------------------------
>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: cvs access for Paul Spencer
Posted by Frans <ft...@yahoo.com>.
+1 for his Portlet Catalog.
Great job..
Frans
----- Original Message -----
From: "David Sean Taylor" <da...@bluesunrise.com>
To: <je...@jakarta.apache.org>
Sent: Tuesday, July 31, 2001 9:00 AM
Subject: cvs access for Paul Spencer
> I've been working with Paul Spencer on the Jetspeed documentation, and I
> think he's doing a great job of it.
> I'd like to recommend him as a Jetspeed committer, so he continue with his
> work on making frequent and valuable contributions to the documentation.
> I believe Paul is committed to working on Jetspeed, and will be an
excellent
> addition to the team.
>
> +1
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
cvs access for Paul Spencer
Posted by David Sean Taylor <da...@bluesunrise.com>.
I've been working with Paul Spencer on the Jetspeed documentation, and I
think he's doing a great job of it.
I'd like to recommend him as a Jetspeed committer, so he continue with his
work on making frequent and valuable contributions to the documentation.
I believe Paul is committed to working on Jetspeed, and will be an excellent
addition to the team.
+1
---------------------------------------------------------------------
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 Santiago Gala <sg...@hisitech.com>.
Dave Carlson wrote:
>The fix by Santiago still does not work for me. I just did a full cvs
>checkout and rebuilt about 10 minutes ago, and I still get the same
>ClassCastException as I did before. I'm running on RedHat Linux with jvm
>1.3.0 and tomcat 3.2.3. The exception is:
>
>Horrible Exception: java.lang.ClassCastException: java.lang.String
> at
>org.apache.jetspeed.services.rundata.DefaultJetspeedRunData.getProfile(Default
>JetspeedRunData.java:237)
> at
>org.apache.jetspeed.modules.actions.JetspeedSessionValidator.doPerform(Jetspee
>dSessionValidator.java:127)
> at org.apache.turbine.modules.Action.perform(Action.java:87)
>
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.
>
>After copying this file, I get the ClassCastException noted above. The full
>text of the first Resource exception is:
>
>Horrible Exception: org.apache.velocity.exception.ResourceNotFoundException:
>Unable to find resource 'screens/Error'
> at
>org.apache.velocity.runtime.resource.ResourceManager.getResource(ResourceManag
>er.java)
> at org.apache.velocity.runtime.Runtime.getTemplate(Runtime.java)
> at org.apache.velocity.app.Velocity.mergeTemplate(Velocity.java)
> at org.apache.velocity.app.Velocity.mergeTemplate(Velocity.java)
>rethrown as org.apache.turbine.util.TurbineException: Error rendering Velocity
>template: screens/Error: Unable to find resource 'screens/Error'
> at
>org.apache.turbine.services.velocity.TurbineVelocityService.renderingError(Tur
>bineVelocityService.java:392)
> at
>org.apache.turbine.services.velocity.TurbineVelocityService.decodeRequest(Turb
>ineVelocityService.java:356)
>rethrown as org.apache.turbine.util.TurbineException: Error rendering Velocity
>template: screens/Error: Error rendering Velocity template: screens/Error:
>Unable to find resource 'screens/Error'
> at
>org.apache.turbine.services.velocity.TurbineVelocityService.renderingError(Tur
>bineVelocityService.java:392)
> at
>org.apache.turbine.services.velocity.TurbineVelocityService.handleRequest(Turb
>ineVelocityService.java:252)
> at
>org.apache.turbine.services.velocity.TurbineVelocity.handleRequest(TurbineVelo
>city.java:109)
> at
>org.apache.turbine.modules.screens.VelocityScreen.buildTemplate(VelocityScreen
>.java:169)
> at
>org.apache.turbine.modules.screens.TemplateScreen.doBuild(TemplateScreen.java:
>130)
> at org.apache.turbine.modules.Screen.build(Screen.java:99)
> at org.apache.turbine.modules.ScreenLoader.eval(ScreenLoader.java:129)
> at
>org.apache.turbine.modules.layouts.VelocityOnlyLayout.doBuild(VelocityOnlyLayo
>ut.java:98)
> at org.apache.turbine.modules.Layout.build(Layout.java:91)
> at org.apache.turbine.modules.LayoutLoader.exec(LayoutLoader.java:123)
> at org.apache.turbine.modules.pages.DefaultPage.doBuild(DefaultPage.java:166)
> at org.apache.turbine.modules.Page.build(Page.java:90)
> at org.apache.turbine.modules.PageLoader.exec(PageLoader.java:123)
>
>
>----- Original Message -----
>From: "Santiago Gala" <sg...@hisitech.com>
>
>>Better than this, (I got it), I'm committing a change to the
>>CastorPsmlManagerService.
>>
>>The problem was funny: "/WEB-INF/psml" is *not* absolute under Windows
>>(as per java specification, an absolute path in Windows needs the drive
>>letter), but it *is* absolute under Unix, so the test:
>>
>>if( !rootDir.isAbsolute()) was giving different results in both platforms.
>>I have chaged it to if( !rootDir.exists() ) so that now, if the root
>>does not exist, is taken as context-relative, else it is created.
>>
>>I'll be commiting right now. It can take a while, as I'm using GPRS + my
>>mobile phone from my parent's house in the beach, and the connection is
>>flaky.
>>
>
>
>
>---------------------------------------------------------------------
>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>.
One additional note on my last message. The identical jetspeed.war file works
perfectly when copied to Win98 and run in tomcat 3.2.3
-- Dave
----- Original Message -----
From: "Dave Carlson" <dc...@ontogenics.com>
To: <je...@jakarta.apache.org>
Sent: Sunday, July 29, 2001 1:24 PM
Subject: Re: actual cvs source not running?
> The fix by Santiago still does not work for me. I just did a full cvs
> checkout and rebuilt about 10 minutes ago, and I still get the same
> ClassCastException as I did before. I'm running on RedHat Linux with jvm
> 1.3.0 and tomcat 3.2.3. The exception is:
---------------------------------------------------------------------
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>.
The fix by Santiago still does not work for me. I just did a full cvs
checkout and rebuilt about 10 minutes ago, and I still get the same
ClassCastException as I did before. I'm running on RedHat Linux with jvm
1.3.0 and tomcat 3.2.3. The exception is:
Horrible Exception: java.lang.ClassCastException: java.lang.String
at
org.apache.jetspeed.services.rundata.DefaultJetspeedRunData.getProfile(Default
JetspeedRunData.java:237)
at
org.apache.jetspeed.modules.actions.JetspeedSessionValidator.doPerform(Jetspee
dSessionValidator.java:127)
at org.apache.turbine.modules.Action.perform(Action.java:87)
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
After copying this file, I get the ClassCastException noted above. The full
text of the first Resource exception is:
Horrible Exception: org.apache.velocity.exception.ResourceNotFoundException:
Unable to find resource 'screens/Error'
at
org.apache.velocity.runtime.resource.ResourceManager.getResource(ResourceManag
er.java)
at org.apache.velocity.runtime.Runtime.getTemplate(Runtime.java)
at org.apache.velocity.app.Velocity.mergeTemplate(Velocity.java)
at org.apache.velocity.app.Velocity.mergeTemplate(Velocity.java)
rethrown as org.apache.turbine.util.TurbineException: Error rendering Velocity
template: screens/Error: Unable to find resource 'screens/Error'
at
org.apache.turbine.services.velocity.TurbineVelocityService.renderingError(Tur
bineVelocityService.java:392)
at
org.apache.turbine.services.velocity.TurbineVelocityService.decodeRequest(Turb
ineVelocityService.java:356)
rethrown as org.apache.turbine.util.TurbineException: Error rendering Velocity
template: screens/Error: Error rendering Velocity template: screens/Error:
Unable to find resource 'screens/Error'
at
org.apache.turbine.services.velocity.TurbineVelocityService.renderingError(Tur
bineVelocityService.java:392)
at
org.apache.turbine.services.velocity.TurbineVelocityService.handleRequest(Turb
ineVelocityService.java:252)
at
org.apache.turbine.services.velocity.TurbineVelocity.handleRequest(TurbineVelo
city.java:109)
at
org.apache.turbine.modules.screens.VelocityScreen.buildTemplate(VelocityScreen
.java:169)
at
org.apache.turbine.modules.screens.TemplateScreen.doBuild(TemplateScreen.java:
130)
at org.apache.turbine.modules.Screen.build(Screen.java:99)
at org.apache.turbine.modules.ScreenLoader.eval(ScreenLoader.java:129)
at
org.apache.turbine.modules.layouts.VelocityOnlyLayout.doBuild(VelocityOnlyLayo
ut.java:98)
at org.apache.turbine.modules.Layout.build(Layout.java:91)
at org.apache.turbine.modules.LayoutLoader.exec(LayoutLoader.java:123)
at org.apache.turbine.modules.pages.DefaultPage.doBuild(DefaultPage.java:166)
at org.apache.turbine.modules.Page.build(Page.java:90)
at org.apache.turbine.modules.PageLoader.exec(PageLoader.java:123)
----- Original Message -----
From: "Santiago Gala" <sg...@hisitech.com>
> Better than this, (I got it), I'm committing a change to the
> CastorPsmlManagerService.
>
> The problem was funny: "/WEB-INF/psml" is *not* absolute under Windows
> (as per java specification, an absolute path in Windows needs the drive
> letter), but it *is* absolute under Unix, so the test:
>
> if( !rootDir.isAbsolute()) was giving different results in both platforms.
> I have chaged it to if( !rootDir.exists() ) so that now, if the root
> does not exist, is taken as context-relative, else it is created.
>
> I'll be commiting right now. It can take a while, as I'm using GPRS + my
> mobile phone from my parent's house in the beach, and the connection is
> flaky.
>
---------------------------------------------------------------------
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 Santiago Gala <sg...@hisitech.com>.
Raphaël Luta wrote:
> Michael Steindl wrote:
>
>> hi there,
>>
>> having a tremendous problem with the actual cvs files:
>>
>> after building the jetspeed.war I'm receiving the following stack-trace:
>>
>> any idear??
>>
>> =====================================================>
>>
>> Horrible Exception: java.lang.ClassCastException: java.lang.String
>> at
>
>
>
> I've setup a Solaris test box in order to reproduce this bug and it seems
> like there's a weird behavior difference in the Turbine API between Unix
> and Windows:
>
> The cast excpetion comes from the
> getProfile() method is DefaultJetspeedRunData
>
> getProfile()
> {
> return (Profile)rundata.getUser().getTemp("profile");
> }
>
> On Windows, this method returns null when the profile property is not
> set,
> on Unix, it looks like it returns an empty string instead of null for
> some
> reasons.
> I've not yet had the time to investigate more thoroughly and I'd
> appreciate
> if anybody with some time on his hand could track the precise bug.
>
> As an interim fix, you can modify the above method to:
>
> public Profile getProfile()
> {
> Profile profile=null;
> try
> {
> profile=(Profile)this.getUser().getTemp("profile");
> }
> catch (ClassCastException e)
> {
> profile=null;
> }
>
> return profile;
> }
>
> This will get you to the next error but does not solve everything.
Better than this, (I got it), I'm committing a change to the
CastorPsmlManagerService.
The problem was funny: "/WEB-INF/psml" is *not* absolute under Windows
(as per java specification, an absolute path in Windows needs the drive
letter), but it *is* absolute under Unix, so the test:
if( !rootDir.isAbsolute()) was giving different results in both platforms.
I have chaged it to if( !rootDir.exists() ) so that now, if the root
does not exist, is taken as context-relative, else it is created.
I'll be commiting right now. It can take a while, as I'm using GPRS + my
mobile phone from my parent's house in the beach, and the connection is
flaky.
>
> --
> Raphael Luta - raphael.luta@networks.groupvu.com
> Vivendi Universal Networks - Paris
>
>
> ---------------------------------------------------------------------
> 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 Raphaël Luta <ra...@networks.groupvu.com>.
Michael Steindl wrote:
> hi there,
>
> having a tremendous problem with the actual cvs files:
>
> after building the jetspeed.war I'm receiving the following stack-trace:
>
> any idear??
>
> =====================================================>
>
> Horrible Exception: java.lang.ClassCastException: java.lang.String
> at
I've setup a Solaris test box in order to reproduce this bug and it seems
like there's a weird behavior difference in the Turbine API between Unix
and Windows:
The cast excpetion comes from the
getProfile() method is DefaultJetspeedRunData
getProfile()
{
return (Profile)rundata.getUser().getTemp("profile");
}
On Windows, this method returns null when the profile property is not set,
on Unix, it looks like it returns an empty string instead of null for some
reasons.
I've not yet had the time to investigate more thoroughly and I'd appreciate
if anybody with some time on his hand could track the precise bug.
As an interim fix, you can modify the above method to:
public Profile getProfile()
{
Profile profile=null;
try
{
profile=(Profile)this.getUser().getTemp("profile");
}
catch (ClassCastException e)
{
profile=null;
}
return profile;
}
This will get you to the next error but does not solve everything.
--
Raphael Luta - raphael.luta@networks.groupvu.com
Vivendi Universal Networks - Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org