as400 iseries Java ajar tool
The ajar tool is an alternative interface to the jar tool that you use to create and manipulate Java(TM) ARchive (JAR) files. You can use the ajar tool to manipulate both JAR files and ZIP files on the as400.
If you need a ZIP interface or UNZIP interface on the iseries, use the ajar tool instead of the jar tool.
The ajar tool lists the contents of JAR files, extracts from JAR files, creates new JAR files, and supports many of the ZIP formats just as the jar tool does. Additionally, the ajar tool supports adding and deleting files in existing JAR files.
The ajar tool is available using the iseries Qshell Interpreter. For more details, see ajar - Alternative as400 Java archive.
Showing posts with label java. Show all posts
Showing posts with label java. Show all posts
Monday, September 21, 2009
Need to access MS SQL databases from the as400. Use Microsofts JDBC driver
Overview of the JDBC Driver
The Microsoft SQL Server JDBC Driver is a Java Database Connectivity (JDBC) 4.0 compliant driver that provides robust data access to Microsoft SQL Server 2000, SQL Server 2005, and SQL Server 2008 databases. The JDBC driver can access many of the new features of SQL Server 2005, including database mirroring; the xml, user-defined, and large-value data types; and it supports the new "snapshot" transaction isolation. In addition, the JDBC driver also supports the use of integrated authentication with SQL Server 2000, SQL Server 2005, and SQL Server 2008. Note that the Microsoft SQL Server JDBC Driver version 2.0 can connect to SQL Server 2008 but does not support the new data types or other features that are new in SQL Server 2008.
Using the JDBC Driver
This section provides quick start instructions for making a simple connection to a SQL Server database by using the Microsoft SQL Server JDBC Driver. Before you connect to a SQL Server database, SQL Server must first be installed on either your local computer or a server, and the JDBC driver must be installed on your local computer.
Choosing the Right JAR file
The Microsoft SQL Server JDBC Driver version 2.0 provides sqljdbc.jar and sqljdbc4.jar class library files to be used depending on your preferred Java Runtime Environment (JRE) settings. For more information about which JAR file to choose, see System Requirements for the JDBC Driver.
Setting the Classpath
The JDBC driver is not part of the Java SDK. If you want to use it, you must set the classpath to include the sqljdbc.jar file or the sqljdbc4.jar file. If the classpath is missing an entry for sqljdbc.jar or sqljdbc4.jar, your application will throw the common "Class not found" exception.
The sqljdbc.jar file and sqljdbc4.jar file are installed in the following location:
\sqljdbc_\\sqljdbc.jar
\sqljdbc_\\sqljdbc4.jar
The following is an example of the CLASSPATH statement that is used for a Windows application:
CLASSPATH =.;C:\Program Files\Microsoft SQL Server JDBC Driver\sqljdbc_2.0\enu\sqljdbc.jar
The following is an example of the CLASSPATH statement that is used for a Unix/Linux application:
CLASSPATH =.:/home/usr1/mssqlserverjdbc/Driver/sqljdbc_2.0/enu/sqljdbc.jar
You must make sure that the CLASSPATH statement contains only one Microsoft SQL Server JDBC driver, such as either sqljdbc.jar or sqljdbc4.jar.
Note:
On Windows systems, directory names longer than 8.3 or folder names with spaces may cause problems with classpaths. If you suspect these types of issues, you should temporarily move the sqljdbc.jar file or the sqljdbc4.jar file into a simple directory name such as C:\Temp, change the classpath, and determine whether that addresses the problem.
Applications that are run directly at the command prompt
The classpath is configured in the operating system. Append sqljdbc.jar or sqljdbc4.jar to the classpath of the system. Alternatively, you can specify the classpath on the Java command line that runs the application by using the java -classpath option.
Applications that run in an IDE
Each IDE vendor provides a different method for setting the classpath in its IDE. Just setting the classpath in the operating system will not work. You must add sqljdbc.jar or sqljdbc4.jar to the IDE classpath.
Servlets and JSPs
Servlets and JSPs are run in a servlet/JSP engine such as Tomcat. The classpath must be set according to the servlet/JSP engine documentation. Just setting the classpath in the operating system will not work. Some servlet/JSP engines provide setup screens that you can use to set the classpath of the engine. In that situation, you must append the correct JDBC Driver JAR file to the existing engine classpath and restart the engine. In other situations, you can deploy the driver by copying sqljdbc.jar or sqljdbc4.jar to a specific directory, such as lib, during engine installation. The engine driver classpath can also be specified in an engine specific configuration file.
Enterprise Java Beans
Enterprise Java Beans (EJB) are run in an EJB container. EJB containers are sourced from various vendors. Java applets run in a browser but are downloaded from a Web server. Copy sqljdbc.jar or sqljdbc4.jar to the Web server root and specify the name of the JAR file in the HTML archive tab of the applet, for example, applet ... archive=sqljdbc.jar>.
Making a Simple Connection to a Database
Using the sqljdbc.jar class library, applications must first register the driver as follows:
Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver");
When the driver is loaded, you can establish a connection by using a connection URL and the getConnection method of the DriverManager class:
String connectionUrl = "jdbc:sqlserver://localhost:1433;" +
"databaseName=AdventureWorks;user=MyUserName;password=*****;";
Connection con = DriverManager.getConnection(connectionUrl);
In the JDBC API 4.0, the DriverManager.getConnection method is enhanced to load JDBC drivers automatically. Therefore, applications do not need to call the Class.forName method to register or load the driver when using the sqljdbc4.jar class library.
When the getConnection method of the DriverManager class is called, an appropriate driver is located from the set of registered JDBC drivers. sqljdbc4.jar file includes "META-INF/services/java.sql.Driver" file, which contains the com.microsoft.sqlserver.jdbc.SQLServerDriver as a registered driver. The existing applications, which currently load the drivers by using the Class.forName method, will continue to work without modification.
Note:
sqljdbc4.jar class library requires a Java Runtime Environment (JRE) of version 6.0 or later.
The Microsoft SQL Server JDBC Driver is a Java Database Connectivity (JDBC) 4.0 compliant driver that provides robust data access to Microsoft SQL Server 2000, SQL Server 2005, and SQL Server 2008 databases. The JDBC driver can access many of the new features of SQL Server 2005, including database mirroring; the xml, user-defined, and large-value data types; and it supports the new "snapshot" transaction isolation. In addition, the JDBC driver also supports the use of integrated authentication with SQL Server 2000, SQL Server 2005, and SQL Server 2008. Note that the Microsoft SQL Server JDBC Driver version 2.0 can connect to SQL Server 2008 but does not support the new data types or other features that are new in SQL Server 2008.
Using the JDBC Driver
This section provides quick start instructions for making a simple connection to a SQL Server database by using the Microsoft SQL Server JDBC Driver. Before you connect to a SQL Server database, SQL Server must first be installed on either your local computer or a server, and the JDBC driver must be installed on your local computer.
Choosing the Right JAR file
The Microsoft SQL Server JDBC Driver version 2.0 provides sqljdbc.jar and sqljdbc4.jar class library files to be used depending on your preferred Java Runtime Environment (JRE) settings. For more information about which JAR file to choose, see System Requirements for the JDBC Driver.
Setting the Classpath
The JDBC driver is not part of the Java SDK. If you want to use it, you must set the classpath to include the sqljdbc.jar file or the sqljdbc4.jar file. If the classpath is missing an entry for sqljdbc.jar or sqljdbc4.jar, your application will throw the common "Class not found" exception.
The sqljdbc.jar file and sqljdbc4.jar file are installed in the following location:
The following is an example of the CLASSPATH statement that is used for a Windows application:
CLASSPATH =.;C:\Program Files\Microsoft SQL Server JDBC Driver\sqljdbc_2.0\enu\sqljdbc.jar
The following is an example of the CLASSPATH statement that is used for a Unix/Linux application:
CLASSPATH =.:/home/usr1/mssqlserverjdbc/Driver/sqljdbc_2.0/enu/sqljdbc.jar
You must make sure that the CLASSPATH statement contains only one Microsoft SQL Server JDBC driver, such as either sqljdbc.jar or sqljdbc4.jar.
Note:
On Windows systems, directory names longer than 8.3 or folder names with spaces may cause problems with classpaths. If you suspect these types of issues, you should temporarily move the sqljdbc.jar file or the sqljdbc4.jar file into a simple directory name such as C:\Temp, change the classpath, and determine whether that addresses the problem.
Applications that are run directly at the command prompt
The classpath is configured in the operating system. Append sqljdbc.jar or sqljdbc4.jar to the classpath of the system. Alternatively, you can specify the classpath on the Java command line that runs the application by using the java -classpath option.
Applications that run in an IDE
Each IDE vendor provides a different method for setting the classpath in its IDE. Just setting the classpath in the operating system will not work. You must add sqljdbc.jar or sqljdbc4.jar to the IDE classpath.
Servlets and JSPs
Servlets and JSPs are run in a servlet/JSP engine such as Tomcat. The classpath must be set according to the servlet/JSP engine documentation. Just setting the classpath in the operating system will not work. Some servlet/JSP engines provide setup screens that you can use to set the classpath of the engine. In that situation, you must append the correct JDBC Driver JAR file to the existing engine classpath and restart the engine. In other situations, you can deploy the driver by copying sqljdbc.jar or sqljdbc4.jar to a specific directory, such as lib, during engine installation. The engine driver classpath can also be specified in an engine specific configuration file.
Enterprise Java Beans
Enterprise Java Beans (EJB) are run in an EJB container. EJB containers are sourced from various vendors. Java applets run in a browser but are downloaded from a Web server. Copy sqljdbc.jar or sqljdbc4.jar to the Web server root and specify the name of the JAR file in the HTML archive tab of the applet, for example, applet ... archive=sqljdbc.jar>.
Making a Simple Connection to a Database
Using the sqljdbc.jar class library, applications must first register the driver as follows:
Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver");
When the driver is loaded, you can establish a connection by using a connection URL and the getConnection method of the DriverManager class:
String connectionUrl = "jdbc:sqlserver://localhost:1433;" +
"databaseName=AdventureWorks;user=MyUserName;password=*****;";
Connection con = DriverManager.getConnection(connectionUrl);
In the JDBC API 4.0, the DriverManager.getConnection method is enhanced to load JDBC drivers automatically. Therefore, applications do not need to call the Class.forName method to register or load the driver when using the sqljdbc4.jar class library.
When the getConnection method of the DriverManager class is called, an appropriate driver is located from the set of registered JDBC drivers. sqljdbc4.jar file includes "META-INF/services/java.sql.Driver" file, which contains the com.microsoft.sqlserver.jdbc.SQLServerDriver as a registered driver. The existing applications, which currently load the drivers by using the Class.forName method, will continue to work without modification.
Note:
sqljdbc4.jar class library requires a Java Runtime Environment (JRE) of version 6.0 or later.
Friday, July 24, 2009
Calling an RPG program from Groovy
DON DENONCOURT shows how to call RPG from Groovy, via an sql stored procedure call
http://denoncourt.blogspot.com/2009/07/calling-rpg-program-from-groovy.html
I've been integrating Java applications with AS400/iSeries/Systemi RPG programs for over ten years. I've covered it in my book (Java Application Strategies for the iSeries) as well as in many of my articles. Calling RPG from Java can be complex. There are 4 or so options but I've been fairly emphatic about using JDBC callable statements as it is the simplest approach. To do that you need to create a stored produce "wrapper" for the RPG. But the Java code still can be quite verbose. Not so with Groov
http://denoncourt.blogspot.com/2009/07/calling-rpg-program-from-groovy.html
Friday, May 22, 2009
AS400 JTOpen 6.5.1 Available
Fixes and enhancements in as400 JTOpen 6.5.1 (released 2009-05-20)
- Data area: Fixed breakage in JTOpen 6.5: NoClassDefFoundError on Sun JVM's.
- Print: Fixed breakage in JTOpen 6.5: NoClassDefFoundError on Sun JVM's.
- User space: Fixed breakage in JTOpen 6.5: NoClassDefFoundError on Sun JVM's.
What is IBMs Toolbox for Java
The IBM Toolbox for Java is a set of Java classes that allow you to
access IBM i, i5/OS, or OS/400 data through a Java program. With these classes,
you can write client/server applications, applets, and servlets that work
with data on your IBM i, i5/OS, or OS/400 system. You can also run Java
applications that use the IBM Toolbox for Java on the IBM i, i5/OS, or
OS/400 Java Virtual Machine.
The Toolbox is available as an installable licensed program for the AS/400
as of OS/400 V4R2 and the iSeries as of OS/400 V5R1. Here is a breakdown of
Toolbox releases versus operating system versions:
Toolbox Installs on Connects to
release LPP release OS/400 version OS/400 version
------- -------------- -------------- --------------
V4R2 5763JC1 V3R2M0 V3R2 and up V3R2 and up
V4R3 5763JC1 V3R2M1 V3R2 and up V3R2 and up
V4R4 5769JC1 V4R2M0 V4R2 and up V4R2 and up
V4R5 5769JC1 V4R5M0 V4R3 and up V4R2 and up
V5R1 5722JC1 V5R1M0 V4R4 and up V4R3 and up
V5R2 5722JC1 V5R2M0 V4R5 and up V4R5 and up
V5R3(*) 5722JC1 V5R3M0 V5R1 and up V5R1 and up
V5R4(**) 5722JC1 V5R4M0 V5R2 and up V5R2 and up
JTOpen 1.x Not applicable Not applicable V4R3 and up
JTOpen 2.x Not applicable Not applicable V4R4 and up
JTOpen 3.x Not applicable Not applicable V4R5 and up
JTOpen 4.0-4.2 Not applicable Not applicable V4R5 and up
JTOpen 4.3-4.7 5722JC1 V5R3M0 V5R1 and up V5R1 and up
JTOpen 4.8+ 5722JC1 V5R4M0 V5R2 and up V5R2 and up
JTOpen 6.1+ 5761JC1 V6R1M0 V5R3 and up V5R3 and up
(*) Note: Toolbox release V5R3 is equivalent to JTOpen 4.3.
(**) Note: Toolbox release V5R4 is equivalent to JTOpen 4.8.
Newer versions of the Toolbox are backwards-compatible with earlier
versions. Upgrading to a newer version is usually recommended, with the one
main exception being that the Toolbox is only supported for connection
to servers running either of the two prior releases of i5/OS or OS/400.
Why Open Source?
We have chosen to make the Toolbox code open source for the following reasons:
1. To obtain new functions and features from the Toolbox user community.
2. To respond with customer and business partners requirements as rapidly
as possible.
3. To improve the ability for our customers to build and debug their own
applications when using the Toolbox functions.
4. To continue the drive to keep the IBM i platform a leader with Java technology
for application development.
Differences between JTOpen and the Toolbox LPP
1. The initial release of the source code for JTOpen used the V4R5
Toolbox codebase. That is, the Java code in the open source repository
is the same code that was used to build the V4R5 Toolbox LPP. JTOpen 2.0x
uses the V5R1 Toolbox as its codebase. The latest release of JTOpen
(JTOpen 6.x) uses the V6R1 Toolbox as its codebase.
2. When bugs are reported, fixes will be committed to JTOpen as soon as
they are realized. When applicable, these same fixes will be committed
to the Toolbox LPP and made available in a future PTF or service pack.
3. Any new functionality that is committed to JTOpen will be subsequently
added, when applicable, into the Toolbox LPP and made available in a
future PTF or service pack.
Note: All changes to JTOpen are made under the control and at the
discretion of the JTOpen Core Team. All changes to the Toolbox LPP
are made under the control and at the discretion of IBM.
4. In general, the Toolbox LPP is supported directly by IBM. JTOpen
is supported by the JTOpen user community, in which IBM participates
and contributes, specifically through developer email, the JTOpen
mailing list, and the JTOpen web forum
5. Pursuant to the IBM Public License, programmers are free to alter the
JTOpen source code and to distribute it with their own applications.
Download and installation of JTOpen
Requirements
Briefly, the requirements for using the JTOpen code are as follows:
1. A Java Virtual Machine (JVM) with a 1.2.x or higher JDK/JRE. The JTOpen
team highly recommends moving to the latest supported release of the JDK/JRE, as
maintaining backwards-compatible code with older releases becomes
increasingly difficult to support over time.
2. Almost all JTOpen functions require a TCP/IP connection to an IBM i server.
a. The server must be IBM i, i5/OS, or OS/400 V4R3 or higher.
b. The server must have the Option 12 Host Servers installed and
running. JTOpen uses the host servers as TCP/IP endpoints to
communicate with the server from a client.
c. If the Java application using JTOpen is being run directly on a server
running IBM i, i5/OS, or OS/400, then certain JTOpen functions might use
native API and/or local socket calls to improve performance.
This will only occur under certain conditions, and only if the file
jt400Native.jar is included in the application's CLASSPATH.
3. For GUI programming, either Java 2 or Swing 1.1 or higher is required.
Files
JTOpen is comprised of the following files:
Jar file Contents
-------- --------
jtopen_x_x_source.zip This is a zip file of all the source files in the repository.
It is not a Java jar file.
jtopen_x_x_javadoc.zip This is a zip file of the javadoc (in HTML format) for
the JTOpen source files. It is not a Java jar file.
jt400.jar(*) This is the main JTOpen jar file. It contains almost all open
source code (except for the few Toolbox classes that could
not be open-sourced), including the utilities package,
and the JDBC driver (JDBC 3.0).
jt400Micro.jar(*) This contains the ToolboxME (Micro Edition) classes for
use on a handheld device.
jt400Native.jar(*) Previously known as jt400Access.zip, this jar does not
contain the vaccess package. It does contain the native
optimization classes necessary for running performance-enhanced
applications on IBM i, i5/OS, or OS/400 JVM.
jt400Proxy.jar(*) This jar contains just the classes needed to run a client
application using the Toolbox proxy server. It is
especially useful in environments where a smaller jar
is needed.
jt400Servlet.jar(*) This jar contains the html and servlet packages.
jui400.jar(*) Contains the PDML runtime packages as provided by
the Graphical Toolbox.
uitools.jar(*) Contains the GUI Builder packages as provided by the
Graphical Toolbox.
util400.jar(*) Contains various utilities.
composer.jar(*) Contains XSL stylesheet composer classes.
reportwriter.jar(*) Contains XSL report processor classes.
outputwriters.jar(*) Contains PDF, PCL, and font classes.
tes.jar(*) Contains the IBM i Graphical Debugger.
jtopen_x_x_jdbc40.zip This zip file contains versions of jt400.jar and
jt400Native.jar (along with source code) that are
compatible for use with JDBC 4.0. This zip file requires
that you be running on Java 6.0 or higher.
(*) Files contained in file jtopen_x_x.zip.
There are other jar files shipped in the download for JTOpen off of the Toolbox
downloads page. Those jar files do not (yet) contain JTOpen code. They are
provided as a convenience to the developer and to mirror the objects that ship
with the Toolbox LPP.
Building and Using JTOpen
Instructions for using JTOpen:
1. Download the JTOpen jt400.jar.
2. Add it to your CLASSPATH.
3. Run your application.
Instructions for building all or part of the as400 JTOpen source code:
Note: Complete build instructions are specified in the commentary in file
/build/build.xml
1. Download the JTOpen jt400.jar.
2. Download any source files you want to change. The src.zip file includes
all of the source in the repository for convenience.
3. Set up your CLASSPATH to include everything in the correct order:
a. Your source files should be in your CLASSPATH first. Note that you
cannot point to src.zip - you must unzip it, since it contains only
source files.
b. Next, add jt400.jar.
c. Your CLASSPATH should look something like this:
CLASSPATH=C:\jt400\MyApp;C:\jt400\jt400.jar;...
4. Compile your source.
5. Run your as400 application that uses JTOpen.
- Data area: Fixed breakage in JTOpen 6.5: NoClassDefFoundError on Sun JVM's.
- Print: Fixed breakage in JTOpen 6.5: NoClassDefFoundError on Sun JVM's.
- User space: Fixed breakage in JTOpen 6.5: NoClassDefFoundError on Sun JVM's.
What is IBMs Toolbox for Java
The IBM Toolbox for Java is a set of Java classes that allow you to
access IBM i, i5/OS, or OS/400 data through a Java program. With these classes,
you can write client/server applications, applets, and servlets that work
with data on your IBM i, i5/OS, or OS/400 system. You can also run Java
applications that use the IBM Toolbox for Java on the IBM i, i5/OS, or
OS/400 Java Virtual Machine.
The Toolbox is available as an installable licensed program for the AS/400
as of OS/400 V4R2 and the iSeries as of OS/400 V5R1. Here is a breakdown of
Toolbox releases versus operating system versions:
Toolbox Installs on Connects to
release LPP release OS/400 version OS/400 version
------- -------------- -------------- --------------
V4R2 5763JC1 V3R2M0 V3R2 and up V3R2 and up
V4R3 5763JC1 V3R2M1 V3R2 and up V3R2 and up
V4R4 5769JC1 V4R2M0 V4R2 and up V4R2 and up
V4R5 5769JC1 V4R5M0 V4R3 and up V4R2 and up
V5R1 5722JC1 V5R1M0 V4R4 and up V4R3 and up
V5R2 5722JC1 V5R2M0 V4R5 and up V4R5 and up
V5R3(*) 5722JC1 V5R3M0 V5R1 and up V5R1 and up
V5R4(**) 5722JC1 V5R4M0 V5R2 and up V5R2 and up
JTOpen 1.x Not applicable Not applicable V4R3 and up
JTOpen 2.x Not applicable Not applicable V4R4 and up
JTOpen 3.x Not applicable Not applicable V4R5 and up
JTOpen 4.0-4.2 Not applicable Not applicable V4R5 and up
JTOpen 4.3-4.7 5722JC1 V5R3M0 V5R1 and up V5R1 and up
JTOpen 4.8+ 5722JC1 V5R4M0 V5R2 and up V5R2 and up
JTOpen 6.1+ 5761JC1 V6R1M0 V5R3 and up V5R3 and up
(*) Note: Toolbox release V5R3 is equivalent to JTOpen 4.3.
(**) Note: Toolbox release V5R4 is equivalent to JTOpen 4.8.
Newer versions of the Toolbox are backwards-compatible with earlier
versions. Upgrading to a newer version is usually recommended, with the one
main exception being that the Toolbox is only supported for connection
to servers running either of the two prior releases of i5/OS or OS/400.
Why Open Source?
We have chosen to make the Toolbox code open source for the following reasons:
1. To obtain new functions and features from the Toolbox user community.
2. To respond with customer and business partners requirements as rapidly
as possible.
3. To improve the ability for our customers to build and debug their own
applications when using the Toolbox functions.
4. To continue the drive to keep the IBM i platform a leader with Java technology
for application development.
Differences between JTOpen and the Toolbox LPP
1. The initial release of the source code for JTOpen used the V4R5
Toolbox codebase. That is, the Java code in the open source repository
is the same code that was used to build the V4R5 Toolbox LPP. JTOpen 2.0x
uses the V5R1 Toolbox as its codebase. The latest release of JTOpen
(JTOpen 6.x) uses the V6R1 Toolbox as its codebase.
2. When bugs are reported, fixes will be committed to JTOpen as soon as
they are realized. When applicable, these same fixes will be committed
to the Toolbox LPP and made available in a future PTF or service pack.
3. Any new functionality that is committed to JTOpen will be subsequently
added, when applicable, into the Toolbox LPP and made available in a
future PTF or service pack.
Note: All changes to JTOpen are made under the control and at the
discretion of the JTOpen Core Team. All changes to the Toolbox LPP
are made under the control and at the discretion of IBM.
4. In general, the Toolbox LPP is supported directly by IBM. JTOpen
is supported by the JTOpen user community, in which IBM participates
and contributes, specifically through developer email, the JTOpen
mailing list, and the JTOpen web forum
5. Pursuant to the IBM Public License, programmers are free to alter the
JTOpen source code and to distribute it with their own applications.
Download and installation of JTOpen
Requirements
Briefly, the requirements for using the JTOpen code are as follows:
1. A Java Virtual Machine (JVM) with a 1.2.x or higher JDK/JRE. The JTOpen
team highly recommends moving to the latest supported release of the JDK/JRE, as
maintaining backwards-compatible code with older releases becomes
increasingly difficult to support over time.
2. Almost all JTOpen functions require a TCP/IP connection to an IBM i server.
a. The server must be IBM i, i5/OS, or OS/400 V4R3 or higher.
b. The server must have the Option 12 Host Servers installed and
running. JTOpen uses the host servers as TCP/IP endpoints to
communicate with the server from a client.
c. If the Java application using JTOpen is being run directly on a server
running IBM i, i5/OS, or OS/400, then certain JTOpen functions might use
native API and/or local socket calls to improve performance.
This will only occur under certain conditions, and only if the file
jt400Native.jar is included in the application's CLASSPATH.
3. For GUI programming, either Java 2 or Swing 1.1 or higher is required.
Files
JTOpen is comprised of the following files:
Jar file Contents
-------- --------
jtopen_x_x_source.zip This is a zip file of all the source files in the repository.
It is not a Java jar file.
jtopen_x_x_javadoc.zip This is a zip file of the javadoc (in HTML format) for
the JTOpen source files. It is not a Java jar file.
jt400.jar(*) This is the main JTOpen jar file. It contains almost all open
source code (except for the few Toolbox classes that could
not be open-sourced), including the utilities package,
and the JDBC driver (JDBC 3.0).
jt400Micro.jar(*) This contains the ToolboxME (Micro Edition) classes for
use on a handheld device.
jt400Native.jar(*) Previously known as jt400Access.zip, this jar does not
contain the vaccess package. It does contain the native
optimization classes necessary for running performance-enhanced
applications on IBM i, i5/OS, or OS/400 JVM.
jt400Proxy.jar(*) This jar contains just the classes needed to run a client
application using the Toolbox proxy server. It is
especially useful in environments where a smaller jar
is needed.
jt400Servlet.jar(*) This jar contains the html and servlet packages.
jui400.jar(*) Contains the PDML runtime packages as provided by
the Graphical Toolbox.
uitools.jar(*) Contains the GUI Builder packages as provided by the
Graphical Toolbox.
util400.jar(*) Contains various utilities.
composer.jar(*) Contains XSL stylesheet composer classes.
reportwriter.jar(*) Contains XSL report processor classes.
outputwriters.jar(*) Contains PDF, PCL, and font classes.
tes.jar(*) Contains the IBM i Graphical Debugger.
jtopen_x_x_jdbc40.zip This zip file contains versions of jt400.jar and
jt400Native.jar (along with source code) that are
compatible for use with JDBC 4.0. This zip file requires
that you be running on Java 6.0 or higher.
(*) Files contained in file jtopen_x_x.zip.
There are other jar files shipped in the download for JTOpen off of the Toolbox
downloads page. Those jar files do not (yet) contain JTOpen code. They are
provided as a convenience to the developer and to mirror the objects that ship
with the Toolbox LPP.
Building and Using JTOpen
Instructions for using JTOpen:
1. Download the JTOpen jt400.jar.
2. Add it to your CLASSPATH.
3. Run your application.
Instructions for building all or part of the as400 JTOpen source code:
Note: Complete build instructions are specified in the commentary in file
/build/build.xml
1. Download the JTOpen jt400.jar.
2. Download any source files you want to change. The src.zip file includes
all of the source in the repository for convenience.
3. Set up your CLASSPATH to include everything in the correct order:
a. Your source files should be in your CLASSPATH first. Note that you
cannot point to src.zip - you must unzip it, since it contains only
source files.
b. Next, add jt400.jar.
c. Your CLASSPATH should look something like this:
CLASSPATH=C:\jt400\MyApp;C:\jt400\jt400.jar;...
4. Compile your source.
5. Run your as400 application that uses JTOpen.
Friday, February 13, 2009
Redpiece - IBM Express Runtime Web Environments for i5/OS
IBM Express Runtime Web Environments for i5/OS (5733-SO1) provides an integrated
package of software products that you install and configure to your i5/OS® using a wizard.
The product does the following:
Installs V5R4 iSeries® Access for Web (including PTFs), 5722-XH2
Installs WebSphere Application Server - Express. Two versions of Express Runtime Web
Environments for i5/OS V5R4 are available:
– V1R1M0 contains WebSphere® Application Server-Express V6.0 (order Web
Enablement's feature 5905 for CDs and 5906 for a DVD)
– V1R2M0 contains the newer WebSphere Application Server-Express V6.1 (order
feature 5907 for CDs and 5908 for a DVD)
If its not installed, installs V5R4 IBM HTTP Server (5722-DG1), including PTFs
Configures a WebSphere Application Server profile and an HTTP server instance,
generates the WebSphere Application Server plug-in, and starts both servers
Configures iSeries Access for Web
Installs and configures an icon on the Windows® workstation desktop that links to a First Steps static HTML Web page. The First Steps Web page is designed to provide an easy way for you to get started using what the wizard deployed to your i5/OS.
The product includes several sample Web applications. Each Web application modernizes
the flght400 application, a well-known sample RPG application. The flght400 application is installed as part of IBM Express Runtime Web Environments for i5/OS.
The included sample Web applications are as follows:
Host Access Transformation Services (HATS)
A sample application that demonstrates the presentation of an RPG program named
flght400, which was modernized using HATS.
WebFacing
A sample application that demonstrates the presentation of flght400, which was
modernized using the IBM WebFacing tool.
Web Services
This sample application queries flght400 by accessing it using a Web Service.
After the environment is successfully deployed, an icon is placed on your Windows
workstation desktop from which you can access the Web environment.
Web Enablement Environment
The IBM Express Runtime Web Environments for i5/OS product (5733-SO1) have one
option, Web Enablement Environment, V5R4M0.
The Web Enablement Environment significantly reduces the time that is necessary to set up a
Web environment on i5/OS. It installs all of the necessary middleware, fix packs, and program temporary fixes (PTFs). It also automatically configures the Web environment for immediate use of the following types of applications:
J2EE™ applications
Web services applications
WebFacing applications
Host Access Transformation (HATS) applications
WebFacing Deployment Tool with HATS Technology (WDHT) applications
V5R4 iSeries Access for Web applications
package of software products that you install and configure to your i5/OS® using a wizard.
The product does the following:
Installs V5R4 iSeries® Access for Web (including PTFs), 5722-XH2
Installs WebSphere Application Server - Express. Two versions of Express Runtime Web
Environments for i5/OS V5R4 are available:
– V1R1M0 contains WebSphere® Application Server-Express V6.0 (order Web
Enablement's feature 5905 for CDs and 5906 for a DVD)
– V1R2M0 contains the newer WebSphere Application Server-Express V6.1 (order
feature 5907 for CDs and 5908 for a DVD)
If its not installed, installs V5R4 IBM HTTP Server (5722-DG1), including PTFs
Configures a WebSphere Application Server profile and an HTTP server instance,
generates the WebSphere Application Server plug-in, and starts both servers
Configures iSeries Access for Web
Installs and configures an icon on the Windows® workstation desktop that links to a First Steps static HTML Web page. The First Steps Web page is designed to provide an easy way for you to get started using what the wizard deployed to your i5/OS.
The product includes several sample Web applications. Each Web application modernizes
the flght400 application, a well-known sample RPG application. The flght400 application is installed as part of IBM Express Runtime Web Environments for i5/OS.
The included sample Web applications are as follows:
Host Access Transformation Services (HATS)
A sample application that demonstrates the presentation of an RPG program named
flght400, which was modernized using HATS.
WebFacing
A sample application that demonstrates the presentation of flght400, which was
modernized using the IBM WebFacing tool.
Web Services
This sample application queries flght400 by accessing it using a Web Service.
After the environment is successfully deployed, an icon is placed on your Windows
workstation desktop from which you can access the Web environment.
Web Enablement Environment
The IBM Express Runtime Web Environments for i5/OS product (5733-SO1) have one
option, Web Enablement Environment, V5R4M0.
The Web Enablement Environment significantly reduces the time that is necessary to set up a
Web environment on i5/OS. It installs all of the necessary middleware, fix packs, and program temporary fixes (PTFs). It also automatically configures the Web environment for immediate use of the following types of applications:
J2EE™ applications
Web services applications
WebFacing applications
Host Access Transformation (HATS) applications
WebFacing Deployment Tool with HATS Technology (WDHT) applications
V5R4 iSeries Access for Web applications
Tuesday, January 18, 2005
WebLogic Platform 8.1 with SP4 Free Download
WebLogic Platform 8.1 with SP4
BEA WebLogic Platform 8.1 is an integrated platform for building service-oriented Web applications, Web services, EJBs, workflows, messaging applications, enterprise portals, and more. BEA WebLogic Platform includes: WebLogic Server, WebLogic Integration, WebLogic Portal, WebLogic JRockit, and WebLogic Workshop.
The download provides you with a free, non-expiring developer license for BEA WebLogic Workshop 8.1 and WebLogic Platform 8.1. The download automatically installs the development license key. Also included is a scale-limited non-commercial deployment license.
BEA WebLogic Platform 8.1 is an integrated platform for building service-oriented Web applications, Web services, EJBs, workflows, messaging applications, enterprise portals, and more. BEA WebLogic Platform includes: WebLogic Server, WebLogic Integration, WebLogic Portal, WebLogic JRockit, and WebLogic Workshop.
The download provides you with a free, non-expiring developer license for BEA WebLogic Workshop 8.1 and WebLogic Platform 8.1. The download automatically installs the development license key. Also included is a scale-limited non-commercial deployment license.
An Introduction to Jython
Jython is a version of Python written in Java and designed to run under the JVM. Because of this, it integrates closely with Java, and allows Jython programs access to all of the Java libraries. There are several reasons that Java programmers might be interested in learning Jython:
It provides an alternative to Javascript for interacting with Java, and is in many ways more powerful than Javascript. Most would also agree it is much easier to use than Javascript.
It is very easy to embed the Jython interpretor as a scripting or application control language in your Java applications.
It allows more rapid prototyping, and/or "proof of concept" applications than is possible in Java.
Michael Urban
It provides an alternative to Javascript for interacting with Java, and is in many ways more powerful than Javascript. Most would also agree it is much easier to use than Javascript.
It is very easy to embed the Jython interpretor as a scripting or application control language in your Java applications.
It allows more rapid prototyping, and/or "proof of concept" applications than is possible in Java.
Michael Urban
TestNG: Catch the Testing Fever
Writing unit tests has always been the weak point in my portfolio. Each time I go to start them, I get frustrated with setting them up, then trying to get JUnit working just right. Then one day, as I was preparing the JavaPolis presentations, I noticed a presentation by Cedric Beust about a new testing framework, TestNG. As it turned out, I was also starting a new pet project and decided that since I was testing Java 5 and some other new technologies, I might as well try to catch “unit testing fever.”
Matthew Schmidt
Matthew Schmidt
Monday, January 17, 2005
Developing a J2EE application to use JMS
This topic gives an overview of the steps needed to develop a J2EE application (servlet or enterprise bean) to use the JMS API directly for asynchronous messaging
http://jroller.com/page/charlie.li/20050117#jms_example
http://jroller.com/page/charlie.li/20050117#jms_example
Lucene search engine implementation
This case study discusses how TheServerSide built an infrastructure that allows indexing, and searching different content using Lucene.
This will chat about:
High level infrastructure
Building the Index
Allowing various index sources
Tweaking the weighting of various search results
Searching the Index
Configuration
Employing XML configuration files to allow easy tweaking
Web Tier: we want to search via the web don’t we?
as400 apis
More info on Lucene search engine implementation to follow...
This will chat about:
High level infrastructure
Building the Index
Allowing various index sources
Tweaking the weighting of various search results
Searching the Index
Configuration
Employing XML configuration files to allow easy tweaking
Web Tier: we want to search via the web don’t we?
as400 apis
More info on Lucene search engine implementation to follow...
Friday, January 14, 2005
[Tip] - Using Map to quickly populate JSP checkboxes. (jasonbell.blog-city.com)
Using Map to quickly populate JSP checkboxes
http://jasonbell.blog-city.com/read/1000991.htm
http://jasonbell.blog-city.com/read/1000991.htm
Thursday, January 13, 2005
HOWTO : Run an ANT file programmatically
http://orangevolt.com/wordpress/archives/2005/01/13/howto-run-an-ant-file-programmatically/
To run an ANT file programatically there are 2 options - either use the Eclipse AntRunner class or launch Ant by creating a Launch Configuration."
To run an ANT file programatically there are 2 options - either use the Eclipse AntRunner class or launch Ant by creating a Launch Configuration."
The Final Word On the final Keyword
Renaud Waldura's The Final Word On the final Keyword: "The Final Word On the final Keyword
Some features of the Java language simply cannot be ignored. Consider for example interfaces, used extensively by every Java specification; or try/catch blocks, that form the basis for exception handling. Other features are more obscure � useful, but ignored by the masses. Without looking as far as volatile (probably the most obscure Java keyword), think about final. When was the last time you used final in your code?
Me, I'm a final fan. Enamored with final, I'm of the school of thought that inserts final any where, any time. Or almost. But why? In this article I shine the spotlight on the Java keyword final, and invite you to discover its subtle meanings, and the many Java idioms that make use of it. All for better code! "
Some features of the Java language simply cannot be ignored. Consider for example interfaces, used extensively by every Java specification; or try/catch blocks, that form the basis for exception handling. Other features are more obscure � useful, but ignored by the masses. Without looking as far as volatile (probably the most obscure Java keyword), think about final. When was the last time you used final in your code?
Me, I'm a final fan. Enamored with final, I'm of the school of thought that inserts final any where, any time. Or almost. But why? In this article I shine the spotlight on the Java keyword final, and invite you to discover its subtle meanings, and the many Java idioms that make use of it. All for better code! "
Updating an EAR application into WAS Websphere Application Server from as400 WSAD / WDSC / WSSD using WAS admin client
Updating an EAR application into WAS Websphere Application Server from as400 WSAD / WDSC / WSSD using WAS admin client
Look for more on as400 WSAD / WDSC / WSSD
- Navigate to WAS Admin client via your browser and login
- Click Applications
- Click Enterprise Applications
- Tick the relevant application, and click stop (Before you do this take a look at the server name in the left from to make sure you looking at the right server instance, ie development rather than production! Also make sure you stop the right application!)
- When the status changes to stopped (Hover pointer to see various status's), tick the application and click update button
- Click browse to find the file (either from local path or server), and click next. At this point the EAR file will be uploaded to the server
- On the binding page I usually accept the defaults, so click next if your not sure
- On 'Provide options to perform the installation ', unless you need to change any of the settings, click next
- On 'Map virtual hosts for web modules ', select the virtual host that your application is installed under. If you on the as400 / iseries and you cant remember the virtual host at this point, login to the HTTP Server admin client, and look at the properties for the WAS application from there and it will tell you the virtual host it is installed under. The other option is to find the WAS HTTP plugin file, as this info is stored in there.
- Click next
- Unless you need to change these, on 'Map modules to application servers ' , click next
- Click Finish
- At this point, the application is installed to a temporary area. To finish the process, you need to click 'Save to Master Configuration'
- Click save to update the master repository (Or discard to abandon your changes)
- Click Enterprise Applications,select your application, and click start to restart your application
- Your Done!
Look for more on as400 WSAD / WDSC / WSSD
Listing objects in an as400 library from java/jt400
Listing objects in an as400 library from java/jt400
ObjectList libs = new ObjectList( sys, "QSYS",
ObjectList.ALL, "*LIB" );
libs.load( );
or
use the IFSFile object to list directories (including qsys.lib)
And there you have the java code you can run on your as400
ObjectList libs = new ObjectList( sys, "QSYS",
ObjectList.ALL, "*LIB" );
libs.load( );
or
use the IFSFile object to list directories (including qsys.lib)
private IFSFile[] getNewFiles(IFSFile monitoredDir, String newExt)
throws IOException
{
IFSFile[] list = monitoredDir.listFiles("*.*");
if (list != null && list.length > 0)
return list;
return null;
}
And there you have the java code you can run on your as400
Tuesday, January 11, 2005
Using Windows Explorer Copy (in Java)
http://jroller.com/page/ethdsy/20050111#using_windows_explorer_copy
David Shay's Weblog on Java
: "Using Windows Explorer Copy (in Java)
I just got this requirement that the Copy/Paste mechanism we use to copy files around between folders in our application should behave like the Windows Explorer when we paste a file in the same directory it was copied from. That is to say that our customer would like to see the file automatically renamed with the usual 'Copy of ' prefix. In order to use the Explorer features, you have to use the JNI / SHFileOperation couple. It seems that this SHFileOperation function is used by the Explorer for copying, renaming, moving and deleting files (See the send to recycle bin for another example). Here is the JNI method I use for copying: "
David Shay's Weblog on Java
: "Using Windows Explorer Copy (in Java)
I just got this requirement that the Copy/Paste mechanism we use to copy files around between folders in our application should behave like the Windows Explorer when we paste a file in the same directory it was copied from. That is to say that our customer would like to see the file automatically renamed with the usual 'Copy of ' prefix. In order to use the Explorer features, you have to use the JNI / SHFileOperation couple. It seems that this SHFileOperation function is used by the Explorer for copying, renaming, moving and deleting files (See the send to recycle bin for another example). Here is the JNI method I use for copying: "
Monday, January 10, 2005
Problem on checkout / re-synchronise an eclipse/WDSC/WSAD EAR project with a CVS repository
I couldn’t checkout / re-synchronise an eclipse/WDSC/WSAD EAR project with a CVS repository.
Every time I tried to I would get an I/O error on one of the jar files.
Very strange as another guy in my team had no problems with the same project
ButI played with the CVS options in preferences and seems to have got round the problem.
I changed the compression level (Window,Preferences,Team,CVS) from 0, and strangely that cured the problem?
The still didn’t give me the synchronisation options, so I deleted the projects from my workspace and tried again and that appears to have cured it? Weird huh?
Every time I tried to I would get an I/O error on one of the jar files.
Very strange as another guy in my team had no problems with the same project
ButI played with the CVS options in preferences and seems to have got round the problem.
I changed the compression level (Window,Preferences,Team,CVS) from 0, and strangely that cured the problem?
The still didn’t give me the synchronisation options, so I deleted the projects from my workspace and tried again and that appears to have cured it? Weird huh?
Creating advanced input forms
Creating advanced input forms
Creating complex validation on input forms no longer needs to be difficult, and no longer requires detailed knowledge of Java or the internals of JSF. With the release of Rational Application Developer V6, you can quickly and easily create forms involving complex validation using drag and drop.
Websphere Web module or application server dies or hangs
From IBM Infocenter:
Web module or application server dies or hangs
If an application server dies (its process spontaneously closes), or freezes (its Web modules stop responding to new requests):
Isolate the problem by installing Web modules on different servers, if possible. Read the Monitoring performance with Tivoli performance viewer (formerly resource analyzer) topic. You can use the performance viewer to determine which resources have reached their maximum capacity, such as Java heap memory (indicating a possible memory leak) and database connections. If a particular resource appears to have reached its maximum capacity, review the application code for a possible cause: If database connections are used and never freed, ensure that application code performs a close() on any opened Connection object within a finally{} block. If there is a steady increase in servlet engine threads in use, review application synchronized code blocks for possible deadlock conditions. If there is a steady increase in a JVM heap size, review application code for memory leak opportunities, such as static (class-level) collections, that can cause objects to never get garbage-collected. As an alternative to using the performance viewer to detect memory leak problems, enable verbose garbage collection on the application server. This feature adds detailed statements to the JVM error log file of the application server about the amount of available and in-use memory. To set up verbose garbage collection: Select Servers > Application Servers > server_name > Process Definition > Java Virtual Machine, and enable Verbose Garbage Collection. Stop and restart the application server.
Periodically, or after the application server stops, browse the log file for garbage collection statements. Look for statements beginning with "allocation failure". The string indicates that a need for memory allocation has triggered a JVM garbage collection (freeing of unused memory). Allocation failures themselves are normal and not necessarily indicative of a problem. The allocation failure statement is followed by statements showing how many bytes are needed and how many are allocated.
If there is a steady increase in the total amount of free and used memory (the JVM keeps allocating more memory for itself), or if the JVM becomes unable to allocate as much memory as it needs (indicated by the bytes needed statement), there might be a memory leak.
If neither the performance viewer or verbose garbage collection output indicates that the application server is running out of memory, one of the following problems might be present: There is a memory leak in application code that you must address. To pinpoint the cause of a memory leak, enable the RunHProf function in the Servers > Application Servers > server_name > Process Definition > Java Virtual Machine pane of the problem application server: In the same JVM pane, set the HProf Arguments field to a value similar to depth=20,file=heapdmp.txt. This value shows exception stacks to a maximum of 20 levels, and saves the heapdump output to the install_root/bin/heapdmp.txt file. Save the settings.
Stop and restart the application server.
Re-enact the scenario or access the resource that causes the hang or crash, if possible. Stop the application server. If this is not possible, wait until the hang or crash happens again and stop the application server. Examine the file into which the heapdump was saved. For example, examine the install_root/bin/heapdmp.txt file: Search for the string, "SITES BEGIN". This finds the location of a list of Java objects in memory, which shows the amount of memory allocated to the objects. The list of Java objects occurs each time there was a memory allocation in the JVM. There is a record of what type of object the memory instantiated and an identifier of a trace stack, listed elsewhere in the dump, that shows the Java method that made the allocation. The list of Java object is in descending order by number of bytes allocated. Depending on the nature of the leak, the problem class should show up near the top of the list, but this is not always the case. Look throughout the list for large amounts of memory or frequent instances of the same class being instantiated. In the latter case, use the ID in the trace stack column to identify allocations occurring repeatedly in the same class and method. Examine the source code indicated in the related trace stacks for the possibility of memory leaks. The default maximum heap size of the application server needs to be increased.
There is a defect in the WebSphere Application Server product that you must either report, or correct by installing a fix or FixPak, from a maintenance download. Contact IBM support. If an application server spontaneously dies, look for a Java thread dump file. The JVM creates the file in the product directory structure, with a name like javacore[number].txt. Force an application to create a thread dump (or javacore). Here is the process for forcing a thread dump, which is different from the process in earlier releases of the product: Using the wsadmin command prompt, get a handle to the problem application server: wsadmin>set jvm [$AdminControl completeObjectName type=JVM,process=server1,*] Generate the thread dump: wsadmin>$AdminControl invoke $jvm dumpThreads.
Look for an output file in the installation root directory with a name like javacore.date.time.id.txt. Browse the thread dump for clues: If the JVM creates the thread dump as it closes (the thread dump is not manually forced), there might be "error" or "exception information" strings at the beginning of the file. These strings indicate the thread that caused the application server to die. The thread dump contains a snapshot of each thread in the process, starting in the section labeled "Full thread dump." Look for threads with a description that contains "state:R". Such threads are active and running when the dump is forced, or the process exited. Look for multiple threads in the same Java application code source location. Multiple threads from the same location might indicate a deadlock condition (multiple threads waiting on a monitor) or an infinite loop, and help identify the application code with the problem.
If these steps do not fix your problem, search to see if the problem is known and documented, using the methods identified in the available online support (hints and tips, technotes, and fixes) topic. If you find that your problem is not known, contact IBM support to report it.
Web module or application server dies or hangs
If an application server dies (its process spontaneously closes), or freezes (its Web modules stop responding to new requests):
Isolate the problem by installing Web modules on different servers, if possible. Read the Monitoring performance with Tivoli performance viewer (formerly resource analyzer) topic. You can use the performance viewer to determine which resources have reached their maximum capacity, such as Java heap memory (indicating a possible memory leak) and database connections. If a particular resource appears to have reached its maximum capacity, review the application code for a possible cause: If database connections are used and never freed, ensure that application code performs a close() on any opened Connection object within a finally{} block. If there is a steady increase in servlet engine threads in use, review application synchronized code blocks for possible deadlock conditions. If there is a steady increase in a JVM heap size, review application code for memory leak opportunities, such as static (class-level) collections, that can cause objects to never get garbage-collected. As an alternative to using the performance viewer to detect memory leak problems, enable verbose garbage collection on the application server. This feature adds detailed statements to the JVM error log file of the application server about the amount of available and in-use memory. To set up verbose garbage collection: Select Servers > Application Servers > server_name > Process Definition > Java Virtual Machine, and enable Verbose Garbage Collection. Stop and restart the application server.
Periodically, or after the application server stops, browse the log file for garbage collection statements. Look for statements beginning with "allocation failure". The string indicates that a need for memory allocation has triggered a JVM garbage collection (freeing of unused memory). Allocation failures themselves are normal and not necessarily indicative of a problem. The allocation failure statement is followed by statements showing how many bytes are needed and how many are allocated.
If there is a steady increase in the total amount of free and used memory (the JVM keeps allocating more memory for itself), or if the JVM becomes unable to allocate as much memory as it needs (indicated by the bytes needed statement), there might be a memory leak.
If neither the performance viewer or verbose garbage collection output indicates that the application server is running out of memory, one of the following problems might be present: There is a memory leak in application code that you must address. To pinpoint the cause of a memory leak, enable the RunHProf function in the Servers > Application Servers > server_name > Process Definition > Java Virtual Machine pane of the problem application server: In the same JVM pane, set the HProf Arguments field to a value similar to depth=20,file=heapdmp.txt. This value shows exception stacks to a maximum of 20 levels, and saves the heapdump output to the install_root/bin/heapdmp.txt file. Save the settings.
Stop and restart the application server.
Re-enact the scenario or access the resource that causes the hang or crash, if possible. Stop the application server. If this is not possible, wait until the hang or crash happens again and stop the application server. Examine the file into which the heapdump was saved. For example, examine the install_root/bin/heapdmp.txt file: Search for the string, "SITES BEGIN". This finds the location of a list of Java objects in memory, which shows the amount of memory allocated to the objects. The list of Java objects occurs each time there was a memory allocation in the JVM. There is a record of what type of object the memory instantiated and an identifier of a trace stack, listed elsewhere in the dump, that shows the Java method that made the allocation. The list of Java object is in descending order by number of bytes allocated. Depending on the nature of the leak, the problem class should show up near the top of the list, but this is not always the case. Look throughout the list for large amounts of memory or frequent instances of the same class being instantiated. In the latter case, use the ID in the trace stack column to identify allocations occurring repeatedly in the same class and method. Examine the source code indicated in the related trace stacks for the possibility of memory leaks. The default maximum heap size of the application server needs to be increased.
There is a defect in the WebSphere Application Server product that you must either report, or correct by installing a fix or FixPak, from a maintenance download. Contact IBM support. If an application server spontaneously dies, look for a Java thread dump file. The JVM creates the file in the product directory structure, with a name like javacore[number].txt. Force an application to create a thread dump (or javacore). Here is the process for forcing a thread dump, which is different from the process in earlier releases of the product: Using the wsadmin command prompt, get a handle to the problem application server: wsadmin>set jvm [$AdminControl completeObjectName type=JVM,process=server1,*] Generate the thread dump: wsadmin>$AdminControl invoke $jvm dumpThreads.
Look for an output file in the installation root directory with a name like javacore.date.time.id.txt. Browse the thread dump for clues: If the JVM creates the thread dump as it closes (the thread dump is not manually forced), there might be "error" or "exception information" strings at the beginning of the file. These strings indicate the thread that caused the application server to die. The thread dump contains a snapshot of each thread in the process, starting in the section labeled "Full thread dump." Look for threads with a description that contains "state:R". Such threads are active and running when the dump is forced, or the process exited. Look for multiple threads in the same Java application code source location. Multiple threads from the same location might indicate a deadlock condition (multiple threads waiting on a monitor) or an infinite loop, and help identify the application code with the problem.
If these steps do not fix your problem, search to see if the problem is known and documented, using the methods identified in the available online support (hints and tips, technotes, and fixes) topic. If you find that your problem is not known, contact IBM support to report it.
Sunday, January 09, 2005
Tamer Salama's Weblog
Tamer Salama's Weblog: "Opensource CMS
I've been looking around for a a Java based opensourced CMS. The journey is quite fascinating. Many projects with many features, design and architecture.
I've been to Magnolia, InfoGlue, Daisy, and more. Still not set on which one I'm going to use.
Magnolia seems like a good choice, one advantage is their use of the upcoming API for java content repository JSR-170 (Content Repository for JavaTM technology API).
A good place to stop was CMS Matrix for a comparison of features. It doesn't reflect the most recent features, but at least it's quite good in listing them out."
I've been looking around for a a Java based opensourced CMS. The journey is quite fascinating. Many projects with many features, design and architecture.
I've been to Magnolia, InfoGlue, Daisy, and more. Still not set on which one I'm going to use.
Magnolia seems like a good choice, one advantage is their use of the upcoming API for java content repository JSR-170 (Content Repository for JavaTM technology API).
A good place to stop was CMS Matrix for a comparison of features. It doesn't reflect the most recent features, but at least it's quite good in listing them out."
Subscribe to:
Posts (Atom)
Subscribe To as400 blog
Posts
All Comments