The request-handling architecture for an Assembler-driven JSP page looks like this:

In this diagram, the following happens:
The application server receives a request.
The application server passes the request to the Oracle Commerce Core Platform request handling pipeline.
The request handling pipeline does some preliminary work, such as setting up the profile and determining which Oracle Commerce Platform site the request is for. At the appropriate point, the pipeline invokes the
/atg/endeca/assembler/AssemblerPipelineServlet.The
AssemblerPipelineServletdetermines if the request is for a page or a content folder in Experience Manager and creates either aRedirectAwareContentIncludeobject (for a page) or aContentSlotConfigobject (for a content folder). Then,AssemblerPipelineServletcalls theinvokeAssembler()method on the/atg/endeca/assembler/AssemblerToolscomponent and passes it the request object it created.The
AssemblerToolscomponent invokes thecreateAssembler()method on the/atg/endeca/assembler/NucleusAssemblerFactorycomponent.The
NucleusAssemblerFactorycomponent returns anatg.endeca.assembler.NucleusAssemblerinstance.The
AssemblerToolscomponent invokes theassemble()method on theNucleusAssemblerinstance and passes it the request object. The handler for the request object (which may be theRedirectAwareContentIncludeHandlerorContentSlotConfigHandler, depending on the type of request object passed in) resolves a connection to the Workbench and/or the MDEX. For page requests, the handler also invokes a series of other components that transform the request URL into a URI that contains the path to the page in Experience Manager.The
NucleusAssemblerinstance assembles the content for the request URI. Content, in this case, corresponds to a hierarchical set of cartridges and their associated data. For each cartridge, the content starts with any default data that was specified in the Experience Manager cartridge configuration files when the cartridge was added to the page. That data is further modified and augmented with any data stored in the Oracle Commerce Configuration Repository (that is, changes made and saved via the Experience Manager UI).Next, the
NucleusAssemblerinstance calls theNucleusAssembler.getCartridgehandler()method, passing in the cartridge’sContentItemtype, to retrieve the correct handler for the cartridge. The handler gets resolved and executed and the results are stored in the cartridge’s associatedContentItem. This process happens recursively so that the assembled content takes the form of a responseContentItemthat consists of a rootContentItemwhich may have sub-ContentItemobjects as attributes.Note: If a cartridge handler does not exist for a
ContentItem, the initial version of the item, created in step 8, is returned.The
NucleusAssemblerinstance returns the rootContentItemto theAssemblerToolscomponent.The
AssemblerToolscomponent returns the rootContentItemtoAssemblerPipelineServlet.The
AssemblerPipelineServletcomponent calls the/atg/endeca/assembler/cartridge/renderer/ContentItemToRendererPathcomponent to get the path to the renderer (in this case, a JSP file) for the rootContentItem. TheContentItemToRendererPathcomponent uses pattern matching to match theContentItemtype to a JSP file; for example, in Commerce Reference Store, if theContentItemtype isBreadcrumbs, the JSP file is/cartridges/Breadcrumbs/Breadcrumbs.jsp.Note: See ContentItemToRendererPath for more details on how the renderer path is calculated.
The
AssemblerPipelineServletcomponent sets the assembledContentItemas acontentItemparameter on theHttpServletRequest, then forwards the request to the JSP determined by theContentItemToRendererPathcomponentDue to the nested nature of
ContentItems, the JSP for the rootContentItemmay have to render sub-ContentItems, and those sub-ContentItemsmay have their own sub-ContentItemsas well. As such, each JSP renderer, from the root on down, must includedsp:renderContentItemtags for its immediate sub-ContentItems. This configuration creates a recursive scenario that allows all sub-ContentItemsto be rendered.The
dsp:renderContentItemtag invokes theContentItemToRendererPathcomponent to retrieve the JSP renderer for the current sub-ContentItem. The retrieved JSP is then included in the rendered page.The
dsp:renderContentItemtag also sets thecontentItemattribute on theHttpServletRequest, thereby making each sub-ContentItemavailable to its renderer; however, this value lasts only for the duration of theincludeso that after theincludeis done, thecontentItemattribute’s value returns to the rootContentItem.The JSPs returned by the
ContentItemToRendererPathcomponent are included in the response.The response is returned to the browser.

