Setting run.mode on Stax / within WAR

[Stuart Roebuck]

How do you set the run.mode of a web app if you don't have access to
the machine to set run.mode, nor the launch command to add the option -
Drun.mode=production ?

Is it something you set in the web.xml file? or is there another way?

I'm deploying on Stax right now and don't know how to get it to run in
production mode.

Apologies, I have a feeling that this is something I should already
know! :-)

Stuart.

[Richard Dallaway]

This doesn't directly answer anything, but I was under the impression
that if you deployed a packaged war file to an app server the default
run mode was "production" (unlike running mvn jetty:run)

But now I'm going to have to go and quickly check a couple of prod
sites.... :-/ :-)

> --
> You received this message because you are subscribed to the Google Groups "Lift" group.
> To post to this group, send email to lif...@googlegroups.com.
> To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
>
>

[Stuart Roebuck]

Yes, I had that thought in my head too, but then I couldn't find a
text to confirm it so I wondered if I'd made it up!

Just in case it's relevant, I'm running the latest Lift Scala 2.8
snapshot and uploading to Stax with the sbt stax plugin which uploads
it as a WAR (I think!).

Stuart.

[Timothy Perrett]

No, its not the default: you must set it.

Cheers, Tim

[Stuart Roebuck]

Tim... okay, but how?

Is there a properties file I can set it in? I thought the properties
file loading was dependent upon the run mode? Or can I somehow set it
in the web.xml file?

Richard, on reflection I think my assumption about being in production
(deploy) mode if in a WAR file comes from Grails. It does seem to
make some sense to provide the security of knowing that the system
will default to production (deploy) mode unless you specify otherwise
as it is much less of an issue to accidentally run production mode on
a local machine and discover it because it doesn't behave as you
expect vs. running in development mode on a production machine and not
noticing that it is spewing out log files and running from jetty
rather than the intended database.

Stuart.

On Mar 26, 9:43 am, Timothy Perrett <timo...@getintheloop.eu> wrote:
> No, its not the default: you must set it.
>
> Cheers, Tim
>
> On 26 Mar 2010, at 09:31, Richard Dallaway wrote:
>
>
>
> > This doesn't directly answer anything, but I was under the impression
> > that if you deployed a packaged war file to an app server the default
> > run mode was "production" (unlike running mvn jetty:run)
>
> > But now I'm going to have to go and quickly  check a couple of prod
> > sites.... :-/ :-)
>

> > On Friday, March 26, 2010, Stuart Roebuck <stuart.roeb...@gmail.com> wrote:
> >> How do you set the run.mode of a web app if you don't have access to
> >> the machine to set run.mode, nor the launch command to add the option -
> >> Drun.mode=production ?
>
> >> Is it something you set in the web.xml file? or is there another way?
>
> >> I'm deploying on Stax right now and don't know how to get it to run in
> >> production mode.
>
> >> Apologies, I have a feeling that this is something I should already
> >> know! :-)
>
> >> Stuart.
>
> >> --
> >> You received this message because you are subscribed to the Google Groups "Lift" group.
> >> To post to this group, send email to lif...@googlegroups.com.
> >> To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.

> >> For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en.

[Richard Dallaway]

On Fri, Mar 26, 2010 at 9:54 AM, Stuart Roebuck
<stuart....@gmail.com> wrote:
> Richard, on reflection I think my assumption about being in production
> (deploy) mode if in a WAR file comes from Grails.

Ah, possibly, yes, that's maybe where it leaked into my brain too.
I've checked, and on the production sites we have explicitly set the
run mode as we have control over the -D flags where we run.

> It does seem to
> make some sense to provide the security of knowing that the system
> will default to production (deploy) mode unless you specify otherwise

Indeed, but I'd been keen to keep the default when you run locally in
dev mode :-/ Although, at a push, I guess more people have control
over their local environment than their prod environment... but having
to "do something" when you're starting with Lift to get development
mode seems sort of wrong.

Tricky.

If there's not a way to set it, then perhaps (in the future) the run
mode could be read from the props file. That might be a reasonable
solution, as you can keep the default as it is, keep the System
property, but if it's not set fall back to knowing a
production.default.props will take care of the deployment difference.
Maybe.

And thanks, Tim, for quickly fixing up my mis-information.

Richard

[Richard Dallaway]

On Fri, Mar 26, 2010 at 10:10 AM, Richard Dallaway <dall...@gmail.com> wrote:
> If there's not a way to set it, then perhaps (in the future) the run
> mode could be read from the props file.

It's OK: I see a bit of a problem with that. Need to find some other route :-)

Richard

[Timothy Perrett]

Nice - glad to see people using my plugin!

Moreover, if you are using stax, then the default deploy mode is development. Usually it would be set with a -D paramater but in this instance you are unable to. Im sure there is a way of doing it... lemme just check the code

Cheers, Tim

[Jeppe Nejsum Madsen]

On Fri, Mar 26, 2010 at 11:14 AM, Timothy Perrett
<tim...@getintheloop.eu> wrote:
> Nice - glad to see people using my plugin!
>
> Moreover, if you are using stax, then the default deploy mode is development. Usually it would be set with a -D paramater but in this instance you are unable to. Im sure there is a way of doing it... lemme just check the code

