[Lift] Re: apache proxy_balancer

2009-09-16 Thread jon

I was able to get things working and am now fairly confident that I
have enough power on my front end to completely melt my database.   I
think the real benefits will be failover and the ability to stage
releases.

Btw, as far as I can tell, apache proxy_balancer is the only open
source choice for load balancing with sticky sessions. Is anyone aware
of other options?  I would much rather be using nginx.  I'm aware that
there's a third party module for session stickyness, but not sure if
it's at a usable stage: http://code.google.com/p/nginx-upstream-jvm-route/

I'm actually not sure what the problem was with the config below,
though the duplicate "ProxyPass / balancer://cluster/" was probably
not helping

- Jon

On Sep 16, 7:05 pm, jon  wrote:
> Hi,
>
> Is anyone running lift behind apache with proxy_balancer?  I'm trying
> to get that setup, but seeing a really odd problem where the
> javascript on the page seems to cause continuous reloading on some
> pages.  I haven't yet fully investigated the problem, but am wondering
> if anyone has some pointers for getting that setup correctly.
>
> Here's what I'm doing:
>
> In my apache config:
>
> ProxyPass /balancer !
> ProxyPass / balancer://cluster/ stickysession=jsessionid|JSESSIONID
> nofailover=On
>
> 
>     BalancerMemberhttp://serveroneloadfactor=50 route=n2
>     BalancerMemberhttp://servertwoloadfactor=50 route=n1
> 
> ProxyRequests Off
>
> 
>         Order deny,allow
>         Allow from all
> 
> ProxyPreserveHost On
> ProxyPass / balancer://cluster/
>
> And in each of my jetty.xml files, something like this:
>
> 
>      
>         n2
>      
> 
--~--~-~--~~~---~--~~
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: Comet Actors - single browser, multiple tabs, same URL - out of control GET problem

2009-09-16 Thread Xavi Ramirez

I vaguely remember reading a thread that claimed Lift would
auto-increase the 2 connection limit for sessions using more modern
browsers.  Is this feature in M5?

Random Idea:
Would it be possible to get around the 2 connection limit by sending
each comet request to a unique sub-domain?

For example, current lift webapps send comet requests to:
http://www.[your-domain].com/comet_request/96624280773/vhbz24xby3vm

Could lift instead send comet requests to
comet[uniqueId].[your-domain].com/[params]?

Thanks,
Xavi

On Wed, Sep 16, 2009 at 7:49 PM, David Pollak
 wrote:
>
>
> On Wed, Sep 16, 2009 at 4:18 PM, Dano  wrote:
>>
>> We have a lift app (innovationgames.com) which has a page (actually
>> several) with comet actors.  When we go to the same URL in two tabs in
>> the same browser, we see that the long polls (GET requests) return
>> immediately in rapid fire succession and this behavior continues until
>> we exit one of the tabs.
>>
>> We thought maybe we did something wrong in our code, so we tried the
>> same thing using demo.liftweb.net.  We saw the same behavior in the
>> demo site that we see in our site.
>>
>> If you try this with something else like Gmail, it does not show this
>> behavior.
>
> It's not a bug.
> There is a 2 connection per server per browser limit (in most browsers
> although Chrome and FF 3.5 apparently have relaxed this limit).  If there is
> a long polling operation in progress and a second request comes into the
> same session, Lift will immediately end the long polling operation in order
> not to starve the connections.
>>
>> I thought I would post to this group and get some feedback before
>> submitting a bug.
>
>
>>
>> Thanks in advance.
>>
>>
>> Dano
>>
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://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: Comet Actors - single browser, multiple tabs, same URL - out of control GET problem

2009-09-16 Thread DFectuoso

That seems like a logical reason why this is like this, but if i open
2 tabs of http://demo.liftweb.net/, both tabs start to send ajax
request every 100ms, that is 20 ajax request per second, 72k per hour,
so if an app had 100 crazy users who happen to open 2 tabs of the app
(this happens to me a lot, im messy with my tabs) that means 7.2
million request per hour to the server? isnt that something we might
want to avoid somehow?

I'm guessing we can't really fight the connection limit, but we should
be able to specify a frequency to the js if we are going to enter to a
"polling" policy (instead of long poll)?

On Sep 16, 4:49 pm, David Pollak 
wrote:
> On Wed, Sep 16, 2009 at 4:18 PM, Dano  wrote:
>
> > We have a lift app (innovationgames.com) which has a page (actually
> > several) with comet actors.  When we go to the same URL in two tabs in
> > the same browser, we see that the long polls (GET requests) return
> > immediately in rapid fire succession and this behavior continues until
> > we exit one of the tabs.
>
> > We thought maybe we did something wrong in our code, so we tried the
> > same thing using demo.liftweb.net.  We saw the same behavior in the
> > demo site that we see in our site.
>
> > If you try this with something else like Gmail, it does not show this
> > behavior.
>
> It's not a bug.
>
> There is a 2 connection per server per browser limit (in most browsers
> although Chrome and FF 3.5 apparently have relaxed this limit).  If there is
> a long polling operation in progress and a second request comes into the
> same session, Lift will immediately end the long polling operation in order
> not to starve the connections.
>
> > I thought I would post to this group and get some feedback before
> > submitting a bug.
>
> > Thanks in advance.
>
> > Dano
>
> --
> 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: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

2009-09-16 Thread Heiko Seeberger
Of course in a perfect world we would like to use the perfect EPFL actors.
But as know the world, well at least EPFL actors, are not perfect. By the
way: Scala is a lot about libraries, hence IMHO it is OK if Lift uses it's
own approach for actors.
=> Let's go for lift-actor, if possible abstracted to common interfaces to
swap in others like Akka

Heiko

2009/9/16 David Pollak 

>
>
> On Wed, Sep 16, 2009 at 7:50 AM, Timothy Perrett 
> wrote:
>
>> Kevin,
>>
>> To clarify, your talking about akka-actors?
>>
>> The preferred route I think would be to use a fixed EPFL implementation,
>> however, in leu of that i think from a project perspective it would be
>> beneficial for lift to have a corrected actor implementation that we have
>> direct control of. I know DPP would certainly have this be his preference
>> despite Jonas, Viktor and myself being commiters on both projects :-)
>>
>> Bottom line here is that we need this fixed, asap and the path of least
>> resistance is to use lift-actor until EPFL fix the core actor code.
>>
>
> If we make the change, we're not switching back.  If EPFL wants to make
> their Actors conform to a common Akka/Lift interface, that would allow them
> to be used, but otherwise, if we go down this path I'm not messing with EPFL
> Actors anymore.
>
>
>>
>> Cheers, Tim
>>
>>
>>
>> On 16 Sep 2009, at 14:27, Kevin Wright wrote:
>>
>> Is there any reason not to go with something like the Akka framework?  I
>> believe it has a lift-friendly license.
>>
>> On Wed, Sep 16, 2009 at 2:14 PM, David Pollak <
>> feeder.of.the.be...@gmail.com> wrote:
>>
>>> Guys,
>>> The Scala Actor issue has raised its head again.
>>>
>>> From November 2008 - June 2009, I did an epic battle with Scala actors
>>> and their memory retention issues.
>>>
>>> I finally wrote a Lift Actor library that made all the Scala
>>> Actor-related issues go away for the short-lived Actors that Lift uses as
>>> listeners for comet long-polling.
>>>
>>> It seems that the Actor issue is not gone.  I'm not sure it will be gone
>>> in Scala 2.8.
>>>
>>> I can make a change in Lift to move to Lift Actors in CometActor code.
>>>  It means that if you're using Scala Actors beyond !, !! and !? methods, you
>>> will have to change your code, otherwise it will just be a recompile.
>>>
>>> What do people think?
>>>
>>> Thanks,
>>>
>>> David
>>>
>>> --
>>> Lift, the simply functional web framework http://liftweb.net
>>> Beginning Scala http://www.apress.com/book/view/1430219890
>>> Follow me: http://twitter.com/dpp
>>> Git some: http://github.com/dpp
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://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] JPA with more than one front end (Maven! sigh...)

2009-09-16 Thread Charles F. Munat

I have a Lift project with a JPA backend subproject, and then two Lift 
front ends that access the same back end, also as subprojects.

So my master pom.xml looks like this:

   
 web
 web2
 spa
   

Works beautifully. Web responds on one port and Web2 on another (when I 
use the internal Jetty).

But when I do mvn package and put the war on the server, somehow the 
"spa" backend classes do not get included.

Any idea what I'm doing wrong?

Chas.

--~--~-~--~~~---~--~~
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: OOME in using CometActor

2009-09-16 Thread Atsuhiko Yamanaka

Hi,

On Wed, Sep 16, 2009 at 11:50 PM, Atsuhiko Yamanaka
 wrote:
> I'll try lower value, for example, 50 for maxPoolSize before going to the bed.
> I'll look forward to the good result in the next morning.

I got the good result.

By setting maxPoolSize as 50, OOME had not appeared.
With that setting, 50 FJTaskRunner instances was allocated and
204,800 FJTaskRunner$VolatileTaskRef were there in the heap.

I guess that 204,800 corresponds to 50*4096[1].  According to VisualVM, those
204,800 instances cost 2,457,600( == 50*4096*12) bytes.

So, for the default maxPoolSize(255), we will be able to prevent this
kind of OOME
by adding additional 12,533,760 bytes heap size for VolatileTaskRef.

As for the changing the implementation of CometActor in the other thread,
I think current implementation may be enough for "scala 2.7.x" at least,
if we can share above knowledge.

Anyway, thank for your help. Now, my lift app becomes sustainable.
It is a desktop image sharing service and heavily depends on CometActor.
If you are interested in it, it has been experimentally running at
http://lift.jcraft.com/dstream/sc...@tohoku2 .

[1] 
http://lampsvn.epfl.ch/trac/scala/browser/scala/tags/R_2_7_6_final/src/actors/scala/actors/FJTaskRunner.java#L244


Sincerely,
--
Atsuhiko Yamanaka
JCraft,Inc.
1-14-20 HONCHO AOBA-KU,
SENDAI, MIYAGI 980-0014 Japan.
Tel +81-22-723-2150
+1-415-578-3454
Skype callto://jcraft/

--~--~-~--~~~---~--~~
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: Remove OAuth module?

2009-09-16 Thread David Pollak
It's the OAuth server, not OAuth client stuff.  I want to get this feature
into 1.1, so let's not delete the project.

On Wed, Sep 16, 2009 at 2:15 PM, Timothy Perrett wrote:

>
> Guys,
>
> Should we remove the OAuth module now? No code was ever commited to it
> and frankly, n8han's dispatch project (also avalible on scala-tools)
> has amazing scala oauth built in so im not sure we could add any value
> in this arena.
>
> Thoughts?
>
> Cheers, Tim
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://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: suggestion: make Mailer use n.l.util.Props

2009-09-16 Thread David Pollak
Open a ticket... I'll see what I can do to merge system properties and
Lift's props.

On Wed, Sep 16, 2009 at 1:39 PM, harryh  wrote:

>
> Rather than using System.getProperties should Mailer use
> net.liftweb.util.Props?  It seems a little inconsistent as is.
>
> -harryh
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://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: Wicket vs Tapestry vs Grails vs Lift?

2009-09-16 Thread David Pollak
On Wed, Sep 16, 2009 at 4:08 PM, etorreborre  wrote:

>
> Hi,
>
> Anyone is interested in coding the same app with Lift and have a look
> at the numbers?
>

I'm interested, but don't have the time. :-(


>
>
> http://ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-5-and-grails
>
> Eric.
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://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: Comet Actors - single browser, multiple tabs, same URL - out of control GET problem

2009-09-16 Thread David Pollak
On Wed, Sep 16, 2009 at 4:18 PM, Dano  wrote:

>
> We have a lift app (innovationgames.com) which has a page (actually
> several) with comet actors.  When we go to the same URL in two tabs in
> the same browser, we see that the long polls (GET requests) return
> immediately in rapid fire succession and this behavior continues until
> we exit one of the tabs.
>
> We thought maybe we did something wrong in our code, so we tried the
> same thing using demo.liftweb.net.  We saw the same behavior in the
> demo site that we see in our site.
>
> If you try this with something else like Gmail, it does not show this
> behavior.
>

It's not a bug.

There is a 2 connection per server per browser limit (in most browsers
although Chrome and FF 3.5 apparently have relaxed this limit).  If there is
a long polling operation in progress and a second request comes into the
same session, Lift will immediately end the long polling operation in order
not to starve the connections.


> I thought I would post to this group and get some feedback before
> submitting a bug.
>



>
> Thanks in advance.
>
>
> Dano
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://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] Comet Actors - single browser, multiple tabs, same URL - out of control GET problem

2009-09-16 Thread Dano

We have a lift app (innovationgames.com) which has a page (actually
several) with comet actors.  When we go to the same URL in two tabs in
the same browser, we see that the long polls (GET requests) return
immediately in rapid fire succession and this behavior continues until
we exit one of the tabs.

We thought maybe we did something wrong in our code, so we tried the
same thing using demo.liftweb.net.  We saw the same behavior in the
demo site that we see in our site.

If you try this with something else like Gmail, it does not show this
behavior.

I thought I would post to this group and get some feedback before
submitting a bug.

Thanks in advance.


Dano
--~--~-~--~~~---~--~~
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] Wicket vs Tapestry vs Grails vs Lift?

2009-09-16 Thread etorreborre

Hi,

Anyone is interested in coding the same app with Lift and have a look
at the numbers?

http://ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-5-and-grails

Eric.
--~--~-~--~~~---~--~~
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] apache proxy_balancer

2009-09-16 Thread jon

Hi,

Is anyone running lift behind apache with proxy_balancer?  I'm trying
to get that setup, but seeing a really odd problem where the
javascript on the page seems to cause continuous reloading on some
pages.  I haven't yet fully investigated the problem, but am wondering
if anyone has some pointers for getting that setup correctly.

Here's what I'm doing:

In my apache config:

