Moving from AspectJ

[lucas26]

People, I am moving from aspectJ and I found two concerns about jboss-aop:

Some of my aspects work over "metaphors" that I define as Interfaces (very much like serializable interface).

I found that xml configuration does not support subclassing as patterns (right?). So I moves to use a ".*" pattern and filter throught InvocationFilterInterceptor interface.

1) The first problem I found is that a ".*" pattern does not work. The system can not found my Main class my invocation object (for testing purposes) filter the unwantend pointcuts.

2) The "public boolean intercepts(Invocation iv)" is never called, when I explicit do:

public boolean intercepts(Invocation iv) {
System.out.println( "it works?: "+iv);
return false;
}

my aspect continues to work. and notthing is dumped on screen.

===========================

By the way: I do preffer to use that way than have a specific filter for subclasses. That way is much more flexible.

===========================

And I like also to congratulate the developers behind this. It is far better than AspectJ.

[bill.burke]

> People, I am moving from aspectJ and I found two
> concerns about jboss-aop:
>
> Some of my aspects work over "metaphors" that I
> define as Interfaces (very much like serializable
> interface).
>

I've been meaning to add an "instanceof" attribute to pointcuts. Didn't have time to, sorry....

> I found that xml configuration does not support
> subclassing as patterns (right?). So I moves to use a
> ".*" pattern and filter throught
> InvocationFilterInterceptor interface.
>
> 1) The first problem I found is that a ".*" pattern
> does not work. The system can not found my Main class
> my invocation object (for testing purposes) filter
> the unwantend pointcuts.
>
> 2) The "public boolean intercepts(Invocation iv)" is
> never called, when I explicit do:
>
> public boolean intercepts(Invocation iv) {
> System.out.println( "it works?: "+iv);
> return false;
> }
>
> my aspect continues to work. and notthing is dumped
> on screen.
>

I removed this filter. It no longer exists.

> ===========================
>
> By the way: I do preffer to use that way than have a
> specific filter for subclasses. That way is much more
> flexible.
>
> ===========================
>
> And I like also to congratulate the developers behind
> this. It is far better than AspectJ.

What you can do is tag the classes you want to apply interceptors to in the following way.

<class-metadata group="yourtag" class="org.your.TheClass"/>

<interceptor-pointcut group="yourtag">

<interceptor....>
....

You can have an interceptor that is triggered by a metadata tag. This will be trigger by JSR-175 when it is available. See the AOP docs for more info.

Bill

[lucas26]

>
> You can have an interceptor that is triggered by a
> metadata tag. This will be trigger by JSR-175 when
> it is available. See the AOP docs for more info.
>

Yes, I already doing that way.

For example to tag objects that is unmodifiable. I.E. once constructed this objects never change. It was natural to me to tag with a interface (like the cloneable and serializable interfaces).

My point was: Metadata (as it is) resembles very much a deployment descriptor. And a "unmodifiable" its more a characteristics of the object than a deployment strategy like persistence.

Did you get my point?

But Looking in the JSR-175 proposal, it seems that the metadata will be embeded directly into the POJO which really solve the problem.

Thanx Bill

=========================

>
> I removed this filter. It no longer exists.
>

Supposing that this filter was working at load time it seems to me a very good idea. Why this filter was removed?

=========================

I see references to a effort to make aspects that work outside jboss. What is the view of the developers about that? is it a feature or it is a direction?

I think that aop probably will improve and/or aftewards replace the current ejb containers. How is the feeling of the developers of other jboss projects about that?

I feel that aop probably will improve and/or afterwards replace the current ejb containers. How is the feeling of the developers of other projects about that?

[bill.burke]

> >
> > You can have an interceptor that is triggered by a
> > metadata tag. This will be trigger by JSR-175
> when
> > it is available. See the AOP docs for more info.
> >
>
> Yes, I already doing that way.
>
> For example to tag objects that is unmodifiable. I.E.
> once constructed this objects never change. It was
> natural to me to tag with a interface (like the
> cloneable and serializable interfaces).
>
> My point was: Metadata (as it is) resembles very much
> a deployment descriptor. And a "unmodifiable" its
> more a characteristics of the object than a
> deployment strategy like persistence.
>
> Did you get my point?
>

Yes, you want immutable tags? I will implement instanceof when I get a chance.

> But Looking in the JSR-175 proposal, it seems that
> the metadata will be embeded directly into the POJO
> which really solve the problem.
>
> Thanx Bill
>

Yes, I can't wait for JSR-175. In the meantime, you can use the XDoclet integration to mimic it for now.

> =========================
>
> >
> > I removed this filter. It no longer exists.
> >
>
> Supposing that this filter was working at load time
> it seems to me a very good idea. Why this filter was
> removed?
>

Because you can easily implement it yourself within the interceptor.

> =========================
>
> I see references to a effort to make aspects that
> work outside jboss. What is the view of the
> developers about that? is it a feature or it is a
> direction?
>

Some things can work outside of the app server, some things can't.

> I think that aop probably will improve and/or
> aftewards replace the current ejb containers. How is
> the feeling of the developers of other jboss projects
> about that?
>

The general movement is towards POJOs. EJB 3 may move in this direction as well.

Bill