WebSphere ServerRepository.xml / Deployed WAR Works, LH Command Line Fails

Anyone deploying to WebSphere that has gotten the LH Command Line tool to function with a ServerRepository.xml pointing to a DataSource within WebSphere?

We created a ServerRepository.xml that utilizes the WebSphere DataSource as the Performance is significantly greater for the idm.war deployed to WAS. The idm.war file works & performs better using this.

LH Command line fails with a ServerRepository.xml pointing to a WebSphere DataSource. I've been troubleshooting with SUN support & so far we have not made any progress to resolve this. LH fails trying to execute anything...see below for example & partial cut/pasted error message.

**set WSHOME, JAVA_HOME, & WAS_HOME 1st

$WSHOME/bin/lh -Djava.ext.dirs=$JAVA_HOME/jre/lib/ext:$WAS_HOME/lib:/ebiz/sim/dev/lib console -u configurator

Error:

com.waveset.util.InternalError:

==> com.waveset.util.ConfigurationError:

==> java.sql.SQLException: invalid arguments in callDSRA0010E: SQL State = null, Error Code = 17,433DSRA0010E: SQL State = null, Error Code = 17,433

at com.waveset.repository.ServerRepository.initDataStore(ServerRepository.java:152 7)

at com.waveset.repository.ServerRepository.getPrimaryDataStore(ServerRepository.ja va:1343)

at com.waveset.repository.ServerRepository.getPrimaryDataStore(ServerRepository.ja va:1309)

at com.waveset.repository.ServerRepository.init(ServerRepository.java:717)

at com.waveset.repository.ServerRepository.<init>(ServerRepository.java:693)

at com.waveset.repository.ServerRepository.getRepository(ServerRepository.java:134 )

at com.waveset.server.Server.init(Server.java:251)

at com.waveset.server.Server.start(Server.java:217)

at com.waveset.server.Server.getServer(Server.java:807)

at com.waveset.server.Server.getServer(Server.java:784)

at com.waveset.session.SessionFactory.getLoginConfigInfo(SessionFactory.java:849)

at com.waveset.session.SessionFactory.startupMode(SessionFactory.java:916)

at com.waveset.session.SessionFactory.getLoginModGrp(SessionFactory.java:885)

at com.waveset.session.SessionFactory.getSession(SessionFactory.java:170)

at com.waveset.session.SessionFactory.getSession(SessionFactory.java:390)

at com.waveset.session.SessionFactory.getSession(SessionFactory.java:456)

at com.waveset.session.WavesetConsole.newSession(WavesetConsole.java:361)

at com.waveset.session.WavesetConsole.start(WavesetConsole.java:331)

at com.waveset.session.WavesetConsole.main(WavesetConsole.java:218)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.ja va:60)

at java.lang.reflect.Method.invoke(Method.java:391)

at com.waveset.util.CommandProcess.invokeMain(CommandProcess.java:212)

at com.waveset.util.CommandProcess.launch(CommandProcess.java:162)

at com.waveset.util.CommandProcess.run(CommandProcess.java:300)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.ja va:60)

at java.lang.reflect.Method.invoke(Method.java:391)

at com.waveset.util.Command.main(Command.java:96)

Wrapped exception:

Architecture:

IDM 7.0

WebSphere 6.x

Oracle THIN Driver ojdbc14.jar - 10.2.0.x

AIX 5.3 ML3

[3856 byte] By [Andy_Wieganda] at [2007-11-27 4:28:20]
# 1
Bumping this thread...Noone else out there has had success with a ServerRepository.xml using a WebSphere DataSource for both the deployed WAR (which works) & LH Command Line (fails)?
Andy_Wieganda at 2007-7-12 9:37:04 > top of Java-index,Web & Directory Servers,Directory Servers...
# 2

I think the problem is that the Data Source is only accessible within the Websphere domain. When you run LH console from commandline, it is a process running outside of Websphere.

There's probably some voodoo you could try with the configuration of the Data Source to make it available externally, but the most expedient approach is to make a new Server Repository file that contains the connection info from the Data Source and cut out the middleman. Include this file in the WAR, but rename it (e.g. ServerRepositoryDirectConnect.xml)

When you want to run LH Console you would copy the ServerRepositoryDirectConnect.xml file over the Data Source one and then you should be able to connect to the repository.

I do not recommend running LH Console from the Websphere staging/deployment area. Copy the WAR to a working directory, make this your WSHOME, and then copy the ServerRepository.xml file.