ProxyPass /balancer !
ProxyPass / balancer://cluster/ stickysession=jsessionid|JSESSIONID
nofailover=On


BalancerMember http://serverone loadfactor=50 route=n2
BalancerMember http://servertwo loadfactor=50 route=n1

ProxyRequests Off


Order deny,allow
Allow from all

ProxyPreserveHost On
ProxyPass / balancer://cluster/


And in each of my jetty.xml files, something like this:


 
n2
 

--~--~-~--~~~---~--~~
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: suggestion: make Mailer use n.l.util.Props

2009-09-16 Thread Timothy Perrett

I think the mailer is some of the oldest code in lift - so its not a  
huge surprise :-)

Im a bit tied up, but which committer should take this on and fix it?

Cheers, Tim

On 16 Sep 2009, at 21:39, harryh wrote:

>
> Rather than using System.getProperties should Mailer use
> net.liftweb.util.Props?  It seems a little inconsistent as is.
>
> -harryh
>
> >
>


--~--~-~--~~~---~--~~
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] Remove OAuth module?

2009-09-16 Thread Timothy Perrett

Guys,

Should we remove the OAuth module now? No code was ever commited to it
and frankly, n8han's dispatch project (also avalible on scala-tools)
has amazing scala oauth built in so im not sure we could add any value
in this arena.

Thoughts?

Cheers, Tim
--~--~-~--~~~---~--~~
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] suggestion: make Mailer use n.l.util.Props

2009-09-16 Thread harryh

Rather than using System.getProperties should Mailer use
net.liftweb.util.Props?  It seems a little inconsistent as is.

-harryh

--~--~-~--~~~---~--~~
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: DB Log issue, escaping placeholders & LoggedPreparedStatement.paramified()

2009-09-16 Thread Ewan

All working now.

ta

On Sep 16, 6:47 pm, Derek Chen-Becker  wrote:
> It's checked into the build. Hudson is building it now.
>
> On Wed, Sep 16, 2009 at 11:33 AM, Ewan  wrote:
>
> > Thx
>
> > On Sep 16, 5:52 pm, Derek Chen-Becker  wrote:
> > >http://reviewboard.liftweb.net/r/7/
>
> > > Once that gets approved I'll check it into trunk and Hudson will have it
> > > built shortly.
>
> > > Derek
>
> > > On Wed, Sep 16, 2009 at 10:35 AM, Derek Chen-Becker
> > > wrote:
>
> > > > OK, I see where I broke things. Let me fix this.
>
> > > > Derek
>
> > > > On Wed, Sep 16, 2009 at 1:56 AM, Ewan  wrote:
>
> > > >> Derek
>
> > > >> This one is for you I think.  After updating my Boot.scala with
> > > >> revised DB.addLogFunc I have found an issue with logging prepared
> > > >> statements.  My usecase is an insert/update that sets a MappedString -
> > > >> this MappedString is to hold a url such as "http://
> > > >>www.northnorfolkholidaylet.com".  No problem there but if the url also
> > > >> contains a query param the logger stacktraces (below).  The string
> > > >> causing the problem is "http://www.northnorfolkholidaylet.com?
> > > >> property=33".  Looking at LoggingStatementWrappers.scala line 313 it
> > > >> replaces prepared statements placeholders '?' with the the required
> > > >> values but my string value introduces/injects an extra '?' which
> > > >> causes it to fail badly.
>
> > > >> Exception occured while processing /property/edit/5
>
> > > >> Message: java.util.NoSuchElementException: key not found: 4
> > > >>        scala.collection.Map$class.default(Map.scala:169)
> > > >>        scala.collection.immutable.Map3.default(Map3.scala:22)
> > > >>        scala.collection.Map$class.apply(Map.scala:80)
> > > >>        scala.collection.immutable.Map3.apply(Map3.scala:22)
> > > >>        net.liftweb.mapper.LoggedPreparedStatement.substitute$1
> > > >> (LoggingStatementWrappers.scala:315)
> > > >>        net.liftweb.mapper.LoggedPreparedStatement.net$liftweb$mapper
> > > >> $LoggedPreparedStatement$$paramified(LoggingStatementWrappers.scala:
> > > >> 318)
>
> >  net.liftweb.mapper.LoggedPreparedStatement$$anonfun$executeUpdate
> > > >> $9.apply(LoggingStatementWrappers.scala:347)
>
> >  net.liftweb.mapper.LoggedPreparedStatement$$anonfun$executeUpdate
> > > >> $9.apply(LoggingStatementWrappers.scala:347)
> > > >>        net.liftweb.mapper.DBLog$class.logStatement
> > > >> (LoggingStatementWrappers.scala:46)
> > > >>        net.liftweb.mapper.LoggedStatement.logStatement
> > > >> (LoggingStatementWrappers.scala:71)
> > > >>        net.liftweb.mapper.LoggedPreparedStatement.executeUpdate
> > > >> (LoggingStatementWrappers.scala:347)
> > > >>        net.liftweb.mapper.MetaMapper$$anonfun$14$$anonfun$15.apply
> > > >> (MetaMapper.scala:653)
> > > >>        net.liftweb.mapper.MetaMapper$$anonfun$14$$anonfun$15.apply
> > > >> (MetaMapper.scala:636)
>
> > > >>  net.liftweb.mapper.DB$$anonfun$runPreparedStatement$1.apply(DB.scala:
> > > >> 375)
>
> > > >>  net.liftweb.mapper.DB$$anonfun$runPreparedStatement$1.apply(DB.scala:
> > > >> 372)
>
> >  net.liftweb.util.TimeHelpers$class.calcTime(TimeHelpers.scala:241)
> > > >>        net.liftweb.util.Helpers$.calcTime(Helpers.scala:29)
> > > >>        net.liftweb.mapper.DB$.runPreparedStatement(DB.scala:372)
> > > >>        net.liftweb.mapper.DB$.prepareStatement(DB.scala:316)
>
> > > >>  net.liftweb.mapper.MetaMapper$$anonfun$14.apply(MetaMapper.scala:635)
>
> > > >>  net.liftweb.mapper.MetaMapper$$anonfun$14.apply(MetaMapper.scala:630)
> > > >>        net.liftweb.mapper.DB$.use(DB.scala:389)
> > > >>        net.liftweb.mapper.MetaMapper$class.save(MetaMapper.scala:629)
>
> >  org.harrow.findaholidaylet.model.Property$.save(Property.scala:98)
>
> > > >> -- Ewan
>
>
--~--~-~--~~~---~--~~
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: Bug in MappedEmail: emailPattern is wrong

2009-09-16 Thread harryh

Hrm, MappedEmail is now rejecting e-mails with a - in the part before
the @.

is %-+ being interpreted as % through + and not % OR - OR + ?

-harryh, who is easily confused by regular expressions

On Aug 26, 7:32 pm, David Pollak 
wrote:
> Thanks.
>
> Changed and pushed to GitHub.  Allow 2 hours for Maven availability.
>
> On Wed, Aug 26, 2009 at 4:15 PM, harryh  wrote:
>
> > > What's the change to the RegEx?
>
> > val emailPattern = Pattern.compile("^[a-z0-9._%-+]+@(?:[a-z0-9-]+\\.)+
> > [a-z]{2,4}$")
>
> > note the addition of the + to the allowed characters before the @
>
> > -harryh
>
> --
> 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: Still getting nuts with getting/setting foreign key fields

2009-09-16 Thread David Pollak
On Wed, Sep 16, 2009 at 10:58 AM, Tobias Daub  wrote:

>
> Hey Lifters,
>
> Simple problem, but kind of difficult solution:
>
> I've a foreign key field, e.g. myField. I want to get the id of the field.
>
> So I wrote a method inside the class:
>
> def getMyFieldId = myField.obj.map(_.id.is) openOr 0L
>

// why load the object and ask for its id when you already know the id?

def getMyFieldId = myField.is


>
> IDs always start with one, right?
>
> But I get zero back! Why? I definitely know that this foreign key
> exists, because I can print another field value from the foreign key
> object inside some form...? That doesn't make any sense to me.
>
> thanks and sorry for always asking the same questions.
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://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] Still getting nuts with getting/setting foreign key fields

2009-09-16 Thread Tobias Daub

Hey Lifters,

Simple problem, but kind of difficult solution:

I've a foreign key field, e.g. myField. I want to get the id of the field.

So I wrote a method inside the class:

def getMyFieldId = myField.obj.map(_.id.is) openOr 0L

IDs always start with one, right?

But I get zero back! Why? I definitely know that this foreign key 
exists, because I can print another field value from the foreign key 
object inside some form...? That doesn't make any sense to me.

thanks and sorry for always asking the same questions.

--~--~-~--~~~---~--~~
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: DB Log issue, escaping placeholders & LoggedPreparedStatement.paramified()

2009-09-16 Thread Derek Chen-Becker
It's checked into the build. Hudson is building it now.

On Wed, Sep 16, 2009 at 11:33 AM, Ewan  wrote:

>
> Thx
>
> On Sep 16, 5:52 pm, Derek Chen-Becker  wrote:
> > http://reviewboard.liftweb.net/r/7/
> >
> > Once that gets approved I'll check it into trunk and Hudson will have it
> > built shortly.
> >
> > Derek
> >
> > On Wed, Sep 16, 2009 at 10:35 AM, Derek Chen-Becker
> > wrote:
> >
> > > OK, I see where I broke things. Let me fix this.
> >
> > > Derek
> >
> > > On Wed, Sep 16, 2009 at 1:56 AM, Ewan  wrote:
> >
> > >> Derek
> >
> > >> This one is for you I think.  After updating my Boot.scala with
> > >> revised DB.addLogFunc I have found an issue with logging prepared
> > >> statements.  My usecase is an insert/update that sets a MappedString -
> > >> this MappedString is to hold a url such as "http://
> > >>www.northnorfolkholidaylet.com".  No problem there but if the url also
> > >> contains a query param the logger stacktraces (below).  The string
> > >> causing the problem is "http://www.northnorfolkholidaylet.com?
> > >> property=33".  Looking at LoggingStatementWrappers.scala line 313 it
> > >> replaces prepared statements placeholders '?' with the the required
> > >> values but my string value introduces/injects an extra '?' which
> > >> causes it to fail badly.
> >
> > >> Exception occured while processing /property/edit/5
> >
> > >> Message: java.util.NoSuchElementException: key not found: 4
> > >>scala.collection.Map$class.default(Map.scala:169)
> > >>scala.collection.immutable.Map3.default(Map3.scala:22)
> > >>scala.collection.Map$class.apply(Map.scala:80)
> > >>scala.collection.immutable.Map3.apply(Map3.scala:22)
> > >>net.liftweb.mapper.LoggedPreparedStatement.substitute$1
> > >> (LoggingStatementWrappers.scala:315)
> > >>net.liftweb.mapper.LoggedPreparedStatement.net$liftweb$mapper
> > >> $LoggedPreparedStatement$$paramified(LoggingStatementWrappers.scala:
> > >> 318)
> > >>
>  net.liftweb.mapper.LoggedPreparedStatement$$anonfun$executeUpdate
> > >> $9.apply(LoggingStatementWrappers.scala:347)
> > >>
>  net.liftweb.mapper.LoggedPreparedStatement$$anonfun$executeUpdate
> > >> $9.apply(LoggingStatementWrappers.scala:347)
> > >>net.liftweb.mapper.DBLog$class.logStatement
> > >> (LoggingStatementWrappers.scala:46)
> > >>net.liftweb.mapper.LoggedStatement.logStatement
> > >> (LoggingStatementWrappers.scala:71)
> > >>net.liftweb.mapper.LoggedPreparedStatement.executeUpdate
> > >> (LoggingStatementWrappers.scala:347)
> > >>net.liftweb.mapper.MetaMapper$$anonfun$14$$anonfun$15.apply
> > >> (MetaMapper.scala:653)
> > >>net.liftweb.mapper.MetaMapper$$anonfun$14$$anonfun$15.apply
> > >> (MetaMapper.scala:636)
> >
> > >>  net.liftweb.mapper.DB$$anonfun$runPreparedStatement$1.apply(DB.scala:
> > >> 375)
> >
> > >>  net.liftweb.mapper.DB$$anonfun$runPreparedStatement$1.apply(DB.scala:
> > >> 372)
> > >>
>  net.liftweb.util.TimeHelpers$class.calcTime(TimeHelpers.scala:241)
> > >>net.liftweb.util.Helpers$.calcTime(Helpers.scala:29)
> > >>net.liftweb.mapper.DB$.runPreparedStatement(DB.scala:372)
> > >>net.liftweb.mapper.DB$.prepareStatement(DB.scala:316)
> >
> > >>  net.liftweb.mapper.MetaMapper$$anonfun$14.apply(MetaMapper.scala:635)
> >
> > >>  net.liftweb.mapper.MetaMapper$$anonfun$14.apply(MetaMapper.scala:630)
> > >>net.liftweb.mapper.DB$.use(DB.scala:389)
> > >>net.liftweb.mapper.MetaMapper$class.save(MetaMapper.scala:629)
> > >>
>  org.harrow.findaholidaylet.model.Property$.save(Property.scala:98)
> >
> > >> -- Ewan
> >
> >
> >
>

--~--~-~--~~~---~--~~
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: Money and Mapper

2009-09-16 Thread Derek Chen-Becker
That's available in 1.1-SNAPSHOT. If you need it for 1.0 I think that the
same code should work and you can just add it to your local codebase under
the net.liftweb.mapper package.

Derek

On Wed, Sep 16, 2009 at 10:51 AM, Naftoli Gugenheim wrote:

>
> MappedDecimal.
>
> -
> Jos? Mar?a wrote:
>
>
> Hi,
>
> I need to save some prices of products, while working in other
> languages I use some Decimal type so I don't have overflows and
> problems with IEEE floating point numbers. I see that Mapper has types
> for everything, from gender to postal codes... what about BigDecimal
> or Money?
>
> Cheers.
>
>
> >
>

--~--~-~--~~~---~--~~
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: DB Log issue, escaping placeholders & LoggedPreparedStatement.paramified()

2009-09-16 Thread Ewan

Thx

On Sep 16, 5:52 pm, Derek Chen-Becker  wrote:
> http://reviewboard.liftweb.net/r/7/
>
> Once that gets approved I'll check it into trunk and Hudson will have it
> built shortly.
>
> Derek
>
> On Wed, Sep 16, 2009 at 10:35 AM, Derek Chen-Becker
> wrote:
>
> > OK, I see where I broke things. Let me fix this.
>
> > Derek
>
> > On Wed, Sep 16, 2009 at 1:56 AM, Ewan  wrote:
>
> >> Derek
>
> >> This one is for you I think.  After updating my Boot.scala with
> >> revised DB.addLogFunc I have found an issue with logging prepared
> >> statements.  My usecase is an insert/update that sets a MappedString -
> >> this MappedString is to hold a url such as "http://
> >>www.northnorfolkholidaylet.com".  No problem there but if the url also
> >> contains a query param the logger stacktraces (below).  The string
> >> causing the problem is "http://www.northnorfolkholidaylet.com?
> >> property=33".  Looking at LoggingStatementWrappers.scala line 313 it
> >> replaces prepared statements placeholders '?' with the the required
> >> values but my string value introduces/injects an extra '?' which
> >> causes it to fail badly.
>
> >> Exception occured while processing /property/edit/5
>
> >> Message: java.util.NoSuchElementException: key not found: 4
> >>        scala.collection.Map$class.default(Map.scala:169)
> >>        scala.collection.immutable.Map3.default(Map3.scala:22)
> >>        scala.collection.Map$class.apply(Map.scala:80)
> >>        scala.collection.immutable.Map3.apply(Map3.scala:22)
> >>        net.liftweb.mapper.LoggedPreparedStatement.substitute$1
> >> (LoggingStatementWrappers.scala:315)
> >>        net.liftweb.mapper.LoggedPreparedStatement.net$liftweb$mapper
> >> $LoggedPreparedStatement$$paramified(LoggingStatementWrappers.scala:
> >> 318)
> >>        net.liftweb.mapper.LoggedPreparedStatement$$anonfun$executeUpdate
> >> $9.apply(LoggingStatementWrappers.scala:347)
> >>        net.liftweb.mapper.LoggedPreparedStatement$$anonfun$executeUpdate
> >> $9.apply(LoggingStatementWrappers.scala:347)
> >>        net.liftweb.mapper.DBLog$class.logStatement
> >> (LoggingStatementWrappers.scala:46)
> >>        net.liftweb.mapper.LoggedStatement.logStatement
> >> (LoggingStatementWrappers.scala:71)
> >>        net.liftweb.mapper.LoggedPreparedStatement.executeUpdate
> >> (LoggingStatementWrappers.scala:347)
> >>        net.liftweb.mapper.MetaMapper$$anonfun$14$$anonfun$15.apply
> >> (MetaMapper.scala:653)
> >>        net.liftweb.mapper.MetaMapper$$anonfun$14$$anonfun$15.apply
> >> (MetaMapper.scala:636)
>
> >>  net.liftweb.mapper.DB$$anonfun$runPreparedStatement$1.apply(DB.scala:
> >> 375)
>
> >>  net.liftweb.mapper.DB$$anonfun$runPreparedStatement$1.apply(DB.scala:
> >> 372)
> >>        net.liftweb.util.TimeHelpers$class.calcTime(TimeHelpers.scala:241)
> >>        net.liftweb.util.Helpers$.calcTime(Helpers.scala:29)
> >>        net.liftweb.mapper.DB$.runPreparedStatement(DB.scala:372)
> >>        net.liftweb.mapper.DB$.prepareStatement(DB.scala:316)
>
> >>  net.liftweb.mapper.MetaMapper$$anonfun$14.apply(MetaMapper.scala:635)
>
> >>  net.liftweb.mapper.MetaMapper$$anonfun$14.apply(MetaMapper.scala:630)
> >>        net.liftweb.mapper.DB$.use(DB.scala:389)
> >>        net.liftweb.mapper.MetaMapper$class.save(MetaMapper.scala:629)
> >>        org.harrow.findaholidaylet.model.Property$.save(Property.scala:98)
>
> >> -- Ewan
>
>
--~--~-~--~~~---~--~~
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: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

2009-09-16 Thread Derek Chen-Becker
I vote for lift-actor.

On Wed, Sep 16, 2009 at 10:46 AM, David Pollak <
feeder.of.the.be...@gmail.com> wrote:

>
>
> On Wed, Sep 16, 2009 at 7:50 AM, Timothy Perrett 
> wrote:
>
>> Kevin,
>>
>> To clarify, your talking about akka-actors?
>>
>> The preferred route I think would be to use a fixed EPFL implementation,
>> however, in leu of that i think from a project perspective it would be
>> beneficial for lift to have a corrected actor implementation that we have
>> direct control of. I know DPP would certainly have this be his preference
>> despite Jonas, Viktor and myself being commiters on both projects :-)
>>
>> Bottom line here is that we need this fixed, asap and the path of least
>> resistance is to use lift-actor until EPFL fix the core actor code.
>>
>
> If we make the change, we're not switching back.  If EPFL wants to make
> their Actors conform to a common Akka/Lift interface, that would allow them
> to be used, but otherwise, if we go down this path I'm not messing with EPFL
> Actors anymore.
>
>
>>
>> Cheers, Tim
>>
>>
>>
>> On 16 Sep 2009, at 14:27, Kevin Wright wrote:
>>
>> Is there any reason not to go with something like the Akka framework?  I
>> believe it has a lift-friendly license.
>>
>> On Wed, Sep 16, 2009 at 2:14 PM, David Pollak <
>> feeder.of.the.be...@gmail.com> wrote:
>>
>>> Guys,
>>> The Scala Actor issue has raised its head again.
>>>
>>> From November 2008 - June 2009, I did an epic battle with Scala actors
>>> and their memory retention issues.
>>>
>>> I finally wrote a Lift Actor library that made all the Scala
>>> Actor-related issues go away for the short-lived Actors that Lift uses as
>>> listeners for comet long-polling.
>>>
>>> It seems that the Actor issue is not gone.  I'm not sure it will be gone
>>> in Scala 2.8.
>>>
>>> I can make a change in Lift to move to Lift Actors in CometActor code.
>>>  It means that if you're using Scala Actors beyond !, !! and !? methods, you
>>> will have to change your code, otherwise it will just be a recompile.
>>>
>>> What do people think?
>>>
>>> Thanks,
>>>
>>> David
>>>
>>> --
>>> Lift, the simply functional web framework http://liftweb.net
>>> Beginning Scala http://www.apress.com/book/view/1430219890
>>> Follow me: http://twitter.com/dpp
>>> Git some: http://github.com/dpp
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://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: Clearing out options when submitting an empty multiSelect form

2009-09-16 Thread Aaron Valade

On Sep 16, 2009, at 1:07 PM, Derek Chen-Becker wrote:

> What's happening here is that the form doesn't submit a field for  
> "beacons" at all if nothing is selected, so the callback doesn't get  
> called. What I typically do in scenarios like this is add a hidden  
> field whose callback clears the collection. In your case, you could  
> move the "location.beacons.clear" inside the hidden callback for  
> "id" and have it all taken care of.


Ah, I didn't think about adding that clear statement there.  Thanks  
Derek!

- A

--~--~-~--~~~---~--~~
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: JSON forms problem

2009-09-16 Thread Derek Chen-Becker
I'll fix the book right now, but could you please send your complete head
method so that I make sure to include the correct code?

Derek

On Wed, Sep 16, 2009 at 9:30 AM, glenn  wrote:

>
> Marius,
>
> You are right. I added 

[Lift] Re: Clearing out options when submitting an empty multiSelect form

2009-09-16 Thread Derek Chen-Becker
What's happening here is that the form doesn't submit a field for "beacons"
at all if nothing is selected, so the callback doesn't get called. What I
typically do in scenarios like this is add a hidden field whose callback
clears the collection. In your case, you could move the
"location.beacons.clear" inside the hidden callback for "id" and have it all
taken care of.

Derek

On Wed, Sep 16, 2009 at 8:57 AM, Aaron Valade  wrote:

>
> Hello all-
> I'm having an issue when trying to update a many-to-one collection
> attached to a JPA object in Lift.  I'm currently using a
> SHtml.multiSelect for choosing which objects should be assigned to the
> many-to-one collection.  My bind statement looks like this:
>
> bind("location", xhtml,
>"id" -> SHtml.hidden(() => locationVar(current)),
>"name" -> SHtml.text(location.name, location.name = _),
>"beacons" -> SHtml.multiSelect(choices, default, {bsIds : List
> [String] => {
>location.beacons.clear
>bsIds.map( id =>
> location.beacons.add(Model.getReference(classOf
> [Beacon], id.toLong) ) )
>} } ),
>"save" -> SHtml.submit(?("Save"), doAdd) )
>
> This works great when I'm adding or removing beacons to my location as
> long as I don't unselect all options.  When I unselect all options, my
> closure for the multiSelect doesn't get called so the beacons Set
> doesn't get cleared out.
>
> How can I capture when I unselect everything in my multiSelect?
>
> Thanks in advance!
> - Aaron
>
> >
>

--~--~-~--~~~---~--~~
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: DB Log issue, escaping placeholders & LoggedPreparedStatement.paramified()

2009-09-16 Thread Derek Chen-Becker
http://reviewboard.liftweb.net/r/7/

Once that gets approved I'll check it into trunk and Hudson will have it
built shortly.

Derek

On Wed, Sep 16, 2009 at 10:35 AM, Derek Chen-Becker
wrote:

> OK, I see where I broke things. Let me fix this.
>
> Derek
>
>
> On Wed, Sep 16, 2009 at 1:56 AM, Ewan  wrote:
>
>>
>> Derek
>>
>> This one is for you I think.  After updating my Boot.scala with
>> revised DB.addLogFunc I have found an issue with logging prepared
>> statements.  My usecase is an insert/update that sets a MappedString -
>> this MappedString is to hold a url such as "http://
>> www.northnorfolkholidaylet.com".  No problem there but if the url also
>> contains a query param the logger stacktraces (below).  The string
>> causing the problem is "http://www.northnorfolkholidaylet.com?
>> property=33".  Looking at LoggingStatementWrappers.scala line 313 it
>> replaces prepared statements placeholders '?' with the the required
>> values but my string value introduces/injects an extra '?' which
>> causes it to fail badly.
>>
>> Exception occured while processing /property/edit/5
>>
>> Message: java.util.NoSuchElementException: key not found: 4
>>scala.collection.Map$class.default(Map.scala:169)
>>scala.collection.immutable.Map3.default(Map3.scala:22)
>>scala.collection.Map$class.apply(Map.scala:80)
>>scala.collection.immutable.Map3.apply(Map3.scala:22)
>>net.liftweb.mapper.LoggedPreparedStatement.substitute$1
>> (LoggingStatementWrappers.scala:315)
>>net.liftweb.mapper.LoggedPreparedStatement.net$liftweb$mapper
>> $LoggedPreparedStatement$$paramified(LoggingStatementWrappers.scala:
>> 318)
>>net.liftweb.mapper.LoggedPreparedStatement$$anonfun$executeUpdate
>> $9.apply(LoggingStatementWrappers.scala:347)
>>net.liftweb.mapper.LoggedPreparedStatement$$anonfun$executeUpdate
>> $9.apply(LoggingStatementWrappers.scala:347)
>>net.liftweb.mapper.DBLog$class.logStatement
>> (LoggingStatementWrappers.scala:46)
>>net.liftweb.mapper.LoggedStatement.logStatement
>> (LoggingStatementWrappers.scala:71)
>>net.liftweb.mapper.LoggedPreparedStatement.executeUpdate
>> (LoggingStatementWrappers.scala:347)
>>net.liftweb.mapper.MetaMapper$$anonfun$14$$anonfun$15.apply
>> (MetaMapper.scala:653)
>>net.liftweb.mapper.MetaMapper$$anonfun$14$$anonfun$15.apply
>> (MetaMapper.scala:636)
>>
>>  net.liftweb.mapper.DB$$anonfun$runPreparedStatement$1.apply(DB.scala:
>> 375)
>>
>>  net.liftweb.mapper.DB$$anonfun$runPreparedStatement$1.apply(DB.scala:
>> 372)
>>net.liftweb.util.TimeHelpers$class.calcTime(TimeHelpers.scala:241)
>>net.liftweb.util.Helpers$.calcTime(Helpers.scala:29)
>>net.liftweb.mapper.DB$.runPreparedStatement(DB.scala:372)
>>net.liftweb.mapper.DB$.prepareStatement(DB.scala:316)
>>
>>  net.liftweb.mapper.MetaMapper$$anonfun$14.apply(MetaMapper.scala:635)
>>
>>  net.liftweb.mapper.MetaMapper$$anonfun$14.apply(MetaMapper.scala:630)
>>net.liftweb.mapper.DB$.use(DB.scala:389)
>>net.liftweb.mapper.MetaMapper$class.save(MetaMapper.scala:629)
>>org.harrow.findaholidaylet.model.Property$.save(Property.scala:98)
>>
>> -- Ewan
>> >>
>>
>

--~--~-~--~~~---~--~~
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: Money and Mapper

2009-09-16 Thread Naftoli Gugenheim

MappedDecimal.

-
Jos? Mar?a wrote:


Hi,

I need to save some prices of products, while working in other
languages I use some Decimal type so I don't have overflows and
problems with IEEE floating point numbers. I see that Mapper has types
for everything, from gender to postal codes... what about BigDecimal
or Money?

Cheers.


--~--~-~--~~~---~--~~
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: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

2009-09-16 Thread David Pollak
On Wed, Sep 16, 2009 at 7:50 AM, Timothy Perrett wrote:

