FYI, can anyone on this list respond to dave? Begin forwarded message: > Hi Heiko, > > I've been following various discussions about the deployment scanner > and the content repository for a while, and it doesn't seem like > there's a clear answer. What do you think about it? > > I've seen people asking on Stack Overflow whether they are safe to use > both deployment methods, and I know that I've laid some foundations to > the docs by suggesting that the scanner is a developer tool, and not > for production. This surprised some of our consulting team recently, > who suggested that customers will use the scanner for app deployments > in a production environment. > > Do you have any thoughts on this? > > Dave _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

There's nothing not production-worthy about using the deployment scanner and our docs shouldn't imply it's not ready for production use. What the scanner is is a task that periodically runs and monitors a filesystem dir for changes. When it detects changes it invokes operations against the server management API to trigger content upload and deployment. It invokes the same operations that can be invoked quite directly via the CLI or a bit less directly with a GUI via the console. The CLI can be used to accomplish the same thing, and with the advantage that the operation is synchronous -- the command is invoked and the result is known when the command returns. The command can be executed by a human and the result read, or it can be scripted with the script checking the result. Contrast this with copying a file into the deployments dir, waiting some semi-random period of time until the next scanner run, and then trying to figure out what happened from looking at logs or the marker files in the deployments/ dir. In short, using the scanner can be more convenient and has less of a learning curve, since copying a file to a dir is trivial for anyone, while using the CLI makes it easy to have greater control. Typically the "convenience and low learning curve" aspect is more important in a developer environment, but that doesn't mean people won't prefer the scanner in a production environment. An important thing to realize with the scanner though is if you use the scanner, your API for managing those deployments becomes the OS's filesystem API. Users shouldn't try to then manipulate the deployments via the CLI or console. The web console isn't going to let you update or remove the deployments -- you need to manipulate the deployments/ dir. On 4/23/12 1:28 AM, Heiko Braun wrote: > > FYI, can anyone on this list respond to dave? > > > Begin forwarded message: > >> Hi Heiko, >> >> I've been following various discussions about the deployment scanner >> and the content repository for a while, and it doesn't seem like >> there's a clear answer. What do you think about it? >> >> I've seen people asking on Stack Overflow whether they are safe to use >> both deployment methods, and I know that I've laid some foundations to >> the docs by suggesting that the scanner is a developer tool, and not >> for production. This surprised some of our consulting team recently, >> who suggested that customers will use the scanner for app deployments >> in a production environment. >> >> Do you have any thoughts on this? >> >> Dave > > > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev -- Brian Stansberry Principal Software Engineer JBoss by Red Hat _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

> Another factor is that we recommend that the scanner be turned off in the performance tuning guide (unnecessary cycles spent polling things that don't change) This just disable deployment at runtime, correct ? At startup the directory is still scanned making file copying approach still viable for those that prefer that option. /max _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev