: The other option I looked at is writing my own handler for my crawler and : plugging it into Solr's solrconfig.xml. If I do this, then my crawler will : run in the same JVM space as Solr, this is something I want to avoid.
If you don't want you crawler to run in the same JVM as solr, then asking how to deploy it to the same jetty instance makes no sense -- it would still be in the same JVM. : Yet another option is for me deploy a second instance of Jetty on the Solr : server just for my crawler. This is over kill in my opinion. Can you explain the basis of your opinion? You want your application to run in a daemon and be accesible over HTTP -- so implement it as an HTTP daemon. the fact that your app will talk to Solr on the same machine via HTTP doesn't make that design a wrong, any more then talking to a JDBC daemon on the same machine to fetch data from would mean you should skip having your own process and embed your crawler directly in the database server. : issue? Deploy my crawler on a separate server is not an option and for my : use case Solr will be used in a lightweight so there is plenty of CPU / RAM : on this one server to host Solr and my crawler. no one ever suggested you had to deploy to a completley seperate server -- but attempting to hook into the jetty powering Solr isn't supported by Solr, will almost certainly cause you problems down the road when you upgrade, and aparently isn't what you want anyway (since you don't want to be in the same JVM as solr). FWIW: I have built lots of small, lightweight, webapps that i built for exactly the same purpose you described deployed to isolated tomcat or jetty containers running on the same machines as seperate containers running Solr (even back when solr was shipped war and could be deployed to any servlet container) for the precise reason that i wanted ot manage the JVMs resources independently, and i had the added bonus of being able to better scale my deployment in the long run (by reloacating apps on diff boxes and changing host aliases) ... zero problems. -Hoss http://www.lucidworks.com/