> Kevin,
>
> To clarify, your talking about akka-actors?
>
> The preferred route I think would be to use a fixed EPFL implementation,
> however, in leu of that i think from a project perspective it would be
> beneficial for lift to have a corrected actor implementation that we have
> direct control of. I know DPP would certainly have this be his preference
> despite Jonas, Viktor and myself being commiters on both projects :-)
>
> Bottom line here is that we need this fixed, asap and the path of least
> resistance is to use lift-actor until EPFL fix the core actor code.
>

If we make the change, we're not switching back.  If EPFL wants to make
their Actors conform to a common Akka/Lift interface, that would allow them
to be used, but otherwise, if we go down this path I'm not messing with EPFL
Actors anymore.


>
> Cheers, Tim
>
>
>
> On 16 Sep 2009, at 14:27, Kevin Wright wrote:
>
> Is there any reason not to go with something like the Akka framework?  I
> believe it has a lift-friendly license.
>
> On Wed, Sep 16, 2009 at 2:14 PM, David Pollak <
> feeder.of.the.be...@gmail.com> wrote:
>
>> Guys,
>> The Scala Actor issue has raised its head again.
>>
>> From November 2008 - June 2009, I did an epic battle with Scala actors and
>> their memory retention issues.
>>
>> I finally wrote a Lift Actor library that made all the Scala Actor-related
>> issues go away for the short-lived Actors that Lift uses as listeners for
>> comet long-polling.
>>
>> It seems that the Actor issue is not gone.  I'm not sure it will be gone
>> in Scala 2.8.
>>
>> I can make a change in Lift to move to Lift Actors in CometActor code.  It
>> means that if you're using Scala Actors beyond !, !! and !? methods, you
>> will have to change your code, otherwise it will just be a recompile.
>>
>> What do people think?
>>
>> Thanks,
>>
>> David
>>
>> --
>> Lift, the simply functional web framework http://liftweb.net
>> Beginning Scala http://www.apress.com/book/view/1430219890
>> Follow me: http://twitter.com/dpp
>> Git some: http://github.com/dpp
>>
>>
>>
>
>
>
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://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: MINOR BREAKING CHANGE IN mapper.view.ModelView

2009-09-16 Thread Naftoli Gugenheim

Do you override anything in UserView? If not you can just write
val view = new ModelView(new User)
etc.
Otherwise
class UserView(user: User) extends ModelView(user)
should work.
What happened is that in addition to maper.view.ModelView, the latter is 
subclassed inside ModelSnippet so you can leave out the snippet parameter. You 
can still use the old ModelView outside of a snippet (for whatever reason) as 
usual, or inside a snippet as view.ModelView etc.


-
glenn wrote:


Naftoli,

Since I don't seem to have the latest source to follow, how exactly
does this work now?.

If I currently have:this as my ModelView

class UserView(entity:User, snippet:ManageUsers) extends ModelView
[User](entity, snippet)

and

val view: ModelView[User] =  new UserView(new User,this)

in my ModelSnippet, leaving off the User type parameter doesn't
compile and neither does removing the "this" parameter or the snippet
parameter in the UserView type definition.

Glenn

On Sep 14, 3:10?pm, Naftoli Gugenheim  wrote:
> If you useModelViewin a ModelSnippet, read the following:
> I added an inner class to mapper.view.ModelSnippet calledModelView, which 
> extends mapper.view.ModelViewbut allows you to leave out the snippet 
> parameter.
> However if you were using these new classes you may have to make a small 
> change. If you useModelViewinside ModelSnippet, just leave out "this" from 
> the constructor.
> You may also be able to change "ModelView" to "view.ModelView."
> The Wiki article may not yet reflect this.


--~--~-~--~~~---~--~~
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: DB Log issue, escaping placeholders & LoggedPreparedStatement.paramified()

2009-09-16 Thread Derek Chen-Becker
OK, I see where I broke things. Let me fix this.

Derek

On Wed, Sep 16, 2009 at 1:56 AM, Ewan  wrote:

>
> Derek
>
> This one is for you I think.  After updating my Boot.scala with
> revised DB.addLogFunc I have found an issue with logging prepared
> statements.  My usecase is an insert/update that sets a MappedString -
> this MappedString is to hold a url such as "http://
> www.northnorfolkholidaylet.com".  No problem there but if the url also
> contains a query param the logger stacktraces (below).  The string
> causing the problem is "http://www.northnorfolkholidaylet.com?
> property=33".  Looking at LoggingStatementWrappers.scala line 313 it
> replaces prepared statements placeholders '?' with the the required
> values but my string value introduces/injects an extra '?' which
> causes it to fail badly.
>
> Exception occured while processing /property/edit/5
>
> Message: java.util.NoSuchElementException: key not found: 4
>scala.collection.Map$class.default(Map.scala:169)
>scala.collection.immutable.Map3.default(Map3.scala:22)
>scala.collection.Map$class.apply(Map.scala:80)
>scala.collection.immutable.Map3.apply(Map3.scala:22)
>net.liftweb.mapper.LoggedPreparedStatement.substitute$1
> (LoggingStatementWrappers.scala:315)
>net.liftweb.mapper.LoggedPreparedStatement.net$liftweb$mapper
> $LoggedPreparedStatement$$paramified(LoggingStatementWrappers.scala:
> 318)
>net.liftweb.mapper.LoggedPreparedStatement$$anonfun$executeUpdate
> $9.apply(LoggingStatementWrappers.scala:347)
>net.liftweb.mapper.LoggedPreparedStatement$$anonfun$executeUpdate
> $9.apply(LoggingStatementWrappers.scala:347)
>net.liftweb.mapper.DBLog$class.logStatement
> (LoggingStatementWrappers.scala:46)
>net.liftweb.mapper.LoggedStatement.logStatement
> (LoggingStatementWrappers.scala:71)
>net.liftweb.mapper.LoggedPreparedStatement.executeUpdate
> (LoggingStatementWrappers.scala:347)
>net.liftweb.mapper.MetaMapper$$anonfun$14$$anonfun$15.apply
> (MetaMapper.scala:653)
>net.liftweb.mapper.MetaMapper$$anonfun$14$$anonfun$15.apply
> (MetaMapper.scala:636)
>
>  net.liftweb.mapper.DB$$anonfun$runPreparedStatement$1.apply(DB.scala:
> 375)
>
>  net.liftweb.mapper.DB$$anonfun$runPreparedStatement$1.apply(DB.scala:
> 372)
>net.liftweb.util.TimeHelpers$class.calcTime(TimeHelpers.scala:241)
>net.liftweb.util.Helpers$.calcTime(Helpers.scala:29)
>net.liftweb.mapper.DB$.runPreparedStatement(DB.scala:372)
>net.liftweb.mapper.DB$.prepareStatement(DB.scala:316)
>
>  net.liftweb.mapper.MetaMapper$$anonfun$14.apply(MetaMapper.scala:635)
>
>  net.liftweb.mapper.MetaMapper$$anonfun$14.apply(MetaMapper.scala:630)
>net.liftweb.mapper.DB$.use(DB.scala:389)
>net.liftweb.mapper.MetaMapper$class.save(MetaMapper.scala:629)
>org.harrow.findaholidaylet.model.Property$.save(Property.scala:98)
>
> -- Ewan
> >
>

--~--~-~--~~~---~--~~
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] Money and Mapper

2009-09-16 Thread José María

Hi,

I need to save some prices of products, while working in other
languages I use some Decimal type so I don't have overflows and
problems with IEEE floating point numbers. I see that Mapper has types
for everything, from gender to postal codes... what about BigDecimal
or Money?

Cheers.
--~--~-~--~~~---~--~~
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: MINOR BREAKING CHANGE IN mapper.view.ModelView

2009-09-16 Thread glenn

Naftoli,

Since I don't seem to have the latest source to follow, how exactly
does this work now?.

If I currently have:this as my ModelView

class UserView(entity:User, snippet:ManageUsers) extends ModelView
[User](entity, snippet)

and

val view: ModelView[User] =  new UserView(new User,this)

in my ModelSnippet, leaving off the User type parameter doesn't
compile and neither does removing the "this" parameter or the snippet
parameter in the UserView type definition.

Glenn

On Sep 14, 3:10 pm, Naftoli Gugenheim  wrote:
> If you useModelViewin a ModelSnippet, read the following:
> I added an inner class to mapper.view.ModelSnippet calledModelView, which 
> extends mapper.view.ModelViewbut allows you to leave out the snippet 
> parameter.
> However if you were using these new classes you may have to make a small 
> change. If you useModelViewinside ModelSnippet, just leave out "this" from 
> the constructor.
> You may also be able to change "ModelView" to "view.ModelView."
> The Wiki article may not yet reflect this.
--~--~-~--~~~---~--~~
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: Code broken due to hanges to ModelView

2009-09-16 Thread glenn

Naftoli,

Pardon this new discussion. I just discovered your earlier post on
this issue. However,
the source for ModelView still shows it taking a type parameter. Has
that not been
updated yet?

Glenn

On Sep 16, 8:53 am, glenn  wrote:
> Further compounding my confusion, is that the  mapper.view package
> from
> the maven repo,http://scala-tools.org/repo-snapshots,  is not in
> GitHub, so are
> the two repositories out-of-sync, and have
> they always been so?
>
> Glenn
>
> On Sep 16, 8:45 am, glenn  wrote:
>
> > I realize the  risk one takes in using the latest SNAPSHOT source, but
> > there seems to be a recent change to
> > ModelView in the mapper package such that now, it doesn't take type
> > parameters. My questions is, if in my
> > existing ModelSnippet code, I have
>
> >     val view: ModelView[User] =  new UserView(new User, this)
>
> > where UserView extends ModelView[User],
>
> > what do I do to fix this error?
>
> > Glenn
--~--~-~--~~~---~--~~
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: Code broken due to hanges to ModelView

2009-09-16 Thread glenn

Further compounding my confusion, is that the  mapper.view package
from
the maven repo, http://scala-tools.org/repo-snapshots,  is not in
GitHub, so are
the two repositories out-of-sync, and have
they always been so?

Glenn

On Sep 16, 8:45 am, glenn  wrote:
> I realize the  risk one takes in using the latest SNAPSHOT source, but
> there seems to be a recent change to
> ModelView in the mapper package such that now, it doesn't take type
> parameters. My questions is, if in my
> existing ModelSnippet code, I have
>
>     val view: ModelView[User] =  new UserView(new User, this)
>
> where UserView extends ModelView[User],
>
> what do I do to fix this error?
>
> Glenn
--~--~-~--~~~---~--~~
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] Code broken due to hanges to ModelView

2009-09-16 Thread glenn

I realize the  risk one takes in using the latest SNAPSHOT source, but
there seems to be a recent change to
ModelView in the mapper package such that now, it doesn't take type
parameters. My questions is, if in my
existing ModelSnippet code, I have

val view: ModelView[User] =  new UserView(new User, this)

where UserView extends ModelView[User],

what do I do to fix this error?

Glenn
--~--~-~--~~~---~--~~
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: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

2009-09-16 Thread Viktor Klang
On Wed, Sep 16, 2009 at 4:50 PM, Timothy Perrett wrote:

> Kevin,
>
> To clarify, your talking about akka-actors?
>
> The preferred route I think would be to use a fixed EPFL implementation,
> however, in leu of that i think from a project perspective it would be
> beneficial for lift to have a corrected actor implementation that we have
> direct control of. I know DPP would certainly have this be his preference
> despite Jonas, Viktor and myself being commiters on both projects :-)
>
> Bottom line here is that we need this fixed, asap and the path of least
> resistance is to use lift-actor until EPFL fix the core actor code.
>

Seconded.


>
> Cheers, Tim
>
>
>
> On 16 Sep 2009, at 14:27, Kevin Wright wrote:
>
> Is there any reason not to go with something like the Akka framework?  I
> believe it has a lift-friendly license.
>
> On Wed, Sep 16, 2009 at 2:14 PM, David Pollak <
> feeder.of.the.be...@gmail.com> wrote:
>
>> Guys,
>> The Scala Actor issue has raised its head again.
>>
>> From November 2008 - June 2009, I did an epic battle with Scala actors and
>> their memory retention issues.
>>
>> I finally wrote a Lift Actor library that made all the Scala Actor-related
>> issues go away for the short-lived Actors that Lift uses as listeners for
>> comet long-polling.
>>
>> It seems that the Actor issue is not gone.  I'm not sure it will be gone
>> in Scala 2.8.
>>
>> I can make a change in Lift to move to Lift Actors in CometActor code.  It
>> means that if you're using Scala Actors beyond !, !! and !? methods, you
>> will have to change your code, otherwise it will just be a recompile.
>>
>> What do people think?
>>
>> Thanks,
>>
>> David
>>
>> --
>> Lift, the simply functional web framework http://liftweb.net
>> Beginning Scala http://www.apress.com/book/view/1430219890
>> Follow me: http://twitter.com/dpp
>> Git some: http://github.com/dpp
>>
>>
>>
>
>
>
>
> >
>


-- 
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang

Lift Committer - liftweb.com
AKKA Committer - akkasource.org
Cassidy - github.com/viktorklang/Cassidy.git
SoftPub founder: http://groups.google.com/group/softpub

--~--~-~--~~~---~--~~
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: What's the best way to get the current request URL

2009-09-16 Thread Ryan Donahue
Does that include the query string?

On Wed, Sep 16, 2009 at 11:21 AM, harryh  wrote:

>
> S.uri
>
> On Sep 16, 9:35 am, Ryan Donahue  wrote:
> > I want to capture the the current request URL, so I can redirect back
> > to it at a later point.  What's the best way to get at the URL?  The
> > answer is probably obvious, but I can't seem to find it.
> >
> > Thanks,
> >
> > Ryan
> >
>

--~--~-~--~~~---~--~~
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: JSON forms problem

2009-09-16 Thread glenn

Marius,

You are right. I added  to
my head method, and everything works great. The issue here, is that
the Lift Book example doesn't mention
this.

Glenn

