[Lift] Re: [Lift committers] Re: Meeting
2009/4/16 David Pollak feeder.of.the.be...@gmail.com:
Taking the discussion to the main list
On Thu, Apr 16, 2009 at 10:23 AM, Jonas Bonér jo...@jonasboner.com wrote:
2009/4/16 David Pollak feeder.of.the.be...@gmail.com:
On Thu, Apr 16, 2009 at 7:08 AM, Jonas Bonér jo...@jonasboner.com
wrote:
2009/4/16 David Pollak feeder.of.the.be...@gmail.com:
It'd be optimal if you could discuss the JTA stuff in the public
forum.
In
terms of AOP, I'm really not kidding that AOP is not going to happen
in
Lift.
You don't like annotations? E.g. @Transactional etc.?
I'm not keen on annotations, but I can live with them.
I am firmly against anything that re-writes byte-code after the
compilation
phase for production code. Once the Scala-Maven plugin supports
compiler
plugins, then there's a lot of stuff that can be done at compile-time.
The AOP stuff I have done is based on dynamic proxies no bytecode munging.
OKay... I need to see some example to fully understand why a proxy needs AOP
rather than either (1) compile-time proxy generation or (2) the built-in
Java reflect proxy thingy.
You can impl AOP using many different techniques. I proposed the
simplest one (used by Spring, Guice etc.). Using a regular JDK Dynamic
Proxy (which is the 'build in Java reflect proxy thingy'). What is
your question?
So, what does AOP give us that can't be done at another phase?
AOP is not about a specific phase. It can be done at:
* compile time
* class load time
* runtime
Can be done with:
* Bytecode mods
* Generated proxy
* Dynamic proxy
* JVM-level hooks
Semantics to annotations.
Can you help out with an example?
Annotate a class with f.e.
@transactional(type=Required) class Foo { ..}
and have all methods in this class being invoked under a transaction
with Required semantics
or annotate a specific method
@transactional(type=RequiresNew) def foo { ..}
to get the same behavior for a method only
Annotations is the way most JEE devs are used to handle these things
since it is the approach both Spring, Guice, EJB 3 etc. etc. has
taken.
The stuff I have written allow using AspectJ pointcuts as well.
E.g. f.e. apply transactions to all methods in the service layer:
match('* com.biz.service.*(..)')
Or to a specific method:
match('void Store.buy(Item)')
But you could just use call-by-name:
transactional(TransactionType.Required) { // tx begin
.. // do stuff in TX
} // tx commit or rollback
But that pollutes the code, makes it harder to change, configure and
is not declarative.
Perhaps give the user options?
But you guys choose.
I am here to serve :-)
/Jonas
Thanks,
David
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
--
Jonas Bonér | Crisp AB
http://jonasboner.com
http://crisp.se
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: [Lift committers] Re: Meeting
I'm currently giving AOP a try
herehttp://github.com/mighdoll/aspecting/tree/master(not in lift).
I was looking for a cleaner way to create objects with
observable properties. I like that an aspect allows for observable objects
that are idiomatic to use and write, and don't require any extra
boilerplate.
The scala class needs only to add the marker trait Observable.
class Model extends Observable {
var prop:String = _
}
Modifications to the instance will then trigger the aspect, notifying
an observer.
val model = new Model()
m.prop = whee
Run that and the test observer sees the change and prints:
change observed example.mo...@6abf2d5e= prop:whee
I'm getting more tempted to use aspectJ because it enables such a
simple and idiomatic
approach to writing model objects that are:
* Concise to write
* Use the normal idioms for working with mutable scala objects.
* Compatible with java libraries, including JPA...
The sources are in src.
To try it yourself, use this script which runs mvn.
./tryMe
On Fri, Apr 17, 2009 at 4:26 AM, Josh Suereth joshua.suer...@gmail.comwrote:
You can impl AOP using many different techniques. I proposed the
simplest one (used by Spring, Guice etc.). Using a regular JDK Dynamic
Proxy (which is the 'build in Java reflect proxy thingy'). What is
your question?
So, what does AOP give us that can't be done at another phase?
AOP is not about a specific phase. It can be done at:
* compile time
* class load time
* runtime
Can be done with:
* Bytecode mods
* Generated proxy
* Dynamic proxy
* JVM-level hooks
Semantics to annotations.
Can you help out with an example?
Annotate a class with f.e.
@transactional(type=Required) class Foo { ..}
and have all methods in this class being invoked under a transaction
with Required semantics
or annotate a specific method
@transactional(type=RequiresNew) def foo { ..}
to get the same behavior for a method only
Annotations is the way most JEE devs are used to handle these things
since it is the approach both Spring, Guice, EJB 3 etc. etc. has
taken.
I use this all the time in java, because there is no other good option
for transactions in java. It's basically the best method. However I don't
believe this is the case in Scala, and I'd rather think through the options
and determine the best one.
The stuff I have written allow using AspectJ pointcuts as well.
E.g. f.e. apply transactions to all methods in the service layer:
match('* com.biz.service.*(..)')
Or to a specific method:
match('void Store.buy(Item)')
Point-cuts after-the fact seem a decent use of transactions. This is under
the following assumptions:
1) Your code will be used in more than one configuration type
2) Your transaction granularity is determined by the configuration of your
module, not by the module itself.
Regarding 2, I think all-to-often real world problems begin to break this
assumption, making internal business logic and external transaction
configuration dependent on each other.
But you could just use call-by-name:
transactional(TransactionType.Required) { // tx begin
.. // do stuff in TX
} // tx commit or rollback
But that pollutes the code, makes it harder to change, configure and
is not declarative.
Perhaps give the user options?
How is it not declarative? I agree that Aspects really do give you better
configuration abilities for code, however I'm not sure transactions are
ideally suited for AOP. I think Java is not ideally suited for
transactional code, so we use AOP.
I'd love to hear your response! This is something I've been mulling
through recently, and I'm still on the fence for Transactions should be
done using AOP on the JVM
-Josh
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: [Lift committers] Re: Meeting
Lee,
The reason that Lift has the richer MappedField and Field objects in Mapper
and Record is to programmatically add this kind of functionality to fields.
No, it's not PoJos, but it's as syntactically clean and a lot easier to
understand/debug.
Thanks,
David
On Fri, Apr 17, 2009 at 9:47 AM, Lee Mighdoll leemighd...@gmail.com wrote:
I'm currently giving AOP a try
herehttp://github.com/mighdoll/aspecting/tree/master(not in lift). I was
looking for a cleaner way to create objects with
observable properties. I like that an aspect allows for observable objects
that are idiomatic to use and write, and don't require any extra
boilerplate.
The scala class needs only to add the marker trait Observable.
class Model extends Observable {
var prop:String = _
}
Modifications to the instance will then trigger the aspect, notifying an
observer.
val model = new Model()
m.prop = whee
Run that and the test observer sees the change and prints:
change observed example.mo...@6abf2d5e= prop:whee
I'm getting more tempted to use aspectJ because it enables such a simple and
idiomatic
approach to writing model objects that are:
* Concise to write
* Use the normal idioms for working with mutable scala objects.
* Compatible with java libraries, including JPA...
The sources are in src.
To try it yourself, use this script which runs mvn.
./tryMe
On Fri, Apr 17, 2009 at 4:26 AM, Josh Suereth joshua.suer...@gmail.comwrote:
You can impl AOP using many different techniques. I proposed the
simplest one (used by Spring, Guice etc.). Using a regular JDK Dynamic
Proxy (which is the 'build in Java reflect proxy thingy'). What is
your question?
So, what does AOP give us that can't be done at another phase?
AOP is not about a specific phase. It can be done at:
* compile time
* class load time
* runtime
Can be done with:
* Bytecode mods
* Generated proxy
* Dynamic proxy
* JVM-level hooks
Semantics to annotations.
Can you help out with an example?
Annotate a class with f.e.
@transactional(type=Required) class Foo { ..}
and have all methods in this class being invoked under a transaction
with Required semantics
or annotate a specific method
@transactional(type=RequiresNew) def foo { ..}
to get the same behavior for a method only
Annotations is the way most JEE devs are used to handle these things
since it is the approach both Spring, Guice, EJB 3 etc. etc. has
taken.
I use this all the time in java, because there is no other good option
for transactions in java. It's basically the best method. However I don't
believe this is the case in Scala, and I'd rather think through the options
and determine the best one.
The stuff I have written allow using AspectJ pointcuts as well.
E.g. f.e. apply transactions to all methods in the service layer:
match('* com.biz.service.*(..)')
Or to a specific method:
match('void Store.buy(Item)')
Point-cuts after-the fact seem a decent use of transactions. This is
under the following assumptions:
1) Your code will be used in more than one configuration type
2) Your transaction granularity is determined by the configuration of your
module, not by the module itself.
Regarding 2, I think all-to-often real world problems begin to break this
assumption, making internal business logic and external transaction
configuration dependent on each other.
But you could just use call-by-name:
transactional(TransactionType.Required) { // tx begin
.. // do stuff in TX
} // tx commit or rollback
But that pollutes the code, makes it harder to change, configure and
is not declarative.
Perhaps give the user options?
How is it not declarative? I agree that Aspects really do give you better
configuration abilities for code, however I'm not sure transactions are
ideally suited for AOP. I think Java is not ideally suited for
transactional code, so we use AOP.
I'd love to hear your response! This is something I've been mulling
through recently, and I'm still on the fence for Transactions should be
done using AOP on the JVM
-Josh
--
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: [Lift committers] Re: Meeting
I am firmly against anything that re-writes byte-code after the
compilation
phase for production code. Once the Scala-Maven plugin supports
compiler
plugins, then there's a lot of stuff that can be done at compile-time.
The scala-maven plugin already supports compiler plugins. Feel free to
make use of it as I do.
(yes this is unrelated).
BTW - Most cases where aspects would have been useful in Java, I'd rather
see some kind of DSL.
E.g. Transactions -
def doSomeWork() {
transactional {
//My Trasnactional code
}
//Wow, I can even do stuff outside the transaction look at me go
}
The one use of annotations I see as being handy is how it's used in the
Eclipse plugin (i.e. fix a flaw the JDT Community is unwilling to fix).
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
