I think I figured out the problem for why creating an uber-jar of all the restlet dependency classes (plus my own code) wasn't enabling restlets to find the Grizzly server framework:
When I created the jar, I unpacked all the classes, but filtered out the manifest stuff. A quick glance at the source code taught me that the Restlet engine was using them to find servers. I removed the filtering, and I can now do the following: java -jar myapp.jar and see something similar to: Sep 28, 2010 7:56:34 AM org.restlet.ext.grizzly.GrizzlyServerHelper start INFO: Starting the Grizzly [HTTP/1.1] server on port 9000 Sep 28, 2010 7:56:34 AM com.sun.grizzly.Controller logVersion INFO: GRIZZLY0001: Starting Grizzly Framework 1.9.19 - 9/28/10 7:56 AM on start up, which is what I had hoped for. So, problem solved! Keith On Mon, Sep 27, 2010 at 5:10 PM, Keith Irwin <keith.ir...@gmail.com> wrote: > Kind of an interesting thing, here... > > I've got a project using Restlets. I've added the grizzly extension jars. > When I run the project by building up a classpath, and then invoking the > main entry point of my app, the Grizzly framework starts up just fine. > > java -cp $CLASSPATH my.package.Main > > However, if I unpack all the jars to make a single uber-jar so that I can > do the following: > > java -jar uber.jar > > Restlets starts up the internal web-server, and not Grizzly. I'm guessing > that the code actually inspects the classpath for the presence of certain > jar files in order to make its decision. > > Is there any way to call appropriate methods on a Component to insist on > starting Grizzly? > > I'd like to be able to use the uber-jar because it makes my shell scripts a > lot easier, and because I want to insulate my colleagues (who are not Java > programmers) from having to be aware of such issues. > > Thanks! > > Keith > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2665788