On Sep 15, 9:07 pm, "marius d."  wrote:
> Right ... the head method should not have the js script but did you
> include the jlift.js script in your default template?
>
> I'll build an example this week (when I'll find some time for it) and
> see if I'm running into the same problems as you are. If you somehow
> manage to fix it please let me know. How urgent is this for you?
>
> Br's,
> Marius
>
> On Sep 15, 6:15 pm, glenn  wrote:
>
> > But, the head method does add the javascript to the page, so no src
> > attribute is needed, right?
>
> > On Sep 15, 3:59 pm, "marius d."  wrote:
>
> > > Where is the head function in your code ?
>
> > > Here is an example:
>
> > > def head =  {Script(json.jsCmd)}
>
> > > Br's,
> > > Marius
>
> > > On Sep 15, 5:55 pm, "marius d."  wrote:
>
> > > > Do you see any errors in FireBug ? ... Do see the Ajax request being
> > > > send out in FireBug?
>
> > > > On Sep 15, 5:49 pm, glenn  wrote:
>
> > > > > Derek,
>
> > > > > Here is the template. Just as in the book.
>
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > Volvo
> > > > > Saab
> > > > > Opel
> > > > > Audi
> > > > > 
> > > > > Submit
> > > > > 
> > > > > 
> > > > > 
>
> > > > > And  here is my JSONForm class:
>
> > > > > class JSONForm {
>
> > > > >   def head = {Script(json.jsCmd)}
> > > > >   def show(html: Group): NodeSeq = {
> > > > >       json.jsCmd
> > > > >       SHtml.jsonForm(json, html)
> > > > >   }
>
> > > > >    object json extends JsonHandler {
> > > > >                 def apply(in: Any): JsCmd =
> > > > >                   SetHtml("json_result", Text("This is a test"))
>
> > > > >   }
>
> > > > > }
>
> > > > > Here, I just simplified the JsCmd returned from the handler.
>
> > > > > I understand that in the head method, the call to json.jsCmd creates
> > > > > the ajax handler (from the apply method), but clicking on the submit
> > > > > button on the form doesn't populate the json_result div. In fact,
> > > > > it doesn't do anything even though, on the page source, the button's
> > > > > onclick method is
> > > > > wired up.
>
> > > > > Glenn
>
> > > > > On Sep 15, 11:59 am, Derek Chen-Becker  wrote:
>
> > > > > > The apply method should be getting called because the SHtml.json 
> > > > > > method
> > > > > > should register it as the handler for the form. Would you mind 
> > > > > > sending me
> > > > > > the code you have and I'll take a look at it? I'm pretty sure this 
> > > > > > code was
> > > > > > working at one point, but perhaps something has changed.
>
> > > > > > Derek
>
> > > > > > On Mon, Sep 14, 2009 at 2:03 PM, glenn  wrote:
>
> > > > > > > Actually, the JsonHandler in the example gets called, but not the 
> > > > > > > apply
> > > > > > > (in:Any) method, as
> > > > > > > that is never called in the book example. Also, the handler seems 
> > > > > > > to
> > > > > > > be called twice with every submit.
> > > > > > > Why is that?
>
> > > > > > > Glenn
>
> > > > > > > On Sep 14, 8:08 am, glenn  wrote:
> > > > > > > > This may be a question for the Lift Book forum, but has anyone 
> > > > > > > > gotten
> > > > > > > > the JSON forms example 8.13 in the Lift Book to work?  When I 
> > > > > > > > tried
> > > > > > > > it, the JsonHandler in class JSONForm never gets called when the
> > > > > > > > submit button is clicked.
>
> > > > > > > > Glenn
--~--~-~--~~~---~--~~
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: Proper way to upgrade Lift and Scala libs?

2009-09-16 Thread Wilson MacGyver

Got it, thanks for the info. Staying with 2.7.5 then. Just finished
moving to 2.7.6
for non-lift stuff yesterday, reverting... :)

On Wed, Sep 16, 2009 at 8:52 AM, David Pollak
 wrote:
>
>
> On Tue, Sep 15, 2009 at 9:01 PM, Wilson MacGyver 
> wrote:
>>
>> On Tue, Sep 15, 2009 at 11:44 PM, David Pollak
>>  wrote:
>> > Lift (1.1-X and 1.0.1/1.0.2) is compiled against Scala 2.7.5  This is
>> > the
>> > version you should be using.
>> > Do not upgrade to 2.7.6  2.7.6 is a broken release.
>>
>> can you expand on that? Do you mean 2.7.6 is a broken release for using it
>> with lift, or 2.7.6 is just plain broken for scala development, and should
>> stick to 2.7.5?
>
> Both.
> EPFL took a single change off the 2.8 development branch and grafted it onto
> 2.7.5 without testing beyond the standard Scala tests, without any beta
> period, without any discussion on scala-internals, and without any notes to
> the various stake-holders in the Scala community.  The change seems to break
> existential types.  Lift will not compile with the change.  Code compiled
> with the change will likely not work with 2.7.5 and code compiled under
> 2.7.5 will have different pickling (serialization) of Scala-related metadata
> in the class files.
> So, stay as far away from 2.7.6 as you can.
>
>
>>
>> --
>> Omnem crede diem tibi diluxisse supremum.
>>
>>
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
> >
>



-- 
Omnem crede diem tibi diluxisse supremum.

--~--~-~--~~~---~--~~
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: What's the best way to get the current request URL

2009-09-16 Thread harryh

S.uri

On Sep 16, 9:35 am, Ryan Donahue  wrote:
> I want to capture the the current request URL, so I can redirect back
> to it at a later point.  What's the best way to get at the URL?  The
> answer is probably obvious, but I can't seem to find it.
>
> Thanks,
>
> Ryan
--~--~-~--~~~---~--~~
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: Proper way to upgrade Lift and Scala libs?

2009-09-16 Thread Ike

On Sep 16, 8:58 am, David Pollak 
wrote:

> So, that's the Lift policy.  We will have to figure out if we're going to do
> a 1.0.3 release for Scala 2.8.  We're planning to release Lift 1.1 a few
> weeks after 2.8 goes live (which I'm expecting to be in late November-early
> January sometime.)
>
> > It would be great if we could do something
> > like mvn upgrade 1.0.2 or mvn upgrade current to take care of this, at
> > least for minor upgrades.
>
> Maybe a Maven maven on the list will describe if that's possible.

Thanks again for your quick response David. I'll keep an eye on this
list for any related posts. I still think it would be a good idea to
have a central resource that lists "official" Lift releases for
reference. Maybe on the Wiki? Something like:

Current Stable Release: 1.0.2
Compiled with Scala: 2.7.5
Documentation: http://xxx
New project sample Maven line: mvn ...

Latest Milestone Release: 1.1-M5
Compiled with Scala: 2.7.5
Documentation: http://xxx
New project sample Maven line: mvn ...

Last SNAPSHOT Release: 1.1-SNAPSHOT
Compiled with Scala: 2.8-b4
Documentation: http://xxx
New project sample Maven line: mvn ...

I'm thinking a simple version of the Springsource download page for
example: http://www.springsource.org/download

I'll be happy to set up the initial page but I can't commit to keeping
it up-to-date at this point.

--~--~-~--~~~---~--~~
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] Clearing out options when submitting an empty multiSelect form

2009-09-16 Thread Aaron Valade

Hello all-
I'm having an issue when trying to update a many-to-one collection
attached to a JPA object in Lift.  I'm currently using a
SHtml.multiSelect for choosing which objects should be assigned to the
many-to-one collection.  My bind statement looks like this:

bind("location", xhtml,
"id" -> SHtml.hidden(() => locationVar(current)),
"name" -> SHtml.text(location.name, location.name = _),
"beacons" -> SHtml.multiSelect(choices, default, {bsIds : List
[String] => {
location.beacons.clear
bsIds.map( id => location.beacons.add(Model.getReference(classOf
[Beacon], id.toLong) ) )
} } ),
"save" -> SHtml.submit(?("Save"), doAdd) )

This works great when I'm adding or removing beacons to my location as
long as I don't unselect all options.  When I unselect all options, my
closure for the multiSelect doesn't get called so the beacons Set
doesn't get cleared out.

How can I capture when I unselect everything in my multiSelect?

Thanks in advance!
- Aaron

--~--~-~--~~~---~--~~
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: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

2009-09-16 Thread Timothy Perrett
Kevin,

To clarify, your talking about akka-actors?

The preferred route I think would be to use a fixed EPFL  
implementation, however, in leu of that i think from a project  
perspective it would be beneficial for lift to have a corrected actor  
implementation that we have direct control of. I know DPP would  
certainly have this be his preference despite Jonas, Viktor and myself  
being commiters on both projects :-)

Bottom line here is that we need this fixed, asap and the path of  
least resistance is to use lift-actor until EPFL fix the core actor  
code.

Cheers, Tim



On 16 Sep 2009, at 14:27, Kevin Wright wrote:

> Is there any reason not to go with something like the Akka  
> framework?  I believe it has a lift-friendly license.
>
> On Wed, Sep 16, 2009 at 2:14 PM, David Pollak  > wrote:
> Guys,
>
> The Scala Actor issue has raised its head again.
>
> From November 2008 - June 2009, I did an epic battle with Scala  
> actors and their memory retention issues.
>
> I finally wrote a Lift Actor library that made all the Scala Actor- 
> related issues go away for the short-lived Actors that Lift uses as  
> listeners for comet long-polling.
>
> It seems that the Actor issue is not gone.  I'm not sure it will be  
> gone in Scala 2.8.
>
> I can make a change in Lift to move to Lift Actors in CometActor  
> code.  It means that if you're using Scala Actors beyond !, !!  
> and !? methods, you will have to change your code, otherwise it will  
> just be a recompile.
>
> What do people think?
>
> Thanks,
>
> David
>
> -- 
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://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: OOME in using CometActor

2009-09-16 Thread Atsuhiko Yamanaka

Hi,

On Wed, Sep 16, 2009 at 11:36 PM, Erik Engbrecht
 wrote:
> Yes, particularly maxPoolSize.

Thank you for prompt reply.
I'll try lower value, for example, 50 for maxPoolSize before going to the bed.
I'll look forward to the good result in the next morning.


Sincerely,
--
Atsuhiko Yamanaka
JCraft,Inc.
1-14-20 HONCHO AOBA-KU,
SENDAI, MIYAGI 980-0014 Japan.
Tel +81-22-723-2150
+1-415-578-3454
Skype callto://jcraft/

--~--~-~--~~~---~--~~
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: How to XHTML and embedded snippets

2009-09-16 Thread Ewan

Thank you - all works if I replace

"image" -> 

with

"image" -%> 

which results in the expected

http://clients.vc-ltd.co.uk/burnham2/photos/rose.jpg";
height="100" width="75" style="border:3px solid #CC" />

-- Ewan

On Sep 16, 2:40 pm, Naftoli Gugenheim  wrote:
> Tim is right that it worked that way, but apparently that code was committed 
> before the review board was in place :) because DPP wasn't happy with it and 
> took it out. Instead you can use -%> to bind and preserve all attributes.
>
> -
>
> Ewan wrote:
>
> Thanks but I still have no joy.  My snippet binding is as follows:
>
> property.map ({ p =>
>         bind("property", html,
>              "id" -> p.id,
>              "name" -> p.name,
>              "image" -> )
>     }) openOr notFound
>
> with the following xhtml:
>
>         
>                 
>                  property:width="75" property:height="100" />
>                 
>         
>
> and the result is always the img tag with the src attrib that I
> supplied in the binding i.e. the style, width and height are not
> merged.  Code like this in the Lift book (pops a timestamp in a div)
> does not work (merge attribs) either.
>
> Any ideas what I am doing wrong?
>
> -- Ewan
>
> On Sep 16, 11:56?am, Timothy Perrett  wrote:
>
> > I think id do:
>
> > 
> > ? 
> > 
>
> > then in the scala:
>
> > class MySnippet {
> > ? def example(xhtml: NodeSeq):NodeSeq = bind("whatever", xhtml,
> > ? ? "demo" -> 
>
> > }
>
> > Basically, when attributes are name-spaced correctly, they are merged
> > into the node attributes. This is all from memory so might need a
> > slight change to compile properly.
>
> > Cheers, Tim
>
> > On Sep 16, 11:49?am, Viktor Klang  wrote:
>
> > > On Wed, Sep 16, 2009 at 12:37 PM, Ewan  wrote:
>
> > > > I'd like to pop the bound value from a snippet into some standard
> > > > xhtml tags but it does not parse. ?In the case below I want the url to
> > > > be put into the img tag where  is bound to ta
> > > > snippet.
>
> > > >  ?style="border:3px solid #CC"
> > > > width="75" height="100"/>
>
> > > Have a snippet that simply adds the src attribute to the supplied markup
>
> > > 
> > > ? ?http://groups.google.com/group/softpub
>
>
--~--~-~--~~~---~--~~
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: How to XHTML and embedded snippets

2009-09-16 Thread Timothy Perrett

Good catch Naftoli :-)

Cheers, Tim

On 16 Sep 2009, at 14:40, Naftoli Gugenheim wrote:

>
> Tim is right that it worked that way, but apparently that code was  
> committed before the review board was in place :) because DPP wasn't  
> happy with it and took it out. Instead you can use -%> to bind and  
> preserve all attributes.
>
> -
> Ewan wrote:
>
>
> Thanks but I still have no joy.  My snippet binding is as follows:
>
> property.map ({ p =>
>bind("property", html,
> "id" -> p.id,
> "name" -> p.name,
> "image" -> )
>}) openOr notFound
>
> with the following xhtml:
>
>   
>
>property:width="75" property:height="100" />
>
>   
>
> and the result is always the img tag with the src attrib that I
> supplied in the binding i.e. the style, width and height are not
> merged.  Code like this in the Lift book (pops a timestamp in a div)
> does not work (merge attribs) either.
>
> Any ideas what I am doing wrong?
>
> -- Ewan
>
> On Sep 16, 11:56?am, Timothy Perrett  wrote:
>> I think id do:
>>
>> 
>> ? 
>> 
>>
>> then in the scala:
>>
>> class MySnippet {
>> ? def example(xhtml: NodeSeq):NodeSeq = bind("whatever", xhtml,
>> ? ? "demo" -> 
>>
>> }
>>
>> Basically, when attributes are name-spaced correctly, they are merged
>> into the node attributes. This is all from memory so might need a
>> slight change to compile properly.
>>
>> Cheers, Tim
>>
>> On Sep 16, 11:49?am, Viktor Klang  wrote:
>>
>>> On Wed, Sep 16, 2009 at 12:37 PM, Ewan  wrote:
>>
 I'd like to pop the bound value from a snippet into some standard
 xhtml tags but it does not parse. ?In the case below I want the  
 url to
 be put into the img tag where  is bound to ta
 snippet.
>>
  ?style="border:3px solid #CC"
 width="75" height="100"/>
>>
>>> Have a snippet that simply adds the src attribute to the supplied  
>>> markup
>>
>>> 
>>> ? ?http://groups.google.com/group/softpub
>>
>>
>
>
> >
>


--~--~-~--~~~---~--~~
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: OOME in using CometActor

2009-09-16 Thread Erik Engbrecht
Yes, particularly maxPoolSize.

On Wed, Sep 16, 2009 at 10:25 AM, Atsuhiko Yamanaka <
atsuhiko.yaman...@gmail.com> wrote:

>
> Hi,
>
> On Wed, Sep 16, 2009 at 10:33 PM, Erik Engbrecht
>  wrote:
> > The large number of VolatileTaskRefs is a consequence of your thread pool
> > growth.  Each worker thread maintains an array of VolatileTaskRef
> objects.
> > The VolatileTaskRef objects are reused rather than allocated for each
> task,
> > so they will not be GC'd as long as the worker thread is alive.  You can
> > tell that the they being properly cleared because size wise if they
> weren't
> > being cleared you see what they are pointing to dominate heap usage.
> >
> > I'd suggest setting the maximum thread pool size to something reasonable
> for
> > the number of processors and available memory you have.  If you don't,
> the
> > scheduler will happily spawn up to 255 threads.
>
> Thank you for your suggestion.
>
> Do you mean system properties
>  actors.corePoolSize
>  actors.maxPoolSize
>  actors.timeFreq
> referred in scala.actors. FJTaskScheduler2?
>
>
> Sincerely,
> --
> Atsuhiko Yamanaka
> JCraft,Inc.
> 1-14-20 HONCHO AOBA-KU,
> SENDAI, MIYAGI 980-0014 Japan.
> Tel +81-22-723-2150
>+1-415-578-3454
> Skype callto://jcraft/
>
> >
>


-- 
http://erikengbrecht.blogspot.com/

--~--~-~--~~~---~--~~
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: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

2009-09-16 Thread David Pollak
On Wed, Sep 16, 2009 at 6:27 AM, Kevin Wright  wrote:

> Is there any reason not to go with something like the Akka framework?  I
> believe it has a lift-friendly license.


I can work on a way to make CometActors work with Akka Actors or Lift
Actors.  Jonas and I have had a lot of conversations and will be able to
work together on this.

In terms of the light-weight nature of a lot of CometActors, I'd opt, by
default, to go with Lift Actors.


>
>
> On Wed, Sep 16, 2009 at 2:14 PM, David Pollak <
> feeder.of.the.be...@gmail.com> wrote:
>
>> Guys,
>> The Scala Actor issue has raised its head again.
>>
>> From November 2008 - June 2009, I did an epic battle with Scala actors and
>> their memory retention issues.
>>
>> I finally wrote a Lift Actor library that made all the Scala Actor-related
>> issues go away for the short-lived Actors that Lift uses as listeners for
>> comet long-polling.
>>
>> It seems that the Actor issue is not gone.  I'm not sure it will be gone
>> in Scala 2.8.
>>
>> I can make a change in Lift to move to Lift Actors in CometActor code.  It
>> means that if you're using Scala Actors beyond !, !! and !? methods, you
>> will have to change your code, otherwise it will just be a recompile.
>>
>> What do people think?
>>
>> Thanks,
>>
>> David
>>
>> --
>> Lift, the simply functional web framework http://liftweb.net
>> Beginning Scala http://www.apress.com/book/view/1430219890
>> Follow me: http://twitter.com/dpp
>> Git some: http://github.com/dpp
>>
>>
>>
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://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: OOME in using CometActor

2009-09-16 Thread Atsuhiko Yamanaka

Hi,

On Wed, Sep 16, 2009 at 10:33 PM, Erik Engbrecht
 wrote:
> The large number of VolatileTaskRefs is a consequence of your thread pool
> growth.  Each worker thread maintains an array of VolatileTaskRef objects.
> The VolatileTaskRef objects are reused rather than allocated for each task,
> so they will not be GC'd as long as the worker thread is alive.  You can
> tell that the they being properly cleared because size wise if they weren't
> being cleared you see what they are pointing to dominate heap usage.
>
> I'd suggest setting the maximum thread pool size to something reasonable for
> the number of processors and available memory you have.  If you don't, the
> scheduler will happily spawn up to 255 threads.

Thank you for your suggestion.

Do you mean system properties
  actors.corePoolSize
  actors.maxPoolSize
  actors.timeFreq
referred in scala.actors. FJTaskScheduler2?


Sincerely,
--
Atsuhiko Yamanaka
JCraft,Inc.
1-14-20 HONCHO AOBA-KU,
SENDAI, MIYAGI 980-0014 Japan.
Tel +81-22-723-2150
+1-415-578-3454
Skype callto://jcraft/

--~--~-~--~~~---~--~~
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: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

2009-09-16 Thread Viktor Klang
On Wed, Sep 16, 2009 at 3:42 PM, Naftoli Gugenheim wrote:

>
> I haven't used comet, but would it be worthwhile to abstract it with
> implementations (potentially) for Scala, Lift, and Akka actors?
>

I've integrated Atmosphere  into Akka, and
I know that Jeanfrançois Arcand (Atmosphere dude) has shown interest in
integrating it into Lift.


>
> -
> TylerWeir wrote:
>
>
> Given the on again/off again nature of the issue, I'm voting for
> adding your change.
> We can rely on your code working until the issue is sorted with the
> Scala team.
>
> So, +1 to dpp's code.
>
> On Sep 16, 9:14?am, David Pollak 
> wrote:
> > Guys,
> > The Scala Actor issue has raised its head again.
> >
> > From November 2008 - June 2009, I did an epic battle with Scala actors
> and
> > their memory retention issues.
> >
> > I finally wrote a Lift Actor library that made all the Scala
> Actor-related
> > issues go away for the short-lived Actors that Lift uses as listeners for
> > comet long-polling.
> >
> > It seems that the Actor issue is not gone. ?I'm not sure it will be gone
> in
> > Scala 2.8.
> >
> > I can make a change in Lift to move to Lift Actors in CometActor code.
> ?It
> > means that if you're using Scala Actors beyond !, !! and !? methods, you
> > will have to change your code, otherwise it will just be a recompile.
> >
> > What do people think?
> >
> > Thanks,
> >
> > David
> >
> > --
> > 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
>
>
> >
>


-- 
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang

Lift Committer - liftweb.com
AKKA Committer - akkasource.org
Cassidy - github.com/viktorklang/Cassidy.git
SoftPub founder: http://groups.google.com/group/softpub

--~--~-~--~~~---~--~~
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: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

2009-09-16 Thread Naftoli Gugenheim

I haven't used comet, but would it be worthwhile to abstract it with 
implementations (potentially) for Scala, Lift, and Akka actors?

-
TylerWeir wrote:


Given the on again/off again nature of the issue, I'm voting for
adding your change.
We can rely on your code working until the issue is sorted with the
Scala team.

So, +1 to dpp's code.

On Sep 16, 9:14?am, David Pollak 
wrote:
> Guys,
> The Scala Actor issue has raised its head again.
>
> From November 2008 - June 2009, I did an epic battle with Scala actors and
> their memory retention issues.
>
> I finally wrote a Lift Actor library that made all the Scala Actor-related
> issues go away for the short-lived Actors that Lift uses as listeners for
> comet long-polling.
>
> It seems that the Actor issue is not gone. ?I'm not sure it will be gone in
> Scala 2.8.
>
> I can make a change in Lift to move to Lift Actors in CometActor code. ?It
> means that if you're using Scala Actors beyond !, !! and !? methods, you
> will have to change your code, otherwise it will just be a recompile.
>
> What do people think?
>
> Thanks,
>
> David
>
> --
> 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: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

2009-09-16 Thread marius d.

What is the problem this time? .. same thing essentially?

Br's,
Marius

On Sep 16, 8:14 am, David Pollak 
wrote:
> Guys,
> The Scala Actor issue has raised its head again.
>
> From November 2008 - June 2009, I did an epic battle with Scala actors and
> their memory retention issues.
>
> I finally wrote a Lift Actor library that made all the Scala Actor-related
> issues go away for the short-lived Actors that Lift uses as listeners for
> comet long-polling.
>
> It seems that the Actor issue is not gone.  I'm not sure it will be gone in
> Scala 2.8.
>
> I can make a change in Lift to move to Lift Actors in CometActor code.  It
> means that if you're using Scala Actors beyond !, !! and !? methods, you
> will have to change your code, otherwise it will just be a recompile.
>
> What do people think?
>
> Thanks,
>
> David
>
> --
> 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: How to XHTML and embedded snippets

2009-09-16 Thread Naftoli Gugenheim

Tim is right that it worked that way, but apparently that code was committed 
before the review board was in place :) because DPP wasn't happy with it and 
took it out. Instead you can use -%> to bind and preserve all attributes.

-
Ewan wrote:


Thanks but I still have no joy.  My snippet binding is as follows:

property.map ({ p =>
bind("property", html,
 "id" -> p.id,
 "name" -> p.name,
 "image" -> )
}) openOr notFound

with the following xhtml:







and the result is always the img tag with the src attrib that I
supplied in the binding i.e. the style, width and height are not
merged.  Code like this in the Lift book (pops a timestamp in a div)
does not work (merge attribs) either.

Any ideas what I am doing wrong?

-- Ewan

On Sep 16, 11:56?am, Timothy Perrett  wrote:
> I think id do:
>
> 
> ? 
> 
>
> then in the scala:
>
> class MySnippet {
> ? def example(xhtml: NodeSeq):NodeSeq = bind("whatever", xhtml,
> ? ? "demo" -> 
>
> }
>
> Basically, when attributes are name-spaced correctly, they are merged
> into the node attributes. This is all from memory so might need a
> slight change to compile properly.
>
> Cheers, Tim
>
> On Sep 16, 11:49?am, Viktor Klang  wrote:
>
> > On Wed, Sep 16, 2009 at 12:37 PM, Ewan  wrote:
>
> > > I'd like to pop the bound value from a snippet into some standard
> > > xhtml tags but it does not parse. ?In the case below I want the url to
> > > be put into the img tag where  is bound to ta
> > > snippet.
>
> > >  ?style="border:3px solid #CC"
> > > width="75" height="100"/>
>
> > Have a snippet that simply adds the src attribute to the supplied markup
>
> > 
> > ? ?http://groups.google.com/group/softpub
>
>


--~--~-~--~~~---~--~~
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] What's the best way to get the current request URL

2009-09-16 Thread Ryan Donahue

I want to capture the the current request URL, so I can redirect back
to it at a later point.  What's the best way to get at the URL?  The
answer is probably obvious, but I can't seem to find it.

Thanks,

Ryan
--~--~-~--~~~---~--~~
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: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

2009-09-16 Thread Timothy Perrett
Hey David,

Are you saying that scala actors are leaking outside of large rate  
construction / destruction situations? At least, I remember that was  
what was tickling the EPFL bug last time :-)

This has pretty major ramifications if it is! Personally, I'm happy to  
move to lift-actor.

Cheers

Tim

Sent from my iPhone

On 16 Sep 2009, at 14:14, David Pollak   
wrote:

> Guys,
>
> The Scala Actor issue has raised its head again.
>
> From November 2008 - June 2009, I did an epic battle with Scala  
> actors and their memory retention issues.
>
> I finally wrote a Lift Actor library that made all the Scala Actor- 
> related issues go away for the short-lived Actors that Lift uses as  
> listeners for comet long-polling.
>
> It seems that the Actor issue is not gone.  I'm not sure it will be  
> gone in Scala 2.8.
>
> I can make a change in Lift to move to Lift Actors in CometActor  
> code.  It means that if you're using Scala Actors beyond !, !!  
> and !? methods, you will have to change your code, otherwise it will  
> just be a recompile.
>
> What do people think?
>
> Thanks,
>
> David
>
> -- 
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://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: OOME in using CometActor

2009-09-16 Thread Erik Engbrecht
The large number of VolatileTaskRefs is a consequence of your thread pool
growth.  Each worker thread maintains an array of VolatileTaskRef objects.
The VolatileTaskRef objects are reused rather than allocated for each task,
so they will not be GC'd as long as the worker thread is alive.  You can
tell that the they being properly cleared because size wise if they weren't
being cleared you see what they are pointing to dominate heap usage.

I'd suggest setting the maximum thread pool size to something reasonable for
the number of processors and available memory you have.  If you don't, the
scheduler will happily spawn up to 255 threads.

On Wed, Sep 16, 2009 at 6:38 AM, Atsuhiko Yamanaka <
atsuhiko.yaman...@gmail.com> wrote:

