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