[Lift] Re: Problem with LiftFilter in 2.8.0

2009-12-24 Thread Alan M
My most recent posting was just my interpretation of what was said in
this thread and I was just asking for confirmation.  I didn't go
looking for any more answers because I thought I had it.
I've only been monitoring my thread since.. I didn't catch that other
thread.

OK, after reading that other thread I'm surprised I got as far as I
did.  So it seems to me that Lift (the 280 port) was built with RC3
and my stuff with RC5 and that caused some kind of incompatibility..
(hence my odd LogBoot error) but if I recompiled everything (or tried)
with RC5 there'd still be trouble right now building Lift.  OK so I
think I understand where things are now.

Oh and just because I don't want to switch off of Netbeans or go back
a version is no reason to get all snarky about it. :p

Alan

On Dec 23, 5:32 pm, David Pollak 
wrote:
> On Wed, Dec 23, 2009 at 12:29 PM, Alan M  wrote:
> > So the 2.8 port branch(I'm used to subversion lingo) is broken right
> > now?
>
> No.  Until Scala 2.8. RC6, the Scala compiler had problems compiling Lift
> code.  We have been actively working with EPFL to make sure Lift and Scala
> 2.8 together and EPFL has been very responsive.
>
> I am not usually an RTFM kinda guy, but in this case, you should spend just
> a few minutes reviewing the Lift mailing list to understand what's going
> on?  Why?  How often do you see a conversation between me and Martin
> Odersky?  When you see a conversation, which we were having just yesterday
> about the 2.8/Lift issue, between us, you can bet that it worth reading.
> So, go back and read it.
>
> > Ouch, the only netbeans plugin for scala that works on the
> > current release of netbeans requires 2.8xx..
>
> Please refer to my previous email.  And just so you know, "gee, I want to
> use the latest and greatest NetBeans plugin even though there are plenty of
> other Scala IDE environments," is not a compelling reason.
>
> David
>
>
>
>
>
> > Oh and I'm not mixing lift versions in the same webapp, I was mixing
> > in the same container.  But now I moved both webapps to the 2.8.0
> > port.
>
> > I guess I should have just hung back on netbeans, hindsight 20/20 and
> > all, ugh..
>
> > Alan
>
> > On Dec 22, 8:03 pm, Randinn  wrote:
> > > This is not the first time this has cropped up, you may have to sticky
> > > warning not to use 2.8 with Lift for the moment.
>
> > > On Dec 23, 2:55 pm, David Pollak 
> > > wrote:
>
> > > > Lift *DOES NOT* work on Scala 2.8 Beta1 RC4 & 5.  Do not even try it.
> >  We
> > > > are currently working with EPFL to resolve these issues.
>
> > > > Lift 1.1-M8 and Lift 1.1-SNAPSHOT only work with Scala 2.7.7.  That is
> > the
> > > > *only* version of Scala that Lift 1.1-M8 and SNAPSHOT work with.  If
> > you
> > > > have any other version of Scala specified in your pom.xml file, it will
> > not
> > > > work.
>
> > > > Do not try to mix different versions of Lift in the same web app.  The
> > class
> > > > loader will not know which versions of the Lift library go with
> > different
> > > > Servlets.
>
> > > > Once you get your pom.xml file set up with Scala 2.7.7, then you must
> > do a
> > > > "mvn -U clean install" before doing an mvn jetty:run
>
> > > > On Tue, Dec 22, 2009 at 7:39 PM, Alan M 
> > wrote:
> > > > > Update:
>
> > > > > I updated the other servlet to scala 2.8 and lift 1.1 snapshot (much
> > > > > easier than I thought, I must be getting used to it) and I checked
> > the
> > > > > libs for both webapps and the commons lib directory.. no conflicting
> > > > > versions of scala or lift jars.. I'm on Tomcat 6 btw..  Not sure
> > where
> > > > > to look next..
>
> > > > > Alan
>
> > > > > On Dec 22, 7:13 pm, Ross Mellgren  wrote:
> > > > > > Where do you have the scala library jars? If you haven't taken
> > pains to
> > > > > ensure that you have two entirely separate scala JARs (2.7.3 and 2.8)
> > in two
> > > > > separate classloaders I could believe that you'll get all kinds of
> > problems
> > > > > like this. You might be better served using two separate tomcat
> > instances
> > > > > and some kind of reverse proxy like nginx to ensure they remain
> > entirely
> > > > > separated.
>
> > > > > > -Ross
>
> > > > > > On Dec 22, 2009, at 10:07 

[Lift] Re: Problem with LiftFilter in 2.8.0

2009-12-23 Thread Alan M
So the 2.8 port branch(I'm used to subversion lingo) is broken right
now?  Ouch, the only netbeans plugin for scala that works on the
current release of netbeans requires 2.8xx..

Oh and I'm not mixing lift versions in the same webapp, I was mixing
in the same container.  But now I moved both webapps to the 2.8.0
port.

I guess I should have just hung back on netbeans, hindsight 20/20 and
all, ugh..

Alan

On Dec 22, 8:03 pm, Randinn  wrote:
> This is not the first time this has cropped up, you may have to sticky
> warning not to use 2.8 with Lift for the moment.
>
> On Dec 23, 2:55 pm, David Pollak 
> wrote:
>
>
>
> > Lift *DOES NOT* work on Scala 2.8 Beta1 RC4 & 5.  Do not even try it.  We
> > are currently working with EPFL to resolve these issues.
>
> > Lift 1.1-M8 and Lift 1.1-SNAPSHOT only work with Scala 2.7.7.  That is the
> > *only* version of Scala that Lift 1.1-M8 and SNAPSHOT work with.  If you
> > have any other version of Scala specified in your pom.xml file, it will not
> > work.
>
> > Do not try to mix different versions of Lift in the same web app.  The class
> > loader will not know which versions of the Lift library go with different
> > Servlets.
>
> > Once you get your pom.xml file set up with Scala 2.7.7, then you must do a
> > "mvn -U clean install" before doing an mvn jetty:run
>
> > On Tue, Dec 22, 2009 at 7:39 PM, Alan M  wrote:
> > > Update:
>
> > > I updated the other servlet to scala 2.8 and lift 1.1 snapshot (much
> > > easier than I thought, I must be getting used to it) and I checked the
> > > libs for both webapps and the commons lib directory.. no conflicting
> > > versions of scala or lift jars.. I'm on Tomcat 6 btw..  Not sure where
> > > to look next..
>
> > > Alan
>
> > > On Dec 22, 7:13 pm, Ross Mellgren  wrote:
> > > > Where do you have the scala library jars? If you haven't taken pains to
> > > ensure that you have two entirely separate scala JARs (2.7.3 and 2.8) in 
> > > two
> > > separate classloaders I could believe that you'll get all kinds of 
> > > problems
> > > like this. You might be better served using two separate tomcat instances
> > > and some kind of reverse proxy like nginx to ensure they remain entirely
> > > separated.
>
> > > > -Ross
>
> > > > On Dec 22, 2009, at 10:07 PM, Alan M wrote:
>
> > > > > I get this message when it tries to initialize the LiftFilter..
>
> > > > > Dec 22, 2009 6:53:40 PM org.apache.catalina.core.StandardContext
> > > > > filterStart
> > > > > SEVERE: Exception starting filter LiftFilter
> > > > > java.lang.NoSuchMethodError: scala.collection.SeqLike.projection()
> > > > > Ljava/lang/Object;
> > > > >        at net.liftweb.util.ListHelpers$class.first(ListHelpers.scala:
> > > > > 53)
> > > > >        at net.liftweb.util.Helpers$.first(Helpers.scala:32)
> > > > >        at net.liftweb.util.LogBoot$.findTheFile$1(Log.scala:117)
> > > > >        at net.liftweb.util.LogBoot$._log4JSetup(Log.scala:119)
> > > > >        at net.liftweb.util.LogBoot$$anonfun$1.apply(Log.scala:97)
> > > > >        at net.liftweb.util.LogBoot$$anonfun$1.apply(Log.scala:97)
> > > > >        at net.liftweb.util.LogBoot$.checkConfig(Log.scala:95)
> > > > >        at net.liftweb.util.LogBoot$.net$liftweb$util$LogBoot$$_logger
> > > > > (Log.scala:141)
> > > > >        at net.liftweb.util.LogBoot$$anonfun$2.apply(Log.scala:143)
> > > > >        at net.liftweb.util.LogBoot$$anonfun$2.apply(Log.scala:143)
> > > > >        at net.liftweb.util.Log$.rootLogger(Log.scala:27)
> > > > >        at net.liftweb.util.Log$.error(Log.scala:43)
> > > > >        at net.liftweb.http.provider.HTTPProvider$class.bootLift
> > > > > (HTTPProvider.scala:80)
> > > > >        at net.liftweb.http.LiftFilter.bootLift(LiftServlet.scala:524)
> > > > >        at net.liftweb.http.provider.servlet.ServletFilterProvider
> > > > > $class.init(ServletFilterProvider.scala:23)
> > > > >        at net.liftweb.http.LiftFilter.init(LiftServlet.scala:524)
>
> > > > > Are multiple versions of Scala or Lift getting messed up here?  I have
> > > > > two different Lift based servlets on this tomcat, one with Scala 2.7.3
> > > > > and an older lift version and one with Scala 2.8 and the newest lift
> > > > >

[Lift] Re: Problem with LiftFilter in 2.8.0

2009-12-22 Thread Alan M
A little more info.. I just tried to run one of the servlets stand
alone using jetty:run and it had the same problem..

Alan

On Dec 22, 7:39 pm, Alan M  wrote:
> Update:
>
> I updated the other servlet to scala 2.8 and lift 1.1 snapshot (much
> easier than I thought, I must be getting used to it) and I checked the
> libs for both webapps and the commons lib directory.. no conflicting
> versions of scala or lift jars.. I'm on Tomcat 6 btw..  Not sure where
> to look next..
>
> Alan
>
> On Dec 22, 7:13 pm, Ross Mellgren  wrote:
>
> > Where do you have the scala library jars? If you haven't taken pains to 
> > ensure that you have two entirely separate scala JARs (2.7.3 and 2.8) in 
> > two separate classloaders I could believe that you'll get all kinds of 
> > problems like this. You might be better served using two separate tomcat 
> > instances and some kind of reverse proxy like nginx to ensure they remain 
> > entirely separated.
>
> > -Ross
>
> > On Dec 22, 2009, at 10:07 PM, Alan M wrote:
>
> > > I get this message when it tries to initialize the LiftFilter..
>
> > > Dec 22, 2009 6:53:40 PM org.apache.catalina.core.StandardContext
> > > filterStart
> > > SEVERE: Exception starting filter LiftFilter
> > > java.lang.NoSuchMethodError: scala.collection.SeqLike.projection()
> > > Ljava/lang/Object;
> > >        at net.liftweb.util.ListHelpers$class.first(ListHelpers.scala:
> > > 53)
> > >        at net.liftweb.util.Helpers$.first(Helpers.scala:32)
> > >        at net.liftweb.util.LogBoot$.findTheFile$1(Log.scala:117)
> > >        at net.liftweb.util.LogBoot$._log4JSetup(Log.scala:119)
> > >        at net.liftweb.util.LogBoot$$anonfun$1.apply(Log.scala:97)
> > >        at net.liftweb.util.LogBoot$$anonfun$1.apply(Log.scala:97)
> > >        at net.liftweb.util.LogBoot$.checkConfig(Log.scala:95)
> > >        at net.liftweb.util.LogBoot$.net$liftweb$util$LogBoot$$_logger
> > > (Log.scala:141)
> > >        at net.liftweb.util.LogBoot$$anonfun$2.apply(Log.scala:143)
> > >        at net.liftweb.util.LogBoot$$anonfun$2.apply(Log.scala:143)
> > >        at net.liftweb.util.Log$.rootLogger(Log.scala:27)
> > >        at net.liftweb.util.Log$.error(Log.scala:43)
> > >        at net.liftweb.http.provider.HTTPProvider$class.bootLift
> > > (HTTPProvider.scala:80)
> > >        at net.liftweb.http.LiftFilter.bootLift(LiftServlet.scala:524)
> > >        at net.liftweb.http.provider.servlet.ServletFilterProvider
> > > $class.init(ServletFilterProvider.scala:23)
> > >        at net.liftweb.http.LiftFilter.init(LiftServlet.scala:524)
>
> > > Are multiple versions of Scala or Lift getting messed up here?  I have
> > > two different Lift based servlets on this tomcat, one with Scala 2.7.3
> > > and an older lift version and one with Scala 2.8 and the newest lift
> > > version..
>
> > > I guess I'm just trying to avoid updating that other servlet because
> > > it's really not in my schedule right now..  Then again that might not
> > > be the problem at all..
>
> > > Alan
>
> > > --
>
> > > You received this message because you are subscribed to the Google Groups 
> > > "Lift" group.
> > > To post to this group, send email to lift...@googlegroups.com.
> > > To unsubscribe from this group, send email to 
> > > liftweb+unsubscr...@googlegroups.com.
> > > For more options, visit this group 
> > > athttp://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 lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.




[Lift] Re: Problem with LiftFilter in 2.8.0

2009-12-22 Thread Alan M
Update:

I updated the other servlet to scala 2.8 and lift 1.1 snapshot (much
easier than I thought, I must be getting used to it) and I checked the
libs for both webapps and the commons lib directory.. no conflicting
versions of scala or lift jars.. I'm on Tomcat 6 btw..  Not sure where
to look next..

Alan

On Dec 22, 7:13 pm, Ross Mellgren  wrote:
> Where do you have the scala library jars? If you haven't taken pains to 
> ensure that you have two entirely separate scala JARs (2.7.3 and 2.8) in two 
> separate classloaders I could believe that you'll get all kinds of problems 
> like this. You might be better served using two separate tomcat instances and 
> some kind of reverse proxy like nginx to ensure they remain entirely 
> separated.
>
> -Ross
>
> On Dec 22, 2009, at 10:07 PM, Alan M wrote:
>
> > I get this message when it tries to initialize the LiftFilter..
>
> > Dec 22, 2009 6:53:40 PM org.apache.catalina.core.StandardContext
> > filterStart
> > SEVERE: Exception starting filter LiftFilter
> > java.lang.NoSuchMethodError: scala.collection.SeqLike.projection()
> > Ljava/lang/Object;
> >        at net.liftweb.util.ListHelpers$class.first(ListHelpers.scala:
> > 53)
> >        at net.liftweb.util.Helpers$.first(Helpers.scala:32)
> >        at net.liftweb.util.LogBoot$.findTheFile$1(Log.scala:117)
> >        at net.liftweb.util.LogBoot$._log4JSetup(Log.scala:119)
> >        at net.liftweb.util.LogBoot$$anonfun$1.apply(Log.scala:97)
> >        at net.liftweb.util.LogBoot$$anonfun$1.apply(Log.scala:97)
> >        at net.liftweb.util.LogBoot$.checkConfig(Log.scala:95)
> >        at net.liftweb.util.LogBoot$.net$liftweb$util$LogBoot$$_logger
> > (Log.scala:141)
> >        at net.liftweb.util.LogBoot$$anonfun$2.apply(Log.scala:143)
> >        at net.liftweb.util.LogBoot$$anonfun$2.apply(Log.scala:143)
> >        at net.liftweb.util.Log$.rootLogger(Log.scala:27)
> >        at net.liftweb.util.Log$.error(Log.scala:43)
> >        at net.liftweb.http.provider.HTTPProvider$class.bootLift
> > (HTTPProvider.scala:80)
> >        at net.liftweb.http.LiftFilter.bootLift(LiftServlet.scala:524)
> >        at net.liftweb.http.provider.servlet.ServletFilterProvider
> > $class.init(ServletFilterProvider.scala:23)
> >        at net.liftweb.http.LiftFilter.init(LiftServlet.scala:524)
>
> > Are multiple versions of Scala or Lift getting messed up here?  I have
> > two different Lift based servlets on this tomcat, one with Scala 2.7.3
> > and an older lift version and one with Scala 2.8 and the newest lift
> > version..
>
> > I guess I'm just trying to avoid updating that other servlet because
> > it's really not in my schedule right now..  Then again that might not
> > be the problem at all..
>
> > Alan
>
> > --
>
> > You received this message because you are subscribed to the Google Groups 
> > "Lift" group.
> > To post to this group, send email to lift...@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > liftweb+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://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 lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.




[Lift] Problem with LiftFilter in 2.8.0

2009-12-22 Thread Alan M
I get this message when it tries to initialize the LiftFilter..

Dec 22, 2009 6:53:40 PM org.apache.catalina.core.StandardContext
filterStart
SEVERE: Exception starting filter LiftFilter
java.lang.NoSuchMethodError: scala.collection.SeqLike.projection()
Ljava/lang/Object;
at net.liftweb.util.ListHelpers$class.first(ListHelpers.scala:
53)
at net.liftweb.util.Helpers$.first(Helpers.scala:32)
at net.liftweb.util.LogBoot$.findTheFile$1(Log.scala:117)
at net.liftweb.util.LogBoot$._log4JSetup(Log.scala:119)
at net.liftweb.util.LogBoot$$anonfun$1.apply(Log.scala:97)
at net.liftweb.util.LogBoot$$anonfun$1.apply(Log.scala:97)
at net.liftweb.util.LogBoot$.checkConfig(Log.scala:95)
at net.liftweb.util.LogBoot$.net$liftweb$util$LogBoot$$_logger
(Log.scala:141)
at net.liftweb.util.LogBoot$$anonfun$2.apply(Log.scala:143)
at net.liftweb.util.LogBoot$$anonfun$2.apply(Log.scala:143)
at net.liftweb.util.Log$.rootLogger(Log.scala:27)
at net.liftweb.util.Log$.error(Log.scala:43)
at net.liftweb.http.provider.HTTPProvider$class.bootLift
(HTTPProvider.scala:80)
at net.liftweb.http.LiftFilter.bootLift(LiftServlet.scala:524)
at net.liftweb.http.provider.servlet.ServletFilterProvider
$class.init(ServletFilterProvider.scala:23)
at net.liftweb.http.LiftFilter.init(LiftServlet.scala:524)

Are multiple versions of Scala or Lift getting messed up here?  I have
two different Lift based servlets on this tomcat, one with Scala 2.7.3
and an older lift version and one with Scala 2.8 and the newest lift
version..

I guess I'm just trying to avoid updating that other servlet because
it's really not in my schedule right now..  Then again that might not
be the problem at all..

Alan

--

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




[Lift] Re: 280_port and yuicompressor problem

2009-12-22 Thread Alan M
OK cool.. thanks.. I'll look it up.  For now I just excluded it.

Alan

On Dec 21, 5:24 pm, Xuefeng Wu  wrote:
> If you google "[yuicompressor:compress {execution: default}]" would find so
> many information about this.
> It's not caused by scala2.8 or lift.
>
>
>
> On Tue, Dec 22, 2009 at 9:10 AM, Alan M  wrote:
> > I just recently started tinkering around with 2.8.. actually a recent
> > upgrade of Netbeans kind of necessitated it.. (the only Scala plugin
> > for Netbeans 6.8 requires Scala 2.8.xxx, ughh).
>
> > So most of my code is close anyway, except for anything that depends
> > on specs.  But I had to get the 280_port of lift to compile locally
> > for my web services.  When I try it fails very near the end with:
> > ...
> > [INFO] [yuicompressor:compress {execution: default}]
> > [INFO]
> > 
> > [ERROR] FATAL ERROR
> > [INFO]
> > 
> > [INFO] null
> > [INFO]
> > 
> > [INFO] Trace
> > java.lang.RuntimeException
> >        at
> > com.yahoo.platform.yui.compressor.JavaScriptCompressor.printSourceNumber
> > (JavaScriptCompressor.java:299)
> >        at com.yahoo.platform.yui.compressor.JavaScriptCompressor.parse
> > (JavaScriptCompressor.java:335)
> >        at com.yahoo.platform.yui.compressor.JavaScriptCompressor.
> > (JavaScriptCompressor.java:532)
> >        at net.sf.alchim.mojo.yuicompressor.YuiCompressorMojo.processFile
> > (YuiCompressorMojo.java:178)
> > ...
>
> > I'm using maven 2.2.1 and Java 1.6.0.0 on Ubuntu.
>
> > Any ideas?
>
> > Alan
>
> > --
>
> > You received this message because you are subscribed to the Google Groups
> > "Lift" group.
> > To post to this group, send email to lift...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > liftweb+unsubscr...@googlegroups.com
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/liftweb?hl=en.
>
> --
> Scala中文社区:  http://groups.google.com/group/scalacn

--

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




[Lift] 280_port and yuicompressor problem

2009-12-21 Thread Alan M
I just recently started tinkering around with 2.8.. actually a recent
upgrade of Netbeans kind of necessitated it.. (the only Scala plugin
for Netbeans 6.8 requires Scala 2.8.xxx, ughh).

So most of my code is close anyway, except for anything that depends
on specs.  But I had to get the 280_port of lift to compile locally
for my web services.  When I try it fails very near the end with:
...
[INFO] [yuicompressor:compress {execution: default}]
[INFO]

[ERROR] FATAL ERROR
[INFO]

[INFO] null
[INFO]

[INFO] Trace
java.lang.RuntimeException
at
com.yahoo.platform.yui.compressor.JavaScriptCompressor.printSourceNumber
(JavaScriptCompressor.java:299)
at com.yahoo.platform.yui.compressor.JavaScriptCompressor.parse
(JavaScriptCompressor.java:335)
at com.yahoo.platform.yui.compressor.JavaScriptCompressor.
(JavaScriptCompressor.java:532)
at net.sf.alchim.mojo.yuicompressor.YuiCompressorMojo.processFile
(YuiCompressorMojo.java:178)
...

I'm using maven 2.2.1 and Java 1.6.0.0 on Ubuntu.

Any ideas?

Alan

--

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




[Lift] Using Lift to build a Web Service and the PUT HTTP method??

2009-08-27 Thread Alan M

I'm trying to use PUT with Lift and it seems to be working, except I
can't find the content I put.  I'm using jQuery on the front end (a
custom front-end) and firebug seems to think the data gets sent.
Although it doesn't show me the raw request, it adds a PUT tab that
shows the key and value(I couldn't get PUT in jQuery to work without a
key/value pair).  So where should I look for this data in the req?
I've used POST and GET before without problem, but I need to use PUT
here.  I looked in the body field and in the xml field (it is an xml
string being PUT).  BTW, I'm using Lift .11 and scala 2.7.2.

So anyone doing this?  If so where is the PUT data?

Oh also should I upgrade Lift?  Last time I did (from .9 to .11) it
was a lot of work.
Alan
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] A problem involving Lift and javascript dodged for now..

2009-07-21 Thread Alan M

I'm using lift for web services and I need to serve a javascript
driven front end from the same web server (don't feel like messing
with proxies right now) and I figured someone on here would want to
know what I ran into with serving static content.

Basically I was trying to use jQuery and in particular a tree library
called jsTree (it looks really feature rich and flexible).  Anyway, it
turns out either the lift javascript or some conflict derived in part
there from was munging things sufficiently so that everything seemed
normal in the xhtml.. but a few of the classes where deleted.  This
caused the entire jsTree to fail to render properly, making it non-
functional.

I'm not entirely sure why it did what it did, but until I stripped out
Lift and ran it just as an empty servlet I couldn't see what was going
on.  For some reason the lift served version stripped the class off of
a ul (in my case it was only one, but I had a very simple tree).. the
class for the ul was "ltr" and it's gone in the lift version.  This ul
is generated by javascript using jQuery, so I'm not sure what's going
on there.

Anyway, I've decided since all my dynamic content is coming from other
webapps, I might as well just serve my static content from a bare
servlet, therefore cutting down on any variables.  (I've already
wrestled with this for too long).  But if anyone is interested in
following up, maybe with the jsTree guys, have at it.  They have a
very friendly Google group as well :)

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



