[Pki-devel] [PATCH] 60 Added user REST service.

Endi Sukma Dewata edewata at redhat.com
Thu May 31 18:29:11 UTC 2012


On 5/31/2012 10:20 AM, Ade Lee wrote:
> We appear to have come full circle.  When I originally created the first
> drm servlets, I put them under their own package separate from the old
> "servlets" because they did not follow the servlet lifecycle - other
> than going through the RESTEasy servlets.  Based on review discussions,
> we decided then to move them to be integrated with the existing code
> structure.
>
> We need to rethink how all of this is packaged, keeping in mind some
> sort of continuity between the old and new interfaces so that it is easy
> to maintain.
>
> So, lets go ahead and check in for now, and then rearrange as makes
> sense once we have carefully considered the packaging.

OK, pushed to master.

>>> 4. The getUserMessage() functions are perhaps not needed.  If anything,
>>> they should be written as a single vargs method.
>>
>> Changed to use varargs. This method is used to simplify the code, compare:
>> - old: CMS.getUserMessage(getLocale(), "CMS_ADMIN_SRVLT_NULL_RS_ID")
>> - new: getUserMessage("CMS_ADMIN_SRVLT_NULL_RS_ID")
>>
>>> But a better way to do
>>> this would be to specify locale the local as a protected variable in
>>> CMSResourceService.java.  Then getLocale() would return this variable if
>>> it is non-null, or would find it from the headers.
>>
>> You mean caching the value returned by getLocale()? That can be done,
>> but the "locale" variable will be null until we call getLocale() at
>> least once.
>>
>>> Then you can call the regular CMS.getUserMessage(locale, ....) without
>>> the getUserMessage() calls.
>>
>> For this to work we'd have to set the "locale" first, so we need to call
>> getLocale() somewhere. I'm not sure if calling it in the
>> CMSResourceService constructor will work because the "headers" is
>> injected, which I suppose can only happen after the object is
>> constructed. We can call it in the beginning of each REST method, but
>> that's not pretty. So for now I'm keeping the getUserMessage().
>>
> The problem with getUserMessage() is that you cannot call it from a
> non-RESTful servlet context.  That is, you cannot call it from the old
> non-RESTful servlets.  This is not important when you have implemented
> code that is completely independent of the old code (as in the case of
> the Users and Groups), but becomes a problem when you try to create
> modules that can be used by both the old and servlets.
>
> Maintaining two completely independent structures of code for the old
> servlets and the new ones will quickly become a maintenance nightmare.
> And the old servlets will stay around for a long time.
>
> Here is how I have been approaching this problem with regards to
> certificate issuance.
> 1. Create a class which contains the business logic of the process.  In
> my case, I called it ProfileProcessor.  The relevant servlet config and
> things like the locale are passed into the constructor of this object.
> 2. The object makes use of an Auditor, and maybe other classes like an
> Authenticator/ Authorizer.  Ultimately, the Authenticator/Authorizer
> code will be moved into the Realm.
> 3.  This class is instantiated by both the RESTful services and the old
> non-RESTful services.  In both cases, we need to construct the
> ProfileProcessor, call the relevant function(s) and parse the results in
> the appropriate way.
>
> So, while I'm all for getMessage() functions, they need to be done in a
> way that can be called from a common class like the ProfileProcessor.
> Right now, you have them in a place where only the RESTful servlets can
> invoke them.  Maybe, like in the case of the Auditor, we need a Logger
> or Utility class which takes the Locale on instantiation, and provides
> getMessage() calls.

As discussed over IRC, the getUserMessage() is a convenience method 
which is specific to REST services similar to log() and audit() which we 
have specific implementations for CMSServlet and AdminServlet too. 
Common code such as UGSubsystem or the new ProfileProcessor should not 
rely on these methods. A better solution would be to use a different 
logger service that allows customization (ticket #195).

-- 
Endi S. Dewata




More information about the Pki-devel mailing list