[Lift] building lift

[Wilson MacGyver]

Hi,

I git clone the lift source from git hub. then run mvn install to build it.

It fails with

Downloading: 
http://scala-tools.org/repo-releases/javax/transaction/jta/1.0.1B/jta-1.0.1B.jar
[INFO] Unable to find resource 'javax.transaction:jta:jar:1.0.1B' in
repository scala-tools.org (http://scala-tools.org/repo-releases)
Downloading: 
http://scala-tools.org/repo-snapshots/javax/transaction/jta/1.0.1B/jta-1.0.1B.jar
[INFO] Unable to find resource 'javax.transaction:jta:jar:1.0.1B' in
repository scala-tools.org.snapshots
(http://scala-tools.org/repo-snapshots)
Downloading: 
http://repo1.maven.org/maven2/javax/transaction/jta/1.0.1B/jta-1.0.1B.jar
[INFO] Unable to find resource 'javax.transaction:jta:jar:1.0.1B' in
repository central (http://repo1.maven.org/maven2)
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Failed to resolve artifact.

Missing:
--
1) javax.transaction:jta:jar:1.0.1B


is this intentional due to some license issue with the jta jar?

Thanks,
Mac

-- 
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: JTA Transaction Monad - Early Access Program

[David Pollak]

On Sat, Jul 18, 2009 at 11:20 AM, Timothy Perrett
wrote:

>
> Awesome - kudos Jonas.


+1

And more generally, it's great to have such a diverse and talented group of
people contributing to Lift!


>
>
> Cheers, Tim
>
> On Jul 18, 11:53 am, Jonas Bonér  wrote:
> > JTA stuff is in github master branch now.
> http://github.com/dpp/liftweb/tree/4d8405a3dcf93570da8142c078784f9dc1...
> >
> > Have fun.
> > /Jonas
>
> >
>


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

Re: [scala] Re: [Lift] Re: Jersey + Lift, whats the story?

[David Pollak]

Greg,
This sounds interesting... but I'd like to see what the Scala code would
look like that would manipulate the Zipper-based data structures.  If you've
got a pile of XML, what does it look like to map it to nested [case]
classes?  What does it look like to manipulate the XML?

Thanks,

David

On Fri, Jul 17, 2009 at 10:54 AM, Meredith Gregory  wrote:

> Guys,
>
> After playing around with integrating Lift and Jersey before the Jersey
> guys did an 'official' integration and thinking hard about how i wanted to
> reference locations in data structures via URLs, i realized that 
> zipper(cf. this
> explanation ) is a much better,
> much more functional, generic and maintainable solution.
>
> Briefly, the way this works is to automate the calculation of a context
> type, C(T), from a data type T. The context type will allow for the
> representation of locations in an instance of T in terms of contexts and
> holes. There's a natural way to get from contexts to paths. So, there's a
> natural map from URLs (viewed as paths) to locations. One great example of
> how this works in practice is Oleg Kiselyov's Zipper-based file system. The
> analogy between paths to files and URLs to resources should be clear.
>
> This has led me to look at where to cut the line on calculating zippers. As
> the wikipedia article mentions above, it is possible do this completely
> generically, provided one has a notion of differentiation on data
> structures; that is, the zipper can be expressed in terms of the derivative
> of a data structure. There are two natural (and somewhat competing) places
> to hang the differentiation calculation:
>
>- the new collections library for scala
>- the target of a mapping from one of the XML schema proposals to scala
>types
>
> Jorge and i were chatting about this the other day. Either route is a bit
> of a large task and i've got a bunch of other stuff on my plate right now.
> However, i'd be very happy to collaborate with anyone who wants to make this
> happen. Also, by the way, this works really well with a lot of other
> monadically based machinery.
>
> Best wishes,
>
> --greg
>
>
> On Fri, Jul 17, 2009 at 8:17 AM, TylerWeir  wrote:
>
>>
>> >>Wait a few days, and I think there'll be some very good news on this
>> front.
>>
>> Tease! :)
>>
>> On Jul 17, 10:51 am, David Pollak 
>> wrote:
>> > There are benefits to both approaches.  I prefer the partial function
>> > composition, but annotations on Pojos have their place.
>> > Wait a few days, and I think there'll be some very good news on this
>> front.
>> >
>> > On Fri, Jul 17, 2009 at 7:28 AM, Timothy Perrett
>> wrote:
>> >
>> >
>> >
>> >
>> >
>> > > Hey guys,
>> >
>> > > I've been taking a look at Jersey and how it operates with Lift by way
>> > > of the recent integration that cropped up on dev.java.net...
>> >
>> > > From my perspective, I see how having a standard RS service framework
>> > > could be helpful, but it appears to bypass important lift concepts
>> > > like SiteMap etc so I'm just wondering what the benefit of using such
>> > > a layer would be over using DispatchPF etc to create REST services or
>> > > serving xml fragments for templates? (I have no idea about Jersey
>> > > apart from the basic docs ive read, so if im missing a major benefit
>> > > id love to hear discuss)
>> >
>> > > Cheers for any thoughts
>> >
>> > > Tim
>> >
>> > --
>> > Lift, the simply functional web frameworkhttp://liftweb.net
>> > Beginning Scalahttp://www.apress.com/book/view/1430219890
>> > Follow me:http://twitter.com/dpp
>> > Git some:http://github.com/dpp
>> >>
>>
>
>
> --
> L.G. Meredith
> Managing Partner
> Biosimilarity LLC
> 1219 NW 83rd St
> Seattle, WA 98117
>
> +1 206.650.3740
>
> http://biosimilarity.blogspot.com
>



-- 
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: Code Review for Unique Key Constraints

[Calen Pennington]

So, I'm trying to make use of this code, now that it's in the git repo.

However, I'm running into the follow issue:

In my model, I have

object RecipeIngredient extends RecipeIngredient with
LongKeyedMetaMapper[RecipeIngredient] {
  override def dbIndexes = UniqueIndex(new IndexField(recipe), new
IndexField(order)) :: Nil
}

However, when the schemifier runs, I get a match error:

scala.MatchError: UniqueIndex(Array(IndexField(NULL), IndexField(0)))
at
net.liftweb.mapper.Schemifier$$anonfun$net$liftweb$mapper$Schemifier$$ensureIndexes$2.apply(Schemifier.scala:266)
at
net.liftweb.mapper.Schemifier$$anonfun$net$liftweb$mapper$Schemifier$$ensureIndexes$2.apply(Schemifier.scala:261)
...

It seems that the only way that the UniqueIndex wouldn't match would be if
there was a type inconsistency. However, I can't figure out how that could
be happening. (For reference, I get the same error if I use an Index, rather
than a UniqueIndex).

Any thoughts?

Thanks
-Cale

On Tue, Jul 14, 2009 at 4:05 PM, Derek Chen-Becker wrote:

> OK, it's merged. An example usage of the new GenericIndex is:
>
> package com.test.model
>
> import _root_.net.liftweb.mapper._
>
> class DateItem extends Mapper[DateItem] with IdPK {
>   def getSingleton = DateItem
>   object timestamp extends MappedDateTime(this)
>   object time extends MappedTime(this)
>   object date extends MappedDate(this)
> }
>
> object DateItem extends DateItem with MetaMapper[DateItem] {
>   override def fieldOrder = date :: time :: timestamp :: Nil
>   override def dbIndexes = GenericIndex({ (table,columns) =>
> String.format("CREATE UNIQUE INDEX %s ON %s %s", "myindex_" + table + "_" +
> columns.mkString("_"), table, columns.mkString("(", ",", ")"))},
> IHaveValidatedThisSQL("Derek", "2009-07-13"), date) :: Nil
> }
>
> It's basically up to you to generate the DDL statement based on the table
> and column names.
>
> Derek
>
>
> On Mon, Jul 13, 2009 at 4:11 PM, Derek Chen-Becker 
> wrote:
>
>> OK, on wip-dcb-unique-indices there's now a GenericIndex that should give
>> you full flexibility to do whatever you want for an index. I'll hold until
>> tomorrow to merge with trunk.
>>
>> Derek
>>
>>
>> On Mon, Jul 13, 2009 at 9:26 AM, Derek Chen-Becker > > wrote:
>>
>>> I'll add a UserIndex type that will let you specify the creation of the
>>> index directly. Unique indices are generally supported across all DBs,
>>> AFAIK, so it makes it more clear to have a specific type.
>>>
>>> Derek
>>>
>>>
>>> On Mon, Jul 13, 2009 at 7:40 AM, Calen Pennington <
>>> calen.penning...@gmail.com> wrote:
>>>

 Hey, I'm glad the code could make it in. One comment on your changes:
 It seems to me that using the pattern matching in ensureIndexes puts
 Lift in the position of maintaining support for various DBs, rather
 than letting the client code do it in a project by project basis (for
 instance, the FULLTEXT and SPACIAL index types that I mentioned, that
 are mysql specific.) Is there a reason that you preferred that over
 allowing client code to specify the index type?

 -Cale

 On Fri, Jul 10, 2009 at 5:32 PM, Derek Chen-Becker<
 dchenbec...@gmail.com> wrote:
 > I've pushed a smaller commit into the wip-dcb-unique-indices branch on
 > GitHub that adds a UniqueIndex case class. Conceivably we could add
 other
 > types of indices if there's a need. If no one has any objections to
 what
 > I've added I can merge with trunk on Monday.
 >
 > Derek
 >
 > http://github.com/dpp/liftweb/tree/wip-dcb-unique-indices
 >
 > On Thu, Jul 9, 2009 at 9:44 PM, DFectuoso 
 wrote:
 >>
 >> I for one would like to say: Cool! Thanks! If i need unique indexes
 in
 >> the next couple of weeks i'll get this baby to the war( .war thats
 >> it ) =)
 >>
 >> On Jul 9, 11:30 am, Calen Pennington 
 >> wrote:
 >> > As mentioned is this issue
 >> > (http://github.com/dpp/liftweb/issues#issue/19), and as came up on
 the
 >> > list recently, Lift currently has no way to specify that a field or
 an
 >> > index be unique. I've coded up a patch that addresses this, and
 could
 >> > also be used for other index types on a project specific basis (for
 >> > instance, FULLTEXT or SPATIAL indexes in mysql).
 >> >
 >> > -Cale
 >> >
 >> >  0001-Adding-the-ability-to-create-UNIQUE-indexes-over-sin.patch
 >> > 5KViewDownload
 >>
 >>
 >
 >
 > >
 >



>>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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: File upload streaming and progress monitoring ...

[marius d.]

Great. Let me know if I can help with anything.

Br's,
Marius

On Jul 18, 9:22 pm, Timothy Perrett  wrote:
> Marius,
>
> This is awesome. Things are now working as expected - I knew this
> wasn't a browser connection issue causing the problems.
>
> The code in the widget package is pretty rubbish right now, but i just
> had time to hack together a hardcoded sample to make sure that your
> commit actually fix the problem... Im happy to report that it does
> indeed now work exactly as required.
>
> The next step is to work backwards and clean all the code up and fix
> the cross-browser issues as right now it works in firefox and IE but
> not in safari or chrome et al.
>
> Cheers, Tim
>
> On Jul 18, 3:08 pm, "marius d."  wrote:
>
> > Just committed a fix ...
>
> > Br's,
> > Marius
>
> > On Jul 18, 4:10 pm, "marius d."  wrote:
>
> > > A little more on this ...
>
> > > Living the above synchronized blocks where they are but removing the
> > > one from LiftSession.runParams  made it work properly. Looks like this
> > > one was holding the lock while the file upload progress was happening.
> > > Dave I'm not really sure why in runParams the the toRun is obtained
> > > from a synchronized block ... is it because we'rreading from
> > > messageCallback there ? ..cause otherwise the entire expression is
> > > about functions composition that does not change any state.
>
> > > Br's,
> > > Marius
>
> > > On Jul 18, 3:57 pm, Marius  wrote:
>
> > > > HI there,
>
> > > > I know, there have been several other threads around the topic but I
> > > > just wanted to yield somethings here. In the past few days I've been
> > > > talking with Tim as he was having problems with his FileUpload widget.
> > > > Even with short polling the progress was not reported even though the
> > > > LiftSession.progressListener was properly called.
>
> > > > Today I started to look into it and here is what I've done:
>
> > > > 1. Here is the markup:
>
> > > >   
>
> > > >    > > > target="upload_target">
> > > >     
> > > >     
> > > >   
>
> > > >   A simple snippet that uses the invisible iframe trick to upload
> > > > stuff in the background. The so called "Ajax" upload. (I had to add
> > > > the target attribute into the supported form snippet attributed but
> > > > that's ok)
>
> > > > 2. In boot had something like:
>
> > > >     LiftSession.onSetupSession = ((session: LiftSession) => {
> > > >       session.progessListener = Full((chunk, total, index) => {
> > > >          Thread.sleep(100)
> > > >          println(index + " read " + chunk + " out of " + total + " " +
> > > > Thread.currentThread)
> > > >       })
> > > >     }) :: Nil
>
> > > >     Just monitor the progress ... and to make it last a little longer
> > > > I'm sleeping for 100 milliseconds
>
> > > > 3. I set the GC polling to 10 seconds. The think is that GC polling
> > > > would be just like the short polling for getting the progress status
> > > > back in the browser.
>
> > > > The behavior that I observed was that while I was uploading a 30 Mb +
> > > > file the polling requests timed out after 5 secconds per
> > > > LiftRules.ajaxPostTimeout. This means that our progress monitoring
> > > > ajax request would have timed out as well. On the server side the
> > > > execution got stuck until the upload was complete.
> > > > LiftServlet.handleAjax was not called until the upload terminates.
>
> > > > Initially I thought that this has to do to limited request channels
> > > > that browser have but the thing is that we have several places in Lift
> > > > code where we synchronize things. Such as LiftSession.getSession,
> > > > LiftSession.fixSessionTime etc. Acquiring these locks made the
> > > > progress polling to hang until the upload terminated. Of course
> > > > removing th synchronized block made the polling to work right during
> > > > the file upload. Now this was just for test ... I'm not suggesting to
> > > > remove the synchronized blocks as  we'd loose consistency but this
> > > > looks to stay in the way of properly dealing with multiple parallel
> > > > request per same session like fileupload and progress monitoring.
>
> > > > It appears that there is either a thread starvation situation or
> > > > simply a lock that is held while upload is is progress.
>
> > > > Br's,
> > > > Marius
--~--~-~--~~~---~--~~
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: Wiki Articles

[Timothy Perrett]

Hey Alex,

> - Templating
>   * Snippets etc.

You might want to checkout my article here: http://is.gd/sfyT

As for the rest of your list, I agree these need documenting in fair
detail. I can certainly contribute from a localization and REST
perspective - i'll try and crank something out onto my blog.

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] Re: Jersey + Lift, whats the story?

[Timothy Perrett]

Greg, once again your musing are generally over my head but I follow
your thoughts conceptually here.

Sounds like your saying Jersey wasnt the best fit with lift from a
functional perspective and you want to create something more monadic
based  on the zipper pattern?

Like i said, Jersey is not part of my usual tool chain so im not
really familiar with it full stop - let alone what value it adds to
lift as from my perspective the templating system in lift by default
is pretty sweet

Cheers, Tim

On Jul 17, 6:54 pm, Meredith Gregory  wrote:
> Guys,
>
> After playing around with integrating Lift and Jersey before the Jersey guys
> did an 'official' integration and thinking hard about how i wanted to
> reference locations in data structures via URLs, i realized that
> zipper(cf.
> this
> explanation ) is a much better,
> much more functional, generic and maintainable solution.
>
> Briefly, the way this works is to automate the calculation of a context
> type, C(T), from a data type T. The context type will allow for the
> representation of locations in an instance of T in terms of contexts and
> holes. There's a natural way to get from contexts to paths. So, there's a
> natural map from URLs (viewed as paths) to locations. One great example of
> how this works in practice is Oleg Kiselyov's Zipper-based file system. The
> analogy between paths to files and URLs to resources should be clear.
>
> This has led me to look at where to cut the line on calculating zippers. As
> the wikipedia article mentions above, it is possible do this completely
> generically, provided one has a notion of differentiation on data
> structures; that is, the zipper can be expressed in terms of the derivative
> of a data structure. There are two natural (and somewhat competing) places
> to hang the differentiation calculation:
>
>    - the new collections library for scala
>    - the target of a mapping from one of the XML schema proposals to scala
>    types
>
> Jorge and i were chatting about this the other day. Either route is a bit of
> a large task and i've got a bunch of other stuff on my plate right now.
> However, i'd be very happy to collaborate with anyone who wants to make this
> happen. Also, by the way, this works really well with a lot of other
> monadically based machinery.
>
> Best wishes,
>
> --greg
>
>
>
>
>
> On Fri, Jul 17, 2009 at 8:17 AM, TylerWeir  wrote:
>
> > >>Wait a few days, and I think there'll be some very good news on this
> > front.
>
> > Tease! :)
>
> > On Jul 17, 10:51 am, David Pollak 
> > wrote:
> > > There are benefits to both approaches.  I prefer the partial function
> > > composition, but annotations on Pojos have their place.
> > > Wait a few days, and I think there'll be some very good news on this
> > front.
>
> > > On Fri, Jul 17, 2009 at 7:28 AM, Timothy Perrett  > >wrote:
>
> > > > Hey guys,
>
> > > > I've been taking a look at Jersey and how it operates with Lift by way
> > > > of the recent integration that cropped up on dev.java.net...
>
> > > > From my perspective, I see how having a standard RS service framework
> > > > could be helpful, but it appears to bypass important lift concepts
> > > > like SiteMap etc so I'm just wondering what the benefit of using such
> > > > a layer would be over using DispatchPF etc to create REST services or
> > > > serving xml fragments for templates? (I have no idea about Jersey
> > > > apart from the basic docs ive read, so if im missing a major benefit
> > > > id love to hear discuss)
>
> > > > Cheers for any thoughts
>
> > > > Tim
>
> > > --
> > > Lift, the simply functional web frameworkhttp://liftweb.net
> > > Beginning Scalahttp://www.apress.com/book/view/1430219890
> > > Follow me:http://twitter.com/dpp
> > > Git some:http://github.com/dpp
>
> --
> L.G. Meredith
> Managing Partner
> Biosimilarity LLC
> 1219 NW 83rd St
> Seattle, WA 98117
>
> +1 206.650.3740
>
> http://biosimilarity.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: File upload streaming and progress monitoring ...

