yes I think we need to show the netboot thing. It is under most people's radar.
What I would like to do is "adopt a rabbit" directly from our website. So they download a small jar (the boot stuff and empty directory structure) and then we configure *the smalles server possible* I am thinking ONE mbean (at's it). That mbean is the rabbit, all it does is land on your machine (the rabbit has landed!) and call a webservice on JBoss that uploads the machine data (OS, VM, whatever we can get from the System info). This way we should show the power of the "easy" install. There is still this perception out there (well from our competitors in MS camp really) that "open source" means complex and I want to show that it is not the case *at all* with this simple example. Now that you have gotten the http stuff working, do you want to take this "dog and pony" demo for the website. Fame and glory await you, this is a powerful demo, fame and glory marcf |-----Original Message----- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Jason |Dillon |Sent: Monday, March 04, 2002 8:28 PM |To: [EMAIL PROTECTED] |Subject: Re: RE: [JBoss-dev] |org.jboss.deployment.scanner.DeploymentScanner | | |Aside from some small logging issues as well as some configuration |changes, the server as is will run from an http:// url (perhaps |even other protocols, though I have not tested that). | |With only bin/run.sh and bin/run.jar, I was able to run a modified |'default' server configuration. | |The changes were only to replace archives="*" with qualified file |names and to explicitly list out the delpoyment URLs. | |There is a small issue with the JCA/hsql stuff as mentioned |before, but since you have to explicitly list those depends for |the URLDeploymentScanner, just list them in the right order. | |The only other problem that I have run into is that I currently |have to hard code URLs for deployment, as the current impl makes |non-absolute paths reletive to jboss.server.home.dir. Could |probably change this to jboss.server.home.url, which will do the |right thing. | |I still believe we should allow for property subst here so that |user's don't have to guess which base their relative path will |resolve to... but since the xml configuration handling is not |abstracted from the components which use the config, it is not |simple to add this with out duplicating code. | |There is still a need for an "earth bound file system" as you call |it, specifically for the current config, a local tmp, log and db |directory are needed. I have fixed up the bits that use these to |create the directory on demand, so we don't have to artificially |add these to the release archive. | |I image that most of these local dirs could be detached using |some sort of file system abstraction, but I don't know what the |best solution is for that at the moment, so I am gonna leave it |until there is more demand for a filesystem-less jboss instance. |I think it is possible, but will require some effort to make it happen. | |* * * | |I think we might want to setup a simple netboot configuration to |include with the release which has the basic components |configured, to show users how they need to be explicit with |classpath archives and deployment urls. | |Possibly change the default prefix for codebase to |jboss.server.home.url and change the default "lib" to "../../lib" |until a simple aproache to adding property support works itself out. | |--jason | |_________________________________________________________ |View thread online: http://main.jboss.org/thread.jsp?forum=66&thread=9980 | |_______________________________________________ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
