[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
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 --~--~-~--~~~---~--~~ 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
... hit the enter key too quickly! Kudos on the work in this library. I really like how this is coming together. Derek On Sun, Jul 19, 2009 at 11:52 PM, Derek Chen-Becker dchenbec...@gmail.comwrote: 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 --~--~-~--~~~---~--~~ 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
Awesome - kudos Jonas. 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 --~--~-~--~~~---~--~~ 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
On Sat, Jul 18, 2009 at 11:20 AM, Timothy Perrett timo...@getintheloop.euwrote: 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 --~--~-~--~~~---~--~~ 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: 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
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 --~--~-~--~~~---~--~~ 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
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/ --~--~-~--~~~---~--~~ 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: JTA Transaction Monad - Early Access Program
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/ --~--~-~--~~~---~--~~ 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
Lifted,
i gotta say this thread of activity is just so cool. It's what i always
dreamed open source would be like. The community essentially gets to access
and think with each others' best minds and act with each others' best
talents to arrive on a path to a better concrete realization of feature,
function and design. We all know, individually and collectively, just how
hard it is to make excellent software and know that we're more likely to
achieve that aim working together. i can't help but notice that there is no
explicit representation of the profit motive here. Each of us might
individually be in contact with some aspect of profit motive, but it does
not have an explicit representation in this little snippet of process. That
gives this entrepreneur pause for thought.
Best wishes,
--greg
On Tue, Jun 9, 2009 at 3:46 PM, David Pollak
feeder.of.the.be...@gmail.comwrote:
On Tue, Jun 9, 2009 at 1:08 PM, Jonas Bonér jbo...@gmail.com wrote:
Now I have deleted the lib dir with all jars and fixed the POM.
Thanks!
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
--
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
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117
+1 206.650.3740
http://biosimilarity.blogspot.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: JTA Transaction Monad - Early Access Program
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/ --~--~-~--~~~---~--~~ 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
Sweet looking stuff!
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
--~--~-~--~~~---~--~~
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
Starkt jobbat Jonas!
I'll have a look at it asap :)
On Tue, Jun 9, 2009 at 4:27 PM, Jonas Bonér jbo...@gmail.com wrote:
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
--
Viktor Klang
Rockstar Developer
--~--~-~--~~~---~--~~
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
Wow, this is very nice! Kudos Jonas!
Cheers, Tim
On 09/06/2009 14:18, 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/li
ft-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.
--~--~-~--~~~---~--~~
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
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
--~--~-~--~~~---~--~~
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
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.comwrote:
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
--~--~-~--~~~---~--~~
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
Isnt LiftLogger extensible? Perhaps there would be some way to integrate it
with LiftLogger so it was an optional logger just like Log4J, SL4J etc
Disclaimer: I know nothing about Configgy!
Cheers, Tim
On 09/06/2009 17:34, 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
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: JTA Transaction Monad - Early Access Program
Jonas,
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.
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).
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
--~--~-~--~~~---~--~~
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
On Tue, Jun 9, 2009 at 10:13 AM, Jonas Bonér jbo...@gmail.com wrote:
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.
I understand why you did it and that you had the goal of making it easier
for developers.
Do you know if they are in any public repo?
I don't... but if they are not in a public repo, we have two choices:
hosting the JAR files on scala-tools.org (as long as the license allows us
to do that) or finding an alternative that is hosted in a public repo. I'm
dealing with similar issues right now with ZooKeeper.
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.
We can add that to Lift's logger (which can sit on top of slf4j)
Also, note that all of Lift's logger parameters are call-by-name so there's
no evaluation unless the log level is met.
Second I really like Configgys configuration API,
Can you tell me what you specifically like about it?
Thanks,
David
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] 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
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
--~--~-~--~~~---~--~~
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
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.comwrote:
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
--~--~-~--~~~---~--~~
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 Transaction Monad - Early Access Program
On Tue, Jun 9, 2009 at 1:08 PM, Jonas Bonér jbo...@gmail.com wrote:
Now I have deleted the lib dir with all jars and fixed the POM.
Thanks!
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
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: JTA
Jonas,
i just got back from a week of Guitar on Raft Island. So, i just saw this
message. If you want any help, design review, code review, peanuts from the
peanut gallery, just give me a shout. Also, i wanted to reiterate that i
think you can also provide an annotation-style solution over the top of a
monadic solution -- which i think would solve some concerns Josh might have
raised (if my music-addled brain has grasped them). i'm looking forward to
see what you come up with.
Best wishes,
--greg
On Sat, May 30, 2009 at 1:15 PM, Jonas Bonér jbo...@gmail.com wrote:
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
--
L.G. Meredith
[Lift] Re: JTA
Unfortunately, I'm still living in EJB land, and therefore would prefer
something to bridge the gap (between legacy and new code). Goatrodeo looks
very exciting, but something for our next new component.
I actually had a layer I was using between our EJB beans + LIft that perhaps
with some time I can re-write in a open-source setting. I make no promises
on time, but I do see interfacing with legacy systems as being a huge win
for promoting lift/scala use in the enterprise. Basically, my Lift-EJB
Layer looked like the following:
import EJBHelper._
def retreiveSomeValue = {
val result = withBean[BeanLocalInterface] { bean =
bean.someBusinessMethod()
}
result.openOrElse(SomeOtherValue)
}
What I'd like is to be able to migrate scala further down my EJB stack when
refactoring. For example:
@Stateless
class MyBean extends MyBeanLocal with ScalaEJBHelper {
def getMyData(id : Long) {
(for {
tx - transaction(JOIN_OR_NEW)
result - ejb_single_query(from MyDataBean where MyDataBean.id
= ?) % id
} yield result).first
}
}
At least until it becomes more acceptable/feasible to migrate to better
solutions than EJB.
- Josh
On Fri, May 29, 2009 at 11:36 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
On Fri, May 29, 2009 at 7:19 PM, Josh Suereth joshua.suer...@gmail.comwrote:
+30
See http://github.com/dpp/goatrodeo/tree/master
--~--~-~--~~~---~--~~
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
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
--~--~-~--~~~---~--~~
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'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
--~--~-~--~~~---~--~~
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
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
--~--~-~--~~~---~--~~
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
Create a branch (see Oliver's recent thread) and push that. We cna look at
the branch before merging into master. Branching is preferred over forking
because it keeps things in the same stream.
Derek
On Fri, May 29, 2009 at 7: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
--~--~-~--~~~---~--~~
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: JTA
I agree.
Derek Chen-Becker wrote:
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
mailto: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
mailto: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
mailto: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
Wow, that I would very much like to see... using for comprehensions
for transactions!
Cheers, Tim
Sent from my iPhone
On 29 May 2009, at 23:54, Meredith Gregory lgreg.mered...@gmail.com
wrote:
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 wrot
e:
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 wr
ote:
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
--~--~-~--~~~---~--~~
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, too, would like to see Transactions be monadic.
--j
On Fri, May 29, 2009 at 3:54 PM, Meredith Gregory
lgreg.mered...@gmail.comwrote:
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
LINQhttp://github.com/szeiger/scala-query/tree/master,
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
--~--~-~--~~~---~--~~
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
+30
So many pluses in fact, that we are already experimenting with this concept
at work. Unfortunately, the source may not be openable. I'd be more than
willing to contribute to an open-source JTA monadic library.
for( tx - context) {
//Do stuff
if(somethingBad) tx.rollback()
//Do more stuff
}
Just seems to fit the needs of my software *much* better than the magical
annotated method...errr... method seen in EJB and Spring.
-Josh
On Fri, May 29, 2009 at 9:16 PM, Jorge Ortiz jorge.or...@gmail.com wrote:
I, too, would like to see Transactions be monadic.
--j
On Fri, May 29, 2009 at 3:54 PM, Meredith Gregory
lgreg.mered...@gmail.com wrote:
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
LINQhttp://github.com/szeiger/scala-query/tree/master,
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
--~--~-~--~~~---~--~~
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
[Lift] Re: JTA
On Fri, May 29, 2009 at 7:19 PM, Josh Suereth joshua.suer...@gmail.comwrote:
+30
See http://github.com/dpp/goatrodeo/tree/master
So many pluses in fact, that we are already experimenting with this concept
at work. Unfortunately, the source may not be openable. I'd be more than
willing to contribute to an open-source JTA monadic library.
for( tx - context) {
//Do stuff
if(somethingBad) tx.rollback()
//Do more stuff
}
Just seems to fit the needs of my software *much* better than the magical
annotated method...errr... method seen in EJB and Spring.
-Josh
On Fri, May 29, 2009 at 9:16 PM, Jorge Ortiz jorge.or...@gmail.comwrote:
I, too, would like to see Transactions be monadic.
--j
On Fri, May 29, 2009 at 3:54 PM, Meredith Gregory
lgreg.mered...@gmail.com wrote:
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
LINQhttp://github.com/szeiger/scala-query/tree/master,
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
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
[Lift] Re: JTA showSQL
Otherwise you can enable it in the logging:
log4j.logger.org.hibernate.SQL=DEBUG
On Tue, Feb 10, 2009 at 7:50 AM, Derek Chen-Becker dchenbec...@gmail.comwrote:
Interesting idea. I'll look into adding something like this (configurable
at boot and/or runtime) into scalajpa.
Derek
On 2/9/09, Oliver ola...@gmail.com wrote:
Hi Derek and interested parties
I know there is a showSQL option that can be enabled with
JTA/Hibernate but I find the output verbose and uninformative about
parameter replacement.
So, I have my own ScalaQuery that allows simple debugging - the main
differences are -
var queryParams: List[Pair[String,Any]] = Nil
/* the following method needs to be called by the various
SetParameter methods */
def addParam(one: String,two: Any) = {
query.setParameter(one, two)
queryParams = (one, two) :: queryParams
}
/*
output the query with parameters substitued, for debugging ...
*/
def getQueryWithParams() = {
var q = queryStr
try {
queryParams.foreach{v =
var rep = v._2 match {
case d: Date = '+SUtil.formatDate(d,
dd/MM/)+'
case s: String = '+s+'
case x = if (x==null) else x.toString
}
rep = rep.replaceAll(\\$, ddDollardd) // stupid bug
q = q.replaceAll(:+v._1, rep)
}
q.replaceAll(ddDollardd, \\$)
} catch {
case e: Exception = q+ PARAMS +queryParams+ EXCEPTION +e
}
}
With this I can log the query via
Log.info(emailQuery.getQueryWithParams())
Better still, (assuming execOnce exists in a utility object) when I
only need to see the query once in the log
/*
execulte execFn, just once for the jvm.
*/
val execOnceSet = scala.collection.mutable.Set()
def execOnce(key: String, execFn: = Unit) = {
if (!execOnceSet.contains(key)) {
execOnceSet += key
execFn
}
}
execOnce(findByEmail, Log.info(emailQuery.getQueryWithParams()) )
You can add the functionality if you find it useful
cheers
Oliver
--
Viktor Klang
Senior Systems Analyst
--~--~-~--~~~---~--~~
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 showSQL
Yes, but that only works for Hibernate. I use Hibernate from everything, but
I'm trying to keep the library usable for any JPA provider.
Derek
On 2/10/09, Viktor Klang viktor.kl...@gmail.com wrote:
Otherwise you can enable it in the logging:
log4j.logger.org.hibernate.SQL=DEBUG
On Tue, Feb 10, 2009 at 7:50 AM, Derek Chen-Becker
dchenbec...@gmail.comwrote:
Interesting idea. I'll look into adding something like this (configurable
at boot and/or runtime) into scalajpa.
Derek
On 2/9/09, Oliver ola...@gmail.com wrote:
Hi Derek and interested parties
I know there is a showSQL option that can be enabled with
JTA/Hibernate but I find the output verbose and uninformative about
parameter replacement.
So, I have my own ScalaQuery that allows simple debugging - the main
differences are -
var queryParams: List[Pair[String,Any]] = Nil
/* the following method needs to be called by the various
SetParameter methods */
def addParam(one: String,two: Any) = {
query.setParameter(one, two)
queryParams = (one, two) :: queryParams
}
/*
output the query with parameters substitued, for debugging ...
*/
def getQueryWithParams() = {
var q = queryStr
try {
queryParams.foreach{v =
var rep = v._2 match {
case d: Date = '+SUtil.formatDate(d,
dd/MM/)+'
case s: String = '+s+'
case x = if (x==null) else x.toString
}
rep = rep.replaceAll(\\$, ddDollardd) // stupid bug
q = q.replaceAll(:+v._1, rep)
}
q.replaceAll(ddDollardd, \\$)
} catch {
case e: Exception = q+ PARAMS +queryParams+ EXCEPTION
+e
}
}
With this I can log the query via
Log.info(emailQuery.getQueryWithParams())
Better still, (assuming execOnce exists in a utility object) when I
only need to see the query once in the log
/*
execulte execFn, just once for the jvm.
*/
val execOnceSet = scala.collection.mutable.Set()
def execOnce(key: String, execFn: = Unit) = {
if (!execOnceSet.contains(key)) {
execOnceSet += key
execFn
}
}
execOnce(findByEmail, Log.info(emailQuery.getQueryWithParams()) )
You can add the functionality if you find it useful
cheers
Oliver
--
Viktor Klang
Senior Systems Analyst
--~--~-~--~~~---~--~~
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 showSQL
Is there a JPA defined way to turn loggin of DML on?
On Tue, Feb 10, 2009 at 3:45 PM, Derek Chen-Becker dchenbec...@gmail.comwrote:
Yes, but that only works for Hibernate. I use Hibernate from everything,
but I'm trying to keep the library usable for any JPA provider.
Derek
On 2/10/09, Viktor Klang viktor.kl...@gmail.com wrote:
Otherwise you can enable it in the logging:
log4j.logger.org.hibernate.SQL=DEBUG
On Tue, Feb 10, 2009 at 7:50 AM, Derek Chen-Becker dchenbec...@gmail.com
wrote:
Interesting idea. I'll look into adding something like this (configurable
at boot and/or runtime) into scalajpa.
Derek
On 2/9/09, Oliver ola...@gmail.com wrote:
Hi Derek and interested parties
I know there is a showSQL option that can be enabled with
JTA/Hibernate but I find the output verbose and uninformative about
parameter replacement.
So, I have my own ScalaQuery that allows simple debugging - the main
differences are -
var queryParams: List[Pair[String,Any]] = Nil
/* the following method needs to be called by the various
SetParameter methods */
def addParam(one: String,two: Any) = {
query.setParameter(one, two)
queryParams = (one, two) :: queryParams
}
/*
output the query with parameters substitued, for debugging ...
*/
def getQueryWithParams() = {
var q = queryStr
try {
queryParams.foreach{v =
var rep = v._2 match {
case d: Date = '+SUtil.formatDate(d,
dd/MM/)+'
case s: String = '+s+'
case x = if (x==null) else x.toString
}
rep = rep.replaceAll(\\$, ddDollardd) // stupid bug
q = q.replaceAll(:+v._1, rep)
}
q.replaceAll(ddDollardd, \\$)
} catch {
case e: Exception = q+ PARAMS +queryParams+ EXCEPTION
+e
}
}
With this I can log the query via
Log.info(emailQuery.getQueryWithParams())
Better still, (assuming execOnce exists in a utility object) when I
only need to see the query once in the log
/*
execulte execFn, just once for the jvm.
*/
val execOnceSet = scala.collection.mutable.Set()
def execOnce(key: String, execFn: = Unit) = {
if (!execOnceSet.contains(key)) {
execOnceSet += key
execFn
}
}
execOnce(findByEmail, Log.info(emailQuery.getQueryWithParams()) )
You can add the functionality if you find it useful
cheers
Oliver
--
Viktor Klang
Senior Systems Analyst
--
Viktor Klang
Senior Systems Analyst
--~--~-~--~~~---~--~~
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 showSQL
Everything I've ever seen has been provider-specific.
On 2/10/09, Viktor Klang viktor.kl...@gmail.com wrote:
Is there a JPA defined way to turn loggin of DML on?
On Tue, Feb 10, 2009 at 3:45 PM, Derek Chen-Becker
dchenbec...@gmail.comwrote:
Yes, but that only works for Hibernate. I use Hibernate from everything,
but I'm trying to keep the library usable for any JPA provider.
Derek
On 2/10/09, Viktor Klang viktor.kl...@gmail.com wrote:
Otherwise you can enable it in the logging:
log4j.logger.org.hibernate.SQL=DEBUG
On Tue, Feb 10, 2009 at 7:50 AM, Derek Chen-Becker
dchenbec...@gmail.com wrote:
Interesting idea. I'll look into adding something like this
(configurable at boot and/or runtime) into scalajpa.
Derek
On 2/9/09, Oliver ola...@gmail.com wrote:
Hi Derek and interested parties
I know there is a showSQL option that can be enabled with
JTA/Hibernate but I find the output verbose and uninformative about
parameter replacement.
So, I have my own ScalaQuery that allows simple debugging - the main
differences are -
var queryParams: List[Pair[String,Any]] = Nil
/* the following method needs to be called by the various
SetParameter methods */
def addParam(one: String,two: Any) = {
query.setParameter(one, two)
queryParams = (one, two) :: queryParams
}
/*
output the query with parameters substitued, for debugging ...
*/
def getQueryWithParams() = {
var q = queryStr
try {
queryParams.foreach{v =
var rep = v._2 match {
case d: Date = '+SUtil.formatDate(d,
dd/MM/)+'
case s: String = '+s+'
case x = if (x==null) else x.toString
}
rep = rep.replaceAll(\\$, ddDollardd) // stupid bug
q = q.replaceAll(:+v._1, rep)
}
q.replaceAll(ddDollardd, \\$)
} catch {
case e: Exception = q+ PARAMS +queryParams+ EXCEPTION
+e
}
}
With this I can log the query via
Log.info(emailQuery.getQueryWithParams())
Better still, (assuming execOnce exists in a utility object) when I
only need to see the query once in the log
/*
execulte execFn, just once for the jvm.
*/
val execOnceSet = scala.collection.mutable.Set()
def execOnce(key: String, execFn: = Unit) = {
if (!execOnceSet.contains(key)) {
execOnceSet += key
execFn
}
}
execOnce(findByEmail, Log.info(emailQuery.getQueryWithParams()) )
You can add the functionality if you find it useful
cheers
Oliver
--
Viktor Klang
Senior Systems Analyst
--
Viktor Klang
Senior Systems Analyst
--~--~-~--~~~---~--~~
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 showSQL
Interesting idea. I'll look into adding something like this (configurable at
boot and/or runtime) into scalajpa.
Derek
On 2/9/09, Oliver ola...@gmail.com wrote:
Hi Derek and interested parties
I know there is a showSQL option that can be enabled with
JTA/Hibernate but I find the output verbose and uninformative about
parameter replacement.
So, I have my own ScalaQuery that allows simple debugging - the main
differences are -
var queryParams: List[Pair[String,Any]] = Nil
/* the following method needs to be called by the various
SetParameter methods */
def addParam(one: String,two: Any) = {
query.setParameter(one, two)
queryParams = (one, two) :: queryParams
}
/*
output the query with parameters substitued, for debugging ...
*/
def getQueryWithParams() = {
var q = queryStr
try {
queryParams.foreach{v =
var rep = v._2 match {
case d: Date = '+SUtil.formatDate(d,
dd/MM/)+'
case s: String = '+s+'
case x = if (x==null) else x.toString
}
rep = rep.replaceAll(\\$, ddDollardd) // stupid bug
q = q.replaceAll(:+v._1, rep)
}
q.replaceAll(ddDollardd, \\$)
} catch {
case e: Exception = q+ PARAMS +queryParams+ EXCEPTION +e
}
}
With this I can log the query via
Log.info(emailQuery.getQueryWithParams())
Better still, (assuming execOnce exists in a utility object) when I
only need to see the query once in the log
/*
execulte execFn, just once for the jvm.
*/
val execOnceSet = scala.collection.mutable.Set()
def execOnce(key: String, execFn: = Unit) = {
if (!execOnceSet.contains(key)) {
execOnceSet += key
execFn
}
}
execOnce(findByEmail, Log.info(emailQuery.getQueryWithParams()) )
You can add the functionality if you find it useful
cheers
Oliver
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
