[marc.fleury]

> > perform their functions. Perfect examples are
> > security and transactions.
>
> I didn't include that explicitly. Once JSR-175 is
> done
> it will be natural for AspectJ to support this
> through
> the thisJoinPoint object. Something like:
>
> thisJoinPoint.getSignature().getAnnotations()
>
> or something like that. I agree this will be very
> useful
> as a way of communicating information about specific
> member declarations to generic aspects.

yes, in fact logical configuration will be useful.

For example transactions uses the same interceptor java code (with the most trivial of pointcut definitions, the one attached to the method name as in EJB and dotnet, and YES it is AOP gregor ;). That configuration isn't static but each component has a different one, in fact each INSTANCE can have a different one (departure from dotnet) support in JBOSS.

That says that threads should really be attached to logical names "I am executing in the context of that application" and that the context contains the name of the app and that name points to a configuration.
That configuration is accessible through JMX so we can dynamically manage application configuration at runtime.

These are problems juha and adrian were looking at back in Palma last summer, they sketched the solution on the board (interceptors get all state from invocation object, front interceptors sets reference to mbean in invocation at top of stack).

The call we would use in TX is this

invocation.getValue("tx-attribute");

the call we would use in read-ahead is this

invocation.getValue("read-ahead"); and that can actually be overwritten from the client.

it does assume a detyped system underneath, like we have in JBoss and bill mimicks in POJOs to achieve this simple design of metadata specification/retrieval and update in our system.

> > This is one of the things I wanted to accomplish
> with
> > JBoss AOP xml configuration. A clean separation
> > from interceptor, pointcut, and metadata
> definitions
> > so that an advise can be typeless and be
> applicable
> > to any type of class, yet obtain class specific
> > metadata from a facility.

great.

> As described above, I think this should be a
> property
> of join points. That makes it nicely orthogonal
> with
> pointcuts and advice (whatever syntax you use for
> pointcuts and advice).

I don't know the lingo here. What exactly are join points?

[marc.fleury]

> > For me there are 2 types of aspects: typed ones,
> > detyped ones.
> >
> > Detyped ones are the system ones.
>
> What you are saying here is that many generic
> aspects are, roughly speaking, typed to Object.
>
> There's no doubt that's true. But note that:
>
> - that's still statically typed, for example the
> e code
> in question is sure it isn't going to get an
> an unboxed
> int
>
> - just because some aspects are that generic
> doesn't mean that all will be, especially down
> the road when you open this up to users

We are talking about the chain of responsibility GOF pattern with generic signatures so that you can dynamically weave them together. Think "invoke".

One other way to think about the lack of type is the fact that users don't need to be talking to the cache interceptor to get the benefit, nor to the transaction one. For system aspects it is very clear that the highest level of reuse are on purely orthogonal aspects with no type.

> - and if you don't get static typing in from the
> he start,
> your unlikely to be able to add it later as a
> compatible change

negative. Think security, think tx, they are truly orthogonal concerns, we have been doing this in jboss for ever now.

> aspect that is specific to a certain system, I get
> all
> the benefits of static typing that Java programmers
> are familiar with.

The benefits are not really needed at the system level (again I am not arguing typed interceptors as user level constructs aka composition aka multiple inheritance in java). One of the few cases I can think of clearly is the 'read-ahead' case.

Right now we configure that through a static xml file that configures the "persistence engine" when really itis a property of the call and GUI (how many rows do you want to display). There are 2 ways to do this

((ReadAhead) object).setReadAhead(10);

which assumes composition of the typed aspect on the end user object so that a dynamic typecast would result in that call being supported. Also this assumes XML configuration to enable proxy creation a la bill to have the "introduction" put there, man so much lingo to describe something really simple and visual.

BTW I think this would be a kick ass LANGUAGE feature that when you cast an object to a certain type, instead of saying "aaaaa I don't like it, classcast exception" the system makes a dynamic composition of that system aspect (if it is a system aspect that the user is requiring) and offer that dynamically... today once the 'introductions" are set in the class definition, they are set, only detyped ones can be weaved at runtime (e.g. cache interception) and that is a clear advantage of detyped system interceptors.

