We Keep Coding

What is meant by 'There is a type of Spring proxy that can replace the object being returned by the method'?

I am doing a mock exam where I didn't quite understand one of the answers which lacked an explanation of why it was correct.
(Edited from here downward by kriegaex, adding the question from the below comment and some formatting and rephrasing in order to make the text a bit more coherent and readable.)
Question: "Which below statement is true about Spring's proxy feature?"
Answer: "There is a type of Spring proxy that can replace the object being returned by the method."
I understand that Spring AOP can use two types of proxies:
JDK dynamic proxies
CGLIB proxies
In my understanding these are the two type of proxies that are heavily used in Spring. For example when using #Transactional or when creating aspects (#Aspect).
What I understand of the answer given is that they are pointing at the #Around aspect. However, I don't understand why they call it a "type of Spring proxy". Is an aspect a proxy? Thus, is my understanding of an aspect making use of the JDK or the CGLIB proxies incorrect?

The question would be easier to understand if you had provided all possible answers, also the incorrect ones. But given the correct one (which really does sound strange), I can tell you the following:
Both JDK and CGLIB proxies serve the same purpose: to wrap and replace the original objects in order to be able to register some interceptors to their method calls, be it via Spring AOP or other methods.
Yes, both proxy types are used heavily in Spring, JDK proxies for classes implementing interfaces, CGLIB proxies for classes not implementing any interfaces. Optionally, you can configure Spring to use CGLIB proxies also for interface types.
There is no such thing as an "#Around aspect", only an #Around advice type (beside other advice types like e.g. #Before and #After).
No, an aspect is not a proxy. But Spring AOP uses proxies in order to implement its way of doing AOP via delegation pattern, as opposed to AspectJ which does not use any proxies but uses direct bytecode instrumentation to achieve its goal.
Find more information in the Spring documentation.

Adding aspects to OSGi JAX-RS resources

I'm looking for a way to add certain functionality to JAX-RS resources in an OSGI environment. Annotations seem to be a clean way to do this and I've seen it done in the Spring framework (no experience). Annotations such as #Transactional, or (what I wanted to do, requires a permission flag to be set on a user) #Permission(CREATE). However, I'm a bit stuck on how to do this in an OSGI environment.
The normal way(is it?) to go about adding aspects would be to register an aspect service that wraps the original service. If I looked it up correctly, JAX-RS resources are tracked and hooked up to an HttpService. JAX-RS resources do not implement an interface and proxies would need to be dynamically created.
How would I dynamically generate OSGI aspect services/resources that effectively hide the original resource from the JAX-RS tracker that hooks it to the HttpService? I have zero experience with existing AOP frameworks and barely any knowledge of AOP itself.

It is very common in the Java EE and Spring world to use interceptors and define additional behavior based on annotations. There are some solutions in OSGi as well, there is an RFP to support EJB annotations.
However, I have a different opinion. Although this looks cool, it is also magical. See the "Why not annotations, interceptors and other magic?" chapter of this README file where I wrote down my reasons. This project implements the logic that you would like to achieve with #Transactional annotation, but it only uses functional interfaces.
I think it is better to think in lambda expressions to achieve the goal you want (see the java 8 example behind the link). If it is not Java 8, you can still use anonymous classes (see jave 7 and above example behind the link). Your code will look more ugly with anonymous classes, but it will be very clear, what your code does.
Others might not like my answer. Three years ago I was one of the biggest fan of annotation scanning, weaving and interceptors. After a couple of headaches, I became an enemy of this "magical" concept.

Annotating REST web service in Java EE 6

I am making a web service with Java EE 6. From what I understand you can annotate either the local interface with the #Path/#GET etc. annotations or the no-interface bean. I wonder if it is common to make two interfaces; one for the web services with the annotations and another one for the local interface? Or do you just add them on the local interface?