Jason

jsalleea at 2007-7-12 9:37:04 > top of Java-index,Web & Directory Servers,Directory Servers...
# 3

Thanks, I appreciate the response! This is our workaround today.

The main frustration with this is during deployments. The LH Command needs the non-WAS ServerRepository.xml to load XML Objects into the DB repository initially, the WAS ServerRepository.xml is needed during startup & runtime, & we have daily batch feeds (FFAS, etc...) that require the LH Command & the non-WAS ServerRepository.xml again so it becomes a maintenance issue.

This swapping (or having a WAS / non-WAS install of the WAR) works, but should be unnecessary as using a WebSphere DataSource is supported functionality that we haven't gotten to work thus far.

I'm still looking for anyone today that has gotten LH to work with a ServerRepository.xml using a WAS DataSource. I agree that is has to do with being executed outside the WAS footprint, but I'm at a loss as to what else to try (along with Sun Support at this time).

In the meantime, we have an open Sun Case with Sustaining Engineering & I will post any updates received but would appreciate any additional input from others on the forums.

Thanks again!

Andy_Wieganda at 2007-7-12 9:37:04 > top of Java-index,Web & Directory Servers,Directory Servers...
# 4

Hi -

We are experiencing the same issue and I am also working with the Sun Support team to resolve this issue. In fact, we have not been able to get the first part (pointing Sun IdM to use Websphere datasource) working. The command

lh -D-Djava.ext.dirs=$JAVA_HOME/jre/lib/ext:$WAS_HOME/lib setRepo -Uidmadmin -tSQLServer -icom.ibm.websphere.naming.WsnInitialContextFactory -fjdbc/idm -uiiop://localhost:9810 -v

itself is throwing the exception as it is not able to load the necessary jar files. Have you been able to execute this command successfully ?

When I copied all the WAS jars into %WSHOME%/web-inf/lib, the following command executed fine but it wasn't able to look up the jndi name.

Sun support team suggested to use the following command -

lh setRepo -Uidmadmin -oD:\apps\temp.xml -n -c -Pidm@dm1n -tSQLServer -icom.ibm.websphere.naming.WsnInitialContextFactory -fjdbc/idm -uiiop://localhost:9810 -v

to create the new temp.xml and rename it and replace the serverrepository.xml. But I still am not able to get it working. Just wondering if I have to redeploy the war file.

Any suggestions here.. I will also post the solution from Sun Support team on this forum

Thanks

Lalit

ahluwala at 2007-7-12 9:37:04 > top of Java-index,Web & Directory Servers,Directory Servers...
# 5

To get the WAR deployed within WebSphere to function, I found the IDM Doc (IDM 7.0 Installation - "Configuring a WebSphere DataSource for Identity Manager" - Pgs 117 - 134) to be pretty decent for creating the actual JDBC DataSource.

My recommendation is to setup the DataSource at the Scope=Cell Level & use a WAS J2C Auth Entry for the DataSource so you do not need to use the -U or -P options in your setRepo command...this also helps ensure its truly connecting using WAS.

Looking at what you had, try this modified...

$WSHOME/bin/lh -Djava.ext.dirs=$JAVA_HOME/jre/lib/ext:$WAS_HOME/lib setRepo -n -tSQLServer -icom.ibm.websphere.naming.WsnInitialContextFactory -fjdbc/idm -uiiop://localhost:9810 -o"D:\apps\temp.xml"

*Additional comments

-n will bypass any checking and ignore any error message.

-f must be identical to the WAS JDBC DataSource Name jdbc/idm

**You do not need to redeploy after replacing the ServerRepository.xml; however, you do need to bounce the WAS AppServer & should monitor the AppServer SystemOut.log on startup to ensure the IDM WAR starts up successfully

***This is all assuming the DataSource you have within WAS is working (you can validate via the TestConnection)

Andy_Wieganda at 2007-7-12 9:37:04 > top of Java-index,Web & Directory Servers,Directory Servers...
# 6

To keep this posting on track the primary issue we're having is still with getting the LH command to function successfully using a ServerRepository.xml pointing to a WebSphere DataSource.

See the initial post for the specific command & error being encountered.

Any additional input would be greatly appreciated!

Thanks again!!

Andy_Wieganda at 2007-7-12 9:37:04 > top of Java-index,Web & Directory Servers,Directory Servers...