That language must support :dynamic typing.

[marc.fleury]

> you want to display). There are 2 ways to do this
>
> ((ReadAhead) object).setReadAhead(10);

silly me, I forgot the second way.

The second way says

((Advisable) object).setValue(INVOCATION_SCOPE, "read-ahead', 10);

so that the next call comes with this contextual information.

which is what bill is referring to when he says he wants to override the defaults at many logical levels.

[marc.fleury]

> I'm thinking a little bit more than JSR175. I want
> the framework to be able to either allow overrides at
> the Thread level or be able to provide defaults
> cluster-wide. To do this the framework would need to
> have some control over how metadata is resolved.
>
> Bill


yes ok, 2 points.

1- we need an mbean with the logical name and the configuration for it. All configuration at mbean level is by definition the default cluster/vm/logical name wide

2- a good example of thread based in the read-ahead discussion above, this one is triggered by a user. Remember all the talk about 'one thread logging' this would be mbean configuration that says 'next thead this configuration and you are done'.

[marc.fleury]

> After we thrash about on this thread for awhile, I'll
> start a new topic with a summarization of
> bulletpoints of this thread.

That is why I want the development blogs. So we can keep track of what is being discussed here and put some order in the thoughts. The forums discussion lose the 'historical' perspective as the posts go on top and you really don't know where to start. That thread of history will be the blog/journal. I don't like the current journal as it hides the information when you should start by reading the "summary" and then clicking on individual posts.

[marc.fleury]

> One concept I've been fooling around with in JBoss
> AOP is the concept of an Abstract Container. What if
> you wanted to define different sets of
> pointcuts/advices/whatever to the same Java class? A
> definition of an abstract container could provide
> this facility. I have implemented this in our
> framework:
>
> class="org.jboss.SomePOJO"/>
>
> <container-pointcut container="POJOJ2EE">
> <interceptor-ref "Transactions"/>
> <interceptor-ref "Security/>
> </container-pointcut>
>
> <container-metadata container="POJOJ2EE">
>
> <trans-attribute>RequiresNew</trans-attribute>
>
> </container-metadata>

Yes, logical specification of container is what we do with EJB and clearly something that will greatly simplify configuration. Remember that defaults and differential configuration (ala jboss 2.x) can be intuitive. We just have to be very careful with the naming of the xml files.

well done

[bill.burke]

> we are making a mountain out of a mole hill...
> specifying EJB is a pain? come on... we are purely in
> logical containers and the pointcut specification is
> well defined (with requirements of get/set). The
> price isn't high, in fact it is the requirement we
> enforce today (get/set) although bill has ways to do
> it at field interception.
>
> Bill says he can do it, so does Eli of georgia
> tech... but the instrumentation is a bit heavy at the
> classloader level with some dependency issues that we
> haven't looked at yet. It is the reason why I finally
> gave up on the field interception thread on this very
> forum.
>

Marc, we support field interception fully they only 2 drawbacks being, performance, and reflection bypasses field interception.

Bill

[marc.fleury]

Ok, understood. We could do it, mr moore helping.

It will come in a subsequent iteration.

The state of our framework is truly advanced because we stick to real life focused implementations of system aspects. The middleware framework is extremely clear, we own java object running on JBOSS.

See alex's work based on your stuff to instrument collections according to JDO spec, a nice applied work of what we are discussing here and a powerful example of what AOP rescue can do.

[juhalindfors]

> We are doing it with XML and the expressive power is
> already good.

XML is weakly typed. Sucks as far as programming goes.

> > Have a look at the current standardjboss.xml file.
>
> prove it :)

Have a look at the standardjboss.xml file. Should be pretty obvious.


> all we are talking about is xml stuff here, nothing
> revolutionary, not a new language (yet).

XML is weakly typed. That's why it sucks.

> If you are specifying pointcuts on methods then the
> doclet approach is best. Don't create a dependency
> on the name just generate the xml. The XML file may
> still be the easiest way to express the
> configuration. I view the XDoclet/dotnet approach as
> 'nice front end' to the xml file.