To the best of my knowledge, there isn't. There was some talk about
allowing it to be set from servlet init parameters, but afaik this is
not done....

/Jeppe

[Richard Dallaway]

Would it be an option to pull a setting from the servlet context
parameters? Looks like you can set Stax-specific values via
http://wiki.stax.net/w/index.php/Stax-web.xml

[Timothy Perrett]

OK, so this is the solution:

Create this class in bootstrip.liftweb.EnviromentFilter:

package bootstrap {
package liftweb {

import _root_.javax.servlet._
import _root_.javax.servlet.http._

class EnviromentFilter extends Filter {
System.setProperty("run.mode", "production");
// some boiler plate methods we need to implement
def init(config: FilterConfig){}
def destroy {}
def doFilter(req: ServletRequest, res: ServletResponse, chain: FilterChain){}
}

}}

Then, in your web.xml put:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<filter>
<filter-name>EnviromentFilter</filter-name>
<display-name>Enviroment handler</display-name>
<description>The Filter that sets properties before lift loads</description>
<filter-class>bootstrap.liftweb.EnviromentFilter</filter-class>
</filter>
<filter>
<filter-name>LiftFilter</filter-name>
<display-name>Lift Filter</display-name>
<description>The Filter that intercepts lift calls</description>
<filter-class>net.liftweb.http.LiftFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>LiftFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
</web-app>

This will set the run mode for your WAR. Its not overly pretty, but when you dont have -D access its the best solution I can give you ;-)

BTW, this works with stax as i just tried it.

Cheers, Tim

[Jeppe Nejsum Madsen]

Do you get your own JVM on Stax? If not aren't you changing the
settings for the entire JVM?

I guess you do get your own JVM, otherwise the System.setProperty
would not be allowed (or the Stax guys have a security problem :-)

Btw, we've talked about this before:
http://groups.google.com/group/liftweb/browse_frm/thread/e870a13b7051a297/f19f20669c4d0102

/Jeppe

[Stuart Roebuck]

Great and thanks!

Solutions have such a habit of being simple when someone else thought
of them! :-)

Stuart

[Timothy Perrett]

LOL! yeah it would be a fail if you didn't get your own JVM. You do
tho, so don't worry.

I actually checked back to that convo Jeppe as I too remembered it and
thought you had implemented that calc rule... but as the thread say
its not workable unfortunately. This is a decent enough work around
though.

Cheers, Tim

On Mar 26, 10:39 am, Jeppe Nejsum Madsen <je...@ingolfs.dk> wrote:
> Do you get your own JVM on Stax? If not aren't you changing the
> settings for the entire JVM?
>
> I guess you do get your own JVM, otherwise the System.setProperty
> would not be allowed (or the Stax guys have a security problem :-)
>

> Btw, we've talked about this before:http://groups.google.com/group/liftweb/browse_frm/thread/e870a13b7051...

> >> For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en.

[Timothy Perrett]

Possibly, but I don't think so - if memory serves the property would have already been created by the time the context is initialised.

Cheers, Tim

[Timothy Perrett]

In fact, here is a slightly cleaner solution:

in src/main/scala/bootstrap/liftweb/StaxLiftFilter.scala:

package bootstrap {
package liftweb {

import _root_.net.liftweb.http.LiftFilter
import _root_.javax.servlet._
import _root_.javax.servlet.http._

class StaxLiftFilter extends LiftFilter {
override def init(config: FilterConfig){

System.setProperty("run.mode", "production")

super.init(config)
}
}

}}

In my web.xml

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web
Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<filter>

<filter-name>LiftFilter</filter-name>
<display-name>Lift Filter</display-name>
<description>The Filter that intercepts lift calls</description>

<filter-class>bootstrap.liftweb.StaxLiftFilter</filter-class>

</filter>
<filter-mapping>
<filter-name>LiftFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
</web-app>

This negates the need for a second filter :-)

Cheers, Tim

On Mar 26, 10:47 am, Timothy Perrett <timo...@getintheloop.eu> wrote:
> Possibly, but I don't think so - if memory serves the property would have already been created by the time the context is initialised.
>
> Cheers, Tim
>
> On 26 Mar 2010, at 10:29, Richard Dallaway wrote:
>
>
>
> > Would it be an option to pull a setting from the servlet context
> > parameters?  Looks like you can set Stax-specific values via
> >http://wiki.stax.net/w/index.php/Stax-web.xml
>
> > On Fri, Mar 26, 2010 at 10:14 AM, Timothy Perrett
> > <timo...@getintheloop.eu> wrote:
> >> Nice - glad to see people using my plugin!
>
> >> Moreover, if you are using stax, then the default deploy mode is development. Usually it would be set with a -D paramater but in this instance you are unable to. Im sure there is a way of doing it... lemme just check the code
>
> >> Cheers, Tim
>
> >> On 26 Mar 2010, at 09:43, Stuart Roebuck wrote:
>
> >>> Just in case it's relevant, I'm running the latest Lift Scala 2.8
> >>> snapshot and uploading to Stax with the sbt stax plugin which uploads
> >>> it as a WAR (I think!).
>
> >> --
> >> You received this message because you are subscribed to the Google Groups "Lift" group.
> >> To post to this group, send email to lif...@googlegroups.com.
> >> To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.

> >> For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en.