On 2002.03.04 23:28:17 -0500 Jason Dillon wrote: > 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 wonder... db is needed for what? log is dependent on your using a file appender for log4j our tmp dir might be unnecessary given url deployment. The main reason we copy stuff explicitly is for the "can't delete or change an opened jar" bug. jar already makes a local (hidden) copy of any remote url it opens, njar takes this one step further. So we might be able to leave out the local copy step when deploying urls rather than files. david jencks > > 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
