"[EMAIL PROTECTED]" wrote : Elaborating on the last alternative: | | Yes, and to relieve the WebApp from the persistence burden the DeploymentService could be enhanced to "remember" the properties of a module it has produced. So then it'd be very easy to "edit" any deployment created through the console. | So we would just add a method to the DeploymentService, say getCurrentProperties, which takes a module name and returns a Map of property names and values? The DeploymentService would have stored this Map somewhere when the module was first created?
"[EMAIL PROTECTED]" wrote : Trying also to see how to best package things, we could seperate the deployments that can be modified by the console, by making it copy stuff to a subdirectory of deploy e.g: | | ./deploy | ./deploy/console | | or if we want to have a full seperation of the console related stuff, we could have: | | ./console/ | - ./templates | - ./deploy | - ./undeploy | - ./properties | | and simply point URLDeploymentScanner to both: | | ./deploy | ./console/deploy | I like the idea of keeping all the deployments rooted under ./deploy, i.e. the first suggestion. That way people don't have to remember another directory structure in which to look for deployments. The other DeploymentService working directories could then just go under ./console as you described. "[EMAIL PROTECTED]" wrote : | A problem I see in general with the console is the dependency to tomcat, since the console is a webapp itself. Will tomcat be under control of the console? If tomcat is redeployed what happens to the console webapp? | Great question! Tomcat is meant to be one of the services which the Admin Console manages. Clearly the approach of using the DeploymentService to update the instance of Tomcat underlying the Admin Console is not feasible. [The Admin Console would ask the DeploymentService to create a new Tomcat configuration and copy it over the existing one, this would have the effect of undeploying/deploying Tomcat, thus killing the Admin Console]. At best maybe we could aim for *any* change to Tomcat requiring a server restart? But then we need a mechanism to support some sort of "delayed" deployment, i.e. create a new Tomcat configuration but only deploy it when the server restarts, when we can be sure no-one is connected to the Admin Console. Thanks Charles View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3862585#3862585 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3862585 ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