Oh please. It's a crutch. It's a preprocessor. Nothing else. Now ask yourself this: what is the difference between tying yourself to a preprocessor vs. declaring a new language? It's 2 compilation steps vs. 1 compilation step.


> > This is fine if the intended advices,
> introductions
> > and metadata can all be determined from the naming
> > conventions of a statically typed interface. But
> it
> > seems unlikely. So you still end up with part of
> the
> > contract located outside the Java language
> (assuming
> > no language extensions, JSR175) which naturally
> loses
> > any type safety from the programmers point of
> view.
>
> Specifying pointcuts on interfaces (already in JBOSS)
> or specifying pointcuts on POJO (also in JBOSS) isn't
> the question right? when you say "it seems unlikely
> we can express all we want" my question is "give me
> an example".

Show me an interface convention that allows me to specify all the introductions, advices and metadata on a typed Java interface without having to rely on a weakly-typed XML. That is what you need to do to get type-safety.


> we are making a mountain out of a mole hill...
> specifying EJB is a pain? come on...

Umm- yes. Why do you think everyone is using a preprocessor??


> Bill says he can do it, so does Eli of georgia
> tech...

It is not a question of whether you can do it or not. As I already pointed out THIS is the moot point.


> Everything can
> > be equally expressed with a "lower" level
> language.
> > Turing complete. No point in arguing that.
>
> you sound like a bulshit consultant :)

See above.

Later.

[bill.burke]

> > We are doing it with XML and the expressive power
> is
> > already good.
>
> XML is weakly typed. Sucks as far as programming
> goes.
>

XML allows you to componentize configuration rather than having a monolithic parser. With XML you can write an componentized pluggable extension, with a language you cannot.

Let's define where type-safety is needed rather than arguing whether a language or XML is better.

[juhalindfors]

> Let's define where type-safety is needed rather than
> arguing whether a language or XML is better.

Anything that allows me to declare a type in the "configuration", i.e. a fully qualified class name, whether its the interceptor class or part of a method signature (or something else). Make sure the class actually exists (there's no typo in the name), it can be instantiated (the declared or required constructor exists) and the class is of the expected type (it follows the expected assignment rules).

In addition, being able to import Java namespaces would be more than welcome.

[marc.fleury]

> XML is weakly typed. That's why it sucks.

the point I am making is that you don't need type to specify AOP'ed objects. Type-safety at compile time is need but moot here, there is no compile time. Type safety at assembly time, as you point out needs to rely on verifier like constructs (which you did in the past).


> Nothing else. Now ask yourself this: what is the
> difference between tying yourself to a preprocessor
> vs. declaring a new language? It's 2 compilation
> steps vs. 1 compilation step.

You are correct and I totally agree. C# is such a language with the feature built in, that attributes are part of the language. it has nothing to do with type, but everything to do with what the class can carry.

> Show me an interface convention that allows me to
> specify all the introductions, advices and metadata
> on a typed Java interface without having to rely on a
> weakly-typed XML. That is what you need to do to get
> type-safety.

sure but you don't need type safety to express AOP stuff so far.

[marc.fleury]

> Anything that allows me to declare a type in the
> "configuration", i.e. a fully qualified class name,
> whether its the interceptor class or part of a method
> signature (or something else). Make sure the class
> actually exists (there's no typo in the name), it can
> be instantiated (the declared or required constructor
> exists) and the class is of the expected type (it
> follows the expected assignment rules).

ok it is a valid point and you already made it in the beginning of the thread, that you use VERIFIERS to do this. You don't need a language and a compiler to do this, you need a verifier. You of all people have already written run-time versions of these for EJB.

> In addition, being able to import Java namespaces
> would be more than welcome.

please explain

[juhalindfors]

> > XML is weakly typed. That's why it sucks.
>
> the point I am making is that you don't need type to
> specify AOP'ed objects.

Sure I do. Assembling my introductions (when done statically in XML language and not at run-time) all need to be declared by type. And this automatically falls outside of Java's type system.

So you end up duplicating functionality that traditionally belongs into one compiler. You have to compile once with Java (with Java's type checking), deploy, then run the second compiler which does the type checking specific to the semantics you have declared in your XML language (and the additional bytecode generation).

So if you look at the process above, it becomes clear that what you are doing is mimicking the compilation of a new language. You can sit and say its only "Java + XML" but to me it's clear that the next logical step is to combine the split type checking into one, within a single type system. At which point using "two languages" (OO and declarative XML) doesn't make that much sense anymore.

That's my take on the "XML issue" Gregor mentioned in his original posting. It is not at all clear to me what advantages such split approach would give to the programmer yet the disadvantages are obvious (plus you end up building large blocks of code that would better fit into the "original" compiler just so that you can claim you didn't create a new language).


> Type-safety at compile time
> is need but moot here, there is no compile time.

Of course there is! The virtual machine doesn't execute Java source or XML natively. Whether you do all your compilation upfront or you have a second compilation step based on the XML language you declared is irrelevant. It needs to be compiled to run.

Consider the following example:

introduction X[A, B C] where A, B and C are the types I can type my object to. Now given I'm using these types as in your "read-ahead" example, I might code something such as

MyClass mc = new MyClass();
((A)mc).method();

Reconfiguring my introduction to X[B, C] will fail the above code at run-time (which can be two years later when I actually hit that particular path of execution).

Given that if we use a static declaration of introductions we know the specific set of types and could check at compile time the type (either the type of MyClass including its superclasses and interfaces or the types of introductions applied to it) and have a simple assignment rather than cast:

MyClass mc = new MyClass();
mc.method();

At which point the compiler would be able to warn me of the now non-existent method() that was part of A.

Since this cannot be done with a Java compiler (as it's unaware of the functionality you're specifying in the XML language) my choices are:
1) provide 100% test code coverage (which is impossible).
2) Do a search on my codebase and find all the faulty down casts (likely to fail as well).
3) Attempt to analyze the bytecode after the 2nd compilation step for illegal type casts.