[Lift] Re: Turning on Logging for third-party libraries in Lift

2009-06-27 Thread Alan M

I tried the log4j.xml in classes but it didn't work, until... :) I
renamed it to default.log4j.xml and fixed a conflict with log4j and
commons-logging libraries.  It turns out in Tomcat that you have to be
very careful about how you load those libraries, especially when using
something like maven.  Basically as per an interesting article on the
log4j web site (that I don't have the URL for on this computer) you
should put a copy of the log4j and commons-logging jars in the common/
lib directory of tomcat and not in any particular web-app or else it
gets confused.  It was also a bit of an endorsement for SFL4j though I
didn't really look into to that so close yet.
Anyway, once I did that (manually for now, have to fix the pom to not
include those two from dependencies.. ugh..) everything worked as
expected.  Woohoo!!

Alan

On Jun 27, 3:17 am, "marius d."  wrote:
> I think that simply putting log4j.xml in WEB-INF/classes folder does
> the trick.
>
> Br's,
> Marius
>
> On Jun 27, 3:06 am, Alan M  wrote:
>
> > I'm trying to enable log4j logging in a third party library (well
> > third party to me.. it was developed in house) so that it logs it's
> > output to the same place my Lift webapp logs.
>
> > In the third party library, a log4j Logger is obtained and used but no
> > setup is done, figuring the log4j config will be done by the app
> > builder.
>
> > Now I figured the root logger would catch it.. but it didn't seem to
> > work.  So I added a specific logger with the exact string used in the
> > third party code..  Still no output..
>
> > Am I missing something about class loaders?  Or is there something
> > about start-up that's messing with the getLogger method (it's actually
> > in the method so it should be happening after Lift initializes
> > everything)?  Or is there something else special about lift logging
> > that won't let the library piggy back off of it?
>
> > BTW, I should mention that Lift logging otherwise is working for me.
> > By otherwise I mean when logging from any classes directly in the web-
> > app classes directory.
>
> > Alan
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: Getting Username and Password from URL of form hxxp://user:passw...@foo.org

