StackOverflow when initializing a support class

[bjchip_hyperic]

While it works perfectly in tests that stand alone, initializing the support class for the WAS Admin Client (getting the admin client factory), fails with a stackoverflow when it is initialized from within a plugin.

The relevant lines of code being executed are:

System.out.println( connectorSecurityEnabled ); // This is the "false" in the dump.

if (connectorSecurityEnabled == "false") {
adminClient = AdminClientFactory.createAdminClient(props);
return adminClient;
}

When executed from outside plugin it has no trouble connecting. The Hyperic is 4.1.0.19 free. The WAS is a 6.1 version. The jar file is from the WAS and is included in the classpath of the plugin.

Maybe that last is a mistake. The exported jar may have the libs elsewhere?

[bjchip_hyperic]

No... doesn't matter if that is in the plugin definition.

So the plugin classloader doesn't like this? Maybe I just need to set the stack larger to run it?

[bjchip_hyperic]

Nope... just takes longer to break. Xss10m still falls over. Standard is 512k IIRC. Works without any changes otherwise. Hmmmmmm...

[dougm_hyperic]

Hi BJ,

Sounds like the same issue as http://jira.hyperic.com/browse/HHQ-2044
And I believe the workaround for that is here in WebsphereProductPlugin:
//XXX HHQ-2044 emulate -Djava.ext.dirs
private void setExtDirs(String installDir) throws Exception {
...

Not pretty, but this is WebsFear. I believe an alternative workaround would be copying the jars to pdk/lib/ - but be careful to grab the minimal set.
Which fixpack of WAS are you running? I will be looking at an issue related to 6.1 fixpack 20-something in the next couple of days. I also plan to have a look at the WAS related work you've been doing, so I'll likely be following up on some of your other threads.

[bjchip_hyperic]

That looks like the very one. I am not going back to try it out though. I have been through the mill with this thing and I finally capitulated and did what I clearly SHOULD have done in the very first place.

I wrote my code as a standalone monitor. Told it off to write to a log file for the specific values of the queue attributes of the specific queues, and then went for those with a script. Well I am GOING for those with a script.

I am perversely uninterested in the details of the WAS itself at this point. I have a project related problem that MUST get at the queue depths and the standard WAS interface doesn't hand those back. Not nohow. Try to get them from the admin console and you spend 5 minutes drilling into the interface.

What I really wished for and didn't get, was advice on tying into their WAS plugin.

All I needed was access to a running AdminClient to build the custom query stuff around.

Ppphhhht. ( Although that client would be affected by the problem described and my current version is immune - and can be extended in the Java to get any data I want off the WAS ).

The principle problem with any of it is that there's no way I know of to get at the queue names without programming them into the plugin. It can't discover them, present a list for the user to tick and then monitor the ticked ones. That was what I expected to do when I started. Now I have to put them into spring config files and code them into the script-plugin.

Worse, something in the WAS system is a little broken when trying to search for a specific bean. I can get ALL the beans related to SIB based queues, but I can only get a specific one by using its full ObjectName. The substring search is either too obscure or simply broken as it returns nothing.

Eh... bypassed the problem by gum. Working on the script but short of time and sleep.

Which probably has something to do with my current level of incoherence. 🙂

respectfully
BJ