[Lift] Re: JTA Transaction Monad - Early Access Program

2009-07-20 Thread Jonas Bonér

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-07-20 Thread Jonas Bonér

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

2009-07-19 Thread Jonas Bonér

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

2009-07-19 Thread Derek Chen-Becker
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

2009-07-19 Thread Derek Chen-Becker
... 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

2009-07-18 Thread Jonas Bonér

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

Have fun.
/Jonas

2009/7/17 David Pollak 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

2009-07-18 Thread Timothy Perrett

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

2009-07-18 Thread David Pollak
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

2009-07-17 Thread Jonas Bonér

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

2009-07-07 Thread Jonas Bonér

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

2009-07-07 Thread Meredith Gregory
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

2009-07-07 Thread Timothy Perrett


Hey Jonas,

I have no real use case to test it out - I was just interested in its status
as conceptually it was very very clever and wondered where you were too with
it. I think Greg or Derek are most likely to be able to give you valuable
feedback as I believe they are using JTA already.

Cheers, Tim

On 07/07/2009 18:18, Jonas Bonér 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

2009-07-07 Thread Jonas Bonér

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

2009-07-07 Thread Jonas Bonér

Thanks Tim. Thanks for staying on top of it. Derek has already looked
at it and seemed to like it. But I'll wait until I get Greg's
feedback.

2009/7/7 Timothy Perrett 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

2009-06-30 Thread Timothy Perrett

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

2009-06-10 Thread Meredith Gregory
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-06-10 Thread James Strachan

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

2009-06-10 Thread Jonas Bonér

Thanks James.
But I have already found them in a public repo.
/Jonas

2009/6/10 James Strachan james.strac...@gmail.com:

 2009/6/9 Jonas Bonér jbo...@gmail.com:

 2009/6/9 David Pollak feeder.of.the.be...@gmail.com:
 Jonas,
 We always use Maven to load dependencies.  We never use GPL dependencies.
  If you have a question about the license of a dependency and its use in
 Lift, please ping me privately.

 I am using Maven. But as I said I could not find the Atomikos in any
 public library, putting them in lib will let the user easily install
 them in their local repo.
 Do you know if they are in any public repo?

 If its any help I added them here a while back for an integration test
 in ActiveMQ
 http://repo.fusesource.com/maven2-all/com/atomikos/

 the repo is: http://repo.fusesource.com/maven2-all/

 you might wanna put more recent jars up on some public repo though.


 --
 James
 ---
 http://macstrac.blogspot.com/

 Open Source Integration
 http://fusesource.com/

 




-- 
Jonas Bonér

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

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



[Lift] Re: JTA Transaction Monad - Early Access Program

2009-06-09 Thread David Pollak
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-06-09 Thread Jonas Bonér

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

2009-06-09 Thread Viktor Klang
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

2009-06-09 Thread Timothy Perrett


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

2009-06-09 Thread Derek Chen-Becker
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

2009-06-09 Thread Derek Chen-Becker
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

2009-06-09 Thread Jonas Bonér

I added the lib folder only since I have not been able to find the
atomikos and deps in any maven repo.
Now the user can install them in their private repo.
If they exist in a public repo then I will remove the lib folder.
Will switch to the apache libs.
Thanks, Jonas.