2009-06-26 Thread Alan M

Problem solved!

I knew how to get and decode the header style.. it's the
http://username:passw...@foo.org that I couldn't get to.  I didn't see
how to get the string that contains the username and password in this
case.  I found it though.. if you get the HTTPServletRequest and then
the URL from that has the complete string.

Oh and for various reasons I can't use the built in authentication
stuff.

Alan

On Jun 25, 4:17 am, Timothy Perrett  wrote:
> Are you using the builtin support for basic authentication in lift? If
> not, please see my example here:http://is.gd/1cYhR
>
> The format you mention is standard HTTP Basic, and in accordance with
> the RFC's - it should be Base64 encoded. Lift supports both HTTP basic
> and HTTP digest.
>
> Cheers, Tim
>
> On Jun 25, 5:10 am, Alan M  wrote:
>
> > I can't seem to find anyway to get to those two values.  I've been
> > searching all over the request class/object and no luck.
>
> > I'm writing a RESTful web service that uses basic auth and for some
> > reason jQuery likes to send things in the above mentioned format
> > (http://user:passw...@foo.org).  I've tried to fix that on the
> > Javascript side but I couldn't get anything to work.  So instead I
> > decided on the service to recognize either the header style or the URL
> > style of passing the login info.  Sounded simple enough, until I
> > couldn't find how to get at that/those strings..
>
> > Any help would be greatly appreciated..
>
> > Alan Mortensen
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Turning on Logging for third-party libraries in Lift

2009-06-26 Thread Alan M

I'm trying to enable log4j logging in a third party library (well
third party to me.. it was developed in house) so that it logs it's
output to the same place my Lift webapp logs.

