Package org.modeshape.graph.request.processor

This portion of the ModeShape Graph API defines the processor for requests.

See:
Description

Class Summary

LoggingRequestProcessor	A RequestProcessor implementation that wraps another and that logs messages at the supplied level.
RequestProcessor	A component that is used to process and execute Requests.

Package org.modeshape.graph.request.processor Description

This portion of the ModeShape Graph API defines the processor for requests. Simple enough, it defines methods that handle the processing of each kind of request (for example, RequestProcessor.process(org.modeshape.graph.request.ReadNodeRequest)). Usually, an implementation will inherit default implementations for some of these methods, but will override others (or provide implementations for the abstract methods).

The design of the processor is to have a separate process(...) methods that take as their only parameter a particular kind of Request. Since the code to process each kind of request is likely to be different, this helps to separate all the different processing code.

The design also makes it possible to easily inherit or override process(...) implementations. In fact, the RequestProcessor abstract class provides a number of default implementations that are pretty good. Sure, the default implementations may not the fastest, but it allows you to implement the minimum number of methods and have a complete processor. And should you find that the performance is not good enough (which you'll verify by actually measuring performance, right?), then simply override the method in question with an implementation that is more efficient. In other words, start simple and add complexity only when needed.

This design has a great benefit, though: backward compability. Let's imagine that you're using a particular release of ModeShape, and have written a connector that uses your own RequestProcessor subclass. The next release of ModeShape might include additional request types and provide default implementations for the corresponding process(NewRequestType) method, and your RequestProcessor subclass (written against an earlier release) will automatically work with the next release. Plus, your connector will inherit the new functionality with zero effort on your part.