> Hi,
>
> I have encountered OutOfMemory Exception in developing Liftweb app.
> It seems it is related to CometActor(, or scala.actors.Actor)
> At OOME timing, I have found 1,000,000 instances of
>  scala.actors.FJTaskRunner$VolatileTaskRef
> in the heap area by using VisualVM.
>
> I have tried to narrow down the problem, and found that
> following simple clock app has also the similar problem,
>  http://gist.github.com/187924
>
> If you are interested in this problem, please try it.
>
> $ git clone git://gist.github.com/187924.git gist-187924
> $ cd gist-187924
> $ mvn jetty:run
>
> Then, visit http://127.0.0.1:8080/
>
> I will attache the screenshot of VisualVM, which displays
> the internal of heap area after 2 hours later.
> In this shot, you will find that 490,000 FJTaskRunner$VolatileTaskRef
> instances in the heap.  In monitoring the VisualVM, I have found
> that the number of threads has been monotonically increased
> even for the access from only one browser.
>
> Does scala.actors.Actor have still resource leak bug?
>
> I'm trying Liftweb 1.1-SNAPSHOT, Scala 2.7.5
> and JDK1.6.0_16 on GNU/Linux .
>
>
> Sincerely,
> --
> Atsuhiko Yamanaka
> JCraft,Inc.
> 1-14-20 HONCHO AOBA-KU,
> SENDAI, MIYAGI 980-0014 Japan.
> Tel +81-22-723-2150
>+1-415-578-3454
> Skype callto://jcraft/
>
> >
>


-- 
http://erikengbrecht.blogspot.com/

--~--~-~--~~~---~--~~
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: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

2009-09-16 Thread TylerWeir

Given the on again/off again nature of the issue, I'm voting for
adding your change.
We can rely on your code working until the issue is sorted with the
Scala team.

So, +1 to dpp's code.

On Sep 16, 9:14 am, David Pollak 
wrote:
> Guys,
> The Scala Actor issue has raised its head again.
>
> From November 2008 - June 2009, I did an epic battle with Scala actors and
> their memory retention issues.
>
> I finally wrote a Lift Actor library that made all the Scala Actor-related
> issues go away for the short-lived Actors that Lift uses as listeners for
> comet long-polling.
>
> It seems that the Actor issue is not gone.  I'm not sure it will be gone in
> Scala 2.8.
>
> I can make a change in Lift to move to Lift Actors in CometActor code.  It
> means that if you're using Scala Actors beyond !, !! and !? methods, you
> will have to change your code, otherwise it will just be a recompile.
>
> What do people think?
>
> Thanks,
>
> David
>
> --
> 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: How to XHTML and embedded snippets

2009-09-16 Thread Ewan

Thanks but I still have no joy.  My snippet binding is as follows:

property.map ({ p =>
bind("property", html,
 "id" -> p.id,
 "name" -> p.name,
 "image" -> )
}) openOr notFound

with the following xhtml:







and the result is always the img tag with the src attrib that I
supplied in the binding i.e. the style, width and height are not
merged.  Code like this in the Lift book (pops a timestamp in a div)
does not work (merge attribs) either.

Any ideas what I am doing wrong?

-- Ewan

