Ok, sounds good. We should probably disable keep_source in this case, to
stop people accidentally deleting their original source :) I'll commit
the patch to the snapshot plugin.
Standalone mode is intended to mean the webapp is not influenced by
outside factors, such as a JRuby home and gems installed on the same
machine. This is in contrast with shared mode, which is intended to make
use of a common set of libraries. A global environment variable override
for standalone mode seems to go against this.
However, for running Jetty from rake, it's certainly appropriate to
expect an environment variable to take precedence. Perhaps we could use
Jetty's mechanism for overriding web.xml values (I assume it has one),
to set a more suitable value for rails.env (e.g. RAILS_ENV || development).
Cheers,
Robert
Jeffrey Damick wrote:
Thanks for the response,
I think I see what you mean, the 'add_webxml' method checks for
web.xml in WEB-INF relative to the project.. The real issue I was
trying to resolve is the fact that standalone mode copies the project
tree to /tmp/war/... This is not very productive for quickly making
changes and re-launching if you have a project of like 300+ megs then
this is pretty time consuming.. I'd really like to see standalone
mode just use the project out its existing location, so maybe the
'add_webxml' logic could be changed to look somewhere else for a
WEB-INF, config/WEB-INF ? What do you think?
As for the rails.env, I understand the argument for web.xml taking
precedence, but I'm not sure that really makes sense for standalone
mode, and putting it in war.rb or some other file means people have to
change their current behavior of just setting the environment variable
and re-launching mongrel / webrick. Shouldn't the goal be to make the
switch for people ruby/mongrel/webrick to jruby/goldspike as seamless
as possible?
thanks
-jeff
On 5/10/07 12:20 AM, "Robert Egglestone" <[EMAIL PROTECTED]> wrote:
Any files originally in webapp/WEB-INF are included in the
package, especially additional deployment descriptors (e.g.
weblogic.xml and equivalent). If we mix the original files and the
generated files, then there may be some confusion over what came
from where.
webapp specific configuration (web.xml), really should take
precedence over system-level configuration. We could add this as a
fallback if rails.env is not set in web.xml, but I imagine this
may not address what you want. That said, I really don't like the
current situation of defaulting to production mode.
Cheers,
Robert
Jeffrey Damick wrote:
Yeah it seems like it would more efficient to just recursive
copy the top
level directories and then remove the files you need to
exclude later and
then recursive chmod them, since it looks everything is being
set to 0644
anyway..
Another option which is more like mongrel / webrick is to just
run the app
(for war:standalone:run) out of the current prooject directory
and just
create the WEB-INF there, the patch for this is attached
(standalone.patch).
I also added in the standalone patch to use the RAILS_ENV
environment
variable if set rather than hard-code it to production in
war_config.rb.
The rails_env.patch updates the
AbstractRailsServlet.getDeploymentEnvironment to use the
system environment
variable if in standalone mode and it's set rather than the
one in the
web.xml to make it more like mongrel / webrick.
I'd also like to be able to easily change the default
libraries, like the
bcprov-jdk14 since it isn't happy on java 1.5, and I want to
be able to
easily set bcprov-jdk15-136..
thanks,
-jeff
On 5/8/07 4:21 PM, "Nick Sieger" <[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED]> wrote:
On 5/4/07, Jeffrey Damick <[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED]> wrote:
Also the copy process just to run in standalone mode
is extremely long if
you have a large project.. Is anyone taking a look a
this? Maybe I can help
out in this space..
It's the poor speed of File.chmod (via File.install),
which forks for
every file. If you want you can replace File.install
everywhere in
the plugin with File.copy, if you don't need permissions to be
changed. We still need to solve this issue once and for
all, possibly
giving folks an option to turn permissions changing in the
war config.
------------------------------------------------------------------------
_______________________________________________
Jruby-extras-devel mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/jruby-extras-devel
------------------------------------------------------------------------
_______________________________________________
Jruby-extras-devel mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/jruby-extras-devel
------------------------------------------------------------------------
_______________________________________________
Jruby-extras-devel mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/jruby-extras-devel
_______________________________________________
Jruby-extras-devel mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/jruby-extras-devel
