WebSphere Portal 6.0.1 introduced a capability called the URI resolution service or POC servlet or the Resolver Framework depending on where you see it mentioned. The DeveloperWorks article called Accessing portal content with custom URLs is the most recent and informative post I have found describing this service.
This service was created to allow non-portal sites in your organization to link to your portal content (the acronym POC means Piece of Content). The service works by using the scheme portion of the URI to divert the request to a collection of handlers that use the chain of responsibility pattern to modify a Resolved object which ultimately communicates parameters to portal objects.
Some examples of where this concept is used include:
- The JSR 286 Web Content Viewer uses POC URIs (prefixed with wcm:). The WCM web content pages work by selecting which page best fits the current content request.
- The PageBuilder2 themes use this to implement dynamic content spots and many other items.
- The Lotus Connections Portlets for WebSphere Portal also use POC URIs.
- The iWidget/Mashup API concepts use this mechanism. In fact, all portlets in WPS 7.0 are wrapped with an iWidget interface via the PageBuilder2 theme.
- The WebDAV mechanism uses POC URIs for resolving resource requests.
This service can also be used for a few use cases you may not expect:
- You can create a dynamic web content pages implementation that improves on web content pages (which still require you to create individual portal pages that are configured to certain Site Areas or content folders).
- You can implement an inter-portlet communication process to replace wires (which require you to create a wire definition through portal administration).
I am going to explore these concepts in more detail in future posts.
Finding Practical Code Samples
You can find examples of resolvers by searching for the plugin.xml files that register them. This unix example would give you a list of EAR files in your installedApps directory:
find . -name plugin.xml -exec grep -q 'locationServiceHandler' {} \; -print
Notice the technique above doesn’t find resolvers that are contained in unexploded JAR files. The ${PortalServer}/base directory contains many jars that include plugin.xml files that register resolver implementations.
The following dump of the uriSchemeMap field of the ContentOperationsRegistryHomeImpl$RegistryBean shows that there are 59 of these resolvers in the WPS 7.0 server:
ll=[com.ibm.portal.resolver.model.language], lm=[com.ibm.portal.resolver.model.layout], tx=[com.ibm.portal.resolver.model.tx], pacdump=[wp.ac.pacdump], message=[com.ibm.wps.mmi.message], http=[com.ibm.wps.resolver.proxy.http], virtual=[virtual], mashupjs=[com.ibm.wps.mmi.js], state=[com.ibm.portal.resolver.state], catalog=[com.ibm.wps.mmi.catalog], wsrp=[com.ibm.wps.resolver.wsrp.rest, com.ibm.portal.resolver.wsrp.wsdl], skinlist=[com.ibm.wps.resolver.webdav.admin.sl], res=[com.ibm.portal.resolver.res], wp.operations=[com.ibm.wps.resolver.operations], prototype=[com.premierinc.prototype.Resolver], spa=[com.ibm.wps.spa.data], ai=[com.ibm.wps.ai.rest], model=[com.ibm.portal.resolver.model], data=[com.ibm.portal.resolver.data], resourcefeed=[com.ibm.portal.resolver.model.mint.resource], contentmapping=[com.ibm.wps.contentmapping.rest], wcmbw=[com.ibm.wps.wcm.blog.json], fs-type1=[com.ibm.wps.resolver.webdav.filestore.mi], trash=[com.ibm.portal.resolver.model.trash], rm=[com.ibm.portal.cp.resource], mashuptl=[com.ibm.wps.mmi.mashup_tl], fd=[com.ibm.wps.federation.lookup], nm=[com.ibm.wps.mmi.navigation, com.ibm.portal.resolver.model.navigation], bc=[com.ibm.portal.resolver.cai.bc], config=[com.ibm.wps.resolver.config], media-link=[com.ibm.portal.resolver.model.mint.media-link], mashup=[com.ibm.wps.resolver.mashup], cpum=[com.ibm.portal.cp.user], dialog=[wp.dialog], cai=[com.ibm.portal.resolver.cai], com.ibm.content.operations.registry.api=[com.ibm.content.operations.registry.api], fragment=[com.ibm.wps.resolver.aggregation], wm=[com.ibm.portal.resolver.model.wire], tos=[com.ibm.portal.cp.tagging.opensearch], sl=[com.ibm.portal.resolver.model.skin], addtostlist=[addtostlist.resolver], redirect=[com.ibm.portal.resolver.redirect], ca=[com.ibm.portal.resolver.cai], themeGraphic=[com.ibm.wps.theme.resolver.graphic], op=[com.ibm.wps.resolver.operation], com.ibm.wps.logging.resolver.requestresponselogger=[com.ibm.wps.resolver.impl.logging], personrecord=[personrecord.resolver], deploy=[com.ibm.wps.mmi.deploy], cl=[com.ibm.portal.resolver.model.client], cm=[com.ibm.portal.resolver.model.content], rtm=[com.ibm.portal.cp.rating], mashupai=[com.ibm.wps.mmi.mashupai], iwidget=[com.ibm.portal.resolver.iwidget], com.ibm.portal.friendly.name=[com.ibm.wps.resolver.friendly], distmap=[com.ibm.wps.resolver.xml.cache], tl=[com.ibm.portal.resolver.model.theme], tm=[com.ibm.portal.cp.tagging], portlet=[com.ibm.portal.resolver.portlet], skin=[com.ibm.wps.skin.rendering],
Hi I found a problem on receiving params from url.
I have two websphere portal servers, first contains portlets itself, second contains a reomte reference to portlets of the first one.
URI resolver works perfect resolving URIs, but params(declared and tested on my local machine previously) are recieving null.
Any idea, I’m driving crazy, thanks
I enjoy reading through an article that can
make people think. Also, thanks for allowing
for me to comment!
Hi ,
I also have one problem , I am using portal 8 and found that navigation is breaking when params are not encoded and decoded. Like white space is not encded to %20 and then %2520 issue.