CLASSPATH... is not an identifier (Oracle JDBC/B2B)

Came across an interesting error last week, and spent a few hours trying to debug it before discovering the actual cause. Seems like a reasonably severe shortcoming in wM B2B v4.x to me, but I’m still fairly new and this stuff, and could definitely be doing something wrong.

We have a small custom Java Service, which basically tests a JDBC connection to an Oracle 8i database using Oracle’s thin JDBC drivers.

The relevant lines of code are:

try {
Connection connection = DriverManager.getConnection(
“jdbc:oracle:thin:@[SERVER]:[PORT]:[ORASID]”,
“[USERNAME]”,
“[PASSWORD]”
);

Once it’s established a connection to the database, it selects all of the records from a test table, adds them to a pipeline, and exits.

There tends to be, in our current environment, some confusion over whether our Oracle SIDs include the .world suffix or not, so the getConnection statement at one point in time, had a “server.world” SID instead of the correct “server” one.

Unfortunately, with a malformed thin JDBC driver connect string, the wM B2B server crashes returning the error:
server.sh CLASSPATH [CLASSPATH values here] is not an identifier.
We spent a significant amount of time trying different combinations of UNIX shells and environment variable setting schemes before we finally identified that the Oracle SID was incorrect.

Now, we’ve learned our lesson, and will always check our JDBC connect strings thoroughly before clicking the run button, but I’m concerned that this seems extraordinarily brittle. Is it possible that we’ve got something misconfigured?
Why wouldn’t the wM B2B server simply pass the ORA-xxxxx error back to the offending program?

Any ideas?
Thanks in advance for you help and/or commiseration.

Curtis

I may be off-base here, but I believe that wM B2B Server didn’t give you back the ORA-xxx error because it’s not managing the connection–you are. If you’re going to drop down to Java and interact with the JDBC manager, you get to manage all the fun little details. From what you described, B2B isn’t doing anything but providing a JVM environment for your code to run in.

Why aren’t you using the B2B server facilities and built-in services for the database interaction? Unless you’re doing something out of the ordinary, you shouldn’t need to be doing anything with DriverManager, Connection, or any of the JDBC classes. B2B can handle all of that for you.

Or have I misread your post?

Rob

Hi Rob.
Your comments are completely valid, and I appreciate them. Thanks.
You are correct in stating that I’m basically reducing B2B to a JVM. It is not our intent to do this (if we can avoid it) for anything other than debugging database connections.

How we got to writing the Java service to test the database connection was trying to overcome the less than useful “No Suitable Driver Found” error, which was returned by the standard B2B services. We wrote a command-line app to test the connection, ported that to a Java Service, and then used the settings in the Java service to setup the standard services. One of the developers was having problems with their database connection, so they changed the parameters in the Java source, ran it and boom - the server went down.

I guess my question was sort of - “how do we protect ourselves from ourselves?”
Should expect the B2B server to go down, when we execute poorly constructed code. I would have expected the B2BServer application to stay up, even when (or maybe especially when) an untrapped/uncaught Java error occurs. Maybe that’s an unfair expectation. I can see the sense in both sides of the issue.

Thanks again, Rob.

Curtis

Ah, I see what you’re doing now. Slick.

Actually, the “No suitable driver found” isn’t peculiar to B2B–it seems to be a JDBC “feature” that I’ve encountered in other environments.

I agree whole-heartedly that the server shouldn’t crash. And in this case, where your code isn’t misbehaving but using supposedly “bad” data, it definitely shouldn’t crash. Even at that, the JDBC driver/manager shouldn’t be urping just because of what amounts to a not found error.

What sort of exception handling do you have in your service? Have you zeroed in on the exact statement that causes the crash? What does the command-line app do with the same parameters?

The specific error message you’re getting is awfully wierd. It almost seems like a memory overlay or something like that. What else is in the logs that might give a clue?

If you can isolate this (sounds like it may be already) then webMethods support should be able to dupe it fairly easily. Crashing the server is definitely something they should be able to fix.

Rob

Thanks again, Rob.

I would tend to agree that the “No suitable driver found” is a Java/JDBC thing - not that I’m an expert at either of them.

The statement that brings the B2B Server down is DriverManager.getConnection with the appropriately “inaccurate” information (i.e. connection string). There is, I’m ashamed to admit, no exception handling on the DriverManager.getConnection statement since this program would definitely fall in the “quick & dirty” category. Presumably catching the exception would prevent the server crash.

We’re upgrading to v4.6 (from v4.0.1) as I write this, and I’m going to try to bring the server down with my bad java as soon as it’s up and running to see what happens.

I’ll think about reporting it to webMethods if it’s behaviour that still apparent in the new version.

Thanks again for your input.

Curtis

We’ve got a webMethods PS consultant on-site now, and we’ve got answers to a couple of the questions posed in my email, so I thought I would post them in case anyone else was having problems.

First off, I should say that the specific version of B2B/Integration Server we’re using is distributed by SAP AG and contains the SAP Adapter (SAP calls it the Business Connector).

The “CLASSPATH is not an identifier” error is a problem with the server.sh shell script which is used to start the service under solaris. It occurs after the statement which invokes the server.jar, so that the statement is not processed until after the java vm which is running the server.jar stops (for any reason). So, regardless of why your B2B Server application stops, you’ll see that message.

As to what was causing the B2B Server to go down, we’re still not 100% sure, but we have a good working theory. In the java service we coded, there is a “System.exit (-1);” statement which is executed on “java.sql.SQLException”. It appears as though any database error (anything returned from Oracle as an ORA-XXXXX) will kill the Java VM, which will stop the B2B Server which is running as an application in the same VM.

So, I presume that the lesson learned is not to use any “System.exit (-1);” statements in any services you write in Java?

Hopefully that helps someone else at some point.