Comments by David Days

David Days 1-Mar-14 15:49pm View

Glad to help. Stop by any time.

David Days 28-Feb-14 10:21am View

I changed the solution to put the definition in the markup. This should work for you.

David Days 26-Feb-14 16:23pm View

Just guessing, but I'm betting that it's the "http://" address, as in "http://localhost/VinNowDataServiceLite/VinNowDataSvc.svc". wsHttpBinding looks for an SSL address by default, I believe.

You can get around this by changing your binding to <security mode="None"> at the security level.

The reason that it works for the Windows authentication is that Windows auth goes to an encrypted channel by default--so the negotiation is secured and the host doesn't complain. With a web service, the equivalent is an "https" address by default, which is not what you have.

I've had this problem many time, and it continues to bite me if I'm not paying attention--I'm just faster to fix it nowadays.

David Days 25-Feb-14 12:53pm View

Reason for my vote of 5 \n Good way to translate difficult data

David Days 21-Feb-14 12:42pm View

I'm glad to have helped you get in the right direction.

Running the same servlet multiple times on Tomcat is a normal capability--different contexts (URL paths) means they get treated as independent apps for the most part. I'm not sure why SSL becomes an issue, though; it's either a driver-dependent limitation (possible, but would seem to be a strange way to set it up) or it has to do with how SSL kind of strips away all pretension and forces both sides to talk with distinct machine names (as in, you can't do an alias for "appsrv.secure.domain" to "www.secure.domain" and have the SSL cert continue to be valid)...

In my limited experience with other drivers over SSL, it's not usually a problem--but it's always been one app trying to get to one database, not two instances of the same app.

I'll do some checking around to see if anything pops up--I've had other SSL issues that trip me up when everything else is working correctly, and this one sounds familiar.

Glad it got resolved; hopefully this whole conversation will help someone else that runs into the same thing.

Good luck, and don't hesitate if you have any other issues.

Sincerely,
David

David Days 20-Feb-14 10:37am View

First thing that comes to mind is that the servlet you are ultimately trying to change might be getting configuration from another source.

Try a file search on the Tomcat directories for the server url--you might find the servlet is getting its config from a different context.xml; it's a shot in the dark, but it sounds like you've solved the parameters issue--just making sure the servlet uses the correct ones.

David Days 18-Feb-14 11:52am View

Personally, I always used the JTDS driver--much easier to use, and never had any issues with it. I have never used any of the SSL options, though, so I can't speak to that. Having said that, though, it sounds like it's more a matter of having your app connect to an https connection rather than providing authentication via one (client certificate stuff).

I would try some test projects with both in Eclipse, and concentrate on the driver setup rather than the results, since you may not want to rework your code on the main servlet.

David Days 18-Feb-14 11:47am View

I would probably either pull out the subfolder "enu" (on the version I have), or add "C:\tomcat\lib\sqljdbc_4.0\enu" to the classpath, since the actual JAR files are lower down in the structure.

David Days 18-Feb-14 11:28am View

Admittedly, I don't know what else to do. You can turn up the logging level to see where in the JDBC process it is dying--I would suggest that as a next step.

After that, it all depends on what you find: Are the various PATH variables correct? Is it a permission issue because Hibernate can't reach into the correct DDL? etc..

David Days 18-Feb-14 10:53am View

It sounds correct with regards to configuring the driver resources. I generally stuck with the context.xml parameters that I spoke about earlier. This way, though, your entire Tomcat server should have this configured connection available; it's up to you to decide if that's what you want or not.

David Days 18-Feb-14 10:47am View

Easiest way to go would be in the catalina.bat file. Tomcat is one of those systems that is configured almost identically in both the Windows and *nix versions, so it's often easier to stick with a Tomcat-oriented configuration (Tomcat Classpaths, configs, etc), than to try and do machine-level configurations, like installing DLLs in the Mystery Folders.

David Days 18-Feb-14 10:20am View

Ok--I downloaded the driver and went through the installation process.

What the installation does is basically deliver you a structured package. The entire structure should be used at once in your application--meaning, you don't just pull out the DLL. If the Tomcat server is going to be the only user of this type of connection (JDBC to Sql Server), I would recommend placing the entire extracted package (subfolders and all) in the Tomcat's JAR library (whatever the currently configured CLASSPATH is.)

The help files included in the download show code, configuration, and examples of each, so you should be able to get closer to your goal.

David Days 14-Feb-14 12:22pm View

sqljdbc_auth.dll is (and I'm guessing, but very confident) part of the windows installation of the jdbc driver. Getting to the edge of my guesswork here, but I would recommend re-installing the driver, then confirming that the DLL is present.

David Days 14-Feb-14 11:32am View

Actually, the "failed to load sqljdbc_auth.dll" sounds like more of an installation issue. The hibernate error is (99% sure) likely because of the previously mentioned error.

"failed to load" may not mean that the dll isn't on the machine, but that it's not where the Tomcat system can find it. You may have to go through the installation steps again, or check the permissions and account under which the Tomcat server is running.

From my reading, the "trustServerCertificate=true" should cover it--you don't necessarily need a keystore at that point ('course, you just trusting anyone who says they are the server, but one issue at a time).

Comments by David Days (Top 14 by date)