[ovirt-devel] oVirt-specific aspect languages

[Vojtech Szocs]

----- Original Message -----
> From: "Arik Hadas" <ahadas at redhat.com>
> To: "Martin Sivak" <msivak at redhat.com>, "Vojtech Szocs" <vszocs at redhat.com>
> Cc: "devel" <devel at ovirt.org>
> Sent: Wednesday, April 13, 2016 10:58:46 PM
> Subject: Re: [ovirt-devel] oVirt-specific aspect languages
> 
> Hi,
> 
> Thanks for the feedback!
> I commented below.
> 
> ----- Original Message -----
> > Hi all,
> > 
> > I agree that it was an interesting article.
> > 
> > > However, since AspectJ is an extension to Java, most of oVirt
> > > developers would need to know additional programming language
> > > which puts the cost-effectiveness of this approach into question.
> > 
> > Actually you only need to learn some very basic stuff about pointcut
> > definition. The rest was pure Java for anything I ever needed (before,
> > after and around cases).
> > 
> 
> Well, it depends on both the base code and the crosscutting-concerns you
> develop the aspects for I guess.
> From my experience with AspectJ, the very basic stuff there typically fits
> only for very simple crosscutting concerns.
> For example, in the generated aspects for the languages I developed for the
> crosscutting concerns in oVirt I had to use more than the basic stuff (e.g.
> inter-type declarations).
> I'm curios, where did you use AspectJ? For how many and what kind of
> crosscutting concerns did you use it?
> 
> > DSLs are a nice thing to have, and we can start by utilizing object
> > builders more :) Those are a kind of DSL too if nicely written. See
> > the latest email on this list from Roman Mohr that talks about Domain
> > Object Builders (or Spring Security Java configuration [2] to see a
> > more complicated example of how it is used elsewhere).
> > 
> > Martin
> > 
> > [1] http://lists.ovirt.org/pipermail/devel/2016-April/012790.html
> > [2]
> > http://docs.spring.io/spring-security/site/docs/current/reference/html/jc.html
> > 
> > On Mon, Apr 11, 2016 at 4:13 PM, Vojtech Szocs <vszocs at redhat.com> wrote:
> > > Hi Arik,
> > >
> > > thanks for sharing this, the article is very interesting!
> > >
> > > "
> > > However, since AspectJ is an extension to Java, most of oVirt
> > > developers would need to know additional programming language
> > > which puts the cost-effectiveness of this approach into question.
> > > "
> > >
> > > I always thought that good Java developers should be familiar
> > > with AOP concepts anyway.
> 
> I think that many are familiar with the general AOP concepts but nevertheless
> decide not to adopt them.

I think it comes down to two factors - experience and willingness
to learn given technology. The fact that many people don't use AOP
doesn't imply that AOP isn't appropriate to solve their problems.

In previous company, I've used AOP with GWT to implement "command"
invocation bus between client and server. The client would create
an instance of a command like this:

  @ImplementedBy(DoSomethingWithLogic.class)
  class DoSomething implements Command<MyResult> {

    // fields to carry data go here
    // getters/setters go here

    public MyResult execute() { return null; }

  }

and send it to server for execution. During GWT deserialization
of "DoSomething" instance, an aspect would catch instantiation
of "DoSomething" and replace instantiated instance with this:

  class DoSomethingWithLogic extends DoSomething {

    public MyResult execute() {
      // logic that executes on the server
    }

  }

Many people thought of this as "hacky", I actually liked it :)

> Many think that AOP is useful only for simple logging and tracing or as a
> simplified API for byte-code manipulation (I guess that's why AspectJ is
> used by GWT in our build process, right?)

GWT compiler is written in Java. It parses your code into AST,
does "live" code analysis, and translates "live" code into JS.

When building oVirt GWT UI, we use AOP to trick GWT compiler
into thinking that all common code (shared between frontend
and backend) is "live", because otherwise it would prune
(cut-away) unused code and it would cause de-serialization
issues back on server.

That aspect can be found here:

  frontend/webadmin/modules/gwt-extension/
    src/main/java/org/ovirt/engine/ui/gwtextension/DontPrune.java

(The underlying problem is sharing code between frontend
and backend which couples both sides very tightly, a much
better approach is to have some API like REST in between
the two.)

> or in its simplified form as
> spring-aop, because of the known drawbacks of AspectJ.
> Hopefully the proposed approach would change that :)
> 
> > >
> > > That said, I really like the combo of AOP with DSL (or ASL)
> > > and I agree that it can simplify handling concerns in a way
> > > that is much closer to app's domain, rather than being closer
> > > to its implementation (as with AOP).
> > >
> > > Regards,
> > > Vojtech
> > >
> > >
> > > ----- Original Message -----
> > >> From: "Arik Hadas" <ahadas at redhat.com>
> > >> To: "devel" <devel at ovirt.org>
> > >> Sent: Monday, April 11, 2016 9:02:39 AM
> > >> Subject: [ovirt-devel] oVirt-specific aspect languages
> > >>
> > >> Hi All,
> > >>
> > >> Last month I participated in Modularity'16, an academic conference that
> > >> focuses on advanced software modularization techniques, where I
> > >> presented
> > >> my
> > >> work in the area of domain specific aspect languages that was evaluated
> > >> on
> > >> oVirt.
> > >>
> > >> Many have asked me to elaborate on this work, so I wrote a post that
> > >> explains
> > >> the idea and provides references to relevant materials that were
> > >> presented
> > >> in the conference, which I would like to share with you:
> > >> http://ahadas.github.io/oVirt-Specifc-Aspect-Languages/
> > >>
> > >> Regards,
> > >> Arik
> > >> _______________________________________________
> > >> Devel mailing list
> > >> Devel at ovirt.org
> > >> http://lists.ovirt.org/mailman/listinfo/devel
> > >>
> > > _______________________________________________
> > > Devel mailing list
> > > Devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/devel
> > 
>