org.springframework.roo.classpath.scanner
Class MemberDetailsScannerImpl
java.lang.Object
org.springframework.roo.classpath.scanner.MemberDetailsScannerImpl
- All Implemented Interfaces:
- MemberDetailsScanner
@Service
public class MemberDetailsScannerImpl
- extends Object
- implements MemberDetailsScanner
Default implementation of MemberDetailsScanner.
Automatically detects all MemberDetailsDecorator instances in the
OSGi container and will delegate to them during execution of the
getMemberDetails(String, ClassOrInterfaceTypeDetails) method.
While internally this implementation will visit MetadataProviders and
MemberDetailsDecorators in the order of their type name, it is
essential an add-on developer does not rely on this behaviour. Correct use of
the metadata infrastructure does not require special type naming approaches
to be employed. The ordering behaviour exists solely to simplify debugging
for add-on developers and log comparison between invocations.
- Since:
- 1.1
- Author:
- Ben Alex
| Methods inherited from class java.lang.Object |
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
LOGGER
protected static final Logger LOGGER
metadataService
protected org.springframework.roo.metadata.MetadataService metadataService
MemberDetailsScannerImpl
public MemberDetailsScannerImpl()
activate
protected void activate(org.osgi.service.component.ComponentContext context)
bindDecorators
protected void bindDecorators()
bindProviders
protected void bindProviders()
deactivate
protected void deactivate(org.osgi.service.component.ComponentContext componentContext)
getMemberDetails
public final MemberDetails getMemberDetails(String requestingClass,
ClassOrInterfaceTypeDetails cid)
- Description copied from interface:
MemberDetailsScanner
- 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).
- Specified by:
getMemberDetails in interface MemberDetailsScanner
- 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
getMetadataService
public org.springframework.roo.metadata.MetadataService getMetadataService()
Copyright © 2009–2015. All rights reserved.