RE: Can anybody suggest any reasons why BIRT would be unable to establish a JDBC connection, when running on the same physical box?

Those property tags are probably within a data source <Resource> tag.

Although all the Tomcat documentation tells you that you can put userid and password within property tags in the Resource (or ResourceParams, depending on Tomcat version), the JT400 driver you're using completely ignores them. Userid and password must go in the "odaURL" connection string. Something like this:

<property name="odaURL">jdbc:as400://127.0.0.1/WTI1###;user=someuser;password=somepassword;prompt=false</property>

I know this puts the password in clear text in the config file. Use a user profile that can't do much else so stealing this password won't abridge security. Base64 is pretty close to clear text.

Look at the jar files in the /lib path of your webapp. You'll see either jt400.jar or jt400Native.jar.



-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of James Lampert
Sent: Friday, December 09, 2011 10:45 AM
To: Java Programming on and around the IBM i
Subject: Re: Can anybody suggest any reasons why BIRT would be unable to establish a JDBC connection, when running on the same physical box?

Dan Kimmel wrote:

James, I saw this inquiry on Midrange-L, as well. From there it looks
like you're trying to access database tables (*FILE objects in a *LIB
object) as opposed to files, which on this forum tends to refer to IFS
stream files.

You are correct.

How are you trying to access the tables. Through JDBC using the JDBC
driver from JT400? Are you using JT400 or JT400Native? What does your
connection url look like? One of the important things to remember is
the userid and password for the connection are in this url in most
circumstances. The userid under which the JVM running Tomcat is
running has no bearing on the database connection unless you're
running JT400Native.

Unfortunately, it's not my code (and I don't deal with Toolbox classes enough to know one driver from another), so I wouldn't know whether it's JT400 or JT400Native. And to complicate matters, the customer's box is behind a firewall, and I don't think they're inclined to even temporarily open up the ports needed for us to, say, connect with Squirrel SQL.

But I see this in a configuration file we use for BIRT:

<property name="odaDriverClass">com.ibm.as400.access.AS400JDBCDriver</property>
<property name="odaURL">jdbc:as400://127.0.0.1/WTI1###;prompt=false</property>
<property name="odaUser"></property>
<encrypted-property name="odaPassword"
encryptionID="base64"></encrypted-property>

Since the "WTI1###" library name was causing some interesting effects elsewhere, I set up a similar library here, on our box, and BIRT had no trouble at all accessing the database on our box.

If you're running JDBC through JT400, there should be info in the
joblogs for the QZDASOINIT job that is serving your connection. That
job log will have info about why the file couldn't be found (no
privilege, etc.). Use WRKOBJLCK xxx *USRPRF where xxx is the user in
the JDBC connection string to find the QZDASOINIT job.

Since I *do* have terminal sessions on the box in question, I'll start looking for QZDASOINIT jobs thereon.

--
JHHL
--
This is the Java Programming on and around the IBM i (JAVA400-L) mailing list To post a message email: JAVA400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/java400-l.