On 02/02/11 23:25, Brett Armstrong wrote: > Hi, > > Let me first explain a little bit about what I am trying to accomplish > with SmartFrog. > > I am creating a distributed test automation system for my company. I > have a main server that hosts our website and a bunch of slave > computers that run our tests. My intent is to run the SF Daemon on the > main server with components that monitor the entire system and > distribute jobs from a queue to SF daemons running on the slave > machines. The website is very basic and acts as a front end for users > to submit jobs to the queue and display information about the current > state of the system (what is in the queue, are any machines down).
OK. There's some past work on gridunit you should have a look at for how they've managed and presented tests run on large sets of machines, with the key point being its the tests that only fail on some machines that are the most interesting/hard to track down. > > However, I cannot figure out how to get jobs into the queue from the > website or get the status of the queue out to the website. My initial > thought is to have the website call a command line program (that is > not SF component) that will resolve references to all the components I > need so I can call methods on them. Is this the preferred method for > passing data to the SF system at runtime? Should I use a different > approach entirely? If this is the proper approach, how can I resolve > these components? You can directly access SF components via RMI from your web application, both to deploy things or to manipulate and query them. You just need to make sure that the JAR files at both ends are synchronized, and if you are running with security turned on (recommended), that the machines trust each other. Look at core/testharness/src/org/smartfrog/test/SmartFrogTestBase.java For examples of how to deploy and query different processes from JUnit test cases; the same approach will work from a web application. Now, if you deploy your web application using SmartFrog and Jetty, running it in a SmartFrog daemon, your life is even easier, as you can call SFProcess.getProcessCompound() and get the SF compound that is the base container for all components running in the current process, and work from there. In the very forthcoming 3.18.008 release, you can also get a reference to the specific Jetty instance into which a servlet is deployed, from the servlet itself, by way of the org.smartfrog.services.jetty.contexts.delegates.DelegateHelper class and its static method retrieveOwner(ServletContext ctx) . What we are doing now with Jetty is attaching an RMI reference to the owner in every servlet context, so you can grab it then resolve any references from there. This is very handy and I'm using it resolve references from my web application to the SF components that are doing the heavy lifting underneath. -steve ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Smartfrog-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/smartfrog-users
