Documentation improvements are welcome.

I found this thread discussion on the topic:
https://community.jboss.org/thread/169869?tstart=0

Kabir Khan:
JBoss AOP is not part of AS 7. The main reason for having it in previous AS releases was for our EJB container, however in AS 7 a different mechanism is used. The AOP project has not been under active development for > 2 years, and getting it to work with the modular classloading setup in AS 7 will not be an easy task. So, there are no plans to include it in AS 7.

Customer Comment:
We have developed some AOP interceptor around jboss 4.2 & jboss 6  in our  application on the client as well as  server interceptor stack. Now if we want to move jboss 7 then then How do I migrate those interceptor to new AS 7?

Jaikiran's response:
The server side interceptor can be changed to a EJB3 spec interceptor instead of AOP. As for the client side interceptor, there won't be AOP style interceptor stack for AS7 so that's going to change.

Customer comment:
It seems that old aop libraries still work, the problem is that aopc'd classes are not properly deployed. To work around this you may try -Djboss.aop.path=<your aop config> to deploy them manually

Additional information can be found here: https://docspace.corp.redhat.com/docs/DOC-72063

JBoss AOP is not in JBoss EAP 6, previously JBoss AOP was utilized by such things as EJB's for client & server stacks
Impact:
Standard EJB3 configurations that were made previously in ejb3-interceptors-aop.xml, will now be done in the server configuration file (standalone.xml/domain.xml)
customers who were integrating customer AOP interceptors into the ejb layer will have to redesign their applications
There are EJB interceptors, but I do not think there is a way customers can define client side interceptors on the server side - previously this worked because the remote client would pull an EJB proxy object out of the remote server which would include the client side interceptors (I believe this was one of the things that made backwards compaitbility between EJBs with previous EAP version not possible)
Customers utilizing AOP in general for their applications will either need to utilize EJB Interceptors, CDI or get an AOP implemenation to use with their application
Community thread: https://community.jboss.org/thread/169869

I added a new topic 20278: 'Update Applications That Use JBoss AOP'
You can view it here:http://skynet.usersys.redhat.com:8080/pressgang-ccms-ui/#SearchResultsAndTopicView;query;topicIds=20278

However, I then discovered topic 10144 'Update Applications That Use EJB 2.x' contains information about JBoss AOP. Is that sufficient? You can view it here: 
https://access.redhat.com/site/documentation/en-US/JBoss_Enterprise_Application_Platform/6.1/html-single/Migration_Guide/index.html#sect-EJB_2.x_Changes

Please let me know if the information in the older topic is sufficient or if I should replace it with the new topic.

Shaun,

I don't really like the idea of leaving both in the doc. I proposed adding the new separate topic and adding a warning that using AOP is not supported. Can you take a look at the updated topic and let me know what you think?

http://skynet.usersys.redhat.com:8080/pressgang-ccms-ui/#SearchResultsAndTopicView;query;topicIds=20278

Thanks!

Reworded new topic 20278: 'Update Applications That Use JBoss AOP'
Removed the JBoss AOP text from topic 10144 ''Update Applications That Use JBoss AOP'. It doesn't make sense to add it twice.
Added topic 20278 to the CSP map for the Migration Guide.

Shaun, please let me know if the wording is OK in the above link. Thanks!

This fix is staged in the 6.2 docstage:

http://documentation-devel.engineering.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/6.2/html/Migration_Guide/sect-JBoss_AOP_Changes.html

I need to see if I can get it into the 6.1.1 docs also.

Looks OK to me.

This is staged on 6.1 also: 

http://documentation-devel.engineering.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/6.1/html/Migration_Guide/sect-JBoss_AOP_Changes.html

It seems fine to me.