In the third party library, a log4j Logger is obtained and used but no
setup is done, figuring the log4j config will be done by the app
builder.

Now I figured the root logger would catch it.. but it didn't seem to
work.  So I added a specific logger with the exact string used in the
third party code..  Still no output..

Am I missing something about class loaders?  Or is there something
about start-up that's messing with the getLogger method (it's actually
in the method so it should be happening after Lift initializes
everything)?  Or is there something else special about lift logging
that won't let the library piggy back off of it?

BTW, I should mention that Lift logging otherwise is working for me.
By otherwise I mean when logging from any classes directly in the web-
app classes directory.

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



[Lift] Getting Username and Password from URL of form hxxp://user:passw...@foo.org

2009-06-24 Thread Alan M

I can't seem to find anyway to get to those two values.  I've been
searching all over the request class/object and no luck.

I'm writing a RESTful web service that uses basic auth and for some
reason jQuery likes to send things in the above mentioned format
(http://user:passw...@foo.org).  I've tried to fix that on the
Javascript side but I couldn't get anything to work.  So instead I
decided on the service to recognize either the header style or the URL
style of passing the login info.  Sounded simple enough, until I
couldn't find how to get at that/those strings..

Any help would be greatly appreciated..

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



[Lift] Re: Getting the "file" out of a Put Request..

2009-02-16 Thread Alan M

OK just to wrap up for me, because I didn't really follow all the
implications of the change being made..  If I send a Put to a lift web
service I should not be able to see the "file" content in the body of
the Request?  (now as in when the update is live/updated on my Maven)

Alan

On Feb 16, 3:47 pm, David Pollak 
wrote:
> On Mon, Feb 16, 2009 at 3:44 PM, Tim Perrett  wrote:
>
> > It appears that DPP is solving your issue now :-)
>
> > However, for the record, I do exactly what you describe in terms of
> > PUT / POST - this is a fairly normal ROA (but with objective-c
> > clients, not javascript). FYI... if you have xml messages, you can
> > access the xml automagically in your dispatching:
>
> > req.xml_? // => boolean to check if its an xml body
> > req.xml // => the actual xml passed (do whatever parsing)
>
> > Not sure if im adding any value to this conversation - so please say
> > if im just confusing you! REST services in lift is something I care
> > about a lot and ensuring its correct is of great importance to me :-)
>
> Tim,
>
> The Lift bug was that it was not respecting the Content-Type except in a few
> cases.  The change is better all around and I believe will support any mime
> type with more flexibility.  The current "special case" mime types are XML,
> multi-part mime, and forms.  All other mime types will just pass the request
> body on the Req instance.
>
> This should make doing web services better in Lift.
>
> Thanks,
>
> David
>
>
>
> > Cheers, Tim
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net
> Beginning Scalahttp://www.apress.com/book/view/1430219890
> Follow me:http://twitter.com/dpp
> Git some:http://github.com/dpp
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: Getting the "file" out of a Put Request..

