<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
This newer patch added the getInt() and getString() methods per
suggestion of Jack.<br>
<br>
Please review.<br>
thanks,<br>
Christina<br>
<br>
<div class="moz-cite-prefix">On 06/02/2014 11:14 AM, Christina Fu
wrote:<br>
</div>
<blockquote cite="mid:538CBF23.6050205@redhat.com" type="cite">Jack,
<br>
<br>
Thanks for the review comments. Attached please find the new
patch that addressed your comments, both on-line and off-line.
<br>
<br>
Christina
<br>
<br>
On 05/30/2014 05:06 PM, John Magne wrote:
<br>
<blockquote type="cite">Couple of initial comments on this after
looking over it:
<br>
<br>
1.
<br>
<br>
<br>
Your TokenProfileParams class has this hash map.
<br>
<br>
private HashMap<String, Object> content = new
HashMap<String, Object>();
<br>
<br>
Then when we add items and get items from this thing, we have to
do some fancy
<br>
footwork to account for the fact that the "Object" part is
holding either a String
<br>
value or an int value.
<br>
<br>
My opinion after doing some research is that this is kind of
awkward.
<br>
<br>
A couple of possible solutions:
<br>
<br>
1. Have the HashMap hold <String,String>.
<br>
<br>
When we want an int we just convert back and forth from string.
<br>
This is done often when processing http name value pairs and
such.
<br>
<br>
2. Instead of relying upon the "get" method of the hash map
to return
<br>
encoded values, maybe have the parent object
"TokenProfileParams" have two
<br>
separate methods getString() and getInt(). Each one would take
the key name
<br>
and output the proper value, int or String
<br>
<br>
<br>
2. We have the following abstract base class:
<br>
<br>
public abstract class BaseTokenProfileResolver
<br>
<br>
<br>
The abstract class sounds like a good way to have some base
functionality to be used by derived classes.
<br>
I also believe that the idea is to declare some abstract methods
that forces derived classes to implement
<br>
these methods.
<br>
<br>
In this case it sounds like the following method would be a good
candidate for abstract:
<br>
<br>
public String getTokenType(TokenProfileParams pPram);
<br>
<br>
<br>
<br>
<br>
<br>
<br>
----- Original Message -----
<br>
<blockquote type="cite">From: "Christina Fu"
<a class="moz-txt-link-rfc2396E" href="mailto:cfu@redhat.com"><cfu@redhat.com></a>
<br>
To: <a class="moz-txt-link-abbreviated" href="mailto:pki-devel@redhat.com">pki-devel@redhat.com</a>
<br>
Sent: Friday, May 30, 2014 3:07:56 PM
<br>
Subject: [Pki-devel] [PATCH]
pki-cfu-0009-TPS-Token-Profile-Resolver-Plugin-Framework-Ticket-4.patch
<br>
<br>
This patch implements a Token Profile Resolver Plugin
Framework for
<br>
TPS. It allows a site to implement its own token profile
resolver.
<br>
<br>
The TokenProfileResolverManager initializes the token Resolver
plugin
<br>
framework from the following configuration files:
<br>
- <instance patch>/conf/registry.cfg
<br>
- <instance patch>/conf/CS.cfg
<br>
<br>
The existing mapping method "getTokenType" was extracted into
the
<br>
default plugin code: MappingTokenProfileResolver. All
resolver plugin
<br>
codes will extend from BaseTokenProfileResolver.
<br>
<br>
The most visible change from sites running previous versions
of TPS is
<br>
that the mapping related config params
<br>
e.g. op.format.mapping.xxx
<br>
have now being extracted into token resolver instance params
<br>
e.g. tokenProfileResolver.formatMappingResolver.mapping.xxxx
<br>
where "class_id" defines the plugin implementation name
defined in the
<br>
registry.cfg
<br>
and op.format.tokenProfileResolver points to the defined
resolver instance
<br>
e.g. op.format.tokenProfileResolver=formatMappingResolver
<br>
<br>
A separate ticket will be filed to provide actual plugin
writing
<br>
instruction as well as a sample plugin.
<br>
<br>
Finally, even though this patch does not directly address
<br>
<a class="moz-txt-link-freetext" href="https://fedorahosted.org/pki/ticket/447">https://fedorahosted.org/pki/ticket/447</a> RFE: Mapping tokens to
<br>
tokentype, where the request was to figure out the tokenType
(Token
<br>
profile) by uid instead of the current mapping method, it
provides the
<br>
means for one to write any customized plugins.
<br>
<br>
thanks,
<br>
Christina
<br>
<br>
_______________________________________________
<br>
Pki-devel mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Pki-devel@redhat.com">Pki-devel@redhat.com</a>
<br>
<a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/pki-devel">https://www.redhat.com/mailman/listinfo/pki-devel</a>
<br>
</blockquote>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Pki-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Pki-devel@redhat.com">Pki-devel@redhat.com</a>
<a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/pki-devel">https://www.redhat.com/mailman/listinfo/pki-devel</a></pre>
</blockquote>
<br>
</body>
</html>