One file deploy(including jetty)

[Maarten Koopmans]

Does anybody ever manage to bundle jetty6, it's configs and your
(root.)war file in one standalone jar?

Seems like an ultimate deployment in some cases (e.g. to 3rd party sysadmins).

Anybody ever done that, or have pointers on how to....?

--Maarten

[Maarten Koopmans]

Forgot to mention: I was thinking of using jetty-runner, unpack that
and my war file, and bundle it again as one jar. Not sure that will
work though.

On Tuesday, February 22, 2011, Maarten Koopmans

[David Pollak]

On Tue, Feb 22, 2011 at 5:34 AM, Maarten Koopmans <maarten....@gmail.com> wrote:

Forgot to mention: I was thinking of using jetty-runner, unpack that
and my war file, and bundle it again as one jar. Not sure that will
work though.

I've heard tell that this is how Foursquare packages/deploys.
 

On Tuesday, February 22, 2011, Maarten Koopmans

<maarten....@gmail.com> wrote:
>  Does anybody ever manage to bundle jetty6, it's configs and your
> (root.)war file in one standalone jar?
>
> Seems like an ultimate deployment in some cases (e.g. to 3rd party sysadmins).
>
> Anybody ever done that, or have pointers on how to....?
>
> --Maarten
>

--
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.

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im
Surf the harmonics

[Maarten Koopmans]

On Tue, Feb 22, 2011 at 3:03 PM, David Pollak <feeder.of...@gmail.com> wrote:

On Tue, Feb 22, 2011 at 5:34 AM, Maarten Koopmans <maarten....@gmail.com> wrote:

Forgot to mention: I was thinking of using jetty-runner, unpack that
and my war file, and bundle it again as one jar. Not sure that will
work though.

I've heard tell that this is how Foursquare packages/deploys.

Good, then the next step would be to see of an AOT like Excelsior JET would add performance benefits (I do a lot of large file processing with compression an encryption).

--Maarten

[Timothy Perrett]

Yup, this is exactly what I do. Works great and have had next to no problems. Was a complete nightmare to setup in the first instance as it requires a very specific balance of class embedding (due to conflicting dependencies). The bonus is that I can package it completely standalone and not have any other headaches to worry about; do it once and just replicate it. 

FYI, I use Shade for the embedding and it works great; you just have to get the right mix of dependencies. As I run on windows this meant I had to contend with some other win specific stuff, which affected my config but yes, shading the JAR will give you the most stable type of uber jar.

http://maven.apache.org/plugins/maven-shade-plugin/

I've not used Jetty runner, but apparently it works well. 

Cheers, Tim

[David Bernard]

for maven user : http://simplericity.com/2009/11/10/1257880778509.html

--

[David Pollak]

My experience with HotSpot running on 64 bit machines in server mode is that it is significantly faster once warmed up than AOT compilers.  This is likely to be true with Scala where a lot of the call paths are monomorphic and thus HotSpot can optimize/inline them very, very well.
 

--Maarten

--
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.

[Maarten Koopmans]

Hm, and something along these lines might work as well:

https://github.com/scalatra/scalatra/wiki/How-to-deploy-a-Scalatra-app-as-a-single,-executable-JAR

(I use the assembly plugin in another SBT project with great success). I'd "just" need to hook up the LiftFilter etc (?) to an object.

[Maarten Koopmans]

I think I'm going to give it a shot with the SBT assembly plugin and a custom object that adds the Lift filter the next few days. Any things to keep in mind when doing embedded Jetty with a Lift Filter?

--Maarten

--

[Maarten Koopmans]

My experience with HotSpot running on 64 bit machines in server mode is that it is significantly faster once warmed up than AOT compilers.  This is likely to be true with Scala where a lot of the call paths are monomorphic and thus HotSpot can optimize/inline them very, very well.

That's why I am evaluating :-) On EC2, it might be worth a lot of small 32 bit (the AOT is 32 bit only, sadly), vs one 64 bit larger instance.

[Timothy Perrett]

Its actually nothing to do with LiftFilter, you'll need a jetty loader inside the JAR, thats the main thing (plenty of examples online); they loader could either be a home-baked class or if jetty7, use jetty-runner and just point it at your WAR file. 

[Maarten Koopmans]

[Maarten Koopmans]

Wait the loader would do something like this, right:

package com.example   // remember this package in the sbt project definition
import org.mortbay.jetty.Server
import org.mortbay.jetty.servlet.{Context, ServletHolder}
import org.scalatra.TemplateExample  // this is the example Scalatra servlet

