cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From stev...@outerthought.org
Subject [WIKI-UPDATE] Th As400 WebServiceProxyGenerator Mon May 17 21:00:06 2004
Date Mon, 17 May 2004 19:00:07 GMT
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
- 



Mime
View raw message