Should have mentioned, this extra ::Rails::Initializer.run somehow was causing LOAD_PATH not laoding correctly form environment.rb.
-vivek. On Tue, Apr 7, 2009 at 9:37 PM, Vivek Pandey <vivek.pan...@gmail.com> wrote: > Found the bug. Thanks to Damian, who pointed to the extra initialization > happening inside our rack code. I just applied the fix and tested to find it > working. This should go in to the next gem release. > > -vivek. > > [1] > http://rubyforge.org/tracker/?func=detail&atid=21080&aid=25253&group_id=5450 > > > On Wed, Apr 1, 2009 at 3:30 PM, Charles Oliver Nutter < > charles.nut...@sun.com> wrote: > >> Hmm, strange. I guess I'm out of ideas, but I can definitely see that >> those added entries aren't making it to runtime... >> >> - Charlie >> >> Vivek Pandey wrote: >> >>> both gem as well as standalone v3 server have exactly the same path. It >>> is not like it work in either one anyway. >>> >>> -vivek. >>> >>> On Fri, Mar 27, 2009 at 4:08 PM, Jacob Kessler >>> <jacob.kess...@sun.com<mailto: >>> jacob.kess...@sun.com>> wrote: >>> >>> I'm a bit fuzzy on gem vs. stand-alone startup, but I don't think >>> that that is relevant here (since I see the same behavior in >>> stand-alone. >>> >>> In Stand-alone, we create a new runtime (using >>> JavaEmbedUtils.initialize after setting some very basic parameters), >>> use loadservice.require to bring in config/environment.rb, and our >>> rack handler, then call call(env) on whatever rails hands to our >>> rack handler. We tried to stay as hands-off with the Ruby codes as >>> possible, to try to avoid weird things like this. >>> >>> >>> Charles Oliver Nutter wrote: >>> >>> Charles Oliver Nutter wrote: >>> >>> Jacob Kessler wrote: >>> >>> In the second (non-working) case, of Glassfish Gem, >>> RAILS_ROOT/app/models/subfo ends up in >>> config.load_paths, the same as with mongrel. $LOAD_PATH >>> is slightly different, but it looks like it's mostly >>> related to not having loaded mongrel. However, when >>> rails needs to load post.rb, it fails with a NameError >>> rather than loading the file. >>> >>> >>> This seems to be a problem not directly related to loading. >>> The load process there is trying to load a file in order to >>> define a constant that does not exist. It seems like it's >>> successfully loading the file, but not producing the >>> constant needed. >>> >>> >>> After some exploration, it appears that the load_path change in >>> environment.rb is getting clobbered at some point after it >>> loads. I've traced through the dependencies.rb handling of >>> const_missing, and it fails to locate the file because by that >>> point the config.load_path does not have the added path anymore. >>> >>> Can you describe the sequence of events that happen during GF >>> gem load time? I suspect they're different than script/server, >>> and as a result the load path change is disappearing. >>> >>> - Charlie >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this list, please visit: >>> >>> http://xircles.codehaus.org/manage_email >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this list, please visit: >>> >>> http://xircles.codehaus.org/manage_email >>> >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> >