object JettyLauncher {  // this is my entry object as specified in sbt project definition
   def main(args: Array[String]) {
     val server = new Server(8080)
     val root   = new Context(server, "/", Context.SESSIONS)
     root.addServlet(new ServletHolder(new TemplateExample), "/*")
     server.start()
     server.join()
   }
}

root.addServlet(new ServletHolder(new TemplateExample), "/*")

...would be the line where Lift comes in, but I thought I read Lift was a filter. Anyway, worth finding out :-) 

Imagine a SBT project file where you could just type 'sbt assembly' and then pass whatever you have around!

--Maarten

[Nolan Darilek]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

There's also this blog post on making executable wars:

http://eclipsesource.com/blogs/2009/10/02/executable-wars-with-jetty/

Note that I haven't tried this. I was just amazed at how easy it was to
deploy Hudson and wondered how difficult it'd be to produce
similarly-packaged apps. I'm guessing that a bit of wiring in Boot.scala
and SBT's package action should do it--that and command line parsing for
the port and other values.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1j1RMACgkQIaMjFWMehWI7BQCbBaTtPczG/xMJHEWmGZyx4EG9
t1gAmgMwUg0x/yqhFWmiXKgjeIXM3l/y
=W8pj
-----END PGP SIGNATURE-----

[Indrajit Raychaudhuri]

David Bernard wrote:
> see RunWebApp in any Lift archetype

+1 This is what we do in our existing project :)

- Indrajit

>> <tim...@getintheloop.eu <mailto:tim...@getintheloop.eu>>

>> wrote:
>>
>> Yup, this is exactly what I do. Works great and have
>> had next to no problems. Was a complete nightmare to
>> setup in the first instance as it requires a very
>> specific balance of class embedding (due to
>> conflicting dependencies). The bonus is that I can
>> package it completely standalone and not have any
>> other headaches to worry about; do it once and just
>> replicate it.
>>
>> FYI, I use Shade for the embedding and it works great;
>> you just have to get the right mix of dependencies. As
>> I run on windows this meant I had to contend with some
>> other win specific stuff, which affected my config but
>> yes, shading the JAR will give you the most stable
>> type of uber jar.
>>
>> http://maven.apache.org/plugins/maven-shade-plugin/
>>
>> I've not used Jetty runner, but apparently it works well.
>>
>> Cheers, Tim
>>
>> --
>> 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

>> <mailto:lif...@googlegroups.com>.

>> To unsubscribe from this group, send email to
>> liftweb+u...@googlegroups.com

>> <mailto:liftweb%2Bunsu...@googlegroups.com>.

>> For more options, visit this group at
>> http://groups.google.com/group/liftweb?hl=en.
>>
>>
>
> --
> 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 <mailto:lif...@googlegroups.com>.

> To unsubscribe from this group, send email to
> liftweb+u...@googlegroups.com

> <mailto:liftweb%2Bunsu...@googlegroups.com>.

> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>
>
> --
> 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

> <mailto:lif...@googlegroups.com>.

> To unsubscribe from this group, send email to
> liftweb+u...@googlegroups.com

> <mailto:liftweb%2Bunsu...@googlegroups.com>.

[David Bernard]

see RunWebApp in any Lift archetype

[Indrajit Raychaudhuri]

Hi Maarten,

Maarten Koopmans wrote:
> Wait the loader would do something like this, right:
>
> |package com.example // remember this package in the sbt project definition
> import org.mortbay.jetty.Server
> import org.mortbay.jetty.servlet.{Context, ServletHolder}
> import org.scalatra.TemplateExample // this is the example Scalatra servlet
>
> object JettyLauncher { // this is my entry object as specified in sbt project definition
> def main(args: Array[String]) {
> val server = new Server(8080)
> val root = new Context(server,"/", Context.SESSIONS)
> root.addServlet(new ServletHolder(new TemplateExample),"/*")
> server.start()
> server.join()
> }
> }|
>
> |root.addServlet(new ServletHolder(new TemplateExample),"/*")|
>
> ...would be the line where Lift comes in, but I thought I read Lift was
> a filter. Anyway, worth finding out :-)
>
> Imagine a SBT project file where you could just type 'sbt assembly' and
> then pass whatever you have around!

Please file a ticket and assign this to me. I would attempt to have this
out of the box in 2.3 as part of LiftDefaultWebProject [1].

The idea is to have all the common configuration stuff available to the
applications out of the box by just having this mixed into your project.

- Indrajit

[1]
https://github.com/lift/superbuild/blob/master/sbt/src/main/scala/net/liftweb/sbt/LiftProject.scala#L48

