2009/7/20 Derek Chen-Becker :
> ... 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
> wrote:
>>
>> FYI, it looks like the Hibernate dependency you had i
I'm really sorry. I never checked building with an empty maven repo.
Thanks for fixing it.
2009/7/20 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
... 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
wrote:
> FYI, it looks like the Hibernate dependency you had in your pom was pulling
> in the javax.transactions:jta lib, whi
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 wrote:
>
> Thanks Tim and David.
Thanks Tim and David.
2009/7/19 David Pollak :
>
>
> On Sat, Jul 18, 2009 at 11:20 AM, Timothy Perrett
> wrote:
>>
>> Awesome - kudos Jonas.
>
> +1
>
> And more generally, it's great to have such a diverse and talented group of
> people contributing to Lift!
>
>>
>> Cheers, Tim
>>
>> On Jul 18,
On Sat, Jul 18, 2009 at 11:20 AM, Timothy Perrett
wrote:
>
> Awesome - kudos Jonas.
+1
And more generally, it's great to have such a diverse and talented group of
people contributing to Lift!
>
>
> Cheers, Tim
>
> On Jul 18, 11:53 am, Jonas Bonér wrote:
> > JTA stuff is in github master bran
Awesome - kudos Jonas.
Cheers, Tim
On Jul 18, 11:53 am, Jonas Bonér wrote:
> JTA stuff is in github master branch
> now.http://github.com/dpp/liftweb/tree/4d8405a3dcf93570da8142c078784f9dc1...
>
> Have fun.
> /Jonas
--~--~-~--~~~---~--~~
You received this messa
JTA stuff is in github master branch now.
http://github.com/dpp/liftweb/tree/4d8405a3dcf93570da8142c078784f9dc127933c/lift-jta
Have fun.
/Jonas
2009/7/17 David Pollak :
>
>
> On Fri, Jul 17, 2009 at 1:02 AM, Jonas Bonér wrote:
>>
>> Hi Greg.
>>
>> Have you had time to look at the JTA stuff?
>>
On Fri, Jul 17, 2009 at 1:02 AM, Jonas Bonér wrote:
>
> Hi Greg.
>
> Have you had time to look at the JTA stuff?
> Should I merge in master?
Please merge into Master. We've got 6-8 weeks until with have the 1.1
release code slush... and if stuff is in the Maven repo, it'll get used.
>
>
> /J
Hi Greg.
Have you had time to look at the JTA stuff?
Should I merge in master?
/Jonas
2009/7/7 Jonas Bonér :
> Thanks Tim. Thanks for staying on top of it. Derek has already looked
> at it and seemed to like it. But I'll wait until I get Greg's
> feedback.
>
> 2009/7/7 Timothy Perrett :
>>
>>
>
Thanks Tim. Thanks for staying on top of it. Derek has already looked
at it and seemed to like it. But I'll wait until I get Greg's
feedback.
2009/7/7 Timothy Perrett :
>
>
> Hey Jonas,
>
> I have no real use case to test it out - I was just interested in its status
> as conceptually it was very
Thanks Greg. I would love to get your feedback on it.
2009/7/7 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, 20
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
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 wrote:
>
> No I haven't. Should I? Is everyone happy with it?
> Have a
No I haven't. Should I? Is everyone happy with it?
Have anyone tried it? Is anyone using it?
2009/6/30 Timothy Perrett :
>
> Jonas,
>
> Did you roll this into master? What's its status?
>
> Cheers, Tim
>
> On Jun 10, 4:46 pm, James Strachan wrote:
>> 2009/6/9 Jonas Bonér :
>>
>>
>>
>> > 2009/6/9
Jonas,
Did you roll this into master? What's its status?
Cheers, Tim
On Jun 10, 4:46 pm, James Strachan wrote:
> 2009/6/9 Jonas Bonér :
>
>
>
> > 2009/6/9 David Pollak :
> >> Jonas,
> >> We always use Maven to load dependencies. We never use GPL dependencies.
> >> If you have a question abou
Thanks James.
But I have already found them in a public repo.
/Jonas
2009/6/10 James Strachan :
>
> 2009/6/9 Jonas Bonér :
>>
>> 2009/6/9 David Pollak :
>>> Jonas,
>>> We always use Maven to load dependencies. We never use GPL dependencies.
>>> If you have a question about the license of a depe
2009/6/9 Jonas Bonér :
>
> 2009/6/9 David Pollak :
>> Jonas,
>> We always use Maven to load dependencies. We never use GPL dependencies.
>> If you have a question about the license of a dependency and its use in
>> Lift, please ping me privately.
>
> I am using Maven. But as I said I could not f
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,
On Tue, Jun 9, 2009 at 1:08 PM, Jonas Bonér wrote:
>
> Now I have deleted the lib dir with all jars and fixed the POM.
Thanks!
>
>
> 2009/6/9 Derek Chen-Becker :
> > In my email above I have the link to the Maven artifacts for Atomikos:
> >
> > http://mvnrepository.com/artifact/com.atomikos
>
Now I have deleted the lib dir with all jars and fixed the POM.
2009/6/9 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:
>
>
> com.atomikos
> trans
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 :
> 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 on
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
Thanks Greg. And thanks for the suggestion to see transactions as monadic.
All feedback is more than welcome.
/Jonas
2009/6/9 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 wrote:
>>
Thanks Derek. I missed that. I will fix the pom.xml.
2009/6/9 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:
>
>
> com.atomikos
> transactions-jta
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:
com.atomikos
transactions-jta
3.2.3
Derek
On Tue, Jun 9, 2009 at 12:54 PM, Meredith Gregory
wrote:
> Jonas,
>
> Awesome!
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 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:
>
> f
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
>>
>> 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 unles
On Tue, Jun 9, 2009 at 10:13 AM, Jonas Bonér wrote:
>
> 2009/6/9 David Pollak :
> > Jonas,
> > We always use Maven to load dependencies. We never use GPL dependencies.
> > If you have a question about the license of a dependency and its use in
> > Lift, please ping me privately.
>
> I am using
2009/6/9 David Pollak :
> Jonas,
> We always use Maven to load dependencies. We never use GPL dependencies.
> If you have a question about the license of a dependency and its use in
> Lift, please ping me privately.
I am using Maven. But as I said I could not find the Atomikos in any
public lib
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 Confi
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 :
> Awesome! I'll take a look a
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" wrote:
>
> I am only depending on Lift through the Lif
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
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
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 wrote:
>
> Hey guys.
>
> I have hacked together an early draft of the JTA trans
Wow, this is very nice! Kudos Jonas!
Cheers, Tim
On 09/06/2009 14:18, "Jonas Bonér" 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
Starkt jobbat Jonas!
I'll have a look at it asap :)
On Tue, Jun 9, 2009 at 4:27 PM, Jonas Bonér wrote:
>
> 2009/6/9 David Pollak :
> > Sweet looking stuff!
>
> Thanks.
>
> >
> > On Tue, Jun 9, 2009 at 6:18 AM, Jonas Bonér wrote:
> >>
> >> Hey guys.
> >>
> >> I have hacked together an early dra
2009/6/9 David Pollak :
> Sweet looking stuff!
Thanks.
>
> On Tue, Jun 9, 2009 at 6:18 AM, Jonas Bonér 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
Sweet looking stuff!
On Tue, Jun 9, 2009 at 6:18 AM, Jonas Bonér 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 <- upd
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
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 :
> 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 co
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
On Fri, May 29, 2009 at 7:19 PM, Josh Suereth wrote:
> +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 co
+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.roll
I, too, would like to see Transactions be monadic.
--j
On Fri, May 29, 2009 at 3:54 PM, Meredith Gregory
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. Sinc
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
wrote:
> Jonas,
>
> i applaud the effort. i agree with DPP sentiments regarding
> annotations. That said, i feel pretty comfort
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
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 Bo
Thanks Tim and Derek.
I'll work in a branch. Simpler for me as well.
/Jonas
2009/5/29 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--
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 wrote:
>
> I'll go for closures. Much simpler and
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--
E.g. wip-tim-localization
Checkout the thread oliver started "git ouch" - I just posted instructions
there for cre
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.transacti
On Fri, May 29, 2009 at 6:47 AM, 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.
I view annotations as a "second la
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 wrote:
>
> No perf difference. The annotations
No perf difference. The annotations are turned into the same exact closures.
2009/5/29 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." wro
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." wrote:
>
> I think that would be really good. But I'd rather not use annotations.
> Personally I find closures approach
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 wrote:
> Hi guys.
>
> I have been talking with David Pollak the r
Everything I've ever seen has been provider-specific.
On 2/10/09, Viktor Klang 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
> wrote:
>
>> Yes, but that only works for Hibernate. I use Hibernate from everything,
>> but I'm
Is there a JPA defined way to turn loggin of DML on?
On Tue, Feb 10, 2009 at 3:45 PM, Derek Chen-Becker wrote:
> 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 wrote
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 wrote:
>
> Otherwise you can enable it in the logging:
>
> log4j.logger.org.hibernate.SQL=DEBUG
>
> On Tue, Feb 10, 2009 at 7:50
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 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 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 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 un
64 matches
Mail list logo