2009/6/9 Derek Chen-Becker dchenbec...@gmail.com:
 OK, one quick comment before I dive in: we generally want to depend on Maven
 to grab dependencies. Right now you have a lib folder checked into git that
 appears to hold the JTA libs and Atomikos. If that's the Sun JTA libs then
 we can't distribute them. We generally use the geronimo JTA API, so you
 could instead add dependencies to your pom.xml from the following:

 http://mvnrepository.com/artifact/com.atomikos

 dependency
 groupIdorg.apache.geronimo.specs/groupId
 artifactIdgeronimo-jta_1.1_spec/artifactId
 version1.1.1/version
 /dependency

 Let me know if you have any problems with that. Now, on to the code!

 Derek

 On Tue, Jun 9, 2009 at 9:44 AM, Derek Chen-Becker dchenbec...@gmail.com
 wrote:

 Awesome! I'll take a look at the code. If you're basing this on ScalaJPA,
 would it be preferable to add the functionality there, or is there anything
 Lift-specific?

 Derek


 On Tue, Jun 9, 2009 at 7:18 AM, Jonas Bonér jbo...@gmail.com wrote:

 Hey guys.

 I have hacked together an early draft of the JTA transaction stuff.

 I have wrapped it up in a monad. Here  are some examples of usage:

  for {
   ctx - TransactionContext.Required
   entity - updatedEntities
   if !ctx.isRollbackOnly
  } {
   // transactional stuff
   ctx.getEntityManager.merge(entity)
  }

 val users = for {
   ctx - TransactionContext.Required
   name - userNames
  } yield {
   // transactional stuff
   val query = ctx.getEntityManager.createNamedQuery(findUserByName)
   query.setParameter(userName, name)
   query.getSingleResult
  }

 If you don't like the monadic approach you can just use the high-order
 functions:

 TransactionContext.withTxRequired {
    ... // REQUIRED semantics

  TransactionContext.withTxRequiresNew {
    ... // REQUIRES_NEW semantics
  }
 }

 I have implemented the same semantics as used in the EJB spec.
 Required, RequiresNew, Mandatory, Supports, Never. All these are
 monadic objects in the TransactionContext object.
 I don't have a webapp to try this out, so I would be happy to get all
 kinds of feedback, but API wise and bug reports or fixes.

 This API is hooked into Derek's Scala-JPA stuff. I had my own impl of
 this but replaced it with Derek's work.

 Derek,
 please go through the integration to see if I have done it correctly,
 and where things code be improved.

 All committers,
 feel free to hack and change this code anyway you want.

 The code is in a branch (wip-jta-jonas), you can find it here:

 http://github.com/dpp/liftweb/tree/3783b9e2200cc57dd72baa1bd8cabdb1365ee923/lift-jta

 Check the ScalaDoc (or the source) for the documentation on usage,
 semantics etc.
 Also see the README for configuration in persistence.xml etc.

 Currently it is hard-coded to use the Atomikos Transaction library and
 Hibernate JPA, that would have to be configurable + some other options
 as well. See the TODOs in the code.

 As I said, this needs feedback and testing. Thanks.

 --
 Jonas Bonér

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





 




-- 
Jonas Bonér

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

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



[Lift] Re: JTA Transaction Monad - Early Access Program

2009-06-09 Thread Timothy Perrett


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

2009-06-09 Thread David Pollak
Jonas,
We always use Maven to load dependencies.  We never use GPL dependencies.
 If you have a question about the license of a dependency and its use in
Lift, please ping me privately.

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-06-09 Thread Jonas Bonér

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

2009-06-09 Thread David Pollak
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

2009-06-09 Thread Jonas Bonér


 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

2009-06-09 Thread Jonas Bonér

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

2009-06-09 Thread Meredith Gregory
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

2009-06-09 Thread Derek Chen-Becker
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

2009-06-09 Thread Jonas Bonér

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

2009-06-09 Thread Jonas Bonér

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

2009-06-09 Thread Jonas Bonér

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

2009-06-09 Thread Jonas Bonér

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

2009-06-09 Thread David Pollak
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

2009-06-08 Thread Meredith Gregory
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

2009-05-30 Thread Josh Suereth
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

2009-05-30 Thread Jonas Bonér

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

2009-05-29 Thread Timothy Perrett


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

2009-05-29 Thread Jonas Bonér

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

2009-05-29 Thread Derek Chen-Becker
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

2009-05-29 Thread Jonas Bonér

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

2009-05-29 Thread Timothy Perrett


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

2009-05-29 Thread Derek Chen-Becker
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

2009-05-29 Thread Jonas Bonér

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

2009-05-29 Thread Charles F. Munat

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

2009-05-29 Thread Timothy Perrett
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

2009-05-29 Thread Jorge Ortiz
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

2009-05-29 Thread Josh Suereth
+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

2009-05-29 Thread David Pollak
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

2009-02-10 Thread Viktor Klang
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

2009-02-10 Thread Derek Chen-Becker
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

2009-02-10 Thread Viktor Klang
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

2009-02-10 Thread Derek Chen-Becker
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

2009-02-09 Thread Derek Chen-Becker
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
-~--~~~~--~~--~--~---