>> lif...@googlegroups.com <mailto:lif...@googlegroups.com>.

>> To unsubscribe from this group, send email to
>> liftweb+u...@googlegroups.com

>> <mailto:liftweb%2Bunsu...@googlegroups.com>.

>> For more options, visit this group at
>> http://groups.google.com/group/liftweb?hl=en.
>>
>>
>
> --
> 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

> <mailto:lif...@googlegroups.com>.

> To unsubscribe from this group, send email to
> liftweb+u...@googlegroups.com

> <mailto:liftweb%2Bunsu...@googlegroups.com>.

[Maarten Koopmans]

Oh, and memory footprint is an issue here as well, of course. Well, simple enough to test!

[Maarten Koopmans]

Done, http://www.assembla.com/spaces/liftweb/tickets/909-one-file-deploy-(including-jetty)

Hope it captures the discussion.

[Glen]

Hi Maarten,


I wrote an sbt-plugin to do this for a couple of personal projects,
its pretty raw but it works well for me, it may help.

https://github.com/glenford/sbt-jetty-embed



Regards,


Glen




On Feb 22, 1:27 pm, Maarten Koopmans <maarten.koopm...@gmail.com>
wrote:

[Maarten Koopmans]

My experience with HotSpot running on 64 bit machines in server mode is that it is significantly faster once warmed up than AOT compilers.  This is likely to be true with Scala where a lot of the call paths are monomorphic and thus HotSpot can optimize/inline them very, very well.

Seems true, especially since the AOT is 32 bit only. Uploading between two servers from curl to my custom WebDAV Daemon (in Scala), roughly doubles the time. Of course, the Hotspot is 64 bit and warmed up. There is a slight but important difference that might make me consider an AOT rout for parts of the application: the availability of the Sun JDK on Linux in the medium-to-long-run.

OpenJDK seems to do worse under concurrent load, suggesting that the thread scheduling is sub-par compared to the AOT and Sun's JDK (which is now Oracle's, so having a native compiler gives me some sort of control... Wit Oracle, you never know).

--Maarten

[David Pollak]

I am interested to see what you come up with.  It might be an interesting alternative for deploying Lift apps.
 

--Maarten

--
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.

[Maarten Koopmans]

I'll report back in this thread within the next week.

On Wednesday, February 23, 2011, David Pollak

[Maarten Koopmans]

OK, I updated Glen's work, but the embedded jars in WEB-INF/libs can't be loaded. If somebody has a good idea, feel free to clone and play while I get some sleep. 

It's at https://github.com/mbk/Lift-standalone

Please that because of the embedded Jars, neither the scala, my commented out Java, or the copied in WebServerStart from Glen will work. The problems seems to be that embedded jar class loading is not possible. 

Note that I opted not to use a plugin but an expanded project file for starters - stripping things out can be done later. Also note that I ported this to Jetty 7.x branch, plain lift template.

If you have time and knowledge, take a look! This is valuable stuff.

--Maarten

[Maarten Koopmans]

https://github.com/mbk/Lift-standalone  ...really need sleep.... but seems to start working!

The output takes a long time to really boot, but as said, it seems to work. Anyone wants to give it a spin and improve upon it? I'll get back on it later.

--Maarten

[Glen]

Hi Marteen,


Well done - I had some issues with the way SBT handled the manifest stuff, as well as some bugs in SBT 0.7.4

If you have no objections I will at some point back port your Jetty-7 stuff into my plug-in, whilst I use it for Lift stuff, I use it in a lot of other webby stuff as well.


Regards,

Glen

[Maarten Koopmans]

OK, cleaned it up, Main web server start now in Scala. Works for an empty project, but fails on a larger one that I tested it. Plus the Jetty console output is a lot - it looks like it unpacks every thing it loads to a temp folder first. Boot time is very slow. 

I'll let it rest for now, hopefully somebody else has an "aha moment". I'll stick with wars for now :-)

--Maarten

[Maarten Koopmans]

Correction, in production mode all runs fine, except Comet actors (against 2.3-M1) in my app. I'll check SNAPSHOT

[Maarten Koopmans]

Nope, Comet breaks for me. All other stuff semms to work fine, but bot time is so long on my McMini (>1 minute). that I'l stick with good old wars. Having said that, if Comet would work for me, once you're past the initial boot all is warmed up and it works like a charm.

[Maarten Koopmans]

Go ahead! I shamelessly built on your stuff, and the assembly plugin.
As Comet support seems to break this way ( at least for me), the next
thing to try is to backport it to the Jetty 6.x branch.

