<added jruby-devel list back in> Whew, quite a mouthful. It looks like you are right...BSF does not lend itself to configurability. Your engine better work out of the box or you're screwed, since there's no way to pass alternate configuration to it.
But then again, we must have a way to deploy JRuby in a setting where Gems and friends can install libraries as expected. This necessitates haveing jruby.home set to something so that lib, bin, etc paths are available. Now to ramble a bit myself. If we were going to see JRuby used in a typical Java-like deployment, what would Rails and friends look like? I think we can rule out the possibility of keeping them loose on the filesystem as with stock Ruby, because that not only defeats the benefits of deploying JRuby in an app server but it would probably be wholely disallowed by many security configurations. So what then? Maybe what we're looking at is that JRuby needs to be run in a "loose" configuration for Ruby apps, and perhaps later bundled up into a deployable jar that simulates the runtime environment. After gems install and so on, we ought to be able to jar up the entire customized distro for a given target, Rails and all. So once you've got your setup sufficiently customized, you run one more ant target to bundle the lot and you have a complete working "Ruby environment" snapshot, much like you'd have after going through typical install tasks on a server where Ruby is in a read-only location. It may also prove true that BSF-style applications are usually independent of Ruby-style applications, wherein you are unlikely to use both BSF and Ruby apps as entry points into. So some possible scenarios: 1. BSF-based app run from command line - jruby.home must be set, either by our script or by the user's 2. BSF-based app run within controlled environment - jruby.home must be acceptable as read-only, i.e. default to a jar-based jruby.home of some kind 3. Ruby-style app run from command line - again, jruby.home must be provided, and makes sense 4. Ruby-style app run within controlled environment - jruby.home is again a pointer to some jar-like path, expected to be read-only since it will be deployed to a server So perhaps it make sense to default to a read-only jruby.home (or at least libdir and friends) and only provide an external jruby.home if one is passed in via the Ruby object constructor or from system properties. A heuristic for searching these locations would probably be fairly simple. I'm not sure we can please everyone all the time, but I'm not sure we'll have to. - Charlie On 1/24/06, Thomas E Enebo <[EMAIL PROTECTED]> wrote: > On Tue, 24 Jan 2006, Charles O Nutter defenestrated me: > > > > Perhaps this is something that should be passed into the runtime when > > it's created, so we can specify it as being a jar URL or other > > location when run within, for example, a servlet engine? It would seem > > to make sense as a configurable property passed into Ruby.new() on a > > per-instance basis, rather than setting it as a system-wide property. > > Yeah global would be bad long-term since two packages both embedding > JRuby would get the changes (HEH-- funny scenario). > > If I have a servlet which communicates to JRuby via BSF. How should > we supply extra paths? There appears to be no way of providing language > config info via BSF. > > This leads to two seperate mechanisms (for BSF -- goal one below): > 1. Set a value in some totally non-jruby (like a system property). > 2. Make BSF users to eval a script which includes the directory via Ruby code. > > Number 2 is ok...Number 1 only adds value if we want that as a general > decoupled way of setting additional paths with the drawback of being > global. > > For my other goal (goal two below): > 1. Set a value in some totally non-jruby (like a system property). > 2. Ruby.getLoadService.init currently sets initial load path (how -I works) > > Number 2 is already ok. Number 1 also sort of happens today by virtue > of being used as a prefix for system paths. I am killing this prefix. > > Of original goals 2a is not supportable with number 2 by itself. > > The other interesting thing coming out of this thread is the ability > to differentiate a jar (classpath-based) load path entry from a filesystem > load path entry. Do we want this abliity? > > Finally, jruby.home is used to set constants for rbconfig library. > The purpose of these variables are largely for creating extensions > and installing new modules. However, we have our modules in an > uninstallable location. This is an interesting dilemma since we do want > things like gems to work. That means we need an external dir for them > to install. So we still need something like jruby.home to exist. > In fact, I am guessing as a normal install a jruby.home should be > specified by -D options, but internally we should capture it as a > config option (via Ruby or something similiar). Then we can override > it progmatically if need be. We do need a home dir for external stuff: > bin (for callouts to run additional jruby runtimes) and lib > (for gems). Embedders likely do not want this. So unsetting a home > config option should make things unavailable.... > > Enough rambling. > > -Tom > > > Naturally when using Main, we'd use the env var or something. > > > > > > > > Goals: > > > 1. with nothing (e.g. JRUBY_HOME) set, all internal jar versions of files > > > should be found regardless of how jruby is invoked (BSF, command-line, > > > etc...) > > > 2. With something set external files should be searched to: > > > a. be override of jar files (good for debugging) > > > b. be supplelement to jar files (also where gems would load from) > > > > > > Both of these things should likely be something like a system property > > > since in BSF we have no way of directly updating the config class. > > -- > + http://www.tc.umn.edu/~enebo +---- mailto:[EMAIL PROTECTED] ----+ > | Thomas E Enebo, Protagonist | "Luck favors the prepared | > | | mind." -Louis Pasteur | > ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ Jruby-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jruby-devel
