CODEWITHSUNDEEP
javaglassfishwebsphere
ConceptSpecs
ConceptSpecs

Reputation: 71

converting ejb project from websphere to glassfish 2.0

Hi I have a project in which the coding is on java and this code is using swing, ejb and ibm's websphere coz it was coded in 2001 by someone , so i have to convert it for using it on glassfish 2.0 . The problem is that in this code using the api of ibm's websphere is used like 

com.ibm.ejs.util.Uuid;
com.ibm.ivj.ejb.runtime.AbstractAccessBean;
com.ibm.ivj.ejb.runtime.AbstractSessionAccessBean;
com.ibm.etools.ejb.client.runtime.AbstractEJBFactory;
com.ibm.ejs.container.EJSWrapper;
com.ibm.ejs.container.*;
com.ibm.ejs.persistence.EJSJDBCPersister;
com.ibm.websphere.cpi.PersisterHome
com.ibm.ejs.container.*;
com.ibm.ejs.container.*;
com.ibm.ivj.ejb.associations.interfaces.Link;
com.ibm.ivj.ejb.runtime.AbstractAccessBean;
com.ibm.ivj.ejb.runtime.AbstractSessionAccessBean;
com.ibm.xml.parsers.SAXParser;
COM.ibm.db2.jdbc.DB2BaseDataSource;
COM.ibm.db2.jdbc.DB2DataSource;

I don't want to use websphere and also not found any jar file to import that classes on glassfish so please suggest me how to convert it.

Upvotes: 1

Views: 1689

Answers (2)

Kurtcebe Eroglu
Kurtcebe Eroglu

Reputation: 1954

The classes you mention are generated by WSAD (WebSphere Application Developer, which is ancestor of RAD) during 'generate deployment and rmic code' phase of build process. You can also tell this from the class names, which probably have funny prefixes and suffixes attached original bean name and reside in the same package. So, developer did not write these classes himself, they are generated for WebSphere, and they shall be omitted (cleaned up from project) before migrating to an application server from another vendor. On how to get rid of these classes you may find instructions at tech note below.

EJBDeploy generation and deletion of stubs, ties and generated deploy code

I would say that you have a pair of problems here, because most probably Enterprise Java spec that was used is not currently supported by new servers (it is probably 1.2 as it is very old). So you must first perform a specification level migration, then application server migration.

For specification level migration (i.e. Java EE 1.2 to 1.4 at least) I would say your best bet would be to use RAD (Rational Application Developer), which can perform specification migration by using simple wizards. You may find information about how to perform this migration at article below.

Migrating the specification level of J2EE projects

Once you upgrade spec level it will be easier to migrate your project to another server because as the spec level increases, effort for server to server migration decreases. At this point what you shall do basically is prepare application server specific deployment descriptors for your target server (Glassfish), for which you shall check glassfish website. A good entry point would be Glassfish migration wiki, and Glassfish verification tool (I can't put links to these because I don't enough reputation to post more than two link at the moment :)

Upvotes: 1

Markus Eisele
Markus Eisele

Reputation: 722

I don't know of any "simple" way to convert such projects. You will end up having to manually change all relevant parts to the updated spec. I assume you are not really willing to upgrade to GF 2.0? You should at least move to 2.1. I highly recommend to move to 3.1.

Upvotes: 0

Related Questions