Request Handling by Spring

The client requests for a resource in the Web application. As seen in earlier section, the web container directs all MVC request to the Spring DispatcherServlet. The Spring Front controller will intercept the request and will find the appropriate handler based on the handler mapping (configured in Spring configuration files or annotation). In other words the handler mapping is used to map a request from the client to the handler. With the help of Handler Adapter, the Spring Front controller will dispatch the request to the handler.

In Windchill we use two handler mappings

• RequestMappingHandlerMapping, which maps handlers based on HTTP paths expressed through the RequestMapping annotation at the type or method level. This mapping is configured along with <mvc:annotation-driven /> entry in mvc.xml file.

• SimpleUrlHandlerMapping which maps from the URLs to request handler beans. Mappings are specified in the properties files at <Windchill>\codebase\config\mvc\

e.g /servlet/WizardServlet* = wizardController

Once the mapping is found, it will find the suitable handler adapter from the configured adapters. In Windchill we use three types of handler adapters

• RequestMappingHandlerAdapter which maps handler methods based on HTTP paths, HTTP methods and request parameters expressed through the RequestMapping annotation.

• SimpleControllerHandlerAdapter, an adapter to use the plain Controller (A type implemented by Controller interface or extended by AbstractController class)

In Windchill 11.1 M020, Spring Framework is upgraded to version 5.0.6. The non-annotation based controllers are replaced with separated-annotation based controllers.

In the upgraded version of Spring Framework, following guidelines must be observed:

• All Spring classes with @Controller annotation must have a URL-mapping with @RequestMapping in the same class. Selecting a controller with a SimpleUrlHandlerMapping or BeanNameUrlHandlerMapping and then narrowing the method based on @RequestMapping annotations is not supported.

• The @RequestMapping methods must be mapped uniquely in the new support classes. You cannot rely on method names as a fall-back mechanism to disambiguate between two @RequestMapping methods which do not have an explicit path mapping URL path but otherwise match equally, such as by HTTP method.

• A single default method must have an explicit path mapping. This method was earlier used for processing requests when no other controller match is found. In the new support classes, a 404–error is raised if a matching method is not found. You cannot have a single default method without an explicit path mapping.

They are beans that can handle a request. An OOTB handler has been provided to handle requests to build components - com.ptc.mvc.components.ComponentController. It prepares a ModelAndView (org.springframework.web.servlet.ModelAndView) which can be handled by the DispatcherServlet

To build a component, we need its description and the data to be presented. We have introduced the concept of builders, which will provide these artifacts. Component description will be represented via ComponentConfig and a ComponentConfigBuilder provides them. Component data will be represented via ComponentData and a ComponentDataBuilder provide them.

ComponentConfig and ComponentData together define the component information to be shown in the UI and will be represented by ComponentDefintion. It is the Model in MVC paradigm, where as the ComponentController is the Controller.

A typical MVC resource to build a component will be ptc1/<handler_key>/<componentId> where

ComponentController is injected with a ComponentBuilderResolver, which will find the respective builders for the given componentId.

Few notable internals of a ComponentController

• ComponentBuilderResolver, finds the ComponentConfigBuilder and ComponentDataBuilder for the componentId specified in the resource

• ComponentParamsFactory create ComponentParams from request and response that will be made available in the builders.

The builders provide ComponentConfig and ComponentData, from which the Model, ComponentDefinition is made. ModelAndView is populated with ComponentDefinition and the view information comes either from the ComponentConfig or from the defaultMapping provided.

The artifacts that are in green are Windchill Client Architecture (e.g JCA) specific ones. The black ones are the ones provided by the component owners.