Maybe I'll find some time next week.

--Maarten

[Maarten Koopmans]

https://github.com/mbk/Lift-standalone is now back on Jetty (6.1.26). This one just works, but one my current app it fails with:

"WARN - failed LiftFilter: java.lang.ClassCastException: org.slf4j.impl.Log4jLoggerFactory cannot be cast to ch.qos.logback.classic.LoggerContext"  Any thoughts on that one?

[Timothy Perrett]

You have a broken class path - seems you have both log4j and the he logback classic facade.

Cheers, Tim

[Maarten Koopmans]

In this project, but not in the lit_blank one?

These are my SBT depencies in the Lift project that breaks on 6.1.26 with one file deploy (and thus prevents me from testing):

class LiftProject( info: ProjectInfo ) extends DefaultWebProject(info) with EmbedJetty {

val liftVersion = "2.3-M1"

    override def compileOptions = super.compileOptions ++ Seq(Optimize)

override def libraryDependencies = Set(

   "net.liftweb" %% "lift-webkit" % liftVersion % "compile->default",

   "org.mortbay.jetty" % "jetty" % jettyEmbedVersion % "compile,test ->default",

   "junit" % "junit" % "4.5" % "test->default",

   "ch.qos.logback" % "logback-classic" % "0.9.26",

   "org.scala-tools.testing" %% "specs" % "1.6.6" % "test->default"

 ) ++ super.libraryDependencies

}

Anything odd here? I did do a sbt clean, clean-lib, update before testing...

--Maarten

On Fri, Feb 25, 2011 at 4:09 PM, Timothy Perrett <tim...@getintheloop.eu> wrote:

You have a broken class path - seems you have both log4j and the he logback classic facade.

Cheers, Tim

--

[Jeppe Nejsum Madsen]

On Fri, Feb 25, 2011 at 4:29 PM, Maarten Koopmans
<maarten....@gmail.com> wrote:
> In this project, but not in the lit_blank one?
> These are my SBT depencies in the Lift project that breaks on 6.1.26 with
> one file deploy (and thus prevents me from testing):
> class LiftProject( info: ProjectInfo ) extends DefaultWebProject(info) with
> EmbedJetty {
> val liftVersion = "2.3-M1"
>     override def compileOptions = super.compileOptions ++ Seq(Optimize)
> override def libraryDependencies = Set(
>    "net.liftweb" %% "lift-webkit" % liftVersion % "compile->default",
>    "org.mortbay.jetty" % "jetty" % jettyEmbedVersion % "compile,test
> ->default",
>    "junit" % "junit" % "4.5" % "test->default",
>    "ch.qos.logback" % "logback-classic" % "0.9.26",
>    "org.scala-tools.testing" %% "specs" % "1.6.6" % "test->default"
>  ) ++ super.libraryDependencies
> }
> Anything odd here? I did do a sbt clean, clean-lib, update before testing...

You might want to look at the transitive dependencies (dunno how to to
that in sbt), some may pull in the log4j stuff. I think jetty uses
slf4j, so perhaps there are some dependencies there that needs
exclusion?

/Jeppe

[Maarten Koopmans]

Too hard for me after a week of 12+ hour days. I may look into it next
week. Good point though.

--Maarten

[Timothy Perrett]

Jeppe is almost certainly right - its going to be one of the transitive dependencies. FYI, you have to override the def ivyXML in order to define dependencies with exclusions through SBT.

Cheers, Tim

[Maarten Koopmans]

I see, thanks, like described here http://scala-programming-language.1934581.n4.nabble.com/conflicting-slf4j-versions-when-using-M3-with-smile-td1976320.html

Now I only need to find out who pulls in what, but it looking at the error:

"WARN - failed LiftFilter: java.lang.ClassCastException: org.slf4j.impl.Log4jLoggerFactory cannot be cast to ch.qos.logback.classic.LoggerContext"

it looks like Jetty pulls in slf4j with log4j. Where does one find these dependencies, in you local ivy or maven repo? I am still to new to that kind of stuff.

--Maarten

On Fri, Feb 25, 2011 at 5:46 PM, Timothy Perrett <tim...@getintheloop.eu> wrote:

Jeppe is almost certainly right - its going to be one of the transitive dependencies. FYI, you have to override the def ivyXML in order to define dependencies with exclusions through SBT.

Cheers, Tim

--

[Timothy Perrett]

