org.springframework.roo.classpath.scanner

Interface MemberDetailsScanner

All Known Implementing Classes:

MemberDetailsScannerImpl

public interface MemberDetailsScanner

Service that automatically builds a MemberDetails instance for a given class or interface type.

Because Spring Roo encourages the use of multiple compilation units (ie AspectJ ITDs) in the creation of a single type, it is relatively complex to build a complete representation of the type. This is especially complex if a representation is desired in the middle of creating an ItdTypeDetailsProvidingMetadataItem for that same type (as the "rest" of the type information is often needed to produce the new ITD-based metadata, plus there are frequently infinite loops to avoid).

A MemberDetailsScanner is therefore the recommended way for add-ons to build representations of Java types. There are several reasons:

• The discovery and collation of multiple compilation units is delegated to a specialized, well-defined service (MemberDetailsScanner)
• A MemberDetailsDecorator facility permits customization of the visible member information on a per-caller basis, thus offering a way to customize the information seen by a given caller
• MemberDetailsDecorators can use the CustomDataAccessor facility to associate custom information with members and compilation units in an easy manne.

Since:

1.1

Author:

Ben Alex

Method Summary

Modifier and Type	Method and Description
MemberDetails	getMemberDetails(String requestingClass, ClassOrInterfaceTypeDetails cid) Builds MemberDetails instance for the given ClassOrInterfaceTypeDetails.

Method Detail

getMemberDetails

MemberDetails getMemberDetails(String requestingClass,
                               ClassOrInterfaceTypeDetails cid)

Builds MemberDetails instance for the given ClassOrInterfaceTypeDetails. In particular, this includes all ITD members that can be acquired at this time. It also includes all members in the standard Java source class hierarchy (as per ClassOrInterfaceTypeDetails.getSuperclass()).

No attempt is made at visibility resolution due to inheritance or aspect overriding, although we may add this in the future (it is difficult to add definitively given the detected members may be incomplete due to infinite loop avoidance).

An implementation will pass the resulting MemberDetails through any detected MemberDetailsDecorator instances so they can potentially replace the result with a new instance that is ultimately returned. It is required that implementations invoke decorators in the alphabetic order of each decorator's fully qualified class name. Only when every MemberDetailsDecorator returns the same MemberDetails as it was passed will processing be regarded as complete. This manages any issues with respect to the order in which MemberDetailsDecorators are invoked.

The requesting class is presented as a String as per normal OSGi conventions. This avoids issues that may occur if a Class was used and the bundle owning that class was being deactivated. A JavaType was not used because of its comparatively heavier weight and is primarily used to represent user project-specific types (not internal types).

Parameters:

requestingClass - the fully-qualified class name requesting the member details (required; may be used for result customization)

cid - the class or interface for which to build member information (can be null)

Returns:

the discovered member details, or null if null ClassOrInterfaceTypeDetails were given