2009-02-16 Thread Alan M

Oh.. so I can stuff data in the body, even if the message is a PUT
message?  Not sure how to do that with curl without sending a bogus
file along for the ride.. but if that's what you are saying then I
guess that'd be acceptable.  With the exception of some GIF/PNG/JPEG
images now and again, the primary data will be XML files, some large
some small.  The primary sender will be a Javascript application
making the webservice calls directly.

Alan

On Feb 16, 3:18 pm, Tim Perrett  wrote:
> I can understand why he wants to use PUT - its more resource
> orientated.
>
> I think we should stop talking about file uploads in the traditional
> sense, as the current lift design is "doing the right thing" for
> normal form based uploads.. However, lets talk about passing large
> entity bodies with web services and what *exactly* you are transfering
> and why.
>
> When im passing large bodies around in my web services, the binary
> content is usually passed as element content (base64 encoded) inside
> my XML body message  as I might be passing some other meta-data such
> as name or whatever (in the case of an image). For example, my request
> body might look like:
>
> 
>   some image
>   
> 
>
> Where  include a base64 encoded image or whatever. This is of
> course an example, but you see how it can work?
>
> Thanks
>
> Tim
>
> On Feb 16, 11:10 pm, David Pollak 
> wrote:
>
> > On Mon, Feb 16, 2009 at 2:58 PM, Alan M  wrote:
>
> > > OK I think I follow up to a point.. so Lift needs to know that it's
> > > multipart to work correctly with a put, and it doesn't.  That much I
> > > get, seems like Put is just broken.
>
> > We are relying on the Apache multipart library to handle multipart uploads.
> >  The library conforms to RFC 1867 which only defines multipart file uploads
> > for POSTs (not PUT, etc.)
>
> >http://www.ietf.org/rfc/rfc1867.txt
>
> > Are you writing your Lift app to a particular spec and if so, can you point
> > us to that spec?
>
> > Thanks,
>
> > David
>
> > What I don't understand is that
>
> > > last bit though..  When you say:
> > > > you can pass your entity body and just access the
> > > > req.body property
> > > Where could you do that?  I don't build the requests myself, so would
> > > I have to modify the Lift code to do this?  Is there an extension
> > > point to make that happen?  (like set request builder here or
> > > something and a class I can extend)
>
> > > Alan
> > > On Feb 16, 2:25 pm, Tim Perrett  wrote:
> > > > Would it not be because of:
>
> > > > ServletFileUpload.isMultipartContent(request) // Req.scala line 79
>
> > > > If you then reference the commons lib, the source of that method looks
> > > > like:
>
> > > >     public static final boolean isMultipartContent(
> > > >             HttpServletRequest request) {
> > > >         if (!"post".equals(request.getMethod().toLowerCase())) {
> > > >             return false;
> > > >         }
> > > >         String contentType = request.getContentType();
> > > >         if (contentType == null) {
> > > >             return false;
> > > >         }
> > > >         if (contentType.toLowerCase().startsWith(MULTIPART)) {
> > > >             return true;
> > > >         }
> > > >         return false;
> > > >     }
>
> > > > As DPP says, it looks as though you will *need* to make it a POST
> > > > request, and also set the content type to multi-part.
>
> > > > Alternatively, if, like me, you dont want to use overloaded post as
> > > > its not very ROA, you can pass your entity body and just access the
> > > > req.body property... you wouldnt get any of the useful lift helpers,
> > > > but of course it depends on your use case :-)
>
> > > > Cheers
>
> > > > Tim
>
> > > > On Feb 16, 10:05 pm, David Pollak 
> > > > wrote:
>
> > > > > On Mon, Feb 16, 2009 at 1:53 PM, Alan M 
> > > wrote:
>
> > > > > > I'm still working away on my web service project (mentioned many
> > > > > > months ago when I first lobbied to get Scala used) and we rely
> > > heavily
> > > > > > on Put requests to create new resources.  My first attempt involving
> > > > > > Put and I've been stumped.
>
> > > > > > I've been able to

[Lift] Re: Getting the "file" out of a Put Request..

2009-02-16 Thread Alan M