On Sep 16, 11:56 am, Timothy Perrett  wrote:
> I think id do:
>
> 
>   
> 
>
> then in the scala:
>
> class MySnippet {
>   def example(xhtml: NodeSeq):NodeSeq = bind("whatever", xhtml,
>     "demo" -> 
>
> }
>
> Basically, when attributes are name-spaced correctly, they are merged
> into the node attributes. This is all from memory so might need a
> slight change to compile properly.
>
> Cheers, Tim
>
> On Sep 16, 11:49 am, Viktor Klang  wrote:
>
> > On Wed, Sep 16, 2009 at 12:37 PM, Ewan  wrote:
>
> > > I'd like to pop the bound value from a snippet into some standard
> > > xhtml tags but it does not parse.  In the case below I want the url to
> > > be put into the img tag where  is bound to ta
> > > snippet.
>
> > >   style="border:3px solid #CC"
> > > width="75" height="100"/>
>
> > Have a snippet that simply adds the src attribute to the supplied markup
>
> > 
> >    http://groups.google.com/group/softpub
>
>
--~--~-~--~~~---~--~~
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: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

2009-09-16 Thread Kevin Wright
Is there any reason not to go with something like the Akka framework?  I
believe it has a lift-friendly license.

On Wed, Sep 16, 2009 at 2:14 PM, David Pollak  wrote:

> Guys,
> The Scala Actor issue has raised its head again.
>
> From November 2008 - June 2009, I did an epic battle with Scala actors and
> their memory retention issues.
>
> I finally wrote a Lift Actor library that made all the Scala Actor-related
> issues go away for the short-lived Actors that Lift uses as listeners for
> comet long-polling.
>
> It seems that the Actor issue is not gone.  I'm not sure it will be gone in
> Scala 2.8.
>
> I can make a change in Lift to move to Lift Actors in CometActor code.  It
> means that if you're using Scala Actors beyond !, !! and !? methods, you
> will have to change your code, otherwise it will just be a recompile.
>
> What do people think?
>
> Thanks,
>
> David
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://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] Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

2009-09-16 Thread David Pollak
Guys,
The Scala Actor issue has raised its head again.

>From November 2008 - June 2009, I did an epic battle with Scala actors and
their memory retention issues.

I finally wrote a Lift Actor library that made all the Scala Actor-related
issues go away for the short-lived Actors that Lift uses as listeners for
comet long-polling.

It seems that the Actor issue is not gone.  I'm not sure it will be gone in
Scala 2.8.

I can make a change in Lift to move to Lift Actors in CometActor code.  It
means that if you're using Scala Actors beyond !, !! and !? methods, you
will have to change your code, otherwise it will just be a recompile.

What do people think?

Thanks,

David

-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://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: Proper way to upgrade Lift and Scala libs?

2009-09-16 Thread David Pollak
On Tue, Sep 15, 2009 at 9:04 PM, Ike  wrote:

>
> On Sep 15, 11:44 pm, David Pollak 
> wrote:
> > On Tue, Sep 15, 2009 at 8:28 PM, Ike  wrote:
> >
> > > Hi all,
> >
> > > I've seen in a couple of posts here that I can just update the
> > > corresponding dependencies in the POM and get the updated libraries. I
> > > did this for both the Lift libs (1.0 -> 1.0.2) and the Scala lib
> > > (2.7.5 -> 2.7.6).
> >
> > Lift (1.1-X and 1.0.1/1.0.2) is compiled against Scala 2.7.5  This is the
> > version you should be using.
> >
> > Do not upgrade to 2.7.6  2.7.6 is a broken release.
>
> Got it. Thanks David.
>
> What about the upgrade process itself? Is editing the POM the
> recommended way? What would be the proper way to verify the proper
> versions/combinations to use in the future?
>
> Any plans in the works for upgrading existing projects and keeping the
> lift/scala libs in sync?


We do keep the Lift and scala libs in sync.  However, 2.7.6 is a release
that should never have happened and Lift will not compile under 2.7.6 (see
my prior email about broken existential types.)

In general, when EPFL starts publishing stable nightly builds of a release
of Scala, we work with the ScalaTest, ScalaCheck and Specs folks to get
SNAPSHOT versions of their libraries compiling against the new version of
Scala.  Then we start a branch (git is wonderful) that compiles against the
new version of Scala.  I run my development in parallel with both branches
(the Lift-based projects that I'm part of) to make sure that the code passes
basic smoke tests.

We typically wait 2 weeks after EPFL blesses a final release before
switching Lift over to that release.  Why?  EPFL usually finds a few bugs in
a given release of Scala and issues a dot dot release to patch the problem
within 2 weeks of a release.

So, that's the Lift policy.  We will have to figure out if we're going to do
a 1.0.3 release for Scala 2.8.  We're planning to release Lift 1.1 a few
weeks after 2.8 goes live (which I'm expecting to be in late November-early
January sometime.)


> It would be great if we could do something
> like mvn upgrade 1.0.2 or mvn upgrade current to take care of this, at
> least for minor upgrades.
>

Maybe a Maven maven on the list will describe if that's possible.

>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://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: Proper way to upgrade Lift and Scala libs?

2009-09-16 Thread David Pollak
On Tue, Sep 15, 2009 at 9:01 PM, Wilson MacGyver wrote:

>
> On Tue, Sep 15, 2009 at 11:44 PM, David Pollak
>  wrote:
> > Lift (1.1-X and 1.0.1/1.0.2) is compiled against Scala 2.7.5  This is the
> > version you should be using.
> > Do not upgrade to 2.7.6  2.7.6 is a broken release.
>
> can you expand on that? Do you mean 2.7.6 is a broken release for using it
> with lift, or 2.7.6 is just plain broken for scala development, and should
> stick to 2.7.5?
>

Both.

EPFL took a single change off the 2.8 development branch and grafted it onto
2.7.5 without testing beyond the standard Scala tests, without any beta
period, without any discussion on scala-internals, and without any notes to
the various stake-holders in the Scala community.  The change seems to break
existential types.  Lift will not compile with the change.  Code compiled
with the change will likely not work with 2.7.5 and code compiled under
2.7.5 will have different pickling (serialization) of Scala-related metadata
in the class files.

So, stay as far away from 2.7.6 as you can.




>
>
> --
> Omnem crede diem tibi diluxisse supremum.
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://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: OOME in using CometActor

2009-09-16 Thread Derek Williams
I believe I ran into this before, to fix it I came up with this:

package
scala.actors



object ActorTimerKiller
{

  def kill
{


Actor.timer.cancel


}

}

and then in my Boot.scala:

LiftRules.unloadHooks.append(() => {
  ActorTimerKiller.kill
}

I also have Actor.clearSelf in my unloadHooks, but I can't remember if that
was for this issue or another, since I use Actors in my code, not just
CometActors.

Oh wait, rereading your post, it looks like this is something that doesn't
involve redeploying during development, which was where I was running into
this problem. This post probably wont help you then... but I'll post it
anyways.

-- 
Derek Williams

--~--~-~--~~~---~--~~
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: Spring Security

2009-09-16 Thread David Pollak
On Wed, Sep 16, 2009 at 1:49 AM, Viktor Klang wrote:

>
>
> On Wed, Sep 16, 2009 at 2:38 AM, Charles F. Munat  wrote:
>
>>
>> David Pollak wrote:
>> > The existing page/URL level security has nothing to do with Mapper.
>> >  There's nothing that can be done with Mapper that can't be done with
>> > JPA (with the exception of Mapper's field-level access control which, to
>> > my knowledge, is not being used anywhere.)
>>
>> I meant that the login feature when you use the basic archetype is set
>> up to work with Mapper, not that login is part of Mapper. It could be
>> adapted to work with JPA easily, but there is no JPA archetype so far
>> that includes that login functionality (that I'm aware of). You have to
>> roll your own.
>>
>> > I radically disagree.  Having a separate concern doing "security" is a
>> > disaster because there'll always be some place where one system believes
>> > one thing and the other system believes something else.
>>
>> A disaster? Always? Really?
>
>
Anything that's not strongly typed, IMHO (I guess I'm channelling Greg
Meredith) is a disaster waiting to happen.

For systems written by a small team of people who all currently have the
rule set in their head, the disaster is generally averted.

For systems that have multiple layers of testing and a dedicated QA staff
(both very high cost) the disaster is generally averted.

Lift is not always strongly typed.  Lift doesn't insert all the correct
JavaScript in a page that it's rendering (e.g., references to jQuery).  This
accounts for some measurable traffic on this list.  Lift's binding mechanism
is not strongly typed (although there's immediate feedback on smoke tests)
and that leads to some problems.  Lift's "by convention" snippet/comet
location mechanism is not strongly typed and that leads to a lot of traffic
on this list and no doubt to a lot of problems by developers that don't
bubble up to the list.

But security is special.  Security is something that has to be done better
than by convention or by group knowledge or by testing (you should test for
security as well).  Security is something that should be obvious in the most
basic code review and your program should not compile if the security
assumptions about a resource in one area are not the same as the security
assumptions about the same resource in another area.


> Even allowing for hyperbole, if these
>> systems are so bad, why are so many people using them -- apparently with
>> great success? Without some evidence to back this claim up, I'm dubious.
>>
>
> Chas, there's alot of really shitty software used by millions of people,
> I could name these product to you, but I'm unwilling to bash multinational,
> billion-dollar companies where they have no possibility to retort.
> The morale of the story is that just because everyone else is doing it
> doesn't mean that it's good or even above retarded.
>
>
>>
>> That said, it certainly would be nice to have these capabilities in
>> Lift. But I don't have the time either. SS looks pretty drop in.
>>
>> There may also be situations where using a particular solution (such as
>> SS) is a requirement and make-or-break on whether Lift can be used, so I
>> don't see the ability to make Lift work with such software as a negative.
>>
>> I have a lot more to say on this, but have to run. Maybe later.
>>
>> Chas.
>>
>>
>>
>
>
> --
> Viktor Klang
>
> Blog: klangism.blogspot.com
> Twttr: viktorklang
>
> Lift Committer - liftweb.com
> AKKA Committer - akkasource.org
> Cassidy - github.com/viktorklang/Cassidy.git
> SoftPub founder: http://groups.google.com/group/softpub
>
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://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: OOME in using CometActor

2009-09-16 Thread David Pollak
On Wed, Sep 16, 2009 at 3:38 AM, Atsuhiko Yamanaka <
atsuhiko.yaman...@gmail.com> wrote:

> Hi,
>
> I have encountered OutOfMemory Exception in developing Liftweb app.
> It seems it is related to CometActor(, or scala.actors.Actor)
> At OOME timing, I have found 1,000,000 instances of
>  scala.actors.FJTaskRunner$VolatileTaskRef
> in the heap area by using VisualVM.
>
> I have tried to narrow down the problem, and found that
> following simple clock app has also the similar problem,
>  http://gist.github.com/187924
>
> If you are interested in this problem, please try it.
>
> $ git clone git://gist.github.com/187924.git gist-187924
> $ cd gist-187924
> $ mvn jetty:run
>
> Then, visit http://127.0.0.1:8080/
>
> I will attache the screenshot of VisualVM, which displays
> the internal of heap area after 2 hours later.
> In this shot, you will find that 490,000 FJTaskRunner$VolatileTaskRef
> instances in the heap.  In monitoring the VisualVM, I have found
> that the number of threads has been monotonically increased
> even for the access from only one browser.
>
> Does scala.actors.Actor have still resource leak bug?
>

Apparently so.  Philipp Haller told me that the default in 2.7.5/JVM 1.5
implementations was to use the java.util.concurrent.Executor for
scheduling... I guess not (teaches me not to trust but verify).

I'll Force Scala Actors to use java.util.concurrent.Executor for we avoid
the FJ Library in Scala

I would change CometActors to use Lift's Actor library, but that would be a
breaking change to Lift, although we'd definitely get a more reliable Actor
implementation.




>
> I'm trying Liftweb 1.1-SNAPSHOT, Scala 2.7.5
> and JDK1.6.0_16 on GNU/Linux .
>
>
> Sincerely,
> --
> Atsuhiko Yamanaka
> JCraft,Inc.
> 1-14-20 HONCHO AOBA-KU,
> SENDAI, MIYAGI 980-0014 Japan.
> Tel +81-22-723-2150
>+1-415-578-3454
> Skype callto://jcraft/
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://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] Article about Lift on heise.de

2009-09-16 Thread Tobias Daub

Just found it during my daily look on the site

http://www.heise.de/developer/Lift-Vehikel-zum-naechsten-Web-Framework-Level--/artikel/145143

--~--~-~--~~~---~--~~
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: How to XHTML and embedded snippets

2009-09-16 Thread Viktor Klang
On Wed, Sep 16, 2009 at 12:49 PM, Viktor Klang wrote:

>
>
> On Wed, Sep 16, 2009 at 12:37 PM, Ewan  wrote:
>
>>
>> I'd like to pop the bound value from a snippet into some standard
>> xhtml tags but it does not parse.  In the case below I want the url to
>> be put into the img tag where  is bound to ta
>> snippet.
>>
>>   style="border:3px solid #CC"
>> width="75" height="100"/>
>>
>
> Have a snippet that simply adds the src attribute to the supplied markup
>
> 
>http://www.mail-archive.com/liftweb@googlegroups.com/msg06278.html


>
>
>>
>> I am unable to do this so as a work around I get the snippet to create
>> the xhtml img tag but is there a way to achieve the above as I don't
>> want to change scala src for every minor ui change.
>>
>> -- Ewan
>> >>
>>
>
>
> --
> Viktor Klang
>
> Blog: klangism.blogspot.com
> Twttr: viktorklang
>
> Lift Committer - liftweb.com
> AKKA Committer - akkasource.org
> Cassidy - github.com/viktorklang/Cassidy.git
> SoftPub founder: http://groups.google.com/group/softpub
>



-- 
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang

Lift Committer - liftweb.com
AKKA Committer - akkasource.org
Cassidy - github.com/viktorklang/Cassidy.git
SoftPub founder: http://groups.google.com/group/softpub

--~--~-~--~~~---~--~~
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: How to XHTML and embedded snippets

2009-09-16 Thread Timothy Perrett

I think id do:


  


then in the scala:

class MySnippet {
  def example(xhtml: NodeSeq):NodeSeq = bind("whatever", xhtml,
"demo" -> 
}

Basically, when attributes are name-spaced correctly, they are merged
into the node attributes. This is all from memory so might need a
slight change to compile properly.

Cheers, Tim

On Sep 16, 11:49 am, Viktor Klang  wrote:
> On Wed, Sep 16, 2009 at 12:37 PM, Ewan  wrote:
>
> > I'd like to pop the bound value from a snippet into some standard
> > xhtml tags but it does not parse.  In the case below I want the url to
> > be put into the img tag where  is bound to ta
> > snippet.
>
> >   style="border:3px solid #CC"
> > width="75" height="100"/>
>
> Have a snippet that simply adds the src attribute to the supplied markup
>
> 
>    http://groups.google.com/group/softpub
--~--~-~--~~~---~--~~
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: How to XHTML and embedded snippets

2009-09-16 Thread Viktor Klang
On Wed, Sep 16, 2009 at 12:37 PM, Ewan  wrote:

>
> I'd like to pop the bound value from a snippet into some standard
> xhtml tags but it does not parse.  In the case below I want the url to
> be put into the img tag where  is bound to ta
> snippet.
>
>   style="border:3px solid #CC"
> width="75" height="100"/>
>

Have a snippet that simply adds the src attribute to the supplied markup


   http://groups.google.com/group/softpub

--~--~-~--~~~---~--~~
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] How to XHTML and embedded snippets

2009-09-16 Thread Ewan

I'd like to pop the bound value from a snippet into some standard
xhtml tags but it does not parse.  In the case below I want the url to
be put into the img tag where  is bound to ta
snippet.

  style="border:3px solid #CC"
width="75" height="100"/>

I am unable to do this so as a work around I get the snippet to create
the xhtml img tag but is there a way to achieve the above as I don't
want to change scala src for every minor ui change.

-- Ewan
--~--~-~--~~~---~--~~
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: Spring Security

2009-09-16 Thread Timothy Perrett

Amen to that Viktor. Lift would have never been created if everything
out there was doing a perfect job!

Im a little confused however Chas - on the one had, your talking about
enterprise security and on the other you are talking about simple
logins that are part of the archetypes and that you dont want to "roll
your own". This is a little concerning because its hardly a
difficult / long-winded task to roll your own if you want a simple
login... if however you do indeed want the enterprise stuff you
listed, then is it any wonder thats not provided as an archetype? ;-)

The bottom line is that if you want to use SS, there is absolutely
nothing in Lift stopping you. Perhaps however, you should consider
exactly why you want to use the technologies you listed and what
problems you are actually solving - I get the impression your not 100%
sure why your using them other than that they were made and supported
by someone else and a lot of projects use them.

Tim


> Chas, there's alot of really shitty software used by millions of people,
> I could name these product to you, but I'm unwilling to bash multinational,
> billion-dollar companies where they have no possibility to retort.
> The morale of the story is that just because everyone else is doing it
> doesn't mean that it's good or even above retarded.

--~--~-~--~~~---~--~~
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: Spring Security

2009-09-16 Thread Viktor Klang
On Wed, Sep 16, 2009 at 10:49 AM, Viktor Klang wrote:

>
>
> On Wed, Sep 16, 2009 at 2:38 AM, Charles F. Munat  wrote:
>
>>
>> David Pollak wrote:
>> > The existing page/URL level security has nothing to do with Mapper.
>> >  There's nothing that can be done with Mapper that can't be done with
>> > JPA (with the exception of Mapper's field-level access control which, to
>> > my knowledge, is not being used anywhere.)
>>
>> I meant that the login feature when you use the basic archetype is set
>> up to work with Mapper, not that login is part of Mapper. It could be
>> adapted to work with JPA easily, but there is no JPA archetype so far
>> that includes that login functionality (that I'm aware of). You have to
>> roll your own.
>>
>> > I radically disagree.  Having a separate concern doing "security" is a
>> > disaster because there'll always be some place where one system believes
>> > one thing and the other system believes something else.
>>
>> A disaster? Always? Really? Even allowing for hyperbole, if these
>> systems are so bad, why are so many people using them -- apparently with
>> great success? Without some evidence to back this claim up, I'm dubious.
>>
>
> Chas, there's alot of really shitty software used by millions of people,
> I could name these product to you, but I'm unwilling to bash multinational,
> billion-dollar companies where they have no possibility to retort.
> The morale of the story is that just because everyone else is doing it
> doesn't mean that it's good or even above retarded.
>

Please note that I was not talking about SS in any sense, I'm just a firm
believer that in order to know if something is good or not you need to
establish what you value and how you measure that value and what different
solution you are weighing against eachother.

Never fall for peer pressure when doing software.


>
>
>>
>> That said, it certainly would be nice to have these capabilities in
>> Lift. But I don't have the time either. SS looks pretty drop in.
>>
>> There may also be situations where using a particular solution (such as
>> SS) is a requirement and make-or-break on whether Lift can be used, so I
>> don't see the ability to make Lift work with such software as a negative.
>>
>> I have a lot more to say on this, but have to run. Maybe later.
>>
>> Chas.
>>
>> >>
>>
>
>
> --
> Viktor Klang
>
> Blog: klangism.blogspot.com
> Twttr: viktorklang
>
> Lift Committer - liftweb.com
> AKKA Committer - akkasource.org
> Cassidy - github.com/viktorklang/Cassidy.git
> SoftPub founder: http://groups.google.com/group/softpub
>



-- 
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang

Lift Committer - liftweb.com
AKKA Committer - akkasource.org
Cassidy - github.com/viktorklang/Cassidy.git
SoftPub founder: http://groups.google.com/group/softpub

--~--~-~--~~~---~--~~
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: Spring Security

2009-09-16 Thread Viktor Klang
On Wed, Sep 16, 2009 at 2:38 AM, Charles F. Munat  wrote:

>
> David Pollak wrote:
> > The existing page/URL level security has nothing to do with Mapper.
> >  There's nothing that can be done with Mapper that can't be done with
> > JPA (with the exception of Mapper's field-level access control which, to
> > my knowledge, is not being used anywhere.)
>
> I meant that the login feature when you use the basic archetype is set
> up to work with Mapper, not that login is part of Mapper. It could be
> adapted to work with JPA easily, but there is no JPA archetype so far
> that includes that login functionality (that I'm aware of). You have to
> roll your own.
>
> > I radically disagree.  Having a separate concern doing "security" is a
> > disaster because there'll always be some place where one system believes
> > one thing and the other system believes something else.
>
> A disaster? Always? Really? Even allowing for hyperbole, if these
> systems are so bad, why are so many people using them -- apparently with
> great success? Without some evidence to back this claim up, I'm dubious.
>

Chas, there's alot of really shitty software used by millions of people,
I could name these product to you, but I'm unwilling to bash multinational,
billion-dollar companies where they have no possibility to retort.
The morale of the story is that just because everyone else is doing it
doesn't mean that it's good or even above retarded.


>
> That said, it certainly would be nice to have these capabilities in
> Lift. But I don't have the time either. SS looks pretty drop in.
>
> There may also be situations where using a particular solution (such as
> SS) is a requirement and make-or-break on whether Lift can be used, so I
> don't see the ability to make Lift work with such software as a negative.
>
> I have a lot more to say on this, but have to run. Maybe later.
>
> Chas.
>
> >
>


-- 
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang

Lift Committer - liftweb.com
AKKA Committer - akkasource.org
Cassidy - github.com/viktorklang/Cassidy.git
SoftPub founder: http://groups.google.com/group/softpub

--~--~-~--~~~---~--~~
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: where should i put the props file?

2009-09-16 Thread XiaomingZheng

thanks!

On Sep 16, 2:35 pm, Jeppe Nejsum Madsen  wrote:
> XiaomingZheng  writes:
> > it works~~~thank u!
> > but i read the lift source code, the framework searches "/props/" and
> > "/" dirs, how can this framework find props files in resource dir?
>
> The "/props" and "/" dirs are classpath locations. When building maven will, 
> by
> default, take everything in the src/main/resources dir and put it on the
> classpath at "/"
>
> /Jeppe
--~--~-~--~~~---~--~~
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] DB Log issue, escaping placeholders & LoggedPreparedStatement.paramified()

2009-09-16 Thread Ewan

Derek

This one is for you I think.  After updating my Boot.scala with
revised DB.addLogFunc I have found an issue with logging prepared
statements.  My usecase is an insert/update that sets a MappedString -
this MappedString is to hold a url such as "http://
www.northnorfolkholidaylet.com".  No problem there but if the url also
contains a query param the logger stacktraces (below).  The string
causing the problem is "http://www.northnorfolkholidaylet.com?
property=33".  Looking at LoggingStatementWrappers.scala line 313 it
replaces prepared statements placeholders '?' with the the required
values but my string value introduces/injects an extra '?' which
causes it to fail badly.

Exception occured while processing /property/edit/5

Message: java.util.NoSuchElementException: key not found: 4
scala.collection.Map$class.default(Map.scala:169)
scala.collection.immutable.Map3.default(Map3.scala:22)
scala.collection.Map$class.apply(Map.scala:80)
scala.collection.immutable.Map3.apply(Map3.scala:22)
net.liftweb.mapper.LoggedPreparedStatement.substitute$1
(LoggingStatementWrappers.scala:315)
net.liftweb.mapper.LoggedPreparedStatement.net$liftweb$mapper
$LoggedPreparedStatement$$paramified(LoggingStatementWrappers.scala:
318)
net.liftweb.mapper.LoggedPreparedStatement$$anonfun$executeUpdate
$9.apply(LoggingStatementWrappers.scala:347)
net.liftweb.mapper.LoggedPreparedStatement$$anonfun$executeUpdate
$9.apply(LoggingStatementWrappers.scala:347)
net.liftweb.mapper.DBLog$class.logStatement
(LoggingStatementWrappers.scala:46)
net.liftweb.mapper.LoggedStatement.logStatement
(LoggingStatementWrappers.scala:71)
net.liftweb.mapper.LoggedPreparedStatement.executeUpdate
(LoggingStatementWrappers.scala:347)
net.liftweb.mapper.MetaMapper$$anonfun$14$$anonfun$15.apply
(MetaMapper.scala:653)
net.liftweb.mapper.MetaMapper$$anonfun$14$$anonfun$15.apply
(MetaMapper.scala:636)
net.liftweb.mapper.DB$$anonfun$runPreparedStatement$1.apply(DB.scala:
375)
net.liftweb.mapper.DB$$anonfun$runPreparedStatement$1.apply(DB.scala:
372)
net.liftweb.util.TimeHelpers$class.calcTime(TimeHelpers.scala:241)
net.liftweb.util.Helpers$.calcTime(Helpers.scala:29)
net.liftweb.mapper.DB$.runPreparedStatement(DB.scala:372)
net.liftweb.mapper.DB$.prepareStatement(DB.scala:316)
net.liftweb.mapper.MetaMapper$$anonfun$14.apply(MetaMapper.scala:635)
net.liftweb.mapper.MetaMapper$$anonfun$14.apply(MetaMapper.scala:630)
net.liftweb.mapper.DB$.use(DB.scala:389)
net.liftweb.mapper.MetaMapper$class.save(MetaMapper.scala:629)
org.harrow.findaholidaylet.model.Property$.save(Property.scala:98)

-- Ewan
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---