Every application server has a different installation process for installing J2EE components. Kodo can be installed in a number of ways which may or may not be appropriate to your application server. While this document focuses mainly upon using Kodo as a JCA resource, there are other ways to use Kodo in the J2EE environment.
JCA: Kodo implements the JCA 1.0 spec, and the kodo.rar file that comes in the JCA directory of the distribution can be installed as any other JCA connection resource. This is the preferred way to integrate Kodo into the J2EE environment. It allows for simple installation (usually involving uploading or copying kodo.rar into the application server), guided configuration on many appservers, as well as dynamic reloading for upgrading Kodo to a newer version. The drawback is that older application servers have flaky or non- existent JCA support as the spec is relatively new.
EEPersistenceManagerFactory: This remains the most compatible way to integrate Kodo into the J2EE environment, though this is not seamless and can require a fair bit of custom application server code to manage manually binding an instance of EEPersistenceManagerFactory into the JNDI tree. This is somewhat offset by avoiding JCA configuration issues as well as being able to tailor the binding and start-up process.
JDBCPersistenceManagerFactory: Nothing prevents an application from using com.solarmetric.kodo.impl.jdbc.JDBCPersistenceManagerFactory similar to standalone applications. JDBCPersistenceManagerFactory can be bound into JNDI just as EEPersistenceManagerFactory. However, you lose the ability to integrate the JDO transaction into the J2EE container's transaction.