It doesn't have so much to do with a spec per se (I have my list of
URL's and behaviors but it's like 3 pages of 9 pt text spreadsheets)
as it does with wanting to have full use of the limited array of verbs
you can have in REST.  I'm not sure if there are any URLs where a POST
couldn't be done to replace a PUT.  But the basic semantics I was
planning on, was that a POST creates a child to the URL you are
posting to (with a server generated URL) and a PUT creates or
overwrites a resource where you have the URL.  So if you post to /
parent you would could create say a /parent/child354 .. while if you
put to /parent you would overwrite /parent's own information.

Alan

On Feb 16, 3:10 pm, David Pollak 
wrote:
> On Mon, Feb 16, 2009 at 2:58 PM, Alan M  wrote:
>
> > OK I think I follow up to a point.. so Lift needs to know that it's
> > multipart to work correctly with a put, and it doesn't.  That much I
> > get, seems like Put is just broken.
>
> We are relying on the Apache multipart library to handle multipart uploads.
>  The library conforms to RFC 1867 which only defines multipart file uploads
> for POSTs (not PUT, etc.)
>
> http://www.ietf.org/rfc/rfc1867.txt
>
> Are you writing your Lift app to a particular spec and if so, can you point
> us to that spec?
>
> Thanks,
>
> David
>
> What I don't understand is that
>
>
>
> > last bit though..  When you say:
> > > you can pass your entity body and just access the
> > > req.body property
> > Where could you do that?  I don't build the requests myself, so would
> > I have to modify the Lift code to do this?  Is there an extension
> > point to make that happen?  (like set request builder here or
> > something and a class I can extend)
>
> > Alan
> > On Feb 16, 2:25 pm, Tim Perrett  wrote:
> > > Would it not be because of:
>
> > > ServletFileUpload.isMultipartContent(request) // Req.scala line 79
>
> > > If you then reference the commons lib, the source of that method looks
> > > like:
>
> > >     public static final boolean isMultipartContent(
> > >             HttpServletRequest request) {
> > >         if (!"post".equals(request.getMethod().toLowerCase())) {
> > >             return false;
> > >         }
> > >         String contentType = request.getContentType();
> > >         if (contentType == null) {
> > >             return false;
> > >         }
> > >         if (contentType.toLowerCase().startsWith(MULTIPART)) {
> > >             return true;
> > >         }
> > >         return false;
> > >     }
>
> > > As DPP says, it looks as though you will *need* to make it a POST
> > > request, and also set the content type to multi-part.
>
> > > Alternatively, if, like me, you dont want to use overloaded post as
> > > its not very ROA, you can pass your entity body and just access the
> > > req.body property... you wouldnt get any of the useful lift helpers,
> > > but of course it depends on your use case :-)
>
> > > Cheers
>
> > > Tim
>
> > > On Feb 16, 10:05 pm, David Pollak 
> > > wrote:
>
> > > > On Mon, Feb 16, 2009 at 1:53 PM, Alan M 
> > wrote:
>
> > > > > I'm still working away on my web service project (mentioned many
> > > > > months ago when I first lobbied to get Scala used) and we rely
> > heavily
> > > > > on Put requests to create new resources.  My first attempt involving
> > > > > Put and I've been stumped.
>
> > > > > I've been able to run the server (using mvn/jetty) and my webapp gets
> > > > > a PUT request (says so in the log produced by Jetty) and it does
> > > > > everything it's supposed to in my code, except it never gets the put
> > > > > file.  I used curl to make the call and it shows the bar saying it's
> > > > > uploading the file and finishing.  In the server code, the Reqs body
> > > > > is an Empty Box and it's uploadedFiles is an empty List.
>
> > > > If you do a POST with the same data, does it work correctly
> > (uploadedFiles
> > > > gets populated)?
>
> > > > > So my question is, where do I get that data from?  or is there
> > > > > something else I need to do to turn that feature on? (enable file
> > > > > upload or something?)
>
> > > > > Alan
>
> > > > > P.S. Something that might be relevant, since it's a webservice 

[Lift] Re: Getting the "file" out of a Put Request..

2009-02-16 Thread Alan M

Yeah but when I do the PUT, the req.body is an Empty box (no byte
array).  Also note, I'm using the statelessDispatch not dispatch.. but
other than that, what you wrote code-wise is almost exactly one of the
ways I tried.  (the other way is to look at uploadedFiles instead of
body)

Alan

On Feb 16, 3:08 pm, Tim Perrett  wrote:
> Sorry Alan,
>
> I assumed too much - my fault not yours.
>
> Generally, handling web services is done via dispatching. for
> instance:
>
> // Boot.scala
> LiftRules.dispatch.prepend {
>   case r @ Req("some" :: "path" :: Nil, "", PutRequest) => () =>
> myHandlerFunction(r)
>
> }
>
> def myHandlerFunction(req: Req): Box[LiftResponse] = {
>   println("Entity Body is:" + req.body.toString)
>   ...
>
> }
>
> In this instance, you could pass the "r" property to the function and
> then do r.body to get the entire entity body. Make sense?
>
> If you wish to use lifts built in file uploading functions, you
> catogically cannot use PUT at this present time, you can only use POST
> with the accompanying content type set to multipart.
>
> Does that clear things up at all?
>
> Cheers, Tim
>
> On Feb 16, 10:58 pm, Alan M  wrote:
>
> > OK I think I follow up to a point.. so Lift needs to know that it's
> > multipart to work correctly with a put, and it doesn't.  That much I
> > get, seems like Put is just broken. What I don't understand is that
> > last bit though..  When you say:> you can pass your entity body and just 
> > access the
> > > req.body property
>
> > Where could you do that?  I don't build the requests myself, so would
> > I have to modify the Lift code to do this?  Is there an extension
> > point to make that happen?  (like set request builder here or
> > something and a class I can extend)
>
> > Alan
> > On Feb 16, 2:25 pm, Tim Perrett  wrote:
>
> > > Would it not be because of:
>
> > > ServletFileUpload.isMultipartContent(request) // Req.scala line 79
>
> > > If you then reference the commons lib, the source of that method looks
> > > like:
>
> > >     public static final boolean isMultipartContent(
> > >             HttpServletRequest request) {
> > >         if (!"post".equals(request.getMethod().toLowerCase())) {
> > >             return false;
> > >         }
> > >         String contentType = request.getContentType();
> > >         if (contentType == null) {
> > >             return false;
> > >         }
> > >         if (contentType.toLowerCase().startsWith(MULTIPART)) {
> > >             return true;
> > >         }
> > >         return false;
> > >     }
>
> > > As DPP says, it looks as though you will *need* to make it a POST
> > > request, and also set the content type to multi-part.
>
> > > Alternatively, if, like me, you dont want to use overloaded post as
> > > its not very ROA, you can pass your entity body and just access the
> > > req.body property... you wouldnt get any of the useful lift helpers,
> > > but of course it depends on your use case :-)
>
> > > Cheers
>
> > > Tim
>
> > > On Feb 16, 10:05 pm, David Pollak 
> > > wrote:
>
> > > > On Mon, Feb 16, 2009 at 1:53 PM, Alan M  
> > > > wrote:
>
> > > > > I'm still working away on my web service project (mentioned many
> > > > > months ago when I first lobbied to get Scala used) and we rely heavily
> > > > > on Put requests to create new resources.  My first attempt involving
> > > > > Put and I've been stumped.
>
> > > > > I've been able to run the server (using mvn/jetty) and my webapp gets
> > > > > a PUT request (says so in the log produced by Jetty) and it does
> > > > > everything it's supposed to in my code, except it never gets the put
> > > > > file.  I used curl to make the call and it shows the bar saying it's
> > > > > uploading the file and finishing.  In the server code, the Reqs body
> > > > > is an Empty Box and it's uploadedFiles is an empty List.
>
> > > > If you do a POST with the same data, does it work correctly 
> > > > (uploadedFiles
> > > > gets populated)?
>
> > > > > So my question is, where do I get that data from?  or is there
> > > > > something else I need to do to turn that feature on? (enable file
> > > > > upload or something?)
>
> > > > > Alan
>
> > > > > P.S. Something that might be relevant, since it's a webservice I'm
> > > > > using the stateless dispatcher.. does that effect how/when the
> > > > > paramCalculator works and therefore messes this up somehow?
>
> > > > --
> > > > Lift, the simply functional web frameworkhttp://liftweb.net
> > > > Beginning Scalahttp://www.apress.com/book/view/1430219890
> > > > Follow me:http://twitter.com/dpp
> > > > Git some:http://github.com/dpp

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



