Hi, I migrating my application from Jboss 4.0 to Websphere 6.0. In my application there are two jar files which works as library files and i am putting those files in lib folder in Jboss.But in websphere i don't know where to put those jar(library)files.my application is an ear file which uses these jar(library) files.If i will put those jar files in the ear file then my application is not able to access in websphere,and what are the other things that i need to take care while migrating from Jboss to Websphere.
can u help me plz in this regard. its very urgent.
This is never a quick task. WebSphere is far more complex than JBoss, and JBoss is also more tolerant sloppy use of the J2EE spec. WebSphere's classloader hierarchy is also quite a beast to understand.
I'd recommed you stop trying to port you app till you understand the WSAdmin tool - which is much more powerful than the Admin Console. You can write your deployment scripts in JCL or Jython and WSAdmin will give you much more useful error messages than the Admin Console. Doing this should let you solve your own problems.
I ported an app. build on JBoss a year or so back. The original task was supposed to take a couple of days, instead it took about three weeks. It was my first exposure to WebSphere - so the learing curve slowed me down a lot. If you know and understand WebSphere you could do it far quicker I'm sure. If you don't better settle down for a long, painful task.
Basudev - I'm not exactly clear what you mean by "there are two jar files which works as library files and i am putting those files in lib folder in Jboss", but I am assuming you mean shared libraries., i.e. libraries that are shared by more than one enterprise application. I personally don't like shared libraries because they present problems for those responsible for maintaining the WebSphere environment. Even if the libraries are shared by more than two applications I would still put them in the EAR. All you need do is make a Class-Path entry in the MANIFEST.MF file fore every module that needs to use the library. For example, if you had a utility.jar file used by an EJB module and the WAR module, you would place it in the root of the EAR. In the META-INF/MANIFEST.MF of the EJB jar and the Web module you would add the entry, Class-Path: utility.jar.
If you absolutely have to define a shared library externally, then do the following: 1. From the admin console, define a Shared Library reference. Environment-->Shared Libraries. Choose the scope you want define the shared library reference: Cell, Node, or server. 2. Enter a descriptive name and define the class path to the JARs. Save yourself possible grief by NOT putting the jars in a WebSphere directory. Obviously, before being used by the application the directory must physically exist, and you will have to place the JARs in the directory you defined. Think of this as just a reference; I is not used until you define its use by an application or a server. 3. Now you can use that reference either at the application level or at the server level. If at the application level, then an application classloader will load the shared library. If you define it at the server level, you will first have to create a new classloader for the server, then associate the shared library reference. a. Application level. i. Applications-->Enterprise Applications--><Your application> iii. Select Libraries from the "Additional Properties" category. iv. Select the Add button, the library reference, from the dropdown list, then the OK button. b. Server level. i. Servers-->Application Servers--><your server> ii. Under "Server Infrastructure" select Java and Process Management->Class loader. iii. Select New, then OK to create a new classloader. iv. Select the classloader, then the Libraries link. v. Press the Add button, select the shared library from the drop-down, then press OK. c. Restart the appropriate processes (e.g. DM, node agent, server).
You will make your life, and the lives of those who support the infrastructure much more easy if you avoid using shared libraries.