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.