[Lift] Re: Getting the "file" out of a Put Request..

2009-02-16 Thread Alan M

OK I think I follow up to a point.. so Lift needs to know that it's
multipart to work correctly with a put, and it doesn't.  That much I
get, seems like Put is just broken. What I don't understand is that
last bit though..  When you say:
> you can pass your entity body and just access the
> req.body property
Where could you do that?  I don't build the requests myself, so would
I have to modify the Lift code to do this?  Is there an extension
point to make that happen?  (like set request builder here or
something and a class I can extend)

Alan
On Feb 16, 2:25 pm, Tim Perrett  wrote:
> Would it not be because of:
>
> ServletFileUpload.isMultipartContent(request) // Req.scala line 79
>
> If you then reference the commons lib, the source of that method looks
> like:
>
>     public static final boolean isMultipartContent(
>             HttpServletRequest request) {
>         if (!"post".equals(request.getMethod().toLowerCase())) {
>             return false;
>         }
>         String contentType = request.getContentType();
>         if (contentType == null) {
>             return false;
>         }
>         if (contentType.toLowerCase().startsWith(MULTIPART)) {
>             return true;
>         }
>         return false;
>     }
>
> As DPP says, it looks as though you will *need* to make it a POST
> request, and also set the content type to multi-part.
>
> Alternatively, if, like me, you dont want to use overloaded post as
> its not very ROA, you can pass your entity body and just access the
> req.body property... you wouldnt get any of the useful lift helpers,
> but of course it depends on your use case :-)
>
> Cheers
>
> Tim
>
> On Feb 16, 10:05 pm, David Pollak 
> wrote:
>
> > On Mon, Feb 16, 2009 at 1:53 PM, Alan M  wrote:
>
> > > I'm still working away on my web service project (mentioned many
> > > months ago when I first lobbied to get Scala used) and we rely heavily
> > > on Put requests to create new resources.  My first attempt involving
> > > Put and I've been stumped.
>
> > > I've been able to run the server (using mvn/jetty) and my webapp gets
> > > a PUT request (says so in the log produced by Jetty) and it does
> > > everything it's supposed to in my code, except it never gets the put
> > > file.  I used curl to make the call and it shows the bar saying it's
> > > uploading the file and finishing.  In the server code, the Reqs body
> > > is an Empty Box and it's uploadedFiles is an empty List.
>
> > If you do a POST with the same data, does it work correctly (uploadedFiles
> > gets populated)?
>
> > > So my question is, where do I get that data from?  or is there
> > > something else I need to do to turn that feature on? (enable file
> > > upload or something?)
>
> > > Alan
>
> > > P.S. Something that might be relevant, since it's a webservice I'm
> > > using the stateless dispatcher.. does that effect how/when the
> > > paramCalculator works and therefore messes this up somehow?
>
> > --
> > Lift, the simply functional web frameworkhttp://liftweb.net
> > Beginning Scalahttp://www.apress.com/book/view/1430219890
> > Follow me:http://twitter.com/dpp
> > Git some:http://github.com/dpp

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



[Lift] Versions of Lift..

2009-02-16 Thread Alan M

I'm working on a project that has multiple web services and a simple
one was finished a while ago (a few months at least) and now that I'm
back in the Lift sphere.. I noticed some incompatibilities in the .10
line.  Well nothing too heinous there.. everything is working now.. I
like the Can to Box renaming.. etc..  But what I couldn't find is the
differences between .10 and .11.  Are they significant?  Is it worth
making the jump now, since I'm getting back in to the Lift side of the
project?  Are there major benefits to upgrading?  Is there a large
disparity in documentation between the two?  Etc..  I've had very
little luck in finding out any details..

Alan

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



[Lift] Getting the "file" out of a Put Request..

2009-02-16 Thread Alan M

I'm still working away on my web service project (mentioned many
months ago when I first lobbied to get Scala used) and we rely heavily
on Put requests to create new resources.  My first attempt involving
Put and I've been stumped.

I've been able to run the server (using mvn/jetty) and my webapp gets
a PUT request (says so in the log produced by Jetty) and it does
everything it's supposed to in my code, except it never gets the put
file.  I used curl to make the call and it shows the bar saying it's
uploading the file and finishing.  In the server code, the Reqs body
is an Empty Box and it's uploadedFiles is an empty List.

So my question is, where do I get that data from?  or is there
something else I need to do to turn that feature on? (enable file
upload or something?)

Alan

P.S. Something that might be relevant, since it's a webservice I'm
using the stateless dispatcher.. does that effect how/when the
paramCalculator works and therefore messes this up somehow?

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



[Lift] Re: WebService example and versions of Lift

2008-09-08 Thread Alan M

Thanks a lot, that clears things up considerably.  Now my only concern
is how much stuff has changed so quickly..  But such is life on the
edge eh?

As for the other stuff, that probably belongs in another thread.. my
bad in mixing..

Alan

