Problem with Java Library path on AIX

[forev...@163.com]

Dear all,

I'm running WAS 6.1 ND under AIX 5.3.
I have already tried to set /home/.profile with this variables:

export PATH=$PATH:/usr/mqm/lib
export LIBPATH=/usr/mqm/lib

Then I restart server1.

When I look at the startup verbage in SystemOut.log the path '/usr/mqm/lib' isn't loaded.

How can I add the path '/usr/mqm/lib' to Java Library path on server startup?
Has anyone been able to figure this one out.

Thank you in advance.

P.S.

[Ken Hygh]

Check out the InfoCenter for 'shared libraries', it's the recommended
way of adding jars and setting libpath.

Ken

[Amol Kolhe]

Adding to .profile wont help, you can try any of the following.

1. Add those variables to setupCmdLine.sh under the bin directory of
WebSphere Binaries corresponding to server1.
2. Add JVM level Environment Variables.
3. If you're just trying to add those MQ Jars to JVM startup, then you
can add those paths to JVM CLASS PATH, and also allow that PATH in the
server.policy
4. Create Shared Library as mentioned by Ken.

[Doug Breaux]

P.S.

Add things like this to the setupCmdLine.sh script rather than to the user's .profile.

[forev...@163.com]

Hello,breaux!

Thanks for your reply.
It's done.

[Doug Breaux]

Interesting, Ken. Somehow I didn't see your reply yesterday on the web forum
when NNTP was down.

I don't think I realized that you could set native paths this way. Looking at
the shared library dialog (on 6.1), I see that the classpath is required. I
guess this means such an approach only makes sense if you have both jars and
native libraries you need to load together?

Does this also mean that you can't use this approach if the jar portion of
your library isn't safe to share across multiple applications?(*) Or does
each application get a different copy of the classes?

--
Doug

(*) http://struts.apache.org/1.x/userGuide/configuration.html#config_add

[Ken Hygh]

Doug,
I find the web interface to this forum to be bug-ridden and awkward to
use. NNTP was designed for these kinds of interactions, I'm not sure why
The Powers That Be decided to implement something third-rate. The NNTP
interface to this forum has been around for years.

In any event, and take this with a grain of salt because I'm not a WAS
developer, the shared library configuration was implemented in order to
give people a standard way of adding components to WAS. You can add a
component that has both java and native code, thus the fields for jars
and libpath.

Once created, this shared library can be attached as a classloader to
either an application or to a server. If you have native code, it's
almost always best to add the library to a server (web-container
classpath objects get dumped on reload, which JNI code cannot deal
with). As a classloader, it has the scoping of any other classloader, so
if you attach it to individual applications they each get their own copies.

Ken

[Doug Breaux]

Ken Hygh wrote:
<snip>

> Doug,
> I find the web interface to this forum to be bug-ridden and awkward to
> use. NNTP was designed for these kinds of interactions, I'm not sure why
> The Powers That Be decided to implement something third-rate. The NNTP
> interface to this forum has been around for years.

Yeah, I've been using NNTP for years too, but noticed lately that it's down
pretty often, so occasionally I go check the web forum. With the mass of spam
the forum had received lately, I've wondered if the NNTP version was going to
disappear entirely.

>
> In any event, and take this with a grain of salt because I'm not a WAS
> developer, the shared library configuration was implemented in order to
> give people a standard way of adding components to WAS. You can add a
> component that has both java and native code, thus the fields for jars
> and libpath.
>
> Once created, this shared library can be attached as a classloader to
> either an application or to a server. If you have native code, it's
> almost always best to add the library to a server (web-container
> classpath objects get dumped on reload, which JNI code cannot deal
> with). As a classloader, it has the scoping of any other classloader, so
> if you attach it to individual applications they each get their own copies.
>
> Ken

That makes sense and helps. It still leaves me wondering if there might be
scenarios where using setupCmdLine.sh for the native stuff and the application
classloader for the jars is necessary.

That is, if due to the issues you raise, you need the native libraries in the
server classloader, but due to the issues like described with Struts, you need
the jars in the application classloader.

Thanks for the discussion.

--
Doug

[Ken Hygh]

Doug Breaux wrote:
>
> That makes sense and helps. It still leaves me wondering if there
> might be scenarios where using setupCmdLine.sh for the native stuff
> and the application classloader for the jars is necessary.
>
> That is, if due to the issues you raise, you need the native libraries
> in the server classloader, but due to the issues like described with
> Struts, you need the jars in the application classloader.
>
> Thanks for the discussion.
>

I have strong antipathy for changing something delivered with the
product, like setupCmdLine. In a situation with a hundred servers,
having to make it part of the instructions for installing a new
box...and then checking it after every fixpack...yuck. If something
doesn't work right, the support folks at IBM have a shot at recreating
the environment, yada yada.

I haven't had to change setupCmdLine in years.

Ken