: I tried it on Vista 32 & Java 1.6.0_17-b04 and it works without a problem. : Actually on all other computers in the office there is no problem - I am the : only one using Windows 7 : : I did try with full path and it didn't work as well. Here's the result:
by the looks of it, your problem is happening long before solr (or even java) get access to the system property ... it appears that something About how Windows 7 works is causing the command line args to be split at the first "." character so it thinks hte rest of the sysproperty name is suppose to be a classname. things get even more interesting when you use the full path, and you can see htat somewhere along the way, something is converting the "/" charaters in the path to "." characters. (but that may just be an attempt by the JRE to work arround people who inadvertantly try to run a java class using apathc instead of a fully qualified classname). My suggestion would be that you ignore Solr for a little while. Start by double checking that the docs for your Windows 7 version of Java don't say anything about needing to use special escaping of system properties, then make a little dos batch file (or whatever they are called in Windows 7) that echo's back all of hte comman line arguments it gets, and test that out with some arguments that contain "." charaters in them and see what that tells you ... because everything you describe makes this sound like funky new shell behavior introduced in Windows 7. : PS C:\nginx\solr> java -Dsolr.solr.home=c:/nginx/solr/multicore -jar start.jar : Exception in thread "main" java.lang.NoClassDefFoundError: : /solr/home=c:/nginx/solr/multicore : Caused by: java.lang.ClassNotFoundException: : .solr.home=c:.nginx.solr.multicore -Hoss
