Re: [Lift] Lift on Atmosphere
Akka has excellent Atmosphere support. Akka can be used with Lift. http://doc.akkasource.org/comet 2010/1/6 paksegu paks...@gmail.com: Hello World. I am a Lift beginner and I would like to know if anyone has successfully succeeded in running Lift on Atmosphere: https://atmosphere.dev.java.net thanks. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Jonas Bonér twitter: @jboner blog:http://jonasboner.com work: http://scalablesolutions.se code: http://github.com/jboner code: http://akkasource.org also:http://letitcrash.com -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] ANN: Akka 0.6 is released
Hi. I am proud to announce the release of Akka 0.6. It is a major release in many ways. Many people have made this happen. Especially the great teamhttp://doc.akkasource.org/team but also many of the users on the mailing list. Thank you all. Download Akka 0.6 herehttp://cloud.github.com/downloads/jboner/akka/akka-0.6.zip . The full release notes is available at herehttp://doc.akkasource.org/release-notes, but here is a summary of the highlights. - New STM impl with a declarative, a high-order fun and a monadic API - New persistence module backends; Redis, Cassandra, MongoDB, works with STM - Much improved performance; Akka is now 2-3 times faster than Scala Actors (both event and thread-based) in http://shootout.alioth.debian.org/ benchmark. - Much improved memory footprint; an Actor consumes ~600 bytes, can now create 6.5 million on 4 G RAM - Much improved Remote Actors; reconnect, compression, implicit sender, supervision across nodes etc. - Comet bindings for Actors - REST bindings for Actors - Cluster Membership protocol; nodes find each other automatically, simple API - Security module; HTTP digest and Kerberos - Many new Serializers; SBinary, JSON, Protobuf etc. - AMQP integration - Lift integration - Spring integration (in progress) - Guice integration - Microkernel New home at http://akkasource.org http://akkasource.orgNew docs at http://doc.akkasource.org New tutorial at http://jonasboner.com/2010/01/04/introducing-akka.html Feedback is most welcome. Join the mailing list and help us make it better. Thanks. -- Jonas Bonér twitter: @jboner blog:http://jonasboner.com work: http://scalablesolutions.se code: http://github.com/jboner code: http://akkasource.org also:http://letitcrash.com -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] ANN: Akka 0.6 is released
Thanks Tim. You are part of the story. Thanks. 2010/1/5 Timothy Perrett timo...@getintheloop.eu Congratulations all... you guys have put so much effort into Akka and its a really great framework; cant wait to see what is in store down the track! Cheers, Tim On 5 Jan 2010, at 13:34, Jonas Bonér wrote: Hi. I am proud to announce the release of Akka 0.6. It is a major release in many ways. Many people have made this happen. Especially the great team but also many of the users on the mailing list. Thank you all. Download Akka 0.6 here. The full release notes is available at here, but here is a summary of the highlights. • New STM impl with a declarative, a high-order fun and a monadic API • New persistence module backends; Redis, Cassandra, MongoDB, works with STM • Much improved performance; Akka is now 2-3 times faster than Scala Actors (both event and thread-based) in http://shootout.alioth.debian.org/ benchmark. • Much improved memory footprint; an Actor consumes ~600 bytes, can now create 6.5 million on 4 G RAM • Much improved Remote Actors; reconnect, compression, implicit sender, supervision across nodes etc. • Comet bindings for Actors • REST bindings for Actors • Cluster Membership protocol; nodes find each other automatically, simple API • Security module; HTTP digest and Kerberos • Many new Serializers; SBinary, JSON, Protobuf etc. • AMQP integration • Lift integration • Spring integration (in progress) • Guice integration • Microkernel New home at http://akkasource.org New docs at http://doc.akkasource.org New tutorial at http://jonasboner.com/2010/01/04/introducing-akka.html Feedback is most welcome. Join the mailing list and help us make it better. Thanks. -- Jonas Bonér twitter: @jboner blog:http://jonasboner.com work: http://scalablesolutions.se code: http://github.com/jboner code: http://akkasource.org also:http://letitcrash.com -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Jonas Bonér twitter: @jboner blog:http://jonasboner.com work: http://scalablesolutions.se code: http://github.com/jboner code: http://akkasource.org also:http://letitcrash.com -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] ANN: Akka 0.6 is released
Thanks 2010/1/5 David Pollak feeder.of.the.be...@gmail.com: Congratulations! On Tue, Jan 5, 2010 at 5:34 AM, Jonas Bonér jbo...@gmail.com wrote: Hi. I am proud to announce the release of Akka 0.6. It is a major release in many ways. Many people have made this happen. Especially the great team but also many of the users on the mailing list. Thank you all. Download Akka 0.6 here. The full release notes is available at here, but here is a summary of the highlights. New STM impl with a declarative, a high-order fun and a monadic API New persistence module backends; Redis, Cassandra, MongoDB, works with STM Much improved performance; Akka is now 2-3 times faster than Scala Actors (both event and thread-based) in http://shootout.alioth.debian.org/ benchmark. Much improved memory footprint; an Actor consumes ~600 bytes, can now create 6.5 million on 4 G RAM Much improved Remote Actors; reconnect, compression, implicit sender, supervision across nodes etc. Comet bindings for Actors REST bindings for Actors Cluster Membership protocol; nodes find each other automatically, simple API Security module; HTTP digest and Kerberos Many new Serializers; SBinary, JSON, Protobuf etc. AMQP integration Lift integration Spring integration (in progress) Guice integration Microkernel New home at http://akkasource.org New docs at http://doc.akkasource.org New tutorial at http://jonasboner.com/2010/01/04/introducing-akka.html Feedback is most welcome. Join the mailing list and help us make it better. Thanks. -- Jonas Bonér twitter: @jboner blog: http://jonasboner.com work: http://scalablesolutions.se code: http://github.com/jboner code: http://akkasource.org also: http://letitcrash.com -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Jonas Bonér twitter: @jboner blog:http://jonasboner.com work: http://scalablesolutions.se code: http://github.com/jboner code: http://akkasource.org also:http://letitcrash.com -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Devoxx 2009
Amazing. Great news. Good job guys. Wish I was there. 2009/11/21 Timothy Perrett timo...@getintheloop.eu: Folks, I got back from Devoxx late last night and thought I would just post some thoughts and experiences from the event. Firstly, there was an awesome interest in Scala and Lift - my talk was really busy (~550 people) and the general Scala Enthusiast BOF right afterwards was packed. Myself, Bill Venners, Viktor Klang and Frank Sommers pretty much represented a cross-section of Scala projects at the BOF and throughout the whole week we were pretty much swamped with Scala questions and interest. Lift was getting a lot of attention and was even used by Oracle in the Devoxx keynote!!! Another event of note was when myself, viktor and john were sat in the hotel reception hacking on Scala and showing it so some interested people at around 10pm, the JavaPosse turned up and were like wow, we appear to have stumbled upon the Scala geeks - they then proceeded to join the hackfest which was über cool. All in all, a very very successful week and I think the above mentioned group did an amazing job of raising the profile of Scala even further; moreover, some of the Lift discussions were brilliant - appeared to be a lot of people wanting to convert from Spring bean hell ;-) We as a team should be made up with the awesome framework that has been created here -- the next 12 months I believe will be somewhat of a Scala / Lift golden age where we have the opportunity to really make our mark on the industry. Congratulations everyone! Cheers, Tim PS: If you were at Devoxx and came to my talk, thanks for attending :-) -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=. -- Jonas Bonér twitter: @jboner blog:http://jonasboner.com work: http://scalablesolutions.se code: http://github.com/jboner code: http://akkasource.org also:http://letitcrash.com -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=.
Re: [Lift] Re: intro to lift-json?
I like that.
But still hate JSON ;-)
2009/11/20 Joni Freeman freeman.j...@gmail.com:
Hi,
There's several ways to get values from JSON.
1. Use LINQ style query comprehension:
for { JField(bar, JInt(x)) - json } yield x
2. Extract values with case classes
implicit val formats = net.liftweb.json.DefaultFormats
case class Foo(foo: Bar)
case class Bar(bar: Int)
json.extract[Foo]
3. XPath style
val JField(bar, JInt(x)) = json \ foo \ bar
Cheers Joni
On 19 marras, 22:20, harryh har...@gmail.com wrote:
Is there a basic intro to lift-json floating around anywhere? I'm
having a bit of trouble getting started with a couple basic things.
For example if a have a JObject that corresponds to:
{
foo : {
bar : 999
}
}
How do I get the 999 (as an int) out of the JObject? I'm sure this is
simple, just a bit confused on the basics.
-harryh
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=.
--
Jonas Bonér
twitter: @jboner
blog:http://jonasboner.com
work: http://scalablesolutions.se
code: http://github.com/jboner
code: http://akkasource.org
also:http://letitcrash.com
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=.
[Lift] Re: [scala] Three years of a Scala lust affair, the blog post
Thanks a lot for 3 years of leadership and inspiration. Brilliant and humble at the same time. You have taught me a lot and inspired me to dig deeper into Scala and is also a great guy to hang out with. Keep it up. /Jonas 2009/11/20 David Pollak feeder.of.the.be...@gmail.com: Folks, I've been doing Scala for three years as of today. I wrote a blog post about it: http://blog.lostlake.org/index.php?/archives/97-Happy-3rd-Anniversay.html There are a lot of people to thank for making Scala the great thing it is today. Martin has led his EPFL team to bridge academia and commercial, vigorous debating and politeness, functional and object oriented to bring us Scala and the Scala community. It's been 3 years for me and I can't think of a better language or a better community than what Scala has evolved into. 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 Surf the harmonics -- Jonas Bonér twitter: @jboner blog:http://jonasboner.com work: http://scalablesolutions.se code: http://github.com/jboner code: http://akkasource.org also:http://letitcrash.com -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=.
Re: [Lift] Lift 1.1-M7 and Terracotta
Hi Jon. Could you send me what you have so far and I'll try to take a look at it. I'm pretty choked right now so I can't give it too many cycles but I'll try to do my best :-) Mail it to me directly: my first name AT jonasboner.com /Jonas 2009/11/6 jon jonhoff...@gmail.com: Hi, Has anyone had any recent success with using Terracotta to share session state? I've tried playing around with a simple lift app (1.1-M7) and terracotta's sessions-configurator app. It doesn't just work, but I realized that's because Lift is hijacking sessions from the container and managing them in SessionMaster. I've tried configuring the root object to be net.liftweb.http.SessionMaster$.MODULE$ which is the entire singleton, but that includes a lot of LiftActor stuff (and terracotta complains about unlocked accesses to shared fields), and I think really only want the sessions field. I don't think i can make sessions the root because its reference is overwritten every time a new session is added. Any ideas? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- -- Jonas Bonér twitter: @jboner blog:http://jonasboner.com work: http://scalablesolutions.se code: http://github.com/jboner code: http://akkasource.org also:http://letitcrash.com -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=.
[Lift] Re: A Critique On Lift
I love the _ operator. 2009/10/22 Timothy Perrett timo...@getintheloop.eu: I think this is a bit of a running joke in the scala comunity right now - your right, underscore really does have a number of meanings; I think this will be changed in some future Scala release. Your also forgetting: import some.package._ Cheers, Tim On 22 Oct 2009, at 12:57, tiro wrote: underscore. At least four different uses: - it for defining anonymous functions like above - default value - matching placeholder whose value is ignored - use for constructing setter method names boolean functions (empty_?) -- Jonas Bonér twitter: @jboner blog:http://jonasboner.com work: http://scalablesolutions.se code: http://github.com/jboner code: http://akkasource.org also:http://letitcrash.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: Rolling out the new Lift Actors code
2009/10/21 David Pollak feeder.of.the.be...@gmail.com: Folks, I've just pushed the completed Lift Actor code to the dpp_wip_actorize branch. Jonas and I coordinated on the Actor API and Akka Actors will use the same basic trait so Akka Actors could be used to power Lift's Comet. Very cool David. I'll implement the new API ASAP. I'm very excited about this. Thanks for making it happen. I am ready to push this code to SNAPSHOT. When I do this, there will be breaking changes to all Lift apps (basically, you'll have to import net.liftweb.base._) Does anyone have a timetable for this push? I'd like to have at least a week of solid testing before we do Milestone 7 (currently scheduled for November 4th). Please let me know your thoughts. 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 Surf the harmonics -- Jonas Bonér twitter: @jboner blog:http://jonasboner.com work: http://crisp.se work: http://scalablesolutions.se code: http://github.com/jboner code: http://akkasource.org --~--~-~--~~~---~--~~ 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: Nested 'react'
FWIW, here is the documentation for Akka's AMQP module:
http://wiki.github.com/jboner/akka/reference-amqp
Let me know if you feel that you would like to have things behave
differently or is missing some stuff in the API (it's currently
work-in-progress).
/Jonas
2009/10/2 David Pollak feeder.of.the.be...@gmail.com:
On Mon, Sep 28, 2009 at 1:57 PM, ph pkirsa...@38studios.com wrote:
I don't know if this group is right place to post it, but I couldn't
find any general Scala or Scala/Actor groups, and this is most active
Scala group..
I have server that consumes AMQP messages, handles messages in
dedicated workers(Actors). So design is this:
1. One Dispatcher which is event-based actor (nested reacts)
a. First it listens for event from worker that worker is ready
b. when worker is ready it uses nested react to get AMQP message
and forward it to worker
react {
case WorkerReady(worker:Actor) = react {
case m...@message = worker ! msg; channelHandler ! 'ack; act
}
}
2. Few workers that are thread-based actors (sends 'WorkerReady' to
dispatcher)
3. RabbitMQ Java lib, handleDelivery (baseConsume) in Java lib
Connection thread (sends 'message' to dispatcher)
4. There is also one per dispatcher thread-based actor that handles
AMQP channel, but it's not important here (channelHandler ! 'ack)
so when I'm running load test I see that number of threads that used
by dispatcher is growing (so far up to 200) and performance is going
down. Most of them are always in blocked state
Dispatcher's Actor queue never should be more that few messages as I'm
using QoS = 5 on channel and sending ack only when worker picks up
message, also I have just a few workers
When I'm looking to heap, I can see that more than 80% (up to 95%) are
scala.actors.FJTaskRunner$VolatileTaskRef objects and number of
those is quickly growing (have 1'000'000 right now).
What can be a cause of spawning so many threads and large number of
'scala.actors.FJTaskRunner$VolatileTaskRef' objects (GC doesn't kill
them)? And is there a way to limit size of thread pool used by even
Actors? Is there a way to monitor size of Actor queue?
Please see this thread for more information on tuning Actors
http://groups.google.com/group/liftweb/browse_thread/thread/b3783e24b8417521/f89548ba1fa70319?hl=enlnk=gstq=oome#f89548ba1fa70319
You might consider using akkasource.org Actors.
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--
Jonas Bonér
twitter: @jboner
blog:http://jonasboner.com
work: http://crisp.se
work: http://scalablesolutions.se
code: http://github.com/jboner
code: http://akkasource.org
--~--~-~--~~~---~--~~
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: Removing Scala Actors from Lift
2009/9/30 Josh Suereth joshua.suer...@gmail.com: As much as I agree with your decision, it just makes me sad. I know lots of people that learned scala for actors are the way of the future I think we need to push harder. Hopefully all major projects migrating off actors will give EPFL a wake up call? This is the reason I created Akka, to have a standard platform for Actors with all the things one need to write production applications. Akka already have 4 committers and honestly, looking at the pace EPFL has had with bugfixing, features etc I think they will have a very hard time keep up with what the market needs. I have unfortunately given up up the Scala Actors library. I need the things Akka implements now and don't have time to wait indefinitely. - Josh On Tue, Sep 29, 2009 at 1:41 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com wrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. The issues (with the Scala Actors in general and Lift's use of them) are: Scala Actors use a custom version of Doug Leah's Fork/Join library. This was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent stuff should have been used. I was led to understand that this change was made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still contains fork-join. The FJ library has a memory retention issue where it trades memory for non-locking performance and, with many threads in a thread-pool, this leads to out of memory issues. The Scala Actor code is very brittle. See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html The code has not been materially refactored, which means that even in 2.8, there will be significant potential problems with the Actors. Those potential problems have manifest themselves as real problems in 2.7.x. I have spent in aggregate nearly 3 weeks of my time since November 2008 working around the defects in the Actor library. It's easier to have our own Actors (the current Actor library is about 2 days of work on my part and the refactoring of Lift to work with the existing Actor library is another 2 days of work.) EPFL has been generally slow to respond to bug reports. I am very frustrated and quite frankly tired of having to cajole EPFL into responding to defects in one of the premier Scala libraries. I would strongly suggest that you look at Akka. It's got a better view and implementation of Actors than does the standard Scala distribution. Akka includes support for distributed actors, etc. Hope this helps. Best, Stuart On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: - Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) - If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code - Some methods in Lift that currently take Scala Actors as parameters will take Lift Actors (e.g., ActorPing) There will be a parallel Maven repository with the new Lift Actor stuff in it so you will be able to build you apps against the new code before the official switch-over. Milestone 6 (which should be out next week) will be based on the existing Actor model. After we get feedback from the community about the new Actor stuff, we will switch -SNAPSHOT over to the new Actor stuff. Questions, thoughts, or comments? Thanks, David -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- Jonas Bonér twitter: @jboner blog:http://jonasboner.com work: http://crisp.se work: http://scalablesolutions.se code: http://github.com/jboner code: http://akkasource.org
[Lift] Re: Removing Scala Actors from Lift
Hi Bill. Here is a list of the things that Akka currently does (and that are not in Scala Actors) and what I see needed in a production actor based system (not all in all projects though). Transactors: Marriage of Actors and STM. Allows, ACI (Atomic, Consistent Isolated) compositional message flows. IMO the best of both worlds, since just actors is not sufficient in many scenarios. STM is based on persistent datastructures and managed references. Supervisor hierarchies: Declarative and programatic API with same API and semantics as in Erlang. This is IMO the most interesting part of Actors and is fantastic to build fault-tolerant systems. This was the goal of Scala OTP, but I have rewritten it and is much better now. Pluggable message dispatchers: Thread-based, event-based, single-thread-event-based. With DSL for building and configuring up thread-pools etc. Even concurrent mode which abandons the Actor model contract for best performance (if needed). This exists to some extent in Scala Actors, but not as open as easily configured. Pluggable messagequeue implementation: Choose between LinkedBlockingQueue, SynchronousQueue, ArrayBlockingQueue. Bounded or unbounded, with different back-off strategies and more. NIO-based remote actors: High-performance nio impl based on Netty and Protobuf. Actor supervision (linking) for fault-tolerance works across remote machines as expected. Java API: Through Active Objects. Use plain POJOs which are turned into asynchronous non-blocking “actors” using bytecode munging. RESTful Actors: Expose Actors as restful services through JAX-RS. Persistent Actors: Pluggable persistence. Currently supporting Cassandra and MongoDB. More to come. Works with the STM to create ACI *D* e.g. durable, persistent actors. Persistent messagequeue is on its way. Monitoring and mangament: Through JMX and REST. Allows you to monitor and manage all moving parts including internals such as messagequeues, dispatchers etc. Can be used as a standalone kernel or as a library in webapps etc. That pretty much sums it up. /Jonas 2009/9/30 Bill Venners b...@artima.com: Hi Jonas, Can you list what the things Akka implements now are that Scala actors don't have? Thanks. Bill On Wed, Sep 30, 2009 at 4:34 AM, Jonas Bonér jbo...@gmail.com wrote: 2009/9/30 Josh Suereth joshua.suer...@gmail.com: As much as I agree with your decision, it just makes me sad. I know lots of people that learned scala for actors are the way of the future I think we need to push harder. Hopefully all major projects migrating off actors will give EPFL a wake up call? This is the reason I created Akka, to have a standard platform for Actors with all the things one need to write production applications. Akka already have 4 committers and honestly, looking at the pace EPFL has had with bugfixing, features etc I think they will have a very hard time keep up with what the market needs. I have unfortunately given up up the Scala Actors library. I need the things Akka implements now and don't have time to wait indefinitely. - Josh On Tue, Sep 29, 2009 at 1:41 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com wrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. The issues (with the Scala Actors in general and Lift's use of them) are: Scala Actors use a custom version of Doug Leah's Fork/Join library. This was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent stuff should have been used. I was led to understand that this change was made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still contains fork-join. The FJ library has a memory retention issue where it trades memory for non-locking performance and, with many threads in a thread-pool, this leads to out of memory issues. The Scala Actor code is very brittle. See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html The code has not been materially refactored, which means that even in 2.8, there will be significant potential problems with the Actors. Those potential problems have manifest themselves as real problems in 2.7.x. I have spent in aggregate nearly 3 weeks of my time since November 2008 working around the defects in the Actor library. It's easier to have our own Actors (the current Actor library is about 2 days of work on my part and the refactoring of Lift to work with the existing Actor library is another 2 days of work.) EPFL has been generally slow to respond to bug reports. I am very frustrated and quite frankly tired of having to cajole EPFL into responding to defects in one of the premier Scala libraries. I would strongly suggest
[Lift] Re: Removing Scala Actors from Lift
Also, its pretty well documented. Read more here: http://akkasource.org/ We need feedback so please let me know what you think. 2009/9/30 Jonas Bonér jbo...@gmail.com: Hi Bill. Here is a list of the things that Akka currently does (and that are not in Scala Actors) and what I see needed in a production actor based system (not all in all projects though). Transactors: Marriage of Actors and STM. Allows, ACI (Atomic, Consistent Isolated) compositional message flows. IMO the best of both worlds, since just actors is not sufficient in many scenarios. STM is based on persistent datastructures and managed references. Supervisor hierarchies: Declarative and programatic API with same API and semantics as in Erlang. This is IMO the most interesting part of Actors and is fantastic to build fault-tolerant systems. This was the goal of Scala OTP, but I have rewritten it and is much better now. Pluggable message dispatchers: Thread-based, event-based, single-thread-event-based. With DSL for building and configuring up thread-pools etc. Even concurrent mode which abandons the Actor model contract for best performance (if needed). This exists to some extent in Scala Actors, but not as open as easily configured. Pluggable messagequeue implementation: Choose between LinkedBlockingQueue, SynchronousQueue, ArrayBlockingQueue. Bounded or unbounded, with different back-off strategies and more. NIO-based remote actors: High-performance nio impl based on Netty and Protobuf. Actor supervision (linking) for fault-tolerance works across remote machines as expected. Java API: Through Active Objects. Use plain POJOs which are turned into asynchronous non-blocking “actors” using bytecode munging. RESTful Actors: Expose Actors as restful services through JAX-RS. Persistent Actors: Pluggable persistence. Currently supporting Cassandra and MongoDB. More to come. Works with the STM to create ACI *D* e.g. durable, persistent actors. Persistent messagequeue is on its way. Monitoring and mangament: Through JMX and REST. Allows you to monitor and manage all moving parts including internals such as messagequeues, dispatchers etc. Can be used as a standalone kernel or as a library in webapps etc. That pretty much sums it up. /Jonas 2009/9/30 Bill Venners b...@artima.com: Hi Jonas, Can you list what the things Akka implements now are that Scala actors don't have? Thanks. Bill On Wed, Sep 30, 2009 at 4:34 AM, Jonas Bonér jbo...@gmail.com wrote: 2009/9/30 Josh Suereth joshua.suer...@gmail.com: As much as I agree with your decision, it just makes me sad. I know lots of people that learned scala for actors are the way of the future I think we need to push harder. Hopefully all major projects migrating off actors will give EPFL a wake up call? This is the reason I created Akka, to have a standard platform for Actors with all the things one need to write production applications. Akka already have 4 committers and honestly, looking at the pace EPFL has had with bugfixing, features etc I think they will have a very hard time keep up with what the market needs. I have unfortunately given up up the Scala Actors library. I need the things Akka implements now and don't have time to wait indefinitely. - Josh On Tue, Sep 29, 2009 at 1:41 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.com wrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. The issues (with the Scala Actors in general and Lift's use of them) are: Scala Actors use a custom version of Doug Leah's Fork/Join library. This was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent stuff should have been used. I was led to understand that this change was made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still contains fork-join. The FJ library has a memory retention issue where it trades memory for non-locking performance and, with many threads in a thread-pool, this leads to out of memory issues. The Scala Actor code is very brittle. See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html The code has not been materially refactored, which means that even in 2.8, there will be significant potential problems with the Actors. Those potential problems have manifest themselves as real problems in 2.7.x. I have spent in aggregate nearly 3 weeks of my time since November 2008 working around the defects in the Actor library. It's easier to have our own Actors (the current Actor library is about 2 days of work on my part and the refactoring of Lift to work with the existing Actor library is another 2 days of work.) EPFL has been
[Lift] Re: Removing Scala Actors from Lift
Hi Martin and Philipp. Thanks for your email. What you are saying sounds great. I love Scala Actors and I know its an important thing that brings people over to Scala. I hope that I didn't offend you. You have done amazing things with and for Scala. I really respect you guys. But I saw and felt the need for something like Akka and went away and build it. What you say about the trade-offs in Actor expressiveness is really true. I (and David I think) have not seen that much need for nested receive/react and therefore I have not included in the impl but rather focussing on other things that I find more important. This articles sums it up pretty well: http://erikengbrecht.blogspot.com/2009/06/pondering-actor-design-trades.html Looking forward to 2.8 and the new actor impl. /Jonas 2009/9/30 martin oder...@gmail.com: About actors in Scala 2.8: . they have been refactored substantially compared to what's in the 2.7.x branch . Philipp has sent mails about this to scala-internals (05/31) . Philipp has invited DPP to look at the refactorings in 2.8 (07/21) to which he responded positively. . The ForkJoinPool in 2.8 is completely different from FJTask in 2.7.5; it's the version that's going into JDK7. It has been battle-tested and should not suffer from any memory leaks. The reason why Scala actors use the FJ framework is performance, in particular on multi-core hardware. So we do not think it's a good idea to go back to java.util.concurrent, except maybe for applications with very specialized demands. We think the main problem was that lift depends on Scala 2.7.x, and that the actor refactorings have not gone into the 2.7.x branch. The result is that people have not noticed the changes. For example, most of the issues that Erik raises in his blog post no longer apply to Scala 2.8. Initially we wanted 2.8 to be out by now, but it's taken much longer than we have foreseen, because some of the problems were harder than initially thought. We are sorry to have left the 2.7 branch relatively unattended for so long. It's difficult for us, though, to provide the resources to support two diverging branches in parallel. More community support with backports etc could help. To fix the concrete issue at hand, we replaced FJTask with (a backport of) java.util.concurrent.ThreadPoolExecutor in the Scala 2.7.x branch, to be released as 2.7.7. That takes care of the memory leaks in FJTask. Now to the larger picture. We are not at all wedded to Scala actors here; after all it's just a library. If there are others which fulfill some needs better, great! But we have to be honest to avoid confusion. One of the main differences between Scala actors and lift actors and Akka seems to be that only Scala actors provide nested receives, so only Scala actors really let you avoid an inversion of control. This is a feature which complicates the implementation considerably, and that's what all our main results are about. You might not care about this particular feature in your code, and consequently you might choose a different abstraction. But calling that abstraction simply `actors' causes unnecessary confusion, in our opinion. And that's not good for the goal of convincing people that actors are a useful concurrency abstraction. So, nothing against lift actors and Akka, but we need to be precise about the tradeoffs. Maybe call them `flat actors' or something like that. Martin and Philipp -- Jonas Bonér twitter: @jboner blog:http://jonasboner.com work: http://crisp.se work: http://scalablesolutions.se code: http://github.com/jboner code: http://akkasource.org --~--~-~--~~~---~--~~ 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: Removing Scala Actors from Lift
2009/9/29 Heiko Seeberger heiko.seeber...@googlemail.com: What's the reason to have a new module (lift-base)? Why not put Actor to lift-util and keep Box where it is? In your branch def !?(timeout: Long, param: T) will return an Option. Shouldn't this be a Box? We are trying to find a common interface for the Actors to work with both lift-actors and akka actors. Akka is not using Box but Option. Heiko 2009/9/29 David Pollak feeder.of.the.be...@gmail.com Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. See http://github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code Some methods in Lift that currently take Scala Actors as parameters will take Lift Actors (e.g., ActorPing) There will be a parallel Maven repository with the new Lift Actor stuff in it so you will be able to build you apps against the new code before the official switch-over. Milestone 6 (which should be out next week) will be based on the existing Actor model. After we get feedback from the community about the new Actor stuff, we will switch -SNAPSHOT over to the new Actor stuff. Questions, thoughts, or comments? 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 Surf the harmonics -- Heiko Seeberger My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- Jonas Bonér twitter: @jboner blog:http://jonasboner.com work: http://crisp.se work: http://scalablesolutions.se code: http://github.com/jboner code: http://akkasource.org --~--~-~--~~~---~--~~ 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
I'm really sorry. I never checked building with an empty maven repo. Thanks for fixing it. 2009/7/20 Derek Chen-Becker dchenbec...@gmail.com: FYI, it looks like the Hibernate dependency you had in your pom was pulling in the javax.transactions:jta lib, which isn't available in maven repos. I added an exclusion to prevent that from breaking the build. Derek On Sun, Jul 19, 2009 at 3:08 AM, Jonas Bonér jbo...@gmail.com wrote: Thanks Tim and David. 2009/7/19 David Pollak feeder.of.the.be...@gmail.com: On Sat, Jul 18, 2009 at 11:20 AM, Timothy Perrett timo...@getintheloop.eu 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 jbo...@gmail.com 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 -- 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 --~--~-~--~~~---~--~~ 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
2009/7/20 Derek Chen-Becker dchenbec...@gmail.com: ... hit the enter key too quickly! Kudos on the work in this library. I really like how this is coming together. Thanks Derek. Derek On Sun, Jul 19, 2009 at 11:52 PM, Derek Chen-Becker dchenbec...@gmail.com wrote: FYI, it looks like the Hibernate dependency you had in your pom was pulling in the javax.transactions:jta lib, which isn't available in maven repos. I added an exclusion to prevent that from breaking the build. Derek On Sun, Jul 19, 2009 at 3:08 AM, Jonas Bonér jbo...@gmail.com wrote: Thanks Tim and David. 2009/7/19 David Pollak feeder.of.the.be...@gmail.com: On Sat, Jul 18, 2009 at 11:20 AM, Timothy Perrett timo...@getintheloop.eu 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 jbo...@gmail.com 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 -- 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 --~--~-~--~~~---~--~~ 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
Thanks Tim and David. 2009/7/19 David Pollak feeder.of.the.be...@gmail.com: On Sat, Jul 18, 2009 at 11:20 AM, Timothy Perrett timo...@getintheloop.eu 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 jbo...@gmail.com 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 -- 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 -~--~~~~--~~--~--~---
[Lift] Re: JTA Transaction Monad - Early Access Program
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 feeder.of.the.be...@gmail.com: On Fri, Jul 17, 2009 at 1:02 AM, Jonas Bonér jbo...@gmail.com 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 jbo...@gmail.com: 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 timo...@getintheloop.eu: 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 jbo...@gmail.com 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 timo...@getintheloop.eu: Jonas, Did you roll this into master? What's its status? Cheers, Tim On Jun 10, 4:46 pm, James Strachan james.strac...@gmail.com wrote: 2009/6/9 Jonas Bonér jbo...@gmail.com: 2009/6/9 David Pollak feeder.of.the.be...@gmail.com: 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 -~--~~~~--~~--~--~---
[Lift] Re: JTA Transaction Monad - Early Access Program
Hi Greg. Have you had time to look at the JTA stuff? Should I merge in master? /Jonas 2009/7/7 Jonas Bonér jbo...@gmail.com: 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 timo...@getintheloop.eu: 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 jbo...@gmail.com 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 timo...@getintheloop.eu: Jonas, Did you roll this into master? What's its status? Cheers, Tim On Jun 10, 4:46 pm, James Strachan james.strac...@gmail.com wrote: 2009/6/9 Jonas Bonér jbo...@gmail.com: 2009/6/9 David Pollak feeder.of.the.be...@gmail.com: 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 --~--~-~--~~~---~--~~ 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: ANN: Akka Actor Kernel: RESTful Distributed Persistent Transactional Actors
Hi. On Jul 13, 9:51 am, Timothy Perrett timo...@getintheloop.eu wrote: From what I can see, its not just about concurrency, right? STM is probally used in conjunction with Cassandra...? Right. Even though messages in the actor model are immutable the actors are not. If they were they would be almost useless. The actor model is great for some use cases but terrible for others. I have many times felt like I would like to have a transactional compositional message flows. This is an attempt to solve that problem (and some other problems as well). The STM is working with managed data structures like TransactionalMap/ Vector/Ref. Accessing them outside a tx yields an error. The STM also understand and works with asynchronous messaging something that is not trivial. I think there is some synergy between both Lift and Goat Rodeo. Would love to see what could come out of that. I am open for all suggestions/ crazy ideas. Thank, Jonas. Cheers, Tim On 13/07/2009 07:25, marius d. marius.dan...@gmail.com wrote: I wonder why STM in a message passing concurrency model where things supposed to be immutable. --~--~-~--~~~---~--~~ 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: ANN: Akka Actor Kernel: RESTful Distributed Persistent Transactional Actors
All jars are in the ./lib dir. Running the kernel from ./bin dir works
out of the box. Put apps in the ./deploy dir.
If you want I build it using maven you have install some missing libs
that are not in any public maven repo (and all these jars are in
lib). .
Easiest way is simply to download the distro from the downloads
section.
Hope it helps.
/Jonas
On Jul 13, 12:43 pm, Viktor Klang viktor.kl...@gmail.com wrote:
By the way, installing AKKA requires currently some hand-waving to add
dependencies that are not resolved:
com.facebook.fb303-1.0.jar
org.apache.cassandra:cassandra:jar:0.4.0-dev
Or is my Maven just b0rked?
On Mon, Jul 13, 2009 at 11:15 AM, Viktor Klang viktor.kl...@gmail.comwrote:
Instead of:
class MyActor extends Actor {
makeTransactionRequired …
}
woudn't it be clean to have:
trait TxRequired
{
self : TransactionManagement =
makeTransactionRequired
}
class MyActor extends Actor with TxRequired
{
}
On Mon, Jul 13, 2009 at 11:04 AM, Jonas Bonér jbo...@gmail.com wrote:
Hi.
On Jul 13, 9:51 am, Timothy Perrett timo...@getintheloop.eu wrote:
From what I can see, its not just about concurrency, right? STM is
probally
used in conjunction with Cassandra...?
Right. Even though messages in the actor model are immutable the
actors are not. If they were they would be almost useless.
The actor model is great for some use cases but terrible for others. I
have many times felt like I would like to have a transactional
compositional message flows. This is an attempt to solve that problem
(and some other problems as well).
The STM is working with managed data structures like TransactionalMap/
Vector/Ref. Accessing them outside a tx yields an error. The STM also
understand and works with asynchronous messaging something that is not
trivial.
I think there is some synergy between both Lift and Goat Rodeo. Would
love to see what could come out of that. I am open for all suggestions/
crazy ideas.
Thank, Jonas.
Cheers, Tim
On 13/07/2009 07:25, marius d. marius.dan...@gmail.com wrote:
I wonder why STM in a message passing concurrency model where things
supposed to be immutable.
--
Viktor Klang
Java Specialist
Scala Loudmouth
Lift Committer
--
Viktor Klang
Java Specialist
Scala Loudmouth
Lift Committer
--~--~-~--~~~---~--~~
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: ANN: Akka Actor Kernel: RESTful Distributed Persistent Transactional Actors
Thanks. Good idea. I'll add this option.
On Jul 13, 11:15 am, Viktor Klang viktor.kl...@gmail.com wrote:
Instead of:
class MyActor extends Actor {
makeTransactionRequired …
}
woudn't it be clean to have:
trait TxRequired
{
self : TransactionManagement =
makeTransactionRequired
}
class MyActor extends Actor with TxRequired
{
}
On Mon, Jul 13, 2009 at 11:04 AM, Jonas Bonér jbo...@gmail.com wrote:
Hi.
On Jul 13, 9:51 am, Timothy Perrett timo...@getintheloop.eu wrote:
From what I can see, its not just about concurrency, right? STM is
probally
used in conjunction with Cassandra...?
Right. Even though messages in the actor model are immutable the
actors are not. If they were they would be almost useless.
The actor model is great for some use cases but terrible for others. I
have many times felt like I would like to have a transactional
compositional message flows. This is an attempt to solve that problem
(and some other problems as well).
The STM is working with managed data structures like TransactionalMap/
Vector/Ref. Accessing them outside a tx yields an error. The STM also
understand and works with asynchronous messaging something that is not
trivial.
I think there is some synergy between both Lift and Goat Rodeo. Would
love to see what could come out of that. I am open for all suggestions/
crazy ideas.
Thank, Jonas.
Cheers, Tim
On 13/07/2009 07:25, marius d. marius.dan...@gmail.com wrote:
I wonder why STM in a message passing concurrency model where things
supposed to be immutable.
--
Viktor Klang
Java Specialist
Scala Loudmouth
Lift Committer
--~--~-~--~~~---~--~~
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
No I haven't. Should I? Is everyone happy with it? Have anyone tried it? Is anyone using it? 2009/6/30 Timothy Perrett timo...@getintheloop.eu: Jonas, Did you roll this into master? What's its status? Cheers, Tim On Jun 10, 4:46 pm, James Strachan james.strac...@gmail.com wrote: 2009/6/9 Jonas Bonér jbo...@gmail.com: 2009/6/9 David Pollak feeder.of.the.be...@gmail.com: 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 --~--~-~--~~~---~--~~ 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
Thanks Greg. I would love to get your feedback on it. 2009/7/7 Meredith Gregory lgreg.mered...@gmail.com: Jonas, i'm going to begin playing with it after i've finished the conversion of the DSL stuff to scala-query. The JTA monad should just fit with scala-query. Best wishes, --greg On Tue, Jul 7, 2009 at 10:18 AM, Jonas Bonér jbo...@gmail.com 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 timo...@getintheloop.eu: Jonas, Did you roll this into master? What's its status? Cheers, Tim On Jun 10, 4:46 pm, James Strachan james.strac...@gmail.com wrote: 2009/6/9 Jonas Bonér jbo...@gmail.com: 2009/6/9 David Pollak feeder.of.the.be...@gmail.com: 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 -- L.G. Meredith Managing Partner Biosimilarity LLC 1219 NW 83rd St Seattle, WA 98117 +1 206.650.3740 http://biosimilarity.blogspot.com -- 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 -~--~~~~--~~--~--~---
[Lift] Re: JTA Transaction Monad - Early Access Program
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 timo...@getintheloop.eu: 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 jbo...@gmail.com 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 timo...@getintheloop.eu: Jonas, Did you roll this into master? What's its status? Cheers, Tim On Jun 10, 4:46 pm, James Strachan james.strac...@gmail.com wrote: 2009/6/9 Jonas Bonér jbo...@gmail.com: 2009/6/9 David Pollak feeder.of.the.be...@gmail.com: 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 --~--~-~--~~~---~--~~ 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: Anyone out there using SBT?
Is there a Swedish Bikini Team? I had no idea. 2009/7/6 Kevin Wright kev.lee.wri...@googlemail.com: Single Bullet Theory, or Swedish Bikini Team ? On Mon, Jul 6, 2009 at 10:07 AM, Timothy Perrett timo...@getintheloop.eu wrote: Hey Guys, Is anyone out there using SBT for their lift projects? if so, how are you finding it? Cheers, Tim -- 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 -~--~~~~--~~--~--~---
[Lift] Re: Anyone out there using SBT?
I looked at SBT 4-5 months ago. Was impressed but couldn't use it due to Java module dep. Don't know if it can build Java now. 2009/7/7 Jonas Bonér jbo...@gmail.com: Is there a Swedish Bikini Team? I had no idea. 2009/7/6 Kevin Wright kev.lee.wri...@googlemail.com: Single Bullet Theory, or Swedish Bikini Team ? On Mon, Jul 6, 2009 at 10:07 AM, Timothy Perrett timo...@getintheloop.eu wrote: Hey Guys, Is anyone out there using SBT for their lift projects? if so, how are you finding it? Cheers, Tim -- 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 --~--~-~--~~~---~--~~ 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: [scala] preso on monadic design patterns for the web
Great talk. Thanks. Could you post the slides? It was a bit hard to see them. /Jonas 2009/6/29 Meredith Gregory lgreg.mered...@gmail.com: All, The talk i recently gave on this topic is now available online. Best wishes, --greg -- L.G. Meredith Managing Partner Biosimilarity LLC 1219 NW 83rd St Seattle, WA 98117 +1 206.650.3740 http://biosimilarity.blogspot.com -- 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 -~--~~~~--~~--~--~---
[Lift] Re: preso on monadic design patterns for the web
Thanks 2009/6/29 Eric Bowman ebow...@boboco.ie: Here? http://svn.biosimilarity.com/src/open/talks/MonadicDesignPatternsForTheWeb.pdf Timothy Perrett wrote: +1 would love to read the slides properly. Cheers, Tim On Jun 29, 8:59 am, Jonas Bonér jbo...@gmail.com wrote: Great talk. Thanks. Could you post the slides? It was a bit hard to see them. /Jonas 2009/6/29 Meredith Gregory lgreg.mered...@gmail.com: All, The talk i recently gave on this topic is now available online. Best wishes, --greg -- L.G. Meredith Managing Partner Biosimilarity LLC 1219 NW 83rd St Seattle, WA 98117 +1 206.650.3740 http://biosimilarity.blogspot.com -- Jonas Bonér twitter: @jboner blog: http://jonasboner.com work: http://crisp.se work: http://scalablesolutions.se code: http://github.com/jboner -- Eric Bowman Boboco Ltd ebow...@boboco.ie http://www.boboco.ie/ebowman/pubkey.pgp +35318394189/+353872801532 -- 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 -~--~~~~--~~--~--~---
[Lift] Re: JTA Transaction Monad - Early Access Program
Thanks James. But I have already found them in a public repo. /Jonas 2009/6/10 James Strachan james.strac...@gmail.com: 2009/6/9 Jonas Bonér jbo...@gmail.com: 2009/6/9 David Pollak feeder.of.the.be...@gmail.com: 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 ActiveMQ http://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 Integration http://fusesource.com/ -- 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 -~--~~~~--~~--~--~---
[Lift] Re: JTA Transaction Monad - Early Access Program
2009/6/9 David Pollak feeder.of.the.be...@gmail.com:
Sweet looking stuff!
Thanks.
On Tue, Jun 9, 2009 at 6:18 AM, Jonas Bonér jbo...@gmail.com wrote:
Hey guys.
I have hacked together an early draft of the JTA transaction stuff.
I have wrapped it up in a monad. Here are some examples of usage:
for {
ctx - TransactionContext.Required
entity - updatedEntities
if !ctx.isRollbackOnly
} {
// transactional stuff
ctx.getEntityManager.merge(entity)
}
val users = for {
ctx - TransactionContext.Required
name - userNames
} yield {
// transactional stuff
val query = ctx.getEntityManager.createNamedQuery(findUserByName)
query.setParameter(userName, name)
query.getSingleResult
}
If you don't like the monadic approach you can just use the high-order
functions:
TransactionContext.withTxRequired {
... // REQUIRED semantics
TransactionContext.withTxRequiresNew {
... // REQUIRES_NEW semantics
}
}
I have implemented the same semantics as used in the EJB spec.
Required, RequiresNew, Mandatory, Supports, Never. All these are
monadic objects in the TransactionContext object.
I don't have a webapp to try this out, so I would be happy to get all
kinds of feedback, but API wise and bug reports or fixes.
This API is hooked into Derek's Scala-JPA stuff. I had my own impl of
this but replaced it with Derek's work.
Derek,
please go through the integration to see if I have done it correctly,
and where things code be improved.
All committers,
feel free to hack and change this code anyway you want.
The code is in a branch (wip-jta-jonas), you can find it here:
http://github.com/dpp/liftweb/tree/3783b9e2200cc57dd72baa1bd8cabdb1365ee923/lift-jta
Check the ScalaDoc (or the source) for the documentation on usage,
semantics etc.
Also see the README for configuration in persistence.xml etc.
Currently it is hard-coded to use the Atomikos Transaction library and
Hibernate JPA, that would have to be configurable + some other options
as well. See the TODOs in the code.
As I said, this needs feedback and testing. Thanks.
--
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
-~--~~~~--~~--~--~---
[Lift] Re: JTA Transaction Monad - Early Access Program
I added the lib folder only since I have not been able to find the
atomikos and deps in any maven repo.
Now the user can install them in their private repo.
If they exist in a public repo then I will remove the lib folder.
Will switch to the apache libs.
Thanks, Jonas.
2009/6/9 Derek Chen-Becker dchenbec...@gmail.com:
OK, one quick comment before I dive in: we generally want to depend on Maven
to grab dependencies. Right now you have a lib folder checked into git that
appears to hold the JTA libs and Atomikos. If that's the Sun JTA libs then
we can't distribute them. We generally use the geronimo JTA API, so you
could instead add dependencies to your pom.xml from the following:
http://mvnrepository.com/artifact/com.atomikos
dependency
groupIdorg.apache.geronimo.specs/groupId
artifactIdgeronimo-jta_1.1_spec/artifactId
version1.1.1/version
/dependency
Let me know if you have any problems with that. Now, on to the code!
Derek
On Tue, Jun 9, 2009 at 9:44 AM, Derek Chen-Becker dchenbec...@gmail.com
wrote:
Awesome! I'll take a look at the code. If you're basing this on ScalaJPA,
would it be preferable to add the functionality there, or is there anything
Lift-specific?
Derek
On Tue, Jun 9, 2009 at 7:18 AM, Jonas Bonér jbo...@gmail.com wrote:
Hey guys.
I have hacked together an early draft of the JTA transaction stuff.
I have wrapped it up in a monad. Here are some examples of usage:
for {
ctx - TransactionContext.Required
entity - updatedEntities
if !ctx.isRollbackOnly
} {
// transactional stuff
ctx.getEntityManager.merge(entity)
}
val users = for {
ctx - TransactionContext.Required
name - userNames
} yield {
// transactional stuff
val query = ctx.getEntityManager.createNamedQuery(findUserByName)
query.setParameter(userName, name)
query.getSingleResult
}
If you don't like the monadic approach you can just use the high-order
functions:
TransactionContext.withTxRequired {
... // REQUIRED semantics
TransactionContext.withTxRequiresNew {
... // REQUIRES_NEW semantics
}
}
I have implemented the same semantics as used in the EJB spec.
Required, RequiresNew, Mandatory, Supports, Never. All these are
monadic objects in the TransactionContext object.
I don't have a webapp to try this out, so I would be happy to get all
kinds of feedback, but API wise and bug reports or fixes.
This API is hooked into Derek's Scala-JPA stuff. I had my own impl of
this but replaced it with Derek's work.
Derek,
please go through the integration to see if I have done it correctly,
and where things code be improved.
All committers,
feel free to hack and change this code anyway you want.
The code is in a branch (wip-jta-jonas), you can find it here:
http://github.com/dpp/liftweb/tree/3783b9e2200cc57dd72baa1bd8cabdb1365ee923/lift-jta
Check the ScalaDoc (or the source) for the documentation on usage,
semantics etc.
Also see the README for configuration in persistence.xml etc.
Currently it is hard-coded to use the Atomikos Transaction library and
Hibernate JPA, that would have to be configurable + some other options
as well. See the TODOs in the code.
As I said, this needs feedback and testing. Thanks.
--
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
--~--~-~--~~~---~--~~
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
2009/6/9 David Pollak feeder.of.the.be...@gmail.com:
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?
Sorry about the license issues, didn't think about that.
I can remove them all in any case, even though that would make it
harder to use.
What does Configgy have that Lift's Props and Logger doesn't? I'm all for
enhancing Lift to be as good as Configgy (and Robey didn't have the
bandwidth to integrate Configgy into Lift, thus our own config management).
First I like the printf-style logging API, similar to slf4j. Nice to
use plus better performance.
Second I really like Configgys configuration API, plus that it is
integrated with the logging.
But this was just a comment from my side, I have no problem whatsoever
to use Lift logger.
/Jonas
Thanks,
David
On Tue, Jun 9, 2009 at 9:34 AM, Jonas Bonér jbo...@gmail.com wrote:
I am only depending on Lift through the Lift logger (switched from
Configgy, which I actually like better).
I am only depending on ScalaJPA through one single 'with
ScalaEntityManager'.
I could move it.
What do the rest of you guys think?
2009/6/9 Derek Chen-Becker dchenbec...@gmail.com:
Awesome! I'll take a look at the code. If you're basing this on
ScalaJPA,
would it be preferable to add the functionality there, or is there
anything
Lift-specific?
Derek
On Tue, Jun 9, 2009 at 7:18 AM, Jonas Bonér jbo...@gmail.com wrote:
Hey guys.
I have hacked together an early draft of the JTA transaction stuff.
I have wrapped it up in a monad. Here are some examples of usage:
for {
ctx - TransactionContext.Required
entity - updatedEntities
if !ctx.isRollbackOnly
} {
// transactional stuff
ctx.getEntityManager.merge(entity)
}
val users = for {
ctx - TransactionContext.Required
name - userNames
} yield {
// transactional stuff
val query = ctx.getEntityManager.createNamedQuery(findUserByName)
query.setParameter(userName, name)
query.getSingleResult
}
If you don't like the monadic approach you can just use the high-order
functions:
TransactionContext.withTxRequired {
... // REQUIRED semantics
TransactionContext.withTxRequiresNew {
... // REQUIRES_NEW semantics
}
}
I have implemented the same semantics as used in the EJB spec.
Required, RequiresNew, Mandatory, Supports, Never. All these are
monadic objects in the TransactionContext object.
I don't have a webapp to try this out, so I would be happy to get all
kinds of feedback, but API wise and bug reports or fixes.
This API is hooked into Derek's Scala-JPA stuff. I had my own impl of
this but replaced it with Derek's work.
Derek,
please go through the integration to see if I have done it correctly,
and where things code be improved.
All committers,
feel free to hack and change this code anyway you want.
The code is in a branch (wip-jta-jonas), you can find it here:
http://github.com/dpp/liftweb/tree/3783b9e2200cc57dd72baa1bd8cabdb1365ee923/lift-jta
Check the ScalaDoc (or the source) for the documentation on usage,
semantics etc.
Also see the README for configuration in persistence.xml etc.
Currently it is hard-coded to use the Atomikos Transaction library and
Hibernate JPA, that would have to be configurable + some other options
as well. See the TODOs in the code.
As I said, this needs feedback and testing. Thanks.
--
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
-~--~~~~--~~--~--~---
[Lift] Re: JTA Transaction Monad - Early Access Program
First I like the printf-style logging API, similar to slf4j. Nice to use plus better performance. We can add that to Lift's logger (which can sit on top of slf4j) That would be great. Also, note that all of Lift's logger parameters are call-by-name so there's no evaluation unless the log level is met. Ok, I didn't know that. Great. That's the way to do it. -- 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 -~--~~~~--~~--~--~---
[Lift] Re: JTA Transaction Monad - Early Access Program
Re configgy. I think it is a great balance between properties and xml, like pragmatic xml. Simple as properties but with nesting, hierarchies, type conversions, good override and defaults system (inheritance). It also has notification of changes and a JMX API for management (which I have not used yet). /Jonas 2009/6/9 Jonas Bonér jbo...@gmail.com: First I like the printf-style logging API, similar to slf4j. Nice to use plus better performance. We can add that to Lift's logger (which can sit on top of slf4j) That would be great. Also, note that all of Lift's logger parameters are call-by-name so there's no evaluation unless the log level is met. Ok, I didn't know that. Great. That's the way to do it. -- 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 --~--~-~--~~~---~--~~ 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
Thanks Derek. I missed that. I will fix the pom.xml.
2009/6/9 Derek Chen-Becker dchenbec...@gmail.com:
In my email above I have the link to the Maven artifacts for Atomikos:
http://mvnrepository.com/artifact/com.atomikos
I think that the dependency you want is:
dependency
groupIdcom.atomikos/groupId
artifactIdtransactions-jta/artifactId
version3.2.3/version
/dependency
Derek
On Tue, Jun 9, 2009 at 12:54 PM, Meredith Gregory lgreg.mered...@gmail.com
wrote:
Jonas,
Awesome! i look forward to digging into this stuff!
Best wishes,
--greg
On Tue, Jun 9, 2009 at 6:18 AM, Jonas Bonér jbo...@gmail.com wrote:
Hey guys.
I have hacked together an early draft of the JTA transaction stuff.
I have wrapped it up in a monad. Here are some examples of usage:
for {
ctx - TransactionContext.Required
entity - updatedEntities
if !ctx.isRollbackOnly
} {
// transactional stuff
ctx.getEntityManager.merge(entity)
}
val users = for {
ctx - TransactionContext.Required
name - userNames
} yield {
// transactional stuff
val query = ctx.getEntityManager.createNamedQuery(findUserByName)
query.setParameter(userName, name)
query.getSingleResult
}
If you don't like the monadic approach you can just use the high-order
functions:
TransactionContext.withTxRequired {
... // REQUIRED semantics
TransactionContext.withTxRequiresNew {
... // REQUIRES_NEW semantics
}
}
I have implemented the same semantics as used in the EJB spec.
Required, RequiresNew, Mandatory, Supports, Never. All these are
monadic objects in the TransactionContext object.
I don't have a webapp to try this out, so I would be happy to get all
kinds of feedback, but API wise and bug reports or fixes.
This API is hooked into Derek's Scala-JPA stuff. I had my own impl of
this but replaced it with Derek's work.
Derek,
please go through the integration to see if I have done it correctly,
and where things code be improved.
All committers,
feel free to hack and change this code anyway you want.
The code is in a branch (wip-jta-jonas), you can find it here:
http://github.com/dpp/liftweb/tree/3783b9e2200cc57dd72baa1bd8cabdb1365ee923/lift-jta
Check the ScalaDoc (or the source) for the documentation on usage,
semantics etc.
Also see the README for configuration in persistence.xml etc.
Currently it is hard-coded to use the Atomikos Transaction library and
Hibernate JPA, that would have to be configurable + some other options
as well. See the TODOs in the code.
As I said, this needs feedback and testing. Thanks.
--
Jonas Bonér
twitter: @jboner
blog: http://jonasboner.com
work: http://crisp.se
work: http://scalablesolutions.se
code: http://github.com/jboner
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117
+1 206.650.3740
http://biosimilarity.blogspot.com
--
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
-~--~~~~--~~--~--~---
[Lift] Re: JTA Transaction Monad - Early Access Program
Thanks Greg. And thanks for the suggestion to see transactions as monadic.
All feedback is more than welcome.
/Jonas
2009/6/9 Meredith Gregory lgreg.mered...@gmail.com:
Jonas,
Awesome! i look forward to digging into this stuff!
Best wishes,
--greg
On Tue, Jun 9, 2009 at 6:18 AM, Jonas Bonér jbo...@gmail.com wrote:
Hey guys.
I have hacked together an early draft of the JTA transaction stuff.
I have wrapped it up in a monad. Here are some examples of usage:
for {
ctx - TransactionContext.Required
entity - updatedEntities
if !ctx.isRollbackOnly
} {
// transactional stuff
ctx.getEntityManager.merge(entity)
}
val users = for {
ctx - TransactionContext.Required
name - userNames
} yield {
// transactional stuff
val query = ctx.getEntityManager.createNamedQuery(findUserByName)
query.setParameter(userName, name)
query.getSingleResult
}
If you don't like the monadic approach you can just use the high-order
functions:
TransactionContext.withTxRequired {
... // REQUIRED semantics
TransactionContext.withTxRequiresNew {
... // REQUIRES_NEW semantics
}
}
I have implemented the same semantics as used in the EJB spec.
Required, RequiresNew, Mandatory, Supports, Never. All these are
monadic objects in the TransactionContext object.
I don't have a webapp to try this out, so I would be happy to get all
kinds of feedback, but API wise and bug reports or fixes.
This API is hooked into Derek's Scala-JPA stuff. I had my own impl of
this but replaced it with Derek's work.
Derek,
please go through the integration to see if I have done it correctly,
and where things code be improved.
All committers,
feel free to hack and change this code anyway you want.
The code is in a branch (wip-jta-jonas), you can find it here:
http://github.com/dpp/liftweb/tree/3783b9e2200cc57dd72baa1bd8cabdb1365ee923/lift-jta
Check the ScalaDoc (or the source) for the documentation on usage,
semantics etc.
Also see the README for configuration in persistence.xml etc.
Currently it is hard-coded to use the Atomikos Transaction library and
Hibernate JPA, that would have to be configurable + some other options
as well. See the TODOs in the code.
As I said, this needs feedback and testing. Thanks.
--
Jonas Bonér
twitter: @jboner
blog: http://jonasboner.com
work: http://crisp.se
work: http://scalablesolutions.se
code: http://github.com/jboner
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117
+1 206.650.3740
http://biosimilarity.blogspot.com
--
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
-~--~~~~--~~--~--~---
[Lift] Re: JTA Transaction Monad - Early Access Program
Thanks Derek. Thanks for taking time to do a code review.
I'll add that to the README.
/Jonas
2009/6/9 Derek Chen-Becker dchenbec...@gmail.com:
Jonas, the code looks great! I don't see any issues with how ScalaJPA is
used. It's nice to see that this fits what you're doing well and I really
like how this lets one use transactions without having to go with a
full-blown JEE container. One thing that you might want to put into the
README is a reminder that if you're going to be using JNDI along with an
EntityManager then JTA is not only required, but should be handled
automatically by the container. The only valid operation on a
Container-managed EM (as pointed out by mrxtravis yesterday when he found a
bug in ScalaJPA) is to set the TX as rollback-only.
Derek
On Tue, Jun 9, 2009 at 1:10 PM, Derek Chen-Becker dchenbec...@gmail.com
wrote:
In my email above I have the link to the Maven artifacts for Atomikos:
http://mvnrepository.com/artifact/com.atomikos
I think that the dependency you want is:
dependency
groupIdcom.atomikos/groupId
artifactIdtransactions-jta/artifactId
version3.2.3/version
/dependency
Derek
On Tue, Jun 9, 2009 at 12:54 PM, Meredith Gregory
lgreg.mered...@gmail.com wrote:
Jonas,
Awesome! i look forward to digging into this stuff!
Best wishes,
--greg
On Tue, Jun 9, 2009 at 6:18 AM, Jonas Bonér jbo...@gmail.com wrote:
Hey guys.
I have hacked together an early draft of the JTA transaction stuff.
I have wrapped it up in a monad. Here are some examples of usage:
for {
ctx - TransactionContext.Required
entity - updatedEntities
if !ctx.isRollbackOnly
} {
// transactional stuff
ctx.getEntityManager.merge(entity)
}
val users = for {
ctx - TransactionContext.Required
name - userNames
} yield {
// transactional stuff
val query = ctx.getEntityManager.createNamedQuery(findUserByName)
query.setParameter(userName, name)
query.getSingleResult
}
If you don't like the monadic approach you can just use the high-order
functions:
TransactionContext.withTxRequired {
... // REQUIRED semantics
TransactionContext.withTxRequiresNew {
... // REQUIRES_NEW semantics
}
}
I have implemented the same semantics as used in the EJB spec.
Required, RequiresNew, Mandatory, Supports, Never. All these are
monadic objects in the TransactionContext object.
I don't have a webapp to try this out, so I would be happy to get all
kinds of feedback, but API wise and bug reports or fixes.
This API is hooked into Derek's Scala-JPA stuff. I had my own impl of
this but replaced it with Derek's work.
Derek,
please go through the integration to see if I have done it correctly,
and where things code be improved.
All committers,
feel free to hack and change this code anyway you want.
The code is in a branch (wip-jta-jonas), you can find it here:
http://github.com/dpp/liftweb/tree/3783b9e2200cc57dd72baa1bd8cabdb1365ee923/lift-jta
Check the ScalaDoc (or the source) for the documentation on usage,
semantics etc.
Also see the README for configuration in persistence.xml etc.
Currently it is hard-coded to use the Atomikos Transaction library and
Hibernate JPA, that would have to be configurable + some other options
as well. See the TODOs in the code.
As I said, this needs feedback and testing. Thanks.
--
Jonas Bonér
twitter: @jboner
blog: http://jonasboner.com
work: http://crisp.se
work: http://scalablesolutions.se
code: http://github.com/jboner
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117
+1 206.650.3740
http://biosimilarity.blogspot.com
--
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
-~--~~~~--~~--~--~---
[Lift] Re: JTA Transaction Monad - Early Access Program
Now I have deleted the lib dir with all jars and fixed the POM.
2009/6/9 Derek Chen-Becker dchenbec...@gmail.com:
In my email above I have the link to the Maven artifacts for Atomikos:
http://mvnrepository.com/artifact/com.atomikos
I think that the dependency you want is:
dependency
groupIdcom.atomikos/groupId
artifactIdtransactions-jta/artifactId
version3.2.3/version
/dependency
Derek
On Tue, Jun 9, 2009 at 12:54 PM, Meredith Gregory lgreg.mered...@gmail.com
wrote:
Jonas,
Awesome! i look forward to digging into this stuff!
Best wishes,
--greg
On Tue, Jun 9, 2009 at 6:18 AM, Jonas Bonér jbo...@gmail.com wrote:
Hey guys.
I have hacked together an early draft of the JTA transaction stuff.
I have wrapped it up in a monad. Here are some examples of usage:
for {
ctx - TransactionContext.Required
entity - updatedEntities
if !ctx.isRollbackOnly
} {
// transactional stuff
ctx.getEntityManager.merge(entity)
}
val users = for {
ctx - TransactionContext.Required
name - userNames
} yield {
// transactional stuff
val query = ctx.getEntityManager.createNamedQuery(findUserByName)
query.setParameter(userName, name)
query.getSingleResult
}
If you don't like the monadic approach you can just use the high-order
functions:
TransactionContext.withTxRequired {
... // REQUIRED semantics
TransactionContext.withTxRequiresNew {
... // REQUIRES_NEW semantics
}
}
I have implemented the same semantics as used in the EJB spec.
Required, RequiresNew, Mandatory, Supports, Never. All these are
monadic objects in the TransactionContext object.
I don't have a webapp to try this out, so I would be happy to get all
kinds of feedback, but API wise and bug reports or fixes.
This API is hooked into Derek's Scala-JPA stuff. I had my own impl of
this but replaced it with Derek's work.
Derek,
please go through the integration to see if I have done it correctly,
and where things code be improved.
All committers,
feel free to hack and change this code anyway you want.
The code is in a branch (wip-jta-jonas), you can find it here:
http://github.com/dpp/liftweb/tree/3783b9e2200cc57dd72baa1bd8cabdb1365ee923/lift-jta
Check the ScalaDoc (or the source) for the documentation on usage,
semantics etc.
Also see the README for configuration in persistence.xml etc.
Currently it is hard-coded to use the Atomikos Transaction library and
Hibernate JPA, that would have to be configurable + some other options
as well. See the TODOs in the code.
As I said, this needs feedback and testing. Thanks.
--
Jonas Bonér
twitter: @jboner
blog: http://jonasboner.com
work: http://crisp.se
work: http://scalablesolutions.se
code: http://github.com/jboner
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117
+1 206.650.3740
http://biosimilarity.blogspot.com
--
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
-~--~~~~--~~--~--~---
[Lift] Re: JTA
Thanks a lot Greg.
That's sounds like a great idea. I'll see what I can come up with.
/Jonas
2009/5/30 Meredith Gregory lgreg.mered...@gmail.com:
Jonas,
i applaud the effort. i agree with DPP sentiments regarding annotations.
That said, i feel pretty comfortable that transactions fit entirely in a
monadic context. Since LINQ demonstrates that query fits into monadic
context, and there's already at least one Scala implementation of LINQ,
might i suggest that you come up with a monadic presentation first and then
map the sugar to that. My guess is that the sugar will be informed by the
monadic presentation.
To be suggestive... think of a context with a Tx object, TxCtxt, as like an
Option widget. Then you do stuff inside a transaction via
for ( myTransactedWidget - TxCtxt if someCondition ) yield {
someOperationsThatNeedToBeTransacted }
If you implement flatMap, yada, on TxCtxt you can have fun with nested
transaction semantics. The point is that this should just work with a
LINQ-like presentation of query.
Best wishes,
--greg
On Fri, May 29, 2009 at 6:54 AM, Jonas Bonér jbo...@gmail.com wrote:
I'll go for closures. Much simpler and less intrusive into Lift.
The current impl is based on Atomikos and Hibernate, I'll start with
pushing that in and we can make it pluggable later.
For example for Hibernate one need to add a line to the hibernate
config to register the
org.hibernate.transaction.TransactionManagerLookup class in order to
make Hibernate aware of our TX manager.
Should I fork the github repo and submit patches or how do you guys work?
/Jonas
2009/5/29 Derek Chen-Becker dchenbec...@gmail.com:
I'd vote for closures. We use annotations for JPA because we have to,
but
IMHO closures provide a nicer semantic approach because they
syntactically
enclose the block where the action is occurring.
Derek
On Fri, May 29, 2009 at 7:44 AM, Jonas Bonér jbo...@gmail.com wrote:
No perf difference. The annotations are turned into the same exact
closures.
2009/5/29 Timothy Perrett timo...@getintheloop.eu:
Are there any performance implications considering closures vs
annotations?
Agreed that closures are more lift like however.
Cheers, Tim
On 29/05/2009 10:21, marius d. marius.dan...@gmail.com wrote:
I think that would be really good. But I'd rather not use
annotations.
Personally I find closures approach a much better fit here.
withTxRequired {
... // do transational stuff
}
Br's,
Marius
On May 29, 11:55 am, Jonas Bonér jbo...@gmail.com wrote:
Hi guys.
I have been talking with David Pollak the rest of the lift team
about
adding JTA to Lift. I have implemented that for a product written
in
Scala some time ago. Now some of that code is OSS
at:http://github.com/jboner/skalman/tree
We used using two different APIs.
1. Annotations (would require Lift to support proxied objects, e.g.
grab them from a factory):
@TransactionAttribute(REQUIRED)
def transactionalMethod = { ... }
2. Call-by-name:
withTxRequired {
... // do transational stuff
}
But I don't know what fits Lift and would like to know how you guys
would like to have JTA integrated.
At which level? Which APIs? Etc.
--
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
--
Jonas Bonér
twitter: @jboner
blog: http://jonasboner.com
work: http://crisp.se
work: http://scalablesolutions.se
code: http://github.com/jboner
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117
+1 206.650.3740
http://biosimilarity.blogspot.com
--
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
-~--~~~~--~~--~--~---
[Lift] Re: JTA
No perf difference. The annotations are turned into the same exact closures.
2009/5/29 Timothy Perrett timo...@getintheloop.eu:
Are there any performance implications considering closures vs annotations?
Agreed that closures are more lift like however.
Cheers, Tim
On 29/05/2009 10:21, marius d. marius.dan...@gmail.com wrote:
I think that would be really good. But I'd rather not use annotations.
Personally I find closures approach a much better fit here.
withTxRequired {
... // do transational stuff
}
Br's,
Marius
On May 29, 11:55 am, Jonas Bonér jbo...@gmail.com wrote:
Hi guys.
I have been talking with David Pollak the rest of the lift team about
adding JTA to Lift. I have implemented that for a product written in
Scala some time ago. Now some of that code is OSS
at:http://github.com/jboner/skalman/tree
We used using two different APIs.
1. Annotations (would require Lift to support proxied objects, e.g.
grab them from a factory):
@TransactionAttribute(REQUIRED)
def transactionalMethod = { ... }
2. Call-by-name:
withTxRequired {
... // do transational stuff
}
But I don't know what fits Lift and would like to know how you guys
would like to have JTA integrated.
At which level? Which APIs? Etc.
--
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
--~--~-~--~~~---~--~~
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
I'll go for closures. Much simpler and less intrusive into Lift.
The current impl is based on Atomikos and Hibernate, I'll start with
pushing that in and we can make it pluggable later.
For example for Hibernate one need to add a line to the hibernate
config to register the
org.hibernate.transaction.TransactionManagerLookup class in order to
make Hibernate aware of our TX manager.
Should I fork the github repo and submit patches or how do you guys work?
/Jonas
2009/5/29 Derek Chen-Becker dchenbec...@gmail.com:
I'd vote for closures. We use annotations for JPA because we have to, but
IMHO closures provide a nicer semantic approach because they syntactically
enclose the block where the action is occurring.
Derek
On Fri, May 29, 2009 at 7:44 AM, Jonas Bonér jbo...@gmail.com wrote:
No perf difference. The annotations are turned into the same exact
closures.
2009/5/29 Timothy Perrett timo...@getintheloop.eu:
Are there any performance implications considering closures vs
annotations?
Agreed that closures are more lift like however.
Cheers, Tim
On 29/05/2009 10:21, marius d. marius.dan...@gmail.com wrote:
I think that would be really good. But I'd rather not use annotations.
Personally I find closures approach a much better fit here.
withTxRequired {
... // do transational stuff
}
Br's,
Marius
On May 29, 11:55 am, Jonas Bonér jbo...@gmail.com wrote:
Hi guys.
I have been talking with David Pollak the rest of the lift team about
adding JTA to Lift. I have implemented that for a product written in
Scala some time ago. Now some of that code is OSS
at:http://github.com/jboner/skalman/tree
We used using two different APIs.
1. Annotations (would require Lift to support proxied objects, e.g.
grab them from a factory):
@TransactionAttribute(REQUIRED)
def transactionalMethod = { ... }
2. Call-by-name:
withTxRequired {
... // do transational stuff
}
But I don't know what fits Lift and would like to know how you guys
would like to have JTA integrated.
At which level? Which APIs? Etc.
--
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
--
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
-~--~~~~--~~--~--~---
[Lift] Re: JTA
Thanks Tim and Derek.
I'll work in a branch. Simpler for me as well.
/Jonas
2009/5/29 Timothy Perrett timo...@getintheloop.eu:
Committers can work on branches. The general solution is that if you are
working on something that is new or dangerous use a branch with the
following naming convention:
wip-name-feature
E.g. wip-tim-localization
Checkout the thread oliver started git ouch - I just posted instructions
there for creating branches on the lift repo for committers.
Good luck.
Cheers, Tim
On 29/05/2009 14:54, Jonas Bonér jbo...@gmail.com wrote:
I'll go for closures. Much simpler and less intrusive into Lift.
The current impl is based on Atomikos and Hibernate, I'll start with
pushing that in and we can make it pluggable later.
For example for Hibernate one need to add a line to the hibernate
config to register the
org.hibernate.transaction.TransactionManagerLookup class in order to
make Hibernate aware of our TX manager.
Should I fork the github repo and submit patches or how do you guys work?
/Jonas
2009/5/29 Derek Chen-Becker dchenbec...@gmail.com:
I'd vote for closures. We use annotations for JPA because we have to, but
IMHO closures provide a nicer semantic approach because they syntactically
enclose the block where the action is occurring.
Derek
On Fri, May 29, 2009 at 7:44 AM, Jonas Bonér jbo...@gmail.com wrote:
No perf difference. The annotations are turned into the same exact
closures.
2009/5/29 Timothy Perrett timo...@getintheloop.eu:
Are there any performance implications considering closures vs
annotations?
Agreed that closures are more lift like however.
Cheers, Tim
On 29/05/2009 10:21, marius d. marius.dan...@gmail.com wrote:
I think that would be really good. But I'd rather not use annotations.
Personally I find closures approach a much better fit here.
withTxRequired {
... // do transational stuff
}
Br's,
Marius
On May 29, 11:55 am, Jonas Bonér jbo...@gmail.com wrote:
Hi guys.
I have been talking with David Pollak the rest of the lift team about
adding JTA to Lift. I have implemented that for a product written in
Scala some time ago. Now some of that code is OSS
at:http://github.com/jboner/skalman/tree
We used using two different APIs.
1. Annotations (would require Lift to support proxied objects, e.g.
grab them from a factory):
@TransactionAttribute(REQUIRED)
def transactionalMethod = { ... }
2. Call-by-name:
withTxRequired {
... // do transational stuff
}
But I don't know what fits Lift and would like to know how you guys
would like to have JTA integrated.
At which level? Which APIs? Etc.
--
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
--
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
-~--~~~~--~~--~--~---
[Lift] Re: New Lift Actor code
First, and most important to Lift, a conceptual framework for doing concurrency. Without the Actor model, Lift would not have such a rich model for building interactive applications. A design that keeps true to the Erlang Actor model in that it supports linking, run states, and other things that make an OTP style library possible. (Hey Jonas, where's that OTP library?) Here it is the repo: http://github.com/jboner/scala-otp/tree/master Or do you mean that it has not happened much there for a while? I certainly plan to expand it quite a lot, even have some code I could make its way into it eventually. -- 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 -~--~~~~--~~--~--~---
[Lift] Re: More Actor garbage (collection)
Great job. 2009/5/18 David Pollak feeder.of.the.be...@gmail.com: Folks, As you all may or may not know, I've been battling memory retention issues with the Scala Actor libraries for 6 or so months now. I believe that I've finally nailed the complete issues. They are as follows: There is an object called ActorGC that keeps track of all the actors in the system. Due to the implementation as some other bugs in the Actor library, the ActorGC code retains references to all Actors that have been created until there is significant pressure on the garbage collector, then the references may or may not be released. In order to combat this, I wrote code that uses reflection to look through the ActorGC retained references and I unretain the references for all Actors that have exited. The Actor library sits on top of a modified version of Doug Lea's ForkJoin library. Due to bugs in the library or bugs in the enhancements, the library retains references to a substantial number of messages that have ever been sent from one Actor to another. I've replaced the default scheduler with a scheduler based on the java.util.concurrent library with a default of 10 worker threads. If you want to use the standard Scala Actor scheduler, in Boot, set ActorSchedulerFixer.performFix = false I've been running a stress test against the new code that in the past would result in retaining 32MB of memory over a 30 minute period. Over the last 30 minutes it has not retained any memory. I've started a thread on the Scala internals list and I hope that we'll be able to get the Actors fixed up for the 2.8 release. The above fixes will only impact you if you rely on particular facits of the existing Actor scheduling or ActorGC classes. 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 -- 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 -~--~~~~--~~--~--~---
[Lift] Re: [Lift committers] Re: Meeting
2009/4/16 David Pollak feeder.of.the.be...@gmail.com:
Taking the discussion to the main list
On Thu, Apr 16, 2009 at 10:23 AM, Jonas Bonér jo...@jonasboner.com wrote:
2009/4/16 David Pollak feeder.of.the.be...@gmail.com:
On Thu, Apr 16, 2009 at 7:08 AM, Jonas Bonér jo...@jonasboner.com
wrote:
2009/4/16 David Pollak feeder.of.the.be...@gmail.com:
It'd be optimal if you could discuss the JTA stuff in the public
forum.
In
terms of AOP, I'm really not kidding that AOP is not going to happen
in
Lift.
You don't like annotations? E.g. @Transactional etc.?
I'm not keen on annotations, but I can live with them.
I am firmly against anything that re-writes byte-code after the
compilation
phase for production code. Once the Scala-Maven plugin supports
compiler
plugins, then there's a lot of stuff that can be done at compile-time.
The AOP stuff I have done is based on dynamic proxies no bytecode munging.
OKay... I need to see some example to fully understand why a proxy needs AOP
rather than either (1) compile-time proxy generation or (2) the built-in
Java reflect proxy thingy.
You can impl AOP using many different techniques. I proposed the
simplest one (used by Spring, Guice etc.). Using a regular JDK Dynamic
Proxy (which is the 'build in Java reflect proxy thingy'). What is
your question?
So, what does AOP give us that can't be done at another phase?
AOP is not about a specific phase. It can be done at:
* compile time
* class load time
* runtime
Can be done with:
* Bytecode mods
* Generated proxy
* Dynamic proxy
* JVM-level hooks
Semantics to annotations.
Can you help out with an example?
Annotate a class with f.e.
@transactional(type=Required) class Foo { ..}
and have all methods in this class being invoked under a transaction
with Required semantics
or annotate a specific method
@transactional(type=RequiresNew) def foo { ..}
to get the same behavior for a method only
Annotations is the way most JEE devs are used to handle these things
since it is the approach both Spring, Guice, EJB 3 etc. etc. has
taken.
The stuff I have written allow using AspectJ pointcuts as well.
E.g. f.e. apply transactions to all methods in the service layer:
match('* com.biz.service.*(..)')
Or to a specific method:
match('void Store.buy(Item)')
But you could just use call-by-name:
transactional(TransactionType.Required) { // tx begin
.. // do stuff in TX
} // tx commit or rollback
But that pollutes the code, makes it harder to change, configure and
is not declarative.
Perhaps give the user options?
But you guys choose.
I am here to serve :-)
/Jonas
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
--
Jonas Bonér | Crisp AB
http://jonasboner.com
http://crisp.se
--~--~-~--~~~---~--~~
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] JEE stuff (JTA, JPA, AOP etc.)
Hi guys.
I have thrown up the little JEE container framework that I wrote for
my company last year. I have already written some about what we did on
my blog.
In short it has support for:
- JPA -
JPA Template, Genenic Repository etc.
- JTA -
EJB-style TX semantics: REQUIRED, REQUIRES_NEW, MANDATORY, NEVER,
SUPPORTS. It hooks into Hibernate/JPA. Can make use of the AOP
framework to allow decorating your methods with:
import javax.ejb.{TransactionAttribute, TransactionAttributeType}
trait Foo {
@TransactionAttribute(TransactionAttributeType.REQUIRED)
def foo(msg: String)
}
- AOP -
A simple generic Interceptor/AOP framework. Uses either annotations
or the AspectJ pointcut parser.
See my blog for a detailed post:
http://jonasboner.com/2008/12/09/real-world-scala-managing-cross-cutting-concerns-using-mixin-composition-and-aop.html
(last half)
- Caching -
Annotate your methods with '@Cacheable' to have the cached in a
performant way.
- DI -
We used the Cake Pattern, but used Guice at one point, should be easy
to add that again if requested.
See this article for details:
http://jonasboner.com/2008/10/06/real-world-scala-dependency-injection-di.html
You can find all code here:
http://github.com/jboner/skalman/tree/master
Here is the JTA stuff:
http://github.com/jboner/skalman/blob/610ad8918111c56284640f04ff7dcce7c33d3e5b/core/src/main/scala/JTA.scala
Please come with feedback if there is anything that would fit Lift.
Especially the JTA stuff since that have been discussed to be added.
Thanks.
Jonas Bonér | Crisp AB
http://jonasboner.com
http://crisp.se
--~--~-~--~~~---~--~~
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: JEE stuff (JTA, JPA, AOP etc.)
Cool. Thanks. I'd need some feedback here, since I don't have much
knowledge in what Lift needs and how it can be integrated.
2009/4/5 Derek Chen-Becker dchenbec...@gmail.com:
Very cool. I'm sure there are some things that we can incorporate here.
Derek
On Sun, Apr 5, 2009 at 7:29 AM, Jonas Bonér jbo...@gmail.com wrote:
Hi guys.
I have thrown up the little JEE container framework that I wrote for
my company last year. I have already written some about what we did on
my blog.
In short it has support for:
- JPA -
JPA Template, Genenic Repository etc.
- JTA -
EJB-style TX semantics: REQUIRED, REQUIRES_NEW, MANDATORY, NEVER,
SUPPORTS. It hooks into Hibernate/JPA. Can make use of the AOP
framework to allow decorating your methods with:
import javax.ejb.{TransactionAttribute, TransactionAttributeType}
trait Foo {
�...@transactionattribute(TransactionAttributeType.REQUIRED)
def foo(msg: String)
}
- AOP -
A simple generic Interceptor/AOP framework. Uses either annotations
or the AspectJ pointcut parser.
See my blog for a detailed post:
http://jonasboner.com/2008/12/09/real-world-scala-managing-cross-cutting-concerns-using-mixin-composition-and-aop.html
(last half)
- Caching -
Annotate your methods with '@Cacheable' to have the cached in a
performant way.
- DI -
We used the Cake Pattern, but used Guice at one point, should be easy
to add that again if requested.
See this article for details:
http://jonasboner.com/2008/10/06/real-world-scala-dependency-injection-di.html
You can find all code here:
http://github.com/jboner/skalman/tree/master
Here is the JTA stuff:
http://github.com/jboner/skalman/blob/610ad8918111c56284640f04ff7dcce7c33d3e5b/core/src/main/scala/JTA.scala
Please come with feedback if there is anything that would fit Lift.
Especially the JTA stuff since that have been discussed to be added.
Thanks.
Jonas Bonér | Crisp AB
http://jonasboner.com
http://crisp.se
--
Jonas Bonér | Crisp AB
http://jonasboner.com
http://crisp.se
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