On Sep 5, 2:51 pm, "David Pollak" <[EMAIL PROTECTED]>
wrote:
> On Fri, Sep 5, 2008 at 2:23 PM, Alan M <[EMAIL PROTECTED]> wrote:
>
> > As far as I can tell the example doesn't compile with any version of
> > Lift.  ResponseIt is gone in .10 and SimpleController exists only in .
> > 10.
>
> ResponseIt is now LiftResponse
>
> Here's a pretty simple set of REST services:
>
> object RestAPI extends XMLApiHelper {
>   val logger: Logger = Logger.getLogger("us.esme.api")
>
>   def dispatch: LiftRules.DispatchPf = {
>     case RequestState("api" :: "get_msgs" :: Nil, "", GetRequest) => getMsgs
>   }
>
>     def getMsgs(): LiftResponse = {
>     val r: Can[NodeSeq] =
>     for (user <- calcUser ?~ "User not found";
>                val lst = Mailbox.mostRecentMessagesFor(user.id, 40))
>           yield lst.flatMap{ case (msg, why) => msg.toXml % why.attr}
>
>     r
>   }
>
> }
>
> > So I'm trying to create a basic web service based on the example, any
> > advice on how to proceed?  What is the replacement for ResponseIt or
> > what should I use instead of SimpleController?
>
> > To be honest I'm having a hell of a time so far.  It seems that Lift
> > is very much tailored towards standard webapps with templated pages
> > and O/R mapped data from databases, etc...
>
> Lift does REST and web services in a very simple way.  It's simpler than any
> framework I've used.
>
> Lift also does standard XHTML, Ajax, and Comet in very simple, manageable
> ways.
>
> > But in my case, I'm getting
> > my data from other sources and in particular I'm getting my user
> > authentication and authorization data from an unusual source.  So it's
> > been particularly hard for me to know when I should use the standard
> > Lift stuff and when I should/can go it on my own.  Which may explain
> > why I'm so highly interested in using/referencing/blatantly copying
> > the Web Service example on the wiki.
>
> > Also, just an observation, it seems that Lift is trying to be like
> > Rails.. IE handle every layer by itself.
>
> It has solutions for most layers because in my experience, most of the other
> solutions don't meet my needs.  Most of the Java-derived stuff is amazingly
> heavy weight and requires too much hidden state, XML files, etc.  I've tried
> to make Lift as much as possible oriented to the strengths of Scala and to
> getting common things done simply, easily, and securely.
>
> >  I'm not sure that's a good
> > thing..  such as it's own O/R tools,
>
> You're seeing on another thread just how hard it is to use JPA.  I don't
> know if that's JPA, JPA with Scala or what, but it's not as easy as Lift's
> OR mapper and Lift's OR mapper comes with a lot of side benefits as it's
> integrated into common REST and HTML tasks.  Also, Lift's OR Mapper is
> optional.  If you want to use JPA, go right ahead.
>
> > it's own authentication stuff,
>
> Which is optional... except how many web apps don't have authentication?
> So, you can roll your own or use the Lift stuff.  Your choice.
>
>
>
> > it's own templating (well wicket modified/adapted)
>
> It's Wicket inspired, not adapted and there are very compelling reasons for
> Lift's templating engine.  Please read the View
> First<http://liftweb.net/index.php/Lift_View_First>document.  Lift is
> not front-controller.
>
> > etc..  Correct me
> > if I'm wrong.  Anyway.. it's early days yet.. maybe they'll split off.
>
> There are half a dozen Lift sub-packages and there will be more divisions of
> Lift.  But at the end of the day, Lift gives me most of the common things I
> do when I build web apps.  Why shouldn't a web framework do this?
>
> Thanks,
>
> David
>
>
>
> > Alan
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net
> Collaborative Task Managementhttp://much4.us
> Follow me:http://twitter.com/dpp
> Git some:http://github.com/dpp

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



[Lift] Lift project scope WAS: Web Services example and versions of Lift

2008-09-08 Thread Alan M

I copied the relevant portions of another thread over, because I
thought it was interesting in it's own right.

I just wanted to say that I'm not criticizing the implementations or
designs of any of the Lift components, just the idea that they should
all be in one project.  For instance, on a recent project I used
Hibernate for storage.. it does it very well.. much better than say
Rails does..  And what tends to happen when a project tries to do all
these layers/functions is that the core of the project gets tailored
and at least conceptually coupled to these implementations.  I can see
why at such an early state in Scala that these things are necessary
(there is no Scala Hibernate for example)..  I just worry that it may
be too much for one project to take on and could get left in the dust,
if there ever is a Scala Hibernate and a Scala Velocity, etc..  and a
project comes along that allows you to mix and match those by design.

Of course this is all theoretical for me.. since I don't have a grand
understanding of the Lift code universe.. but even if it's very easy
to use 3rd party stuff now, speaking from experience, it's very hard
to keep that swappability without a very clear intention of allowing
it, and designing for it.  And a good way to keep that intention/
separation is having separate projects for the different components so
that both sides of an interface between components isn't "owned" by
the same group.

Not that I have any great answers for all of this.. I guess it's just
something that struck me the more I tried to understand Lift and I
wanted to make sure my thinking/reasoning was understood.  This isn't
anything to make me going running for the hills or anything.

Alan


From: David Pollak
> Also, just an observation, it seems that Lift is trying to be like
> Rails.. IE handle every layer by itself.

It has solutions for most layers because in my experience, most of the
other
solutions don't meet my needs.  Most of the Java-derived stuff is
amazingly
heavy weight and requires too much hidden state, XML files, etc.  I've
tried
to make Lift as much as possible oriented to the strengths of Scala
and to
getting common things done simply, easily, and securely.

>  I'm not sure that's a good
> thing..  such as it's own O/R tools,

You're seeing on another thread just how hard it is to use JPA.  I
don't
know if that's JPA, JPA with Scala or what, but it's not as easy as
Lift's
OR mapper and Lift's OR mapper comes with a lot of side benefits as
it's
integrated into common REST and HTML tasks.  Also, Lift's OR Mapper is
optional.  If you want to use JPA, go right ahead.

> it's own authentication stuff,

Which is optional... except how many web apps don't have
authentication?
So, you can roll your own or use the Lift stuff.  Your choice.

> it's own templating (well wicket modified/adapted)

It's Wicket inspired, not adapted and there are very compelling
reasons for
Lift's templating engine.  Please read the View
Firstdocument.  Lift is
not front-controller.

> etc..  Correct me
> if I'm wrong.  Anyway.. it's early days yet.. maybe they'll split off.

There are half a dozen Lift sub-packages and there will be more
divisions of
Lift.  But at the end of the day, Lift gives me most of the common
things I
do when I build web apps.  Why shouldn't a web framework do this?

Thanks,

David

> Alan

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



[Lift] WebService example and versions of Lift

2008-09-05 Thread Alan M

As far as I can tell the example doesn't compile with any version of
Lift.  ResponseIt is gone in .10 and SimpleController exists only in .
10.

So I'm trying to create a basic web service based on the example, any
advice on how to proceed?  What is the replacement for ResponseIt or
what should I use instead of SimpleController?

To be honest I'm having a hell of a time so far.  It seems that Lift
is very much tailored towards standard webapps with templated pages
and O/R mapped data from databases, etc... But in my case, I'm getting
my data from other sources and in particular I'm getting my user
authentication and authorization data from an unusual source.  So it's
been particularly hard for me to know when I should use the standard
Lift stuff and when I should/can go it on my own.  Which may explain
why I'm so highly interested in using/referencing/blatantly copying
the Web Service example on the wiki.

Also, just an observation, it seems that Lift is trying to be like
Rails.. IE handle every layer by itself.  I'm not sure that's a good
thing..  such as it's own O/R tools, it's own authentication stuff,
it's own templating (well wicket modified/adapted) etc..  Correct me
if I'm wrong.  Anyway.. it's early days yet.. maybe they'll split off.

Alan

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