• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Liutauras Vilda
  • Jeanne Boyarsky
  • paul wheaton
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Henry Wong
Saloon Keepers:
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Tim Moores
  • Mikalai Zaikin
Bartenders:
  • Frits Walraven

migrating from Jboss4.0 to websphere 6.0

 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

thanks,
basudev
 
Bartender
Posts: 10336
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 50
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

Bill Lasley
Versant Corp.
http://www.versant.com
 
You would be much easier to understand if you took that bucket off of your head. And that goes for the tiny ad too!
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
reply
    Bookmark Topic Watch Topic
  • New Topic