Yeah this is the only annoying thing about SBT - as far as im aware there is not an equivalent to mvn dependency:tree from Maven. I'm not aware of anyone having made that plugin either so you might be a bit stuck and have to use maven to at least determine the usage.

Cheers, Tim

[Maarten Koopmans]

Maven (to me) is sudden death for pursuing this path. Beautiful, but I don't have the time for that.

Best, Maarten

On Fri, Feb 25, 2011 at 8:29 PM, Timothy Perrett <tim...@getintheloop.eu> wrote:

Yeah this is the only annoying thing about SBT - as far as im aware there is not an equivalent to mvn dependency:tree from Maven. I'm not aware of anyone having made that plugin either so you might be a bit stuck and have to use maven to at least determine the usage.

Cheers, Tim

--

[Glen]

Hi Maarten,

Haven't checked your code, but make sure you are using NIO, if you use BIO then continuations won't be enabled, so no comet.  That caught me out, took a while to work out what was happening.

Regards,

Glen

[Maarten Koopmans]

Aha, a clue! Thank you!

--

[Maarten Koopmans]

Hm, I see that I do you use that:

val scc = new SelectChannelConnector

scc.setPort(8080)

val server = new Server

server.setConnectors(Array(scc))

So with Jetty 7, that's not the problem. Maybe add something in Boot?

--Maarten

[Glen]

Hi Marteen,

Yes it seems Lift requires change in boot to work with Jetty-7 for continuations, see Tim's post:  http://blog.getintheloop.eu/2010/02/18/using-jetty-7-continuations-to-power-lift-comet-support/

I've almost finished support for 7 in my plugin, and can verify that this will make comet work.

Regards,

Glen 

[David Pollak]

On Sat, Feb 26, 2011 at 12:09 PM, Glen <glen....@gmail.com> wrote:

Hi Marteen,

Yes it seems Lift requires change in boot to work with Jetty-7 for continuations, see Tim's post:  http://blog.getintheloop.eu/2010/02/18/using-jetty-7-continuations-to-power-lift-comet-support/

THis post is out of date.  Lift 2.3-M1 and newer automatically detects Jetty 6, Jetty 7, and Servlet 3.0 and does continuations accordingly.

 

I've almost finished support for 7 in my plugin, and can verify that this will make comet work.

Regards,

Glen 

--

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.

[Maarten Koopmans]

I know, but why is my comet failing now? I will try this (again), the
assembly task might interfere. Wouldn't expect it to work, but it's
too easy to test and stop discussions going down that path.

--Maarten

On Sunday, February 27, 2011, David Pollak

[Glen]

Hi David, Maarten,

Makes sense all my Lift projects are still using 2.2 however it seems to be broken in 2.3-M1

I've updated my plugin to support both Jetty-6 and Jetty-7, http://bit.ly/gY5fhl and included an example lift project code

I can see comet is working find with Lift-2.2 and Jetty-7

But moving it to Lift-2.3-M1 and removing the call to:

  LiftRules.servletAsyncProvider = (req) => new Jetty7AsyncProvider(req

in Boot.scala breaks comet.

Regards,

Glen

[David Pollak]

You mean that Comet does work when you remove this line when you compile to native code?
 

Regards,

Glen

--
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.

[Glen]

Hi David,

I am not compiling to native code, simply building a war with an embedded jetty.

Steps to reproduce:

  git clone git://github.com/glenford/sbt-jetty-embed.git

  cd sbt-jetty-embed/lift-project/

  sbt update jetty-embed-prepare package

  java -jar target/scala_2.8.1/sbt-jetty-embed-lift_2.8.1-0.1.war

  verify http://localhost:8080 the page shows two clocks updating each second using comet

  edit src/main/scala/bootstrap/liftweb/Boot.scala

  comment out line 35

  sbt clean package

  java -jar target/scala_2.8.1/sbt-jetty-embed-lift_2.8.1-0.1.war

  verify http://localhost:8080 the page shows two clocks no longer updating

Regards,

Glen

[David Pollak]

Please try it without embedding Jetty... just by running the WAR in a Jetty 7 container.

 

Regards,

Glen

--
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.

[Glen]

Hi David,

Same behaviour using jetty-distribution-7.3.0.v20110203

Regards,

Glen

[Maarten Koopmans]

So, ticket 909, http://www.assembla.com/spaces/liftweb/tickets/909-one-file-deploy-(including-jetty) now comes down to resolving this?

--Maarten

Regards,

Glen

--

[Maarten Koopmans]

...and even without the Assembly (plain Lift project) I only got Lift working by adding the explicit support forJetty7 as AsyncProvider.