> Type safety at assembly time, as you point out needs
> to rely on verifier like constructs (which you did
> in the past).

I wrote a verifier that checked a contract set by the EJB specification. In this case:
a) we don't have a spec
b) we're dealing with type checking rather than contract checking which is quite a different thing

> > Nothing else. Now ask yourself this: what is the
> > difference between tying yourself to a
> preprocessor
> > vs. declaring a new language? It's 2 compilation
> > steps vs. 1 compilation step.
>
> You are correct and I totally agree. C# is such a
> language with the feature built in, that attributes
> are part of the language. it has nothing to do with
> type, but everything to do with what the class can
> carry.

You're wrong. See above. Two languages, separate type systems. It has quite a bit to do with type (plus C# only carries metadata, we're talking about AOP).

> sure but you don't need type safety to express AOP
> stuff so far.

The point I've tried to get across twice is that: no, you don't need type safety to express AOP (this one is obvious) but yes as a programmer I want type safety in many cases (pointcuts, advices and introductions applied at run-time are another case (and we agree they're very much needed) but I would not want to give up type safety completely just to gain these).

[juhalindfors]

> ok it is a valid point and you already made it in the
> beginning of the thread, that you use VERIFIERS to do
> this.

This one could be achieved with a tool that does the checking. It is only one simple case however.

> You don't need a language and a compiler to do
> this, you need a verifier.

Compiler provides the static type checking. Whether you call the piece of code inside the compiler a verifier or not is not relevant.

> You of all people have
> already written run-time versions of these for EJB.

On a static non-changing spec that had only to concern itself with trivial cases of type checking (no checking in method bodies, only class and interface types).


> > In addition, being able to import Java namespaces
> > would be more than welcome.
>
> please explain

So I would not have to repeat the fully qualified class name all over the place, so rather than having

some.long.package.misstyped.SecurityInterceptor
some.long.package.misstyped.LogInterceptor

I can have:

some.long.package.misstyped.*

SecurityInterceptor
LogInterceptor