On Tue, 24 Jan 2006, Charles O Nutter defenestrated me: > <added jruby-devel list back in> > Whew, quite a mouthful. > > 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.
For people who embed using ant makes sense as a scenario for repackaging. We don't even need an additional rule for this. We can just add an additional project root subdir into the the serialize/jar targets. For example, if 'extras' is the special dir then they can put the new packages there and type 'ant'...jruby.jar now contains those new packages without making CVS say you have possible new modules to commit. OTOH, if you are deploying to a web-app (using ROR) you probably could add some relative load path which grabs those files from WEB-INF/*. Doing a web-app in java neccesitates having a build process to deploy. JRuby will not provide that. I do not know enough about how RoR would fit into a web container to know about possible scenarios. One would be the live container scenario where you can copy new files in an exploded web-app and the changes happen live without bouncing tomcat/your-web-container-here. For people who don't embed then they will basically install the unzip'd binary distro into a directory. Those people will not use ant. When they install a package it should work identically to ruby (except pre-packaged modules will be in jar and not lib). For people who use JRuby to embed in a web app and dynamically install packages in a deployed dir via gems....Hardly a best practice? > 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. Scenario 1 is not really a concern...It is an embedded app they can do an eval to load the libraries they need. jruby.home is not a requirement (unless they plan on doing anything with what is in rbconfig. Same with 2. If they want to have a bizarre config and set jruby.home outside the container, then that is there rope to hang with. Scenario 3. yep makes sense Scenario 4. makes sense. Though again we should let them set whatever dir they want (including any external). So it sounds like we should add the ability to specify a "classpath-only" directory specifier so we can allow people to set up these embedded environments better. > I'm not sure we can please everyone all the time, but I'm not sure > we'll have to. Yep...Garden party -Tom > > 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 | > > -- + 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&kid=103432&bid=230486&dat=121642 _______________________________________________ Jruby-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jruby-devel
