Jim Hicks

I am also working on upgrading from 4.0 to 5.1. The apps we have converted so far have converted with little problem. The new JSP compiler rejects tags that do not have proper ends. In the previous version you could leave some end tags off. I had one app in which the programer had been lazy and not done this.

We setup our http server to use the version 5 plugin so we can map apps to either the version 5.1 app server or the 4.0 app server. This allows us to migrate the apps as we have time.

A classloader loads the jars so, the files in a jar are accessed from the classloader. Use the method classloader.getResourceAsStream(String), or URL classloader.getResource(String).

To make sure you are using the same classloader as the one that loaded the jar, you should get the classloader from a object who's class is in the jar.

Classloader classloader = someObject.getClass().getClassloader();

If you want to access the jar with jar apis, you can get a url then use jar api's.

The PRPOFIND method is used in WEBDAV. I would say you are trying to call a webdav method in an environment that does not support it.

If you look at the web.xml property standards, you will see that there are parameters for setting security, like who can access a webapp. In a J2EE server, you can control access to EJBs and EJB methods. These parameters only work, if there is a JASS security system loaded.

JASS is an interface, where the actual user and role information comes from depends upon the implementation of JASS.

The problem with storing the data in a file may be your file system setup. If your computer file system is setup to only store 8 bit chars, then saving 16 bit chars in a file will result in unreadable data. Java chars are 16 bit but by default, they are converted to your computer's file systems char set which is usually 8 bit for western systems. In version 4 of Java, they made handling of charsets easier.

I would recommend you goto:

http://java.sun.com/developer/technicalArticles/Intl/index.html

Also when you write the html out, you need to make sure you set the html charset to something like "UTF-8". Setting it to ISO-8859-1 will limit you to 8 bits.

Its kind of hard to help when you don't list the exception. However, the driver I use in WDSC 5.1 is:

com.ibm.as400.access.AS400JDBCConnectionPoolDataSource

System properties apply to the JVM. When the JVM executes multiple apps may be executing in it. Any app in the JVM can change a system property that is not restricted. In general, I don't recommend setting system properties unless it is for a property value that is for all the apps in the JVM.

However, to answer the question, access to the System object is controller by the SecurityManager. When you start the JVM, a security manager can be loaded. This security manager will be notified of any attempt to change a system property. However, if you are on a j2ee web server, you may not be able to load your own security manager as most J2ee environments supply a security manager that you cant override. These seucrity managers usually have a way to restrict system property changes. You can restrict the changes and see who get a the SecurityException.

You can't change a classloaders classpath. The only time you can set a classpath is when you create an instance of a classloader. In your application, you can create instances of URLClassloader and supply it with your classpath list.

There is a an Apache utility that does this, called AvalonRepository. You can download it from www.apache.org. The avalon project is not documented very well, and it has a lot of sub projects. The people I know who use avalon, didn't learn how to use avalon from the docs at the avalon site. Rather they tend to learn by doing. Thats how I learned how to use it. I had to work on a project that had a Turbine servlet in it. The Turbine servlet uses avalon.

Avalon is much larger than the repository. This is just one small item, but it is broken out into its own jars and sub project.

To use it, you place your common jar files into a directory that functions as the repository. You then create these property files that end with .meta and place them into the repository. You create an instance of the InitialContext class that requires a path to the repository.
You use the context to request "Artifacts" from the repository. The name of the artifact corresponds to a .meta file. It reads the .meta file, creates the classloader and loads the jars listed in the .meta file.

There are code examples that you should be able to follow. However there is one very important item not documented. When you download the repository jars, do not place all of them into the application's class path. Only put the avalon-repository-main in the application's classpath. The other jars go into the repository. The main jar is a boot jar. It loads the others from the repository.

If anyone is interested in using the avalon repository and has any questions just post them.
[ June 24, 2004: Message edited by: Jim Hicks ]

Peter

Every AS/400 has a big jar file in its java lib called JT400. Copy that jar to your tomcat and all of the AS400 toolbox classes will be available to you. For information on the classes in the toolbox, goto the as400 information center at:

http://publib.boulder.ibm.com/infocenter/iseries/v5r3/ic2924/index.htm

From the main menu select:

programming,
java,
IBM Toolbox for Java,
classes,
access classes,
data queue

Yes Stan it does make sense. Basicly the code:

Class.forName("string").newInstance()

is asking the class named "Class" to load a class.

The class named Class is loaded by the system classloader. So when you ask Class to load a class it ask the system classloader to load the class. If you do that, then only the classpath settings for the system classloader and its parents will be searched.

When you are in an EJB you are several classloasders below the system. There is at least one for the container and usually more. In order to locate a class set in the container's classpath or lower, you must use something other than the system classloader.

Every classloader has a classpath. Every classloader, except the primordial classloader has a parent. When a classloader is asked to load a class, it always ask its parent classloader to load it. Only if the parent can not find the class will it load the class.

The load order of the parent always going first, prevents an application from trying to change the function of a class with the same name, like java.security.AccessController. If an application's class loader went first, it could override the security.

The JVM has an extension class loader that loads classes from the ext lib when the jvm starts. Jars placed in the extension lib will always be there. They will be like java.lang always in the jvm.

In a JVM, you may have multiple apps executing at the same time. Each app will be loaded by its own class loader because each app needs it own class path.

If you placed mycode-1.0.jar in the ext lib all apps would use mycode-1.0.jar because it was loaded by a parent classloader. Placing mycode-2.0.jar into your application's classpath would not change this. So all applications in a jvm must use the same version of any jars placed in the extension lib.

In our shop, each app has its own area that contains its own jars but these application jars usually only deal with presentation. We place the business rules in a common repository. Business rules are reused in many applications. Example: a parts order can come in from 5 different ways at our company. Via web pages, ftp, web servcies etc. You do not want to write a version of parts order proessing for each application. The application only knows that it needs to execute a particular business rule.

The business rule has dependencies, like daos. A property file in the repository that holds the business rules, tells us what dependencies a business rule has. We use this to create instances of URLClassloader. The jars in the dependency list are added to the classpath of this classloader.
We use the URLClassloader to get an instance of the business rule.