[Timothy Perrett]

Marius,

This is awesome. Things are now working as expected - I knew this
wasn't a browser connection issue causing the problems.

The code in the widget package is pretty rubbish right now, but i just
had time to hack together a hardcoded sample to make sure that your
commit actually fix the problem... Im happy to report that it does
indeed now work exactly as required.

The next step is to work backwards and clean all the code up and fix
the cross-browser issues as right now it works in firefox and IE but
not in safari or chrome et al.

Cheers, Tim

On Jul 18, 3:08 pm, "marius d."  wrote:
> Just committed a fix ...
>
> Br's,
> Marius
>
> On Jul 18, 4:10 pm, "marius d."  wrote:
>
>
>
> > A little more on this ...
>
> > Living the above synchronized blocks where they are but removing the
> > one from LiftSession.runParams  made it work properly. Looks like this
> > one was holding the lock while the file upload progress was happening.
> > Dave I'm not really sure why in runParams the the toRun is obtained
> > from a synchronized block ... is it because we'rreading from
> > messageCallback there ? ..cause otherwise the entire expression is
> > about functions composition that does not change any state.
>
> > Br's,
> > Marius
>
> > On Jul 18, 3:57 pm, Marius  wrote:
>
> > > HI there,
>
> > > I know, there have been several other threads around the topic but I
> > > just wanted to yield somethings here. In the past few days I've been
> > > talking with Tim as he was having problems with his FileUpload widget.
> > > Even with short polling the progress was not reported even though the
> > > LiftSession.progressListener was properly called.
>
> > > Today I started to look into it and here is what I've done:
>
> > > 1. Here is the markup:
>
> > >   
>
> > >    > > target="upload_target">
> > >     
> > >     
> > >   
>
> > >   A simple snippet that uses the invisible iframe trick to upload
> > > stuff in the background. The so called "Ajax" upload. (I had to add
> > > the target attribute into the supported form snippet attributed but
> > > that's ok)
>
> > > 2. In boot had something like:
>
> > >     LiftSession.onSetupSession = ((session: LiftSession) => {
> > >       session.progessListener = Full((chunk, total, index) => {
> > >          Thread.sleep(100)
> > >          println(index + " read " + chunk + " out of " + total + " " +
> > > Thread.currentThread)
> > >       })
> > >     }) :: Nil
>
> > >     Just monitor the progress ... and to make it last a little longer
> > > I'm sleeping for 100 milliseconds
>
> > > 3. I set the GC polling to 10 seconds. The think is that GC polling
> > > would be just like the short polling for getting the progress status
> > > back in the browser.
>
> > > The behavior that I observed was that while I was uploading a 30 Mb +
> > > file the polling requests timed out after 5 secconds per
> > > LiftRules.ajaxPostTimeout. This means that our progress monitoring
> > > ajax request would have timed out as well. On the server side the
> > > execution got stuck until the upload was complete.
> > > LiftServlet.handleAjax was not called until the upload terminates.
>
> > > Initially I thought that this has to do to limited request channels
> > > that browser have but the thing is that we have several places in Lift
> > > code where we synchronize things. Such as LiftSession.getSession,
> > > LiftSession.fixSessionTime etc. Acquiring these locks made the
> > > progress polling to hang until the upload terminated. Of course
> > > removing th synchronized block made the polling to work right during
> > > the file upload. Now this was just for test ... I'm not suggesting to
> > > remove the synchronized blocks as  we'd loose consistency but this
> > > looks to stay in the way of properly dealing with multiple parallel
> > > request per same session like fileupload and progress monitoring.
>
> > > It appears that there is either a thread starvation situation or
> > > simply a lock that is held while upload is is progress.
>
> > > Br's,
> > > Marius
--~--~-~--~~~---~--~~
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: JTA Transaction Monad - Early Access Program

[Timothy Perrett]

Awesome - kudos Jonas.

Cheers, Tim

On Jul 18, 11:53 am, Jonas Bonér  wrote:
> JTA stuff is in github master branch 
> now.http://github.com/dpp/liftweb/tree/4d8405a3dcf93570da8142c078784f9dc1...
>
> Have fun.
> /Jonas

--~--~-~--~~~---~--~~
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: File upload streaming and progress monitoring ...

[marius d.]

Just committed a fix ...

Br's,
Marius

On Jul 18, 4:10 pm, "marius d."  wrote:
> A little more on this ...
>
> Living the above synchronized blocks where they are but removing the
> one from LiftSession.runParams  made it work properly. Looks like this
> one was holding the lock while the file upload progress was happening.
> Dave I'm not really sure why in runParams the the toRun is obtained
> from a synchronized block ... is it because we'rreading from
> messageCallback there ? ..cause otherwise the entire expression is
> about functions composition that does not change any state.
>
> Br's,
> Marius
>
> On Jul 18, 3:57 pm, Marius  wrote:
>
> > HI there,
>
> > I know, there have been several other threads around the topic but I
> > just wanted to yield somethings here. In the past few days I've been
> > talking with Tim as he was having problems with his FileUpload widget.
> > Even with short polling the progress was not reported even though the
> > LiftSession.progressListener was properly called.
>
> > Today I started to look into it and here is what I've done:
>
> > 1. Here is the markup:
>
> >   
>
> >    > target="upload_target">
> >     
> >     
> >   
>
> >   A simple snippet that uses the invisible iframe trick to upload
> > stuff in the background. The so called "Ajax" upload. (I had to add
> > the target attribute into the supported form snippet attributed but
> > that's ok)
>
> > 2. In boot had something like:
>
> >     LiftSession.onSetupSession = ((session: LiftSession) => {
> >       session.progessListener = Full((chunk, total, index) => {
> >          Thread.sleep(100)
> >          println(index + " read " + chunk + " out of " + total + " " +
> > Thread.currentThread)
> >       })
> >     }) :: Nil
>
> >     Just monitor the progress ... and to make it last a little longer
> > I'm sleeping for 100 milliseconds
>
> > 3. I set the GC polling to 10 seconds. The think is that GC polling
> > would be just like the short polling for getting the progress status
> > back in the browser.
>
> > The behavior that I observed was that while I was uploading a 30 Mb +
> > file the polling requests timed out after 5 secconds per
> > LiftRules.ajaxPostTimeout. This means that our progress monitoring
> > ajax request would have timed out as well. On the server side the
> > execution got stuck until the upload was complete.
> > LiftServlet.handleAjax was not called until the upload terminates.
>
> > Initially I thought that this has to do to limited request channels
> > that browser have but the thing is that we have several places in Lift
> > code where we synchronize things. Such as LiftSession.getSession,
> > LiftSession.fixSessionTime etc. Acquiring these locks made the
> > progress polling to hang until the upload terminated. Of course
> > removing th synchronized block made the polling to work right during
> > the file upload. Now this was just for test ... I'm not suggesting to
> > remove the synchronized blocks as  we'd loose consistency but this
> > looks to stay in the way of properly dealing with multiple parallel
> > request per same session like fileupload and progress monitoring.
>
> > It appears that there is either a thread starvation situation or
> > simply a lock that is held while upload is is progress.
>
> > Br's,
> > Marius
--~--~-~--~~~---~--~~
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: File upload streaming and progress monitoring ...

[marius d.]

A little more on this ...

Living the above synchronized blocks where they are but removing the
one from LiftSession.runParams  made it work properly. Looks like this
one was holding the lock while the file upload progress was happening.
Dave I'm not really sure why in runParams the the toRun is obtained
from a synchronized block ... is it because we'rreading from
messageCallback there ? ..cause otherwise the entire expression is
about functions composition that does not change any state.


Br's,
Marius

On Jul 18, 3:57 pm, Marius  wrote:
> HI there,
>
> I know, there have been several other threads around the topic but I
> just wanted to yield somethings here. In the past few days I've been
> talking with Tim as he was having problems with his FileUpload widget.
> Even with short polling the progress was not reported even though the
> LiftSession.progressListener was properly called.
>
> Today I started to look into it and here is what I've done:
>
> 1. Here is the markup:
>
>   
>
>    target="upload_target">
>     
>     
>   
>
>   A simple snippet that uses the invisible iframe trick to upload
> stuff in the background. The so called "Ajax" upload. (I had to add
> the target attribute into the supported form snippet attributed but
> that's ok)
>
> 2. In boot had something like:
>
>     LiftSession.onSetupSession = ((session: LiftSession) => {
>       session.progessListener = Full((chunk, total, index) => {
>          Thread.sleep(100)
>          println(index + " read " + chunk + " out of " + total + " " +
> Thread.currentThread)
>       })
>     }) :: Nil
>
>     Just monitor the progress ... and to make it last a little longer
> I'm sleeping for 100 milliseconds
>
> 3. I set the GC polling to 10 seconds. The think is that GC polling
> would be just like the short polling for getting the progress status
> back in the browser.
>
> The behavior that I observed was that while I was uploading a 30 Mb +
> file the polling requests timed out after 5 secconds per
> LiftRules.ajaxPostTimeout. This means that our progress monitoring
> ajax request would have timed out as well. On the server side the
> execution got stuck until the upload was complete.
> LiftServlet.handleAjax was not called until the upload terminates.
>
> Initially I thought that this has to do to limited request channels
> that browser have but the thing is that we have several places in Lift
> code where we synchronize things. Such as LiftSession.getSession,
> LiftSession.fixSessionTime etc. Acquiring these locks made the
> progress polling to hang until the upload terminated. Of course
> removing th synchronized block made the polling to work right during
> the file upload. Now this was just for test ... I'm not suggesting to
> remove the synchronized blocks as  we'd loose consistency but this
> looks to stay in the way of properly dealing with multiple parallel
> request per same session like fileupload and progress monitoring.
>
> It appears that there is either a thread starvation situation or
> simply a lock that is held while upload is is progress.
>
> Br's,
> Marius
--~--~-~--~~~---~--~~
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] File upload streaming and progress monitoring ...

[Marius]

HI there,

I know, there have been several other threads around the topic but I
just wanted to yield somethings here. In the past few days I've been
talking with Tim as he was having problems with his FileUpload widget.
Even with short polling the progress was not reported even though the
LiftSession.progressListener was properly called.

Today I started to look into it and here is what I've done:

1. Here is the markup:

  

  


  

  A simple snippet that uses the invisible iframe trick to upload
stuff in the background. The so called "Ajax" upload. (I had to add
the target attribute into the supported form snippet attributed but
that's ok)

2. In boot had something like:

LiftSession.onSetupSession = ((session: LiftSession) => {
  session.progessListener = Full((chunk, total, index) => {
 Thread.sleep(100)
 println(index + " read " + chunk + " out of " + total + " " +
Thread.currentThread)
  })
}) :: Nil

Just monitor the progress ... and to make it last a little longer
I'm sleeping for 100 milliseconds

3. I set the GC polling to 10 seconds. The think is that GC polling
would be just like the short polling for getting the progress status
back in the browser.

The behavior that I observed was that while I was uploading a 30 Mb +
file the polling requests timed out after 5 secconds per
LiftRules.ajaxPostTimeout. This means that our progress monitoring
ajax request would have timed out as well. On the server side the
execution got stuck until the upload was complete.
LiftServlet.handleAjax was not called until the upload terminates.

Initially I thought that this has to do to limited request channels
that browser have but the thing is that we have several places in Lift
code where we synchronize things. Such as LiftSession.getSession,
LiftSession.fixSessionTime etc. Acquiring these locks made the
progress polling to hang until the upload terminated. Of course
removing th synchronized block made the polling to work right during
the file upload. Now this was just for test ... I'm not suggesting to
remove the synchronized blocks as  we'd loose consistency but this
looks to stay in the way of properly dealing with multiple parallel
request per same session like fileupload and progress monitoring.

It appears that there is either a thread starvation situation or
simply a lock that is held while upload is is progress.


Br's,
Marius
--~--~-~--~~~---~--~~
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: JTA Transaction Monad - Early Access Program

[Jonas Bonér]

JTA stuff is in github master branch now.
http://github.com/dpp/liftweb/tree/4d8405a3dcf93570da8142c078784f9dc127933c/lift-jta

Have fun.
/Jonas

2009/7/17 David Pollak :
>
>
> On Fri, Jul 17, 2009 at 1:02 AM, Jonas Bonér  wrote:
>>
>> Hi Greg.
>>
>> Have you had time to look at the JTA stuff?
>> Should I merge in master?
>
> Please merge into Master.  We've got 6-8 weeks until with have the 1.1
> release code slush... and if stuff is in the Maven repo, it'll get used.
>
>>
>> /Jonas
>>
>> 2009/7/7 Jonas Bonér :
>> > Thanks Tim. Thanks for staying on top of it. Derek has already looked
>> > at it and seemed to like it. But I'll wait until I get Greg's
>> > feedback.
>> >
>> > 2009/7/7 Timothy Perrett :
>> >>
>> >>
>> >> Hey Jonas,
>> >>
>> >> I have no real use case to test it out - I was just interested in its
>> >> status
>> >> as conceptually it was very very clever and wondered where you were too
>> >> with
>> >> it. I think Greg or Derek are most likely to be able to give you
>> >> valuable
>> >> feedback as I believe they are using JTA already.
>> >>
>> >> Cheers, Tim
>> >>
>> >> On 07/07/2009 18:18, "Jonas Bonér"  wrote:
>> >>
>> >>>
>> >>> No I haven't. Should I? Is everyone happy with it?
>> >>> Have anyone tried it? Is anyone using it?
>> >>>
>> >>> 2009/6/30 Timothy Perrett :
>> 
>>  Jonas,
>> 
>>  Did you roll this into master? What's its status?
>> 
>>  Cheers, Tim
>> 
>>  On Jun 10, 4:46 pm, James Strachan  wrote:
>> > 2009/6/9 Jonas Bonér :
>> >
>> >
>> >
>> >> 2009/6/9 David Pollak :
>> >>> Jonas,
>> >>> We always use Maven to load dependencies.  We never use GPL
>> >>> dependencies.
>> >>>  If you have a question about the license of a dependency and its
>> >>> use in
>> >>> Lift, please ping me privately.
>> >
>> >> I am using Maven. But as I said I could not find the Atomikos in
>> >> any
>> >> public library, putting them in lib will let the user easily
>> >> install
>> >> them in their local repo.
>> >> Do you know if they are in any public repo?
>> >
>> > If its any help I added them here a while back for an integration
>> > test
>> > in ActiveMQhttp://repo.fusesource.com/maven2-all/com/atomikos/
>> >
>> > the repo is:http://repo.fusesource.com/maven2-all/
>> >
>> > you might wanna put more recent jars up on some public repo though.
>> >
>> > --
>> > James
>> > ---http://macstrac.blogspot.com/
>> >
>> > Open Source Integrationhttp://fusesource.com/
>> >
>> 
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Jonas Bonér
>> >
>> > twitter: @jboner
>> > blog:    http://jonasboner.com
>> > work:   http://crisp.se
>> > work:   http://scalablesolutions.se
>> > code:   http://github.com/jboner
>> >
>>
>>
>>
>> --
>> Jonas Bonér
>>
>> twitter: @jboner
>> blog:    http://jonasboner.com
>> work:   http://crisp.se
>> work:   http://scalablesolutions.se
>> code:   http://github.com/jboner
>>
>>
>
>
>
> --
> 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
>
> >
>



-- 
Jonas Bonér

twitter: @jboner
blog:http://jonasboner.com
work:   http://crisp.se
work:   http://scalablesolutions.se
code:   http://github.com/jboner

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