Re: [SPAM] Re: How to get localized string in VelocityPortletAction
Hello David,
Thanks to everybody for help.
But I need to get localized string in my Action class inherited from
Velocity Action class, not in Velocity template.
I figured out that I can use CustomLocalization.getString(...) method. Is that right
way?
Hello ,
My question is:
how to get localized string from buildNormalContext(VelocityPortlet
portlet, Context context, RunData rundata)
method in VelocityPortletAction.
I was able to do this via this code, in my buildNormalContext method:
Object ltojb = context.get(l10n);
CustomLocalizationTool lt = (CustomLocalizationTool) ltojb;
context.put(test, lt.get(HELLO));
In the template, you just reference $test as normal.
DST the localized string HELLO can be accessed in your templates as:
DST ${l10n.HELLO}
DST this the context.put is unnecessary
--
Best regards,
Petermailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: working oracle psml in jetspeed 1.5
Dan Moore wrote: Hi David, --- David Sean Taylor [EMAIL PROTECTED] wrote: Dan Moore wrote: In order to get the PSML working in Oracle, from the 1.5 binary distribution of Jetspeed, in addition to following the instructions here regarding importing, http://portals.apache.org/jetspeed-1/psml_db.html, I also had to make some changes to class files and sql files. You need both the src and binary distributions. There's a diff of the relevant files below. Modify the java files: Add _SEQ onto the value in setPrimaryKeyMethodInfo in each of the org/apache/jetspeed/om/dbpsml/map/Jetspeed* files. The files that are you recommended for patching are not in the CVS. They are Torque generated files. To use Oracle, or any other database besides Hypersonic with Jetspeed-1, follow the steps here: http://portals.apache.org/jetspeed-1/database.html I'm certainly no Torque expert. Thanks for the link. I followed the instructions on that page. I changed Torque.properties: torque.database.default.adapter=oracle Did you see step #1: edit project.properties ? After doing that, run maven torque:sql just to see what your DDL looks like Go to target/classes/sql/dbpsml-schema.sql It should look something like this: (disclaimer: im using 1.6-dev from the cvs head) DROP TABLE JETSPEED_USER_PROFILE CASCADE CONSTRAINTS; DROP SEQUENCE JETSPEED_USER_PROFILE_SEQ; CREATE TABLE JETSPEED_USER_PROFILE ( PSML_ID NUMBER NOT NULL, USER_NAME VARCHAR2 (32) NOT NULL, MEDIA_TYPE VARCHAR2 (99), LANGUAGE VARCHAR2 (2), COUNTRY VARCHAR2 (2), PAGE VARCHAR2 (99), PROFILE LONG RAW, CONSTRAINT JETSPEED_USER_PROFILE_UNIQUE UNIQUE (USER_NAME, MEDIA_TYPE, LANGUAGE, COUNTRY, PAGE) ); ALTER TABLE JETSPEED_USER_PROFILE ADD CONSTRAINT JETSPEED_USER_PROFILE_PK PRIMARY KEY (PSML_ID); CREATE SEQUENCE JETSPEED_USER_PROFILE_SEQ INCREMENT BY 1 START WITH 1 NOMAXVALUE NOCYCLE NOCACHE ORDER; I didn't change the other config in Torque.properties yet--my database is down at the moment. Does Torque need to connect to the db to generate the sql? (I hope not.) no Anyway, maven dist did generate new sql files here: jetspeed-1.5/target/jetspeed-1.5/src/jetspeed-1.5/src/sql/external check the time stamp i beleve even with 1.5 we started writing to the target/classes/sql directory This sounds like a fantastic idea! Any volunteers? ;) -- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] [office] +01 707 773 4646 [mobile] +01 707 529 9194 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to redirect or forward a page
I encounter a problem in redirecting/forwarding a page in jetspeed. I
know how to forward page between a same portlet by using setTemplate
method. But I can't get to forward to another URL. I have try two ways,
by redirecting in action class and in jsp page, they just don't work:
**Action class**
public void doPrintlabel(RunData rundata, Portlet portlet) {
rundata.getResponse().sendRedirect(http://www.google.com;);
}
**jsp page in a portlet**
% response.sendRedirect(http://www.google.com;); %
or
jsp:forward page=http://www.google.com; /
In both case, the error I received says that the page cannot be
redirected because the response header has been sent. How can I bypass
this? Any suggestion on page redirect/forward will be helpful! Thanks!
This e-mail (including any attachments) may contain information which is privileged or
confidential or constitute non-public information. It is to be conveyed only to the
intended recipient(s). If you received this e-mail in error, please notify the sender
immediately by e-mail or telephone and delete the e-mail from your system without
reading, copying or disclosing its contents to any other person.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Compile
Hi all, Were I can specify to Maven that it executed the compile with parameter encoding=windows-1251 ? For example:javac -encoding=windows-1251 .. Thanks in advance VL
RE: Running Jetspeed 1.5 on JRun4
Figured out the problem. It was indeed a conflict between the log4j versions, but somehow, the Jetspeed application was not picking up the log4j jar in its own WEB-INF\lib directory, but rather, the log4j classes in the JRUN_HOME\lib\oem-xdoclet.jar. The problem was rectified by taking the Jetspeed log4j jar out of the jetspeed WEB-INF\lib and putting it in JRUN_HOME\servers\lib. This is a bit unorthodox though. Shouldn't the application specific jars in WEB-INF\lib be overriding the other classpaths? Anyway, thanks to Scott for taking the time to help out! -Original Message- From: Stathis, George [mailto:[EMAIL PROTECTED] Sent: Thursday, October 14, 2004 10:47 AM To: 'Jetspeed Users List' Subject: RE: Running Jetspeed 1.5 on JRun4 Thank you for the prompt reply. I'm running J1.5 by the way. I just tried your suggestion and the problem persists in the exact same way (same messages). Looking at the classpath available to the JRun JVM, I see that there are two versions of log4j *in addition* to the one in Jetspeed itself. They both come built-in JRun. One is in: %JRUN_HOME%\servers\cfusion\cfusion-ear\cfusion-war\WEB-INF\cfusion\lib\log4 j.jar The other in: %JRUN_HOME%\lib\oem-xdoclet.jar which contains open source libraries, one of which is log4j. Both directories above are in the JVM classpath. For a test, I put back the log4j jar in jetspeed/WEB-INF/lib and *removed* the two directories above from the class path. Same error. Then, I removed the log4j jar from jetspeed/WEB-INF/lib again, and also left out the two directories above from the classpath. Different error: (!) NOTICE: Turbine: init() failed: java.lang.NoClassDefFoundError: org/apache/log4j/LogManager Ahaa! NoClassDefFoundError Now I know that log4j is completely out of the classpath. I re-tested now by putting back into the classpath each jar one by one. Results: The %JRUN_HOME%\servers\cfusion\cfusion-ear\cfusion-war\WEB-INF\cfusion\lib\log4 j.jar is not being picked up. If it's the only one in the classpath, I still get a NoClassDefFoundError error. But both the %JRUN_HOME%\lib\oem-xdoclet.jar and the Jetspeed log4j.jar cause the exact same error: (!) NOTICE: Turbine: init() failed: java.lang.VerifyError: (class: org/apache/log4j/LogManager, method: clinit signature: ()V) Incompatible argument to function Either there is yet another log4j jar somewhere (not likely since I get a NoClassDefFoundError already), or the problem is somewhere else. I will keep experimenting. If there are any other ideas or I'm missing something, please, someone let me know. -Original Message- From: Scott T. Weaver [mailto:[EMAIL PROTECTED] Sent: Thursday, October 14, 2004 10:00 AM To: Jetspeed Users List Subject: Re: Running Jetspeed 1.5 on JRun4 Hi George, Looks like a version conflict in the version of log4j included with J2 and the one JRun appears to be using. Try removing the log4j jar from the jetspeed/WEB-INF/lib directory. Stathis, George wrote: A few more details: 1) Our JRun installation came with ColdFusion MX 6.1, so a bunch of ColdFusion classes are in the classpath. 2) When starting the server that houses the Jetspeed 1.5 application, the following JetspeedLoggingService related error appears in the JRun Launcher log: Starting Apache Jetspeed Portal/1.5 (!) NOTICE: init (!) NOTICE: ServiceBroker: LoggingService enabled. (!) NOTICE: Turbine: init() failed: java.lang.VerifyError: (class: org/apache/log4j/LogManager, method: clinit signature: ()V) Incompatible argument to function at org.apache.jetspeed.services.logging.JetspeedLogFactoryService.getLogge r(Jet speedLogFactoryService.java:168) at org.apache.jetspeed.services.logging.JetspeedLoggingService.clinit(Jetspe e dLoggingService.java:59) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.apache.turbine.services.BaseInitableBroker.getInitableInstance(Base Init a bleBroker.java:257)rethrown as org.apache.turbine.services.InstantiationException: Failed to instantiate org.apache.jetspeed.services.logging.JetspeedLoggingService at org.apache.turbine.services.BaseInitableBroker.getInitableInstance(Base Init a bleBroker.java:295) at org.apache.turbine.services.BaseInitableBroker.initClass(BaseInitableBr oker . java:145) at org.apache.turbine.services.BaseServiceBroker.initService(BaseServiceBr oker . java:139) at org.apache.turbine.services.TurbineServices.initPrimaryServices(Turbine Serv i ces.java:204) at org.apache.turbine.Turbine.init(Turbine.java:247) at javax.servlet.GenericServlet.init(GenericServlet.java:258) at jrun.servlet.WebApplicationService.loadServlet(WebApplicationService.ja va:1 2 43) at jrun.servlet.WebApplicationService.preloadServlets(WebApplicationServic e.ja v a:790) at jrun.servlet.WebApplicationService.postStart(WebApplicationService.java :297 ) at
RE: Running Jetspeed 1.5 on JRun4
Hi George, This isn't a Jetspeed issue, I don't think. I'm pretty sure that WEB-INF/lib is not itself added to any webapp's classpath. Each jar inside WEB-INF/lib is, but WEB-INF/lib itself is not. Did you try putting log4j.properties in WEB-INF/classes? This directory is in the classpath. Dan PS A typical webapp classpath will look like: WEB-INF/classes:WEB-INF/lib/a.jar:WEB-INF/lib/b.jar:WEB-INF/lib/c.jar Section SRV.9.5 of the servlet 2.3 spec says The web application classloader must load classes from the WEB-INF/ classes directory first, and then from library JARs in the WEB-INF/lib directory. --- Stathis, George [EMAIL PROTECTED] wrote: Figured out the problem. It was indeed a conflict between the log4j versions, but somehow, the Jetspeed application was not picking up the log4j jar in its own WEB-INF\lib directory, but rather, the log4j classes in the JRUN_HOME\lib\oem-xdoclet.jar. The problem was rectified by taking the Jetspeed log4j jar out of the jetspeed WEB-INF\lib and putting it in JRUN_HOME\servers\lib. This is a bit unorthodox though. Shouldn't the application specific jars in WEB-INF\lib be overriding the other classpaths? Anyway, thanks to Scott for taking the time to help out! -Original Message- From: Stathis, George [mailto:[EMAIL PROTECTED] Sent: Thursday, October 14, 2004 10:47 AM To: 'Jetspeed Users List' Subject: RE: Running Jetspeed 1.5 on JRun4 Thank you for the prompt reply. I'm running J1.5 by the way. I just tried your suggestion and the problem persists in the exact same way (same messages). Looking at the classpath available to the JRun JVM, I see that there are two versions of log4j *in addition* to the one in Jetspeed itself. They both come built-in JRun. One is in: %JRUN_HOME%\servers\cfusion\cfusion-ear\cfusion-war\WEB-INF\cfusion\lib\log4 j.jar The other in: %JRUN_HOME%\lib\oem-xdoclet.jar which contains open source libraries, one of which is log4j. Both directories above are in the JVM classpath. For a test, I put back the log4j jar in jetspeed/WEB-INF/lib and *removed* the two directories above from the class path. Same error. Then, I removed the log4j jar from jetspeed/WEB-INF/lib again, and also left out the two directories above from the classpath. Different error: (!) NOTICE: Turbine: init() failed: java.lang.NoClassDefFoundError: org/apache/log4j/LogManager Ahaa! NoClassDefFoundError Now I know that log4j is completely out of the classpath. I re-tested now by putting back into the classpath each jar one by one. Results: The %JRUN_HOME%\servers\cfusion\cfusion-ear\cfusion-war\WEB-INF\cfusion\lib\log4 j.jar is not being picked up. If it's the only one in the classpath, I still get a NoClassDefFoundError error. But both the %JRUN_HOME%\lib\oem-xdoclet.jar and the Jetspeed log4j.jar cause the exact same error: (!) NOTICE: Turbine: init() failed: java.lang.VerifyError: (class: org/apache/log4j/LogManager, method: clinit signature: ()V) Incompatible argument to function Either there is yet another log4j jar somewhere (not likely since I get a NoClassDefFoundError already), or the problem is somewhere else. I will keep experimenting. If there are any other ideas or I'm missing something, please, someone let me know. -Original Message- From: Scott T. Weaver [mailto:[EMAIL PROTECTED] Sent: Thursday, October 14, 2004 10:00 AM To: Jetspeed Users List Subject: Re: Running Jetspeed 1.5 on JRun4 Hi George, Looks like a version conflict in the version of log4j included with J2 and the one JRun appears to be using. Try removing the log4j jar from the jetspeed/WEB-INF/lib directory. Stathis, George wrote: A few more details: 1) Our JRun installation came with ColdFusion MX 6.1, so a bunch of ColdFusion classes are in the classpath. 2) When starting the server that houses the Jetspeed 1.5 application, the following JetspeedLoggingService related error appears in the JRun Launcher log: Starting Apache Jetspeed Portal/1.5 (!) NOTICE: init (!) NOTICE: ServiceBroker: LoggingService enabled. (!) NOTICE: Turbine: init() failed: java.lang.VerifyError: (class: org/apache/log4j/LogManager, method: clinit signature: ()V) Incompatible argument to function at org.apache.jetspeed.services.logging.JetspeedLogFactoryService.getLogge r(Jet speedLogFactoryService.java:168) at org.apache.jetspeed.services.logging.JetspeedLoggingService.clinit(Jetspe e dLoggingService.java:59) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.apache.turbine.services.BaseInitableBroker.getInitableInstance(Base Init a bleBroker.java:257)rethrown as org.apache.turbine.services.InstantiationException: Failed to instantiate org.apache.jetspeed.services.logging.JetspeedLoggingService at
RE: Running Jetspeed 1.5 on JRun4
I'm pretty sure this is not a Jetspeed issue. I think it's JRun not prioritizing properly where each web application should be loading its' classes from (i.e. jars in WEB-INF/lib should take priority over JRun jars). Tomcat for example has 5 loaders that take care of this prioritization. Dan, you want me to try putting log4j.properties in WEB-INF/classes or did you mean the log4j jar? -Original Message- From: Dan Moore [mailto:[EMAIL PROTECTED] Sent: Friday, October 15, 2004 10:13 AM To: Jetspeed Users List Subject: RE: Running Jetspeed 1.5 on JRun4 Hi George, This isn't a Jetspeed issue, I don't think. I'm pretty sure that WEB-INF/lib is not itself added to any webapp's classpath. Each jar inside WEB-INF/lib is, but WEB-INF/lib itself is not. Did you try putting log4j.properties in WEB-INF/classes? This directory is in the classpath. Dan PS A typical webapp classpath will look like: WEB-INF/classes:WEB-INF/lib/a.jar:WEB-INF/lib/b.jar:WEB-INF/lib/c.jar Section SRV.9.5 of the servlet 2.3 spec says The web application classloader must load classes from the WEB-INF/ classes directory first, and then from library JARs in the WEB-INF/lib directory. --- Stathis, George [EMAIL PROTECTED] wrote: Figured out the problem. It was indeed a conflict between the log4j versions, but somehow, the Jetspeed application was not picking up the log4j jar in its own WEB-INF\lib directory, but rather, the log4j classes in the JRUN_HOME\lib\oem-xdoclet.jar. The problem was rectified by taking the Jetspeed log4j jar out of the jetspeed WEB-INF\lib and putting it in JRUN_HOME\servers\lib. This is a bit unorthodox though. Shouldn't the application specific jars in WEB-INF\lib be overriding the other classpaths? Anyway, thanks to Scott for taking the time to help out! -Original Message- From: Stathis, George [mailto:[EMAIL PROTECTED] Sent: Thursday, October 14, 2004 10:47 AM To: 'Jetspeed Users List' Subject: RE: Running Jetspeed 1.5 on JRun4 Thank you for the prompt reply. I'm running J1.5 by the way. I just tried your suggestion and the problem persists in the exact same way (same messages). Looking at the classpath available to the JRun JVM, I see that there are two versions of log4j *in addition* to the one in Jetspeed itself. They both come built-in JRun. One is in: %JRUN_HOME%\servers\cfusion\cfusion-ear\cfusion-war\WEB-INF\cfusion\lib\log4 j.jar The other in: %JRUN_HOME%\lib\oem-xdoclet.jar which contains open source libraries, one of which is log4j. Both directories above are in the JVM classpath. For a test, I put back the log4j jar in jetspeed/WEB-INF/lib and *removed* the two directories above from the class path. Same error. Then, I removed the log4j jar from jetspeed/WEB-INF/lib again, and also left out the two directories above from the classpath. Different error: (!) NOTICE: Turbine: init() failed: java.lang.NoClassDefFoundError: org/apache/log4j/LogManager Ahaa! NoClassDefFoundError Now I know that log4j is completely out of the classpath. I re-tested now by putting back into the classpath each jar one by one. Results: The %JRUN_HOME%\servers\cfusion\cfusion-ear\cfusion-war\WEB-INF\cfusion\lib\log4 j.jar is not being picked up. If it's the only one in the classpath, I still get a NoClassDefFoundError error. But both the %JRUN_HOME%\lib\oem-xdoclet.jar and the Jetspeed log4j.jar cause the exact same error: (!) NOTICE: Turbine: init() failed: java.lang.VerifyError: (class: org/apache/log4j/LogManager, method: clinit signature: ()V) Incompatible argument to function Either there is yet another log4j jar somewhere (not likely since I get a NoClassDefFoundError already), or the problem is somewhere else. I will keep experimenting. If there are any other ideas or I'm missing something, please, someone let me know. -Original Message- From: Scott T. Weaver [mailto:[EMAIL PROTECTED] Sent: Thursday, October 14, 2004 10:00 AM To: Jetspeed Users List Subject: Re: Running Jetspeed 1.5 on JRun4 Hi George, Looks like a version conflict in the version of log4j included with J2 and the one JRun appears to be using. Try removing the log4j jar from the jetspeed/WEB-INF/lib directory. Stathis, George wrote: A few more details: 1) Our JRun installation came with ColdFusion MX 6.1, so a bunch of ColdFusion classes are in the classpath. 2) When starting the server that houses the Jetspeed 1.5 application, the following JetspeedLoggingService related error appears in the JRun Launcher log: Starting Apache Jetspeed Portal/1.5 (!) NOTICE: init (!) NOTICE: ServiceBroker: LoggingService enabled. (!) NOTICE: Turbine: init() failed: java.lang.VerifyError: (class: org/apache/log4j/LogManager, method: clinit signature: ()V) Incompatible argument to function at
RE: Running Jetspeed 1.5 on JRun4
Hi George, I entirely misread your problem. Twice. If the wrong version of the log4j classes are being picked up, it sounds like you've found the solution. Sorry for the confusion. Dan --- Stathis, George [EMAIL PROTECTED] wrote: I'm pretty sure this is not a Jetspeed issue. I think it's JRun not prioritizing properly where each web application should be loading its' classes from (i.e. jars in WEB-INF/lib should take priority over JRun jars). Tomcat for example has 5 loaders that take care of this prioritization. Dan, you want me to try putting log4j.properties in WEB-INF/classes or did you mean the log4j jar? -Original Message- From: Dan Moore [mailto:[EMAIL PROTECTED] Sent: Friday, October 15, 2004 10:13 AM To: Jetspeed Users List Subject: RE: Running Jetspeed 1.5 on JRun4 Hi George, This isn't a Jetspeed issue, I don't think. I'm pretty sure that WEB-INF/lib is not itself added to any webapp's classpath. Each jar inside WEB-INF/lib is, but WEB-INF/lib itself is not. Did you try putting log4j.properties in WEB-INF/classes? This directory is in the classpath. Dan PS A typical webapp classpath will look like: WEB-INF/classes:WEB-INF/lib/a.jar:WEB-INF/lib/b.jar:WEB-INF/lib/c.jar Section SRV.9.5 of the servlet 2.3 spec says The web application classloader must load classes from the WEB-INF/ classes directory first, and then from library JARs in the WEB-INF/lib directory. --- Stathis, George [EMAIL PROTECTED] wrote: Figured out the problem. It was indeed a conflict between the log4j versions, but somehow, the Jetspeed application was not picking up the log4j jar in its own WEB-INF\lib directory, but rather, the log4j classes in the JRUN_HOME\lib\oem-xdoclet.jar. The problem was rectified by taking the Jetspeed log4j jar out of the jetspeed WEB-INF\lib and putting it in JRUN_HOME\servers\lib. This is a bit unorthodox though. Shouldn't the application specific jars in WEB-INF\lib be overriding the other classpaths? Anyway, thanks to Scott for taking the time to help out! -Original Message- From: Stathis, George [mailto:[EMAIL PROTECTED] Sent: Thursday, October 14, 2004 10:47 AM To: 'Jetspeed Users List' Subject: RE: Running Jetspeed 1.5 on JRun4 Thank you for the prompt reply. I'm running J1.5 by the way. I just tried your suggestion and the problem persists in the exact same way (same messages). Looking at the classpath available to the JRun JVM, I see that there are two versions of log4j *in addition* to the one in Jetspeed itself. They both come built-in JRun. One is in: %JRUN_HOME%\servers\cfusion\cfusion-ear\cfusion-war\WEB-INF\cfusion\lib\log4 j.jar The other in: %JRUN_HOME%\lib\oem-xdoclet.jar which contains open source libraries, one of which is log4j. Both directories above are in the JVM classpath. For a test, I put back the log4j jar in jetspeed/WEB-INF/lib and *removed* the two directories above from the class path. Same error. Then, I removed the log4j jar from jetspeed/WEB-INF/lib again, and also left out the two directories above from the classpath. Different error: (!) NOTICE: Turbine: init() failed: java.lang.NoClassDefFoundError: org/apache/log4j/LogManager Ahaa! NoClassDefFoundError Now I know that log4j is completely out of the classpath. I re-tested now by putting back into the classpath each jar one by one. Results: The %JRUN_HOME%\servers\cfusion\cfusion-ear\cfusion-war\WEB-INF\cfusion\lib\log4 j.jar is not being picked up. If it's the only one in the classpath, I still get a NoClassDefFoundError error. But both the %JRUN_HOME%\lib\oem-xdoclet.jar and the Jetspeed log4j.jar cause the exact same error: (!) NOTICE: Turbine: init() failed: java.lang.VerifyError: (class: org/apache/log4j/LogManager, method: clinit signature: ()V) Incompatible argument to function Either there is yet another log4j jar somewhere (not likely since I get a NoClassDefFoundError already), or the problem is somewhere else. I will keep experimenting. If there are any other ideas or I'm missing something, please, someone let me know. -Original Message- From: Scott T. Weaver [mailto:[EMAIL PROTECTED] Sent: Thursday, October 14, 2004 10:00 AM To: Jetspeed Users List Subject: Re: Running Jetspeed 1.5 on JRun4 Hi George, Looks like a version conflict in the version of log4j included with J2 and the one JRun appears to be using. Try removing the log4j jar from the jetspeed/WEB-INF/lib directory. Stathis, George wrote: A few more details: 1) Our JRun installation came with ColdFusion MX 6.1, so a bunch of ColdFusion classes are in the classpath. 2) When starting the server that houses the Jetspeed 1.5 application, the following JetspeedLoggingService
RE: Running Jetspeed 1.5 on JRun4
No problem ;-) I appreciate any effort to help. -Original Message- From: Dan Moore [mailto:[EMAIL PROTECTED] Sent: Friday, October 15, 2004 10:31 AM To: Jetspeed Users List Subject: RE: Running Jetspeed 1.5 on JRun4 Hi George, I entirely misread your problem. Twice. If the wrong version of the log4j classes are being picked up, it sounds like you've found the solution. Sorry for the confusion. Dan --- Stathis, George [EMAIL PROTECTED] wrote: I'm pretty sure this is not a Jetspeed issue. I think it's JRun not prioritizing properly where each web application should be loading its' classes from (i.e. jars in WEB-INF/lib should take priority over JRun jars). Tomcat for example has 5 loaders that take care of this prioritization. Dan, you want me to try putting log4j.properties in WEB-INF/classes or did you mean the log4j jar? -Original Message- From: Dan Moore [mailto:[EMAIL PROTECTED] Sent: Friday, October 15, 2004 10:13 AM To: Jetspeed Users List Subject: RE: Running Jetspeed 1.5 on JRun4 Hi George, This isn't a Jetspeed issue, I don't think. I'm pretty sure that WEB-INF/lib is not itself added to any webapp's classpath. Each jar inside WEB-INF/lib is, but WEB-INF/lib itself is not. Did you try putting log4j.properties in WEB-INF/classes? This directory is in the classpath. Dan PS A typical webapp classpath will look like: WEB-INF/classes:WEB-INF/lib/a.jar:WEB-INF/lib/b.jar:WEB-INF/lib/c.jar Section SRV.9.5 of the servlet 2.3 spec says The web application classloader must load classes from the WEB-INF/ classes directory first, and then from library JARs in the WEB-INF/lib directory. --- Stathis, George [EMAIL PROTECTED] wrote: Figured out the problem. It was indeed a conflict between the log4j versions, but somehow, the Jetspeed application was not picking up the log4j jar in its own WEB-INF\lib directory, but rather, the log4j classes in the JRUN_HOME\lib\oem-xdoclet.jar. The problem was rectified by taking the Jetspeed log4j jar out of the jetspeed WEB-INF\lib and putting it in JRUN_HOME\servers\lib. This is a bit unorthodox though. Shouldn't the application specific jars in WEB-INF\lib be overriding the other classpaths? Anyway, thanks to Scott for taking the time to help out! -Original Message- From: Stathis, George [mailto:[EMAIL PROTECTED] Sent: Thursday, October 14, 2004 10:47 AM To: 'Jetspeed Users List' Subject: RE: Running Jetspeed 1.5 on JRun4 Thank you for the prompt reply. I'm running J1.5 by the way. I just tried your suggestion and the problem persists in the exact same way (same messages). Looking at the classpath available to the JRun JVM, I see that there are two versions of log4j *in addition* to the one in Jetspeed itself. They both come built-in JRun. One is in: %JRUN_HOME%\servers\cfusion\cfusion-ear\cfusion-war\WEB-INF\cfusion\lib\log4 j.jar The other in: %JRUN_HOME%\lib\oem-xdoclet.jar which contains open source libraries, one of which is log4j. Both directories above are in the JVM classpath. For a test, I put back the log4j jar in jetspeed/WEB-INF/lib and *removed* the two directories above from the class path. Same error. Then, I removed the log4j jar from jetspeed/WEB-INF/lib again, and also left out the two directories above from the classpath. Different error: (!) NOTICE: Turbine: init() failed: java.lang.NoClassDefFoundError: org/apache/log4j/LogManager Ahaa! NoClassDefFoundError Now I know that log4j is completely out of the classpath. I re-tested now by putting back into the classpath each jar one by one. Results: The %JRUN_HOME%\servers\cfusion\cfusion-ear\cfusion-war\WEB-INF\cfusion\lib\log4 j.jar is not being picked up. If it's the only one in the classpath, I still get a NoClassDefFoundError error. But both the %JRUN_HOME%\lib\oem-xdoclet.jar and the Jetspeed log4j.jar cause the exact same error: (!) NOTICE: Turbine: init() failed: java.lang.VerifyError: (class: org/apache/log4j/LogManager, method: clinit signature: ()V) Incompatible argument to function Either there is yet another log4j jar somewhere (not likely since I get a NoClassDefFoundError already), or the problem is somewhere else. I will keep experimenting. If there are any other ideas or I'm missing something, please, someone let me know. -Original Message- From: Scott T. Weaver [mailto:[EMAIL PROTECTED] Sent: Thursday, October 14, 2004 10:00 AM To: Jetspeed Users List Subject: Re: Running Jetspeed 1.5 on JRun4 Hi George, Looks like a version conflict in the version of log4j included with J2 and the one JRun appears to be using. Try removing the log4j jar from the jetspeed/WEB-INF/lib directory. Stathis, George wrote: A few more details: 1) Our JRun
Re: Running Jetspeed 1.5 on JRun4
I think what is happening here is what you tend to see in the standard JBoss classloader . JRun probably loaded some of the log4j classes at startup from its log4j jar. Now Jetspeed 2 required those classes but instead of the JRun classloaders loading new ones from the WEB-INF/lib it just used the ones it already loaded from its server classloader. Next what probably happened is J2 tried to load up a couple more log4j classes that had not been loaded yet in any classloader yet. So those classes where loaded from the WEB-INF/lib jar. Finally when the app tried to mix these classes, a classcast was thrown. Even if the two jars were identical, this would have happened because for 2 classes to be considered the same they have to be loaded from the same classloader. If they were not loaded from the same classloader a CCE is thrown even if they are, in all other ways, identical. This is just a theory though, and I could be totally wrong ;) Stathis, George wrote: Figured out the problem. It was indeed a conflict between the log4j versions, but somehow, the Jetspeed application was not picking up the log4j jar in its own WEB-INF\lib directory, but rather, the log4j classes in the JRUN_HOME\lib\oem-xdoclet.jar. The problem was rectified by taking the Jetspeed log4j jar out of the jetspeed WEB-INF\lib and putting it in JRUN_HOME\servers\lib. This is a bit unorthodox though. Shouldn't the application specific jars in WEB-INF\lib be overriding the other classpaths? Anyway, thanks to Scott for taking the time to help out! -Original Message- From: Stathis, George [mailto:[EMAIL PROTECTED] Sent: Thursday, October 14, 2004 10:47 AM To: 'Jetspeed Users List' Subject: RE: Running Jetspeed 1.5 on JRun4 Thank you for the prompt reply. I'm running J1.5 by the way. I just tried your suggestion and the problem persists in the exact same way (same messages). Looking at the classpath available to the JRun JVM, I see that there are two versions of log4j *in addition* to the one in Jetspeed itself. They both come built-in JRun. One is in: %JRUN_HOME%\servers\cfusion\cfusion-ear\cfusion-war\WEB-INF\cfusion\lib\log4 j.jar The other in: %JRUN_HOME%\lib\oem-xdoclet.jar which contains open source libraries, one of which is log4j. Both directories above are in the JVM classpath. For a test, I put back the log4j jar in jetspeed/WEB-INF/lib and *removed* the two directories above from the class path. Same error. Then, I removed the log4j jar from jetspeed/WEB-INF/lib again, and also left out the two directories above from the classpath. Different error: (!) NOTICE: Turbine: init() failed: java.lang.NoClassDefFoundError: org/apache/log4j/LogManager Ahaa! NoClassDefFoundError Now I know that log4j is completely out of the classpath. I re-tested now by putting back into the classpath each jar one by one. Results: The %JRUN_HOME%\servers\cfusion\cfusion-ear\cfusion-war\WEB-INF\cfusion\lib\log4 j.jar is not being picked up. If it's the only one in the classpath, I still get a NoClassDefFoundError error. But both the %JRUN_HOME%\lib\oem-xdoclet.jar and the Jetspeed log4j.jar cause the exact same error: (!) NOTICE: Turbine: init() failed: java.lang.VerifyError: (class: org/apache/log4j/LogManager, method: clinit signature: ()V) Incompatible argument to function Either there is yet another log4j jar somewhere (not likely since I get a NoClassDefFoundError already), or the problem is somewhere else. I will keep experimenting. If there are any other ideas or I'm missing something, please, someone let me know. -Original Message- From: Scott T. Weaver [mailto:[EMAIL PROTECTED] Sent: Thursday, October 14, 2004 10:00 AM To: Jetspeed Users List Subject: Re: Running Jetspeed 1.5 on JRun4 Hi George, Looks like a version conflict in the version of log4j included with J2 and the one JRun appears to be using. Try removing the log4j jar from the jetspeed/WEB-INF/lib directory. Stathis, George wrote: A few more details: 1) Our JRun installation came with ColdFusion MX 6.1, so a bunch of ColdFusion classes are in the classpath. 2) When starting the server that houses the Jetspeed 1.5 application, the following JetspeedLoggingService related error appears in the JRun Launcher log: Starting Apache Jetspeed Portal/1.5 (!) NOTICE: init (!) NOTICE: ServiceBroker: LoggingService enabled. (!) NOTICE: Turbine: init() failed: java.lang.VerifyError: (class: org/apache/log4j/LogManager, method: clinit signature: ()V) Incompatible argument to function at org.apache.jetspeed.services.logging.JetspeedLogFactoryService.getLogge r(Jet speedLogFactoryService.java:168) at org.apache.jetspeed.services.logging.JetspeedLoggingService.clinit(Jetspe e dLoggingService.java:59) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.apache.turbine.services.BaseInitableBroker.getInitableInstance(Base Init a bleBroker.java:257)rethrown as
RE: Running Jetspeed 1.5 on JRun4
I think this is indeed very close to what happened. It sounds reasonable. The problem persisted, even when I removed from the JVM classpath the JRun lib directory that contained the JRun provided log4j classes (the only log4j jar that was left in the classpath was the one in the Jetspeed 1.5 WEB-INF/lib directory). This means that the server was loading the JRun built-in classes regardless of what I was putting in the JVM classpath. It seems that the only way to override this in JRun is to put libraries in the JRUN_HOME/servers/lib directory. The problem with this is that these jars will affect all JRun servers and not just the one you are interested in. One of the reasons why we need to use JRun in my organization is that we have old ColdFusion apps that we need to maintain. I know that the cfusion server that comes with JRun has its' own log4j jar in its' WEB-INF/lib (yes, yet another one!). Now that I've placed the Jetspeed log4j jar in the global JRUN_HOME/servers/lib directory, I'm wondering how it's going to affect the ColdFusion apps. I'll give an update when I find out. -Original Message- From: Scott T. Weaver [mailto:[EMAIL PROTECTED] Sent: Friday, October 15, 2004 11:15 AM To: Jetspeed Users List Subject: Re: Running Jetspeed 1.5 on JRun4 I think what is happening here is what you tend to see in the standard JBoss classloader . JRun probably loaded some of the log4j classes at startup from its log4j jar. Now Jetspeed 2 required those classes but instead of the JRun classloaders loading new ones from the WEB-INF/lib it just used the ones it already loaded from its server classloader. Next what probably happened is J2 tried to load up a couple more log4j classes that had not been loaded yet in any classloader yet. So those classes where loaded from the WEB-INF/lib jar. Finally when the app tried to mix these classes, a classcast was thrown. Even if the two jars were identical, this would have happened because for 2 classes to be considered the same they have to be loaded from the same classloader. If they were not loaded from the same classloader a CCE is thrown even if they are, in all other ways, identical. This is just a theory though, and I could be totally wrong ;) Stathis, George wrote: Figured out the problem. It was indeed a conflict between the log4j versions, but somehow, the Jetspeed application was not picking up the log4j jar in its own WEB-INF\lib directory, but rather, the log4j classes in the JRUN_HOME\lib\oem-xdoclet.jar. The problem was rectified by taking the Jetspeed log4j jar out of the jetspeed WEB-INF\lib and putting it in JRUN_HOME\servers\lib. This is a bit unorthodox though. Shouldn't the application specific jars in WEB-INF\lib be overriding the other classpaths? Anyway, thanks to Scott for taking the time to help out! -Original Message- From: Stathis, George [mailto:[EMAIL PROTECTED] Sent: Thursday, October 14, 2004 10:47 AM To: 'Jetspeed Users List' Subject: RE: Running Jetspeed 1.5 on JRun4 Thank you for the prompt reply. I'm running J1.5 by the way. I just tried your suggestion and the problem persists in the exact same way (same messages). Looking at the classpath available to the JRun JVM, I see that there are two versions of log4j *in addition* to the one in Jetspeed itself. They both come built-in JRun. One is in: %JRUN_HOME%\servers\cfusion\cfusion-ear\cfusion-war\WEB-INF\cfusion\lib \log4 j.jar The other in: %JRUN_HOME%\lib\oem-xdoclet.jar which contains open source libraries, one of which is log4j. Both directories above are in the JVM classpath. For a test, I put back the log4j jar in jetspeed/WEB-INF/lib and *removed* the two directories above from the class path. Same error. Then, I removed the log4j jar from jetspeed/WEB-INF/lib again, and also left out the two directories above from the classpath. Different error: (!) NOTICE: Turbine: init() failed: java.lang.NoClassDefFoundError: org/apache/log4j/LogManager Ahaa! NoClassDefFoundError Now I know that log4j is completely out of the classpath. I re-tested now by putting back into the classpath each jar one by one. Results: The %JRUN_HOME%\servers\cfusion\cfusion-ear\cfusion-war\WEB-INF\cfusion\lib \log4 j.jar is not being picked up. If it's the only one in the classpath, I still get a NoClassDefFoundError error. But both the %JRUN_HOME%\lib\oem-xdoclet.jar and the Jetspeed log4j.jar cause the exact same error: (!) NOTICE: Turbine: init() failed: java.lang.VerifyError: (class: org/apache/log4j/LogManager, method: clinit signature: ()V) Incompatible argument to function Either there is yet another log4j jar somewhere (not likely since I get a NoClassDefFoundError already), or the problem is somewhere else. I will keep experimenting. If there are any other ideas or I'm missing something, please, someone let me know. -Original Message- From: Scott T. Weaver [mailto:[EMAIL PROTECTED] Sent: Thursday, October 14, 2004
Fw: Handling errors in customize mode
Has anyone done this? Hello - We are writing a portlet in Jetspeed 1.5 for which we are providing our own customizer (provides.customization=true.) The customizer has a number of data entry fields, which the user could fill in incorrectly. We would like to validate the entered data in an action method (doUpdate() for example,) and return them to the customize screen if there is an error. Is there a way to return the user to the customize view from your doX() methods? I have tried a number of things... none of which seemed to work. This is pretty much a show-stopper for us at the moment... any help would be greatly appreciated! Thanks, Eric Olson
RE: Handling errors in customize mode
You can do this if you do not specify an action in your form form /form This way, it posts back to itself (still under buildconfigurecontext), you can handle the request. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, October 15, 2004 12:32 PM To: Jetspeed Users List Subject: Fw: Handling errors in customize mode Has anyone done this? Hello - We are writing a portlet in Jetspeed 1.5 for which we are providing our own customizer (provides.customization=true.) The customizer has a number of data entry fields, which the user could fill in incorrectly. We would like to validate the entered data in an action method (doUpdate() for example,) and return them to the customize screen if there is an error. Is there a way to return the user to the customize view from your doX() methods? I have tried a number of things... none of which seemed to work. This is pretty much a show-stopper for us at the moment... any help would be greatly appreciated! Thanks, Eric Olson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: working oracle psml in jetspeed 1.5
Hi David. It's all working now. I don't think I was changing my project.properties. Thanks for your help. For posterity, what I did to generate working oracle Torque classes and sql was: rm -rf jetspeed-1.5/ jar -xf jetspeed-current-src.zip cd jetspeed-1.5/ vi project.properties changed 'database' property to 'oracle' vi webapp/WEB-INF/conf/Torque.properties changed 'torque.database.default.adapter' to 'oracle' maven clean dist -Dmaven.test.skip=true cp target/jetspeed-1.5.jar ~/save maven torque:sql cp target/classes/sql/*.sql ~/save I think you need to run both targets, the first to generate the classes, the second to generate the sql. Thanks again for your help. Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: working oracle psml in jetspeed 1.5
Dan Moore wrote: Hi David. It's all working now. I don't think I was changing my project.properties. cool Thanks for your help. For posterity, what I did to generate working oracle Torque classes and sql was: rm -rf jetspeed-1.5/ jar -xf jetspeed-current-src.zip cd jetspeed-1.5/ vi project.properties changed 'database' property to 'oracle' vi webapp/WEB-INF/conf/Torque.properties changed 'torque.database.default.adapter' to 'oracle' maven clean dist -Dmaven.test.skip=true cp target/jetspeed-1.5.jar ~/save maven torque:sql cp target/classes/sql/*.sql ~/save calling maven clean dist -Dmaven.test.skip=true should automatically call both torque:sql and torque:om I think you need to run both targets, the first to generate the classes, the second to generate the sql. Thanks again for your help. Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] [office] +01 707 773 4646 [mobile] +01 707 529 9194 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
torque targets not called in dist (was Re: working oracle psml in jetspeed 1.5)
--- David Sean Taylor [EMAIL PROTECTED] wrote: Dan Moore wrote: Hi David. It's all working now. I don't think I was changing my project.properties. cool Thanks for your help. For posterity, what I did to generate working oracle Torque classes and sql was: rm -rf jetspeed-1.5/ jar -xf jetspeed-current-src.zip cd jetspeed-1.5/ vi project.properties changed 'database' property to 'oracle' vi webapp/WEB-INF/conf/Torque.properties changed 'torque.database.default.adapter' to 'oracle' maven clean dist -Dmaven.test.skip=true cp target/jetspeed-1.5.jar ~/save maven torque:sql cp target/classes/sql/*.sql ~/save calling maven clean dist -Dmaven.test.skip=true should automatically call both torque:sql and torque:om Hrrm... Well, when I called that, nothing was created in target/classes/sql. In fact, after a 'maven clean dist -Dmaven.test.skip=true' these are the only sql files with psml in their name: ./src/sql/external/psml-db-oracle.sql ./target/jetspeed-1.5/src/jetspeed-1.5/src/sql/external/psml-db-oracle.sql And neither of these have the correct sql in them. Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: torque targets not called in dist (was Re: working oracle psml in jetspeed 1.5)
Dan Moore wrote: --- David Sean Taylor [EMAIL PROTECTED] wrote: Dan Moore wrote: Hi David. It's all working now. I don't think I was changing my project.properties. cool Thanks for your help. For posterity, what I did to generate working oracle Torque classes and sql was: rm -rf jetspeed-1.5/ jar -xf jetspeed-current-src.zip cd jetspeed-1.5/ vi project.properties changed 'database' property to 'oracle' vi webapp/WEB-INF/conf/Torque.properties changed 'torque.database.default.adapter' to 'oracle' maven clean dist -Dmaven.test.skip=true cp target/jetspeed-1.5.jar ~/save maven torque:sql cp target/classes/sql/*.sql ~/save calling maven clean dist -Dmaven.test.skip=true should automatically call both torque:sql and torque:om Hrrm... Well, when I called that, nothing was created in target/classes/sql. In fact, after a 'maven clean dist -Dmaven.test.skip=true' these are the only sql files with psml in their name: ./src/sql/external/psml-db-oracle.sql ./target/jetspeed-1.5/src/jetspeed-1.5/src/sql/external/psml-db-oracle.sql My mistake ... java:compile is not dependent on torque:sql Try this: maven clean torque:sql dist -Dmaven.test.skip=true - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