If I understand your question, your asking if you should define an interface just for specifying the annotations. I'm not sure what the advantages would be of doing this, unless you had a really complex project and foresee yourself replacing the Web service annotations with another library. This library would have to be on its virtual deathbed in terms of future support, or there would need to be clear evidence that our CTO would be changing technologies for me to consider this strategy.
For most projects, this seems to be somewhat of an overkill, especially if you already have an interface defined for your controller that you can add those annotations to. As a colleague on your project, I wouldn't want to have to check 3 different files for annotations for 1 class, unless there was a very compelling reason to do so.
With that said, if you wanted to add the annotations to your interface or your subclass, this is supported in this example. However, I think you would want to be sure to create a clear standard, either all your REST annotations are on the interface or all of your annotations are on the subclass. Mixing and matching them could get confusing for someone new to the project.
Without actually seeing your code and how complex it is, I can't tell you which method would be best for your project. The important thing is to balance consistency with flexibility. In summary, Java gives you plenty of rope, which equals flexibility, but you can also hang yourself with that rope if you're not careful. :)

Javassist. What is the main idea and where real use?

I know that Javassist is a Java library providing a means to manipulate the Java bytecode of an application.
Ok, but why we need manipulate bytecode?
Any real example?
Any real app, where javassist used?

A common application is to generate proxy classes at runtime, i.e. to create a subclass at runtime that intercepts all method invocations. Examples:
Hibernate uses Proxies to intercept method invocations on entities to implement lazy loading, i.e. fetching the object from the database when it is first accessed.
The Spring Framework uses Proxies to implement its AOP support, which among other things powers its support for declarative transactions. It also uses proxies to enforce proper scoping.
EJB uses proxies to implement container managed transactions, authorization checking, and to apply user-defined interceptors.
CDI implementations must also proxy the managed beans to ensure proper scoping. I suspect they use a byte code engineering library, too.
I recently used Javassist to implement a transparent cache for method return values, by intercepting all method invocations and only delegating to the super implementation on the first invocation.
Note that java.lang.reflect.Proxy can generate proxy classes at runtime, but can only implement interfaces, not extend a class. All of the above use cases require the proxying of classes.

Bytecode manipulation is useful and necessary, especially when you do not have source code for certain projects. Say you only have the bytecode (like a jar file) for some project, but you want somehow change the behavior of the code, the bytecode manipulation library can help in such cases. The advantage of bytecode manipulation is that you don't need to recompile your code and can directly execute it after manipulation.
I have used bytecode manipulation to do some program analysis. Given a library, I want to know during the runtime what methods in the library have been invoked. I can use bytecode manipulation to insert a System.out.println("method_name"); statement in the beginning of a method. So during the runtime, it will print out what methods have been invoked.
Some bytecode manipulation libraries are:
ASM
ByteBuddy
BCEL

To extend Meriton answer and to provide a real example of use :
Hibernate-core (5.2.8.Final) use javaassit (3.20.0-GA):
https://mvnrepository.com/artifact/org.hibernate/hibernate-core/5.2.8.Final

Users page of the ASM project lists several dozen widely used Java projects and frameworks using ASM for bytecode analysis and manipulation. http://asm.ow2.org/users.html

How is AOP being implemented to Change Java interface content?

I am current using Seasar2 Framework on a project that I am in. The framework is quite popular here in Japan but I am having problem in finding English documentations. Even on their official English translation site, they just discuss that the framework use Dependency Injection and AOP.
I was intrigued with the way they use it in one of their component S2Dao. Basically you only need to create interface DAO class and the framework automatically, changes the code on runtime and creates intermediate class that get called in the middle. Hence DB transactions codes are automatically added to the class. I was wondering, is there any step by step explanation on how this is done? Can java change code on runtime and change the method on runtime?
Are good reference on how this is done? I just want to know how the framework is doing this.

Yes, it is possible to do dynamic implementations of an interface at runtime, and to manipulate the compiled bytecode also.
Java provides a built-in mechanism to implement interfaces at run-time, called dynamic proxy classes.
There are also good libraries like cglib or javassist, that allow you not only to implement interfaces, but also to extend classes and to manipulate bytecode at run-time (to change the behavior of a method, for example). Frameworks like Spring and Hibernate use libraries like these to make their magic, so your framework may be using some of these also.
NOTE: If you are curious, these libraries can "tweak" the bytecode because instead of using the default ClassLoader of the JVM, they load your classes using their own ClassLoader, so they have total control of every single byte of the loaded class, and they can do whatever they want with them :).