You are not on right path when try to execute this script. It's because httpd.sh script contains for example path to ../../lib/classserver.jar. Two dots (..) means one directory up. If you are executing this script from $RIVER_HOME/examples/hello/scripts then ../../lib/classserver.jar is equivalent to $RIVER_HOME/examples/lib/classserver.jar, but there is not that directory.
Solution is to just cd one level up and then execute: scripts/httpd.sh 2011/8/29 helcio silva <[email protected]> > Hello, Peter. > > As a matter of fact, I've used the Jan Newmarch's book as a > reference. On chapter named 'Advanced Security', it suggests, for > example, the use of Loggers. Well, when I look the file generated by > loggers, I can see all that proxy verifiers listed below. However, I > am still receiving a message saying that the server's proxy is > untrusted. > > I've calculated the MD5 hash on a -dl.jar file using the > computedigest.jar application, as it's shown on Newmarch's book, and > put that hash in an HTTPMD URL. Next, I've started the classserver.jar > application, pointing it to that -dl.jar file. > > There is another remarkable point that I want to comment here: it > is about the hello demo application included on River distribution > releases. More specifically, I am talking about the > $RIVER_HOME/examples/hello directory. There is a directory named > 'scripts' inside the hello directory, containing (obviously) scripts > to running hello application using different scenarios. However, when > I try to run one of those scripts, httpd.sh, I receive the following > message: > > ./httpd.sh > + java -jar ../../lib/classserver.jar -port 8080 -dir lib:../../lib-dl > Unable to access jarfile ../../lib/classserver.jar > > In my opinion, that script would work just when we use > "../../../lib/classserver.jar" instead of "../../lib/classserver.jar". > It also would work if we move it (without modification) to directory > above. > > Is that an error to be fixed on next distributions? Or am I doing > something wrong here? > > Best regards. > > Helcio. > > 2011/8/28 Peter Firmstone <[email protected]>: > > Hi Helcio, > > > > Good to see your interest in River. The class files are definitely > there, > > I've given you a link to Jan Newmarch's online book, hopefully this will > > help you figure it out. The problem might have something to do with your > > policy or configuration. > > > > http://jan.newmarch.name/java/jini/tutorial/AdvancedSecurity.html > > > > The client needs to have a list of local verifiers that it trusts just > > because they are local. A standard set is given in the Jini library > > jsk-platform.jar file. This jar file contains the following verifiers: > > > > 1. > > > > ConstraintTrustVerifier > > > > 2. > > > > BasicJeriTrustVerifier > > > > 3. > > > > SslTrustVerifier > > > > 4. > > > > KerberosTrustVerifier > > > > 5. > > > > ProxyTrustVerifier > > > > 6. > > > > ConstrainableLookupLocatorTrustVerifier > > > > 7. > > > > DiscoveryConstraintTrustVerifier > > > > Cheers, > > > > Peter. > > > > > > >
