You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@cocoon.apache.org by st...@outerthought.org on 2004/05/17 21:00:07 UTC
[WIKI-UPDATE] Th As400 WebServiceProxyGenerator Mon May 17 21:00:06 2004
Page: http://wiki.cocoondev.org/Wiki.jsp?page=Th , version: 1 on Sun May 17 18:50:51 2004 by Th
New page created:
+ Hello,
+
+ my name ist Thomas Hartwig. I'm looking for a good CMS with a wide possibility to extend it to my needs. I think Lenya/Cocoon has the best future for this.
+ The perfect solution would be a mix with Struts, see here: [http-link-tostruts.sourceforge.net/struts-cocoon/]\\
+ Unfortunately I had no time yet to look into it.
+ \\
+ \\
+ Read more about what I'm doing: [http-link-towww.itth.de]
+
Page: http://wiki.cocoondev.org/Wiki.jsp?page=As400 , version: 23 on Sun May 17 18:39:27 2004 by 80.58.32.107
- *Connection to As 400\\
- *JDK version issues\\
- *Making Cocoon 2.0.4 run in Websphere 3.5.X on an AS/400\\
- !!!Connection to As 400
? -
+ !!!Connection to As 400
- ''mainly but not only by [Gabridome]''\\
- *NOTE: You may also find the jt400.jar file on your AS/400. Look in /QIBM/ProdData/HTTP/Public/jt400. The jar you find there will most likely be an older version than the one available from the web site. There are also the DB2 Native drivers that are typically used for local AS/400 connections (i.e. it connected to itself) but they can work. They are located in /QIBM/ProdData/Java400/ext along with some other jars that you may find useful\\
? ^^
+ *NOTE: You may also find the jt400.jar file on your AS/400. Look in /QIBM/ProdData/HTTP/Public/jt400. The jar you find there will most likely be an older version than the one available from the web site. There are also the DB2 Native drivers that are typically used for local AS/400 connections (i.e. it connected to itself) but they can work. They are located in /QIBM/ProdData/Java400/ext along with some other jars that you may find useful -- [Dan Feather] (didn't properly identify myself at first)
? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- ([DanFeather])
+ !!Comments from the readers
+ ----
+ !!A JDK issue
- !! SQLTransformer Issues
- ''by [LucaMarchetti]''\\
- It appears to exists some problems with SQLTransformer show-nr-of-rows parameter and as400 jtopen jdbc driver. With this paramenter turned on the number of rows returned by the query is always 0 (but data rows still works well). Once I've hacked the sql transformer to get the correct result.
- The new jtopen driver resolved this problem. Now jtopen seems to always return a correct numder of rows.
-
- !!!JDK version issues
- ''by [Lorenzo]''\\
- If you are using JDK 1.3 look at [this page|As400JDK13]
+ !If you need all Cocoon SQL functionality
+ If you need all Cocoon SQL functionality (XSP and SQLTransformer) you probably need to switch to JDK 1.4, which means:
+ * downloading and installing a JDK 1.4.0 or later from [Sun|http-link-to-java.sun.com/j2se/downloads.html] (current successful configurations use version 1.4.1);
+ * have Tomcat use the upgraded JDK (by changing its {{$JAVA_HOME}});
+ * have __all__ applications hosted in your Tomcat instance use a 1.4-targeted version of Cocoon.\\Currently, version 2.0.3 has a ready-made, 1.4-targeted binary distribution in the download directory.\\If your applications are Cocoon 2.0.3-based, the following should be enough:
+ ## Locate {{cocoon-2.0.3-vm14-bin.tar.gz}} or {{cocoon-2.0.3-vm14-bin.zip}} in [Cocoon's distribution directory|http-link-to-xml.apache.org/cocoon/dist/] and download the one which suits yout platform.
+ ## unpack the file in a directory of your choice;
+ ## unpack the {{cocoon.war}} which has been extracted: it expands to a full webapp directory structure;
+ ## locate the {{WEB-INF/lib}} directory: it contains the same {{JAR}}s as your 2.0.3 application's {{WEB-INF/lib}} directory, but retargeted at the JDK 1.4;
+ ## after making a backup copy :), overwrite your application's Cocoon JARs with these new 1.4 ones;
+ ## Restart Tomcat or simply reload your application(s) via the Tomcat Manager.
+ * If your applications are based on another Cocoon version, you need to manually rebuild Cocoon from the source, targetting at the JDK 1.4, and then start from previous point 4.
+ !If you don't need/use SQLTransformer and are happy with ESQL
+ Then maybe you could stick with JDK 1.3 without changing other applications, and retain your current Tomcat setup except for minor changes.
- !!!Making Cocoon 2.0.4 run in Websphere 3.5.X on an AS/400
- ''by [DanFeather]''\\
- # Deploy the cocoon.war file using the "Console\Tasks\Convert a War File" menu option from the Admin Console.
- # Add all the jar files in the "servlets" directory to the classpath of the appliction server you are deploying it in. You can do this a number of ways. You can do it by clicking the button labeled "Environment..." and adding a "CLASSPATH" environment variable with the value being a colon (:) delimited list of the full path to each of the jar files (''This gets to be pretty long. You might want to use a text editor you can cut and paste out of to type up the classpath first. You can edit the classpath once it is set in the console, you will have to delete it and re-add it if you mess up.'') You can also add every jar to the newly created cocoon webapp's classpath. This is the spot where you can run into the most problems. If you have old versions of Xerces, Xalan, and/or any of the other api's in the /QIBM/UserData/Java400/ext directory, they may break cocoon. Any jar files in /QIBM/UserData/Java400/ext are automatically prepended to the classpath of the application server!
. Thus, if you try to add a different version of Xerces to the classpath via the admin console, it will not work if you have another Xerces jar in the above directory, since will get prepended to the classpath and be used first. Remember, if you update any of the jar files in /QIBM/UserData/Java400/ext the effect will be system wide... meaining ANY java programs may be affected, whether they are running in Websphere or QSH. The classpath on the AS/400 can be a strange beast.
- # Go into the web subdirectory under the cocoon webapp directory (i.e. /QIBM/UserData/WebASAdv/default/hosts/default_host/cocoon/web) and copy the __ENTIRE__ WEB-INF subdirectory over to the servlets subdirectory under the cocoon directory (i.e./ QIBM/UserData/WebASAdv/default/hosts/default_host/cocoon/servlets). This is what makes it all work...WAS 3.5 does not deploy WARs properly and it looks for this information in the wrong place. ''You may also be able to just add the web subdirectory to the classpath of the webapp. I have not tried that yet to see if it works. It would be worth a shot though.''\\
- ([DanFeather])
- ''A special thanks to Bob Hitchins for helping me out with this''
- !!Comments from the readers
+ The trick is to not use Cocoon's built-in connection pooling facility (provided by Avalon), but rather use your servlet container's one. Currently, this has been tested on Tomcat, which uses connection pooling services provided by Apache Commons DBCP.
+
+ You need to:
+ # Let the {{com.ibm.as400.access.AS400JDBCDriver}} be accessible by Tomcat at its startup by copying {{jt400.jar}} to {{$TOMCAT_HOME/common/lib}};
+ # Add to Tomcat's {{server.xml}} configuration file (located in {{$TOMCAT_HOME/conf}}) the desired JDBC connection as a JNDI resource: {{{
+ <Resource name="jdbc/as400" auth="Container" type="javax.sql.DataSource"/>
+ <ResourceParams name="jdbc/as400">
+ <parameter>
+ <name>username</name>
+ <value><$YOUR_USERNAME></value>
+ </parameter>
+ <parameter>
+ <name>password</name>
+ <value><$YOUR_PASSWORD></value>
+ </parameter>
+ <parameter>
+ <name>driverClassName</name>
+ <value>com.ibm.as400.access.AS400JDBCDriver</value>
+ </parameter>
+ <parameter>
+ <name>url</name>
+ <value>jdbc:as400://<$YOUR_HOST>/<$YOUR_COLLECTION></value>
+ </parameter>
+ </ResourceParams>
+ }}}
+ ##Please note that you can append a {{;trace=true}} option to the JDBC URL, as well as any other options documented in JTOpen documentation. The trace option obviously kills performance, but allows you to debug connection problems by writing a quite detailed log to {{System.out}}, which in Tomcat default configuration gets logged to {{$TOMCAT_HOME/logs/catalina.out}}.
+ ##Please also note that the snippet above must be inserted inside the relevant {{<Context/>}} element for your application. If you didn't define one (just dropped something into the webapps directory), putting it in the <GlobalNamingResources> could work (?).
+ # Add to your application's {{cocoon.xconf}} file a reference to the J2EE connection you have just defined:{{{<datasources>
+ ...
+ <j2ee name="$CONNECTION_NAME">
+ <dbname>as400</dbname>
+ </j2ee>
+ ...
+ </datasources>}}}
+ Please note that $CONNECTION_NAME is the name you want to use in your Cocoon application.\\The {{<dbname/>}} string is, instead, the name you chose in {{server.xml}}'s resource definition.
+
+ Note that {{server.xml}}'s resource name is {{jdbc/as400}}, where {{<dbname/>}} only contains {{as400}}. This is because database connections are usually looked up inside the {{jdbc/}} hierarchy.
+
+ This latter JNDI configuration is obviously only a "desperation-workaround", since it has shown problems with SQLTransformer.\\Switching to JDK 1.4 should be seen as the best option, since it seems to allow all Cocoon SQL functionality to be used on databases stored on our AS/400 boxes.
+
+
+ !A final note
+ Please note that all the above has been tested on Tomcat 4.1.12.
+
+ ([Lorenzo])
+
+ ''Thank you Lorenzo. I'll correct my part specifying the versions of jdk and Tomcat I have used. If you want we could divide this page in two: one page for jdk 1.4 and one for the case you described'' -- [Gabridome]
Page: http://wiki.cocoondev.org/Wiki.jsp?page=WebServiceProxyGenerator , version: 13 on Sun May 17 18:30:40 2004 by JoergHeinicke
- Assuming that the remote server returns well-formed XML, the WSPG will take it, and send it to the next component in the pipeline. It's pretty simple. ok:)
? -----
+ Assuming that the remote server returns well-formed XML, the WSPG will take it, and send it to the next component in the pipeline. It's pretty simple.
- oki
-