Adapter Controller

To initiate a delivery, you can embed a reference to AdapterController within a link. In the case below, we use the taglib to iterate over all the bundles in the repository, displaying the bundle name.

<table>
 <provisioning:bundle-descriptor allVersions = "false" allVariants = "false">
  <tr>
   <td>
    <a href = "AdapterController?bundleId=
      <%=((BundleDescriptor) pageContext.getAttribute("descriptor")).getBundleID()%>">
     <provisioning:display-name locale = ""/>
    </a>
   </td>
  </tr>
 </provisioning:bundle-descriptor>
</table>
            

When the user selects the bundle by clicking the link (1), the AdapterControllerServlet gets the ServletContext(2) and retrieves the ProvisioningContext by invoking ProvisioningContext.getAttribute("javax.provisioning.ProvisioningContext") (3). Using the bundleId from the hyperlink, the AdapterControllerServlet invokes ProvisioningContext.getBundleRepository().getBundleByID(bundleId). The BundleRepository returns the BundleDescriptor associated with the bundleId (4, 5). At this point, we could invoke BundleDescriptor.getDescriptorFile or BundleDescriptor.getContentFile to get a reference to the underlying content, but that wouldn't help us in knowing how to deliver to the client. For instance for a MIDP delivery, we still need to write the JAR location in the MIDlet-Jar-URL, so that it points to our provisioning server.

Next, the AdapterControllerServlet invokes ProvisioningContext.createFulfillmentTask to get a FulfillmentTask for this delivery interaction (6, 7). In using a JSR-124 implementation, you should become familiar with FufillmentTask because it contains a wealth of information, including a reference to the BundleDescriptor, the name of the Adapter that you will use for the delivery, and the DeliveryURI that the client should go to fulfill its request for content.

The AdapterControllerServlet invokes FulfillmentTask.getDeliveryURI to get the delivery URI needed to fulfill this request (8). A typical delivery URI looks like:

http://localhost:8080/provisioning/adapter/generic?fid=83f2976b-e0d5-4076-bd57-2cf0d8ab8613
            

The URI is constructed from 1) the CONTENT_DELIVERY_URI parameter (http://localhost:8080/provisioning) in the web.xml file; 2) the baseURI in the adapters.xml file; and 3) the fulfillment id associated with this delivery interaction. There is one exception to the rule. If the provisioning.xml file that was in the original PAR file contained an absolute reference to the content (http://somedomain.com/games.jar), rather than a relative reference in the jar (/games.jar), then the delivery URI will be the original absolute reference.

The final job of the AdapterControllerServlet is to redirect the client to delivery URL. If the URI points to our provisioning server, then it goes to the appropriate adapter, with a fulfillmentId (fid) in the query, otherwise the request will go to an external (possibly non JSR-124) server, which is responsible for handling the request. One note of caution. If you are testing JVending with the test.par from Sun's reference implementation, the Spruce GO link is an absolute reference to the spruce site,' which then does another redirect to an Adult site. This has nothing to do with the JVending provisioning server and I have contacted the JSR-124 committee about getting the reference removed from the PAR. In the mean time, I will be releasing, probably in alpha4, a nifty example of using StockingPolicy instances and filters to block such content before it is even stocked.