 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / May 2005Newbie: Just drop it on the classpath
I found what seems to be a good MS SQL driver call jTDS. Its open source and on SourceForge and, as is, typical the doc is sparse. But in this case I think the problem is mine. They say on their site: "Being a type 4 driver, jTDS does not need any special installation. Just drop the jar file into your application's classpath and you're done." Well, bully for them. But there seems to be a hundred different ways to manage ones classpath. AND there's no way to know that when I ship something that the destination machine will have the same classpath as mine. Sometimes it seems maddening. And quite frankly its hampering my ability to get Java into our company. To them having (what they think is) a nice clean MSI package is the way to go. But having worked in a MS shop before I know what its like to have to run "regsvr32" on a bunch of machines just to get them to work. First, at least on my personal machine, can I just drop this thing in my jre/lib directory and be happy? Second, does anyone have advice or resources regarding jar management in the enterprise? Thanks all. J > I found what seems to be a good MS SQL driver call jTDS. Its open source and > on SourceForge and, as is, typical the doc is sparse. But in this case I [quoted text clipped - 7 lines] > manage ones classpath. AND there's no way to know that when I ship something > that the destination machine will have the same classpath as mine. My answer is always 'dont'. I've haven't set a classpath for years. Set JAVA_HOME at most. If your app needs a specific classpath, make it fit and write a script. > First, at least on my personal machine, can I just drop this thing in my > jre/lib directory and be happy? Yes. Especially if you plan to use it again. > Second, does anyone have advice or resources regarding jar management in the > enterprise? It's potentially a hell of a mess. In a development scenario tools like Maven help, but from the app end of things the common solution is to unjar your jars and put the classes in your app classpath. This is perfectly fine with *most* open source stuff but you should check the licence. There is an Uberjar tool but again I'm not sure how useful it is in an app scenario (it is part of classworlds). > Thanks all. > > J  Signature[Ross A. Bamford] [ross AT the.website.domain] Roscopeco Open Tech ++ Open Source + Java + Apache + CMF http://www.roscopec0.f9.co.uk/ + info@the.website.domain > > First, at least on my personal machine, can I just drop this thing in my > > jre/lib directory and be happy? > > Yes. Especially if you plan to use it again. Although now I think more on this there is one caveat: that it will be loaded by the boot classloader, which may matter to you in certain circumstances... Signature[Ross A. Bamford] [ross AT the.website.domain] Roscopeco Open Tech ++ Open Source + Java + Apache + CMF http://www.roscopec0.f9.co.uk/ + info@the.website.domain > I found what seems to be a good MS SQL driver call jTDS. Its open source and > on SourceForge and, as is, typical the doc is sparse. But in this case I [quoted text clipped - 7 lines] > manage ones classpath. AND there's no way to know that when I ship something > that the destination machine will have the same classpath as mine. When you ship something you should either ship it with a startup script in which you launch it AND specify the classpath (with relative paths, so you can place all jars under a single directory) or you can ship an executable jar and then you can specify the classpath inside its MANIFEST.MF file (if you'll look at the jTDS jar file you'll see a sample usage of this). > Sometimes it seems maddening. And quite frankly its hampering my ability to > get Java into our company. To them having (what they think is) a nice clean > MSI package is the way to go. But having worked in a MS shop before I know > what its like to have to run "regsvr32" on a bunch of machines just to get > them to work. As explained above it's quite easy to distribute a piece of Java software (and have it work too, of course). Easier than with an MSI package, I would say. Just extract the whole bunch and it works. > First, at least on my personal machine, can I just drop this thing in my > jre/lib directory and be happy? You could, but I'm not sure you want to do that. First of all, it will be loaded by the bootclassloader (which in some cases could cause problems); second it may interfere with your apps or other apps that may come with another version of that jar file; third, as you can see, this won't help with distributing your app. > Second, does anyone have advice or resources regarding jar management in the > enterprise? Google could help with this. :o) Alin, The jTDS Project. >First, at least on my personal machine, can I just drop this thing in my >jre/lib directory and be happy? I wouldn't recommend this. It reallyl depends on what type of application you are deploying. Web app? Put it in your webapps WEB-INF/lib folder Standalone app? Just invoke with the -classpath option >Second, does anyone have advice or resources regarding jar management in the >enterprise? See above. For standalone apps, I just create a distribution with a lib folder, and in the root folder is a bat/sh file that contains the java command and -classpath option -- now with more cowbell > >First, at least on my personal machine, can I just drop this thing in my > >jre/lib directory and be happy? [quoted text clipped - 4 lines] > > Web app? Put it in your webapps WEB-INF/lib folder I think a JDBC driver is something that should be managed by the container in a webapp scenario. When you get webapps with their own copies of a driver you get problems in my experience. I write my projects to a JNDI datasource, which is configured in the container and uses whatever database / driver is in use on the target machine. Why tie usage to a certain database / version? Plus, I get all the benefits of container managed authentication and connection pooling, transparently in most situations. > Standalone app? Just invoke with the -classpath option Why bother? If you're developing with your driver enough, then why have to remember the classpath every time? In light of the above, if your driver is purely a local concern does it matter exactly how it gets into the classpath? Unless you're doing classworlds type stuff (disabling classloader delegation and whatnot) then you've really no cause for concern. Note I'm not advocating this for everything, or even most things, but I think the driver for this machine's local database does belong with the system classes. At the end of the day it's a matter of opinion. I understand the reasons behind advising against it, but to portray it as outright wrong is, well, outright wrong :) Signature[Ross A. Bamford] [ross AT the.website.domain] Roscopeco Open Tech ++ Open Source + Java + Apache + CMF http://www.roscopec0.f9.co.uk/ + info@the.website.domain >> >First, at least on my personal machine, can I just drop this thing in my >> >jre/lib directory and be happy? [quoted text clipped - 8 lines] >container in a webapp scenario. When you get webapps with their own >copies of a driver you get problems in my experience. You are of course, correct. common/endorsed is where you'd put it then I believe. >> Standalone app? Just invoke with the -classpath option > >Why bother? If you're developing with your driver enough, then why have >to remember the classpath every time? In light of the above, if your >driver is purely a local concern does it matter exactly how it gets into >the classpath? I use a bat/sh file (and any IDE is going to allow you to manage that). >Unless you're doing classworlds type stuff (disabling classloader >delegation and whatnot) then you've really no cause for concern. Note [quoted text clipped - 5 lines] >behind advising against it, but to portray it as outright wrong is, >well, outright wrong :) Which is why I said I wouldn't recommend it. Why? Mainly for deployment reasons. For me, if I'm developing a standalone application, its easy for me to just provide a zip/gz file that contains everything needed, and including a bat/sh file that executes the java command. I find that easier than telling the users they need to make sure this jar file needs to go here, etc... -- now with more cowbell > >> >First, at least on my personal machine, can I just drop this thing in my > >> >jre/lib directory and be happy? [quoted text clipped - 11 lines] > You are of course, correct. common/endorsed is where you'd put it then > I believe. I use server/lib and global sources, but that's a preference I suppose... > >> Standalone app? Just invoke with the -classpath option > > [quoted text clipped - 5 lines] > I use a bat/sh file (and any IDE is going to allow you to manage > that). Again, if you don't mind that's fine, but I prefer not to have a classpath set at all ordinarily, and have a properly generated path for each project (with Maven). It comes down to the fact I guess that I never program against the driver, only a datasource, but then my database requirements aren't particularly taxing... > >Unless you're doing classworlds type stuff (disabling classloader > >delegation and whatnot) then you've really no cause for concern. Note [quoted text clipped - 7 lines] > > Which is why I said I wouldn't recommend it. Fair enough :) Signature++ Ross A. Bamford rosco@the.website.domain ++ Roscopeco Open Tech ++ Open Source + Java + Apache + 2EE http://roscopeco.co.uk/ info@the.website.domain Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.