[Pki-devel] skeleton code for drm restful interface

Adam Young ayoung at redhat.com
Tue Dec 13 23:07:50 UTC 2011


On 12/13/2011 04:55 PM, Ade Lee wrote:
> Attached is some skeleton code for the new DRM interface.  To build, you
> will need to download and install the candlepin-deps rpm.
> (http://repos.fedorapeople.org/repos/candlepin/candlepin/)
>
> We will use these rpms to build/run until we get the resteasy packages
> into Fedora.
>
> The new classes provide the following:
> 1. interface to list/get/submit key requests (for archival and
> recovery).
> 2. interface to recover keys
> 3. interface to approve/reject key recovery requests.
> 4. input/output via XML/JSON/browser.
>
> This is pretty much just a skeleton as not all the functionality is
> currently in the DRM.  There is also no authentication/authz as Jack has
> yet to work that part out.  But it does look pretty much like what the
> restful interface will probably look like - and the comments point  out
> the parts that are missing.
>
> Jack - please look to see how your new code would interact with this -
> and also in terms of the input/output parameters/structures.
>
> Endi, Adam: please look to see if the structure/ coding makes sense - or
> if it can be improved.  Its not at all final - but all feedback will
> help.

I'd forgotten how annoying I find the Bean API.

You catch too many exceptions.  Let them propagate as far as you can.  
You should not be cathing them and then rethrowing them.  Either catch 
them and be done with them, or let them bubble up to the top level.

I understand the reason for splitting the DAO off from the servlet,  but 
I feel that here the division is too arbitrary.  The Resource  doesn't 
do any work,  and the fact that these are all methods of the same 
objects although they do the same thing seems arbitrary.  I realize you 
are following the examples  given in the documentation.  I think that 
the Repository already playts the role of the DAO,  and putting an 
additionaly layer in here provides no additional insulation against 
leaky abstractions....


I also really don't like the split between KeyData and KeyDataInfo.  It 
seems unnecessary.


Let the complexity emerge.  Write the code in a more inline fashion,  
and only refactor out once you have a sense of what the real structure 
is going to be.  I'll try to send you back my version of the patch 
tomorrow:  I'm about to lose Laptop battery right now.


>
> To test, you can do the following:
> 1. Build the code.  You will need to replace pki-common and pki-kra.
> 2. pkicreate and configure a DRM.  The needed changes to web.xml should
> be in the new instance.
> 3. Add links to the following jars in webapps/lib/.  They should all be
> in /usr/share/candlepin/lib
> -->  javassist, jaxrs-api, jettison, resteasy-jaxb-provider,
> resteasy-jaxrs, resteasy-jettison-provider, scannotation
> 4. Archive some keys by doing enrollments with your CA or TPS.
>
> You could also set up the DRM instance to be controlled by eclipse in
> the same way that we do for the CA instance.  If you do this, you will
> be able to step through the code with the debugger.
>
> You should be able to see archived enrollments/ recoveries by going to :
> https://hostname:port/kra/pki/keyrequests
> https://hostname:port/kra/pki/keyrequest/1
>
> using a browser, or using curl to get xml or json.
>
> Ade
>
>
>
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20111213/a49eefed/attachment.htm>


More information about the Pki-devel mailing list