Looks fine to me.
Thanks,
Xuelei
On 6/15/2012 3:59 PM, Weijun Wang wrote:
> Webrev updated:
>
>http://cr.openjdk.java.net/~weijun/6966259/webrev.01/
>
> Changes made:
>
> test/sun/security/krb5/name/Constructors.java
> src/share/classes/sun/security/krb5/RealmException.java
> src/share/cla
Webrev updated:
http://cr.openjdk.java.net/~weijun/6966259/webrev.01/
Changes made:
test/sun/security/krb5/name/Constructors.java
src/share/classes/sun/security/krb5/RealmException.java
src/share/classes/sun/security/krb5/Realm.java
src/share/classes/sun/security/krb5/PrincipalName.java
src/
3. Realm.java
63 } catch (KrbException ke) {
64 RealmException re = new RealmException(ke.getMessage());
65 re.initCause(ke);
66 throw re;
67 }
I think you make a lot cleanup to exception thrown with just one call,
like the one in KerberosPrincipal.java:
-IOException
On 6/15/2012 12:19 PM, Weijun Wang wrote:
>
>
> On 06/15/2012 10:28 AM, Xuelei Fan wrote:
>> Looks fine to me. Just some minor comments.
>>
>> 1. PrincipalName.java
>> need to make it more clear that PrincipalName is not only for the name
>> of a principal, but also include the realm.
>>
>> - 48
On 06/15/2012 10:28 AM, Xuelei Fan wrote:
Looks fine to me. Just some minor comments.
1. PrincipalName.java
need to make it more clear that PrincipalName is not only for the name
of a principal, but also include the realm.
- 48 * This class encapsulates a Kerberos principal.
+ 48 * This cla
Looks fine to me. Just some minor comments.
1. PrincipalName.java
need to make it more clear that PrincipalName is not only for the name
of a principal, but also include the realm.
- 48 * This class encapsulates a Kerberos principal.
+ 48 * This class encapsulates a Kerberos principal,
+ *
On 6/14/2012 5:55 PM, Weijun Wang wrote:
>> I can accept your current design if you won't like to make more changes.
>> I may be able to complete the review tomorrow.
>
> Please go on. I think we agree on the basic idea that name and realm
> should be bound in a single class. The only disagreement
On 06/14/2012 05:26 PM, Xuelei Fan wrote:
It's really confusing to mix the name of a principal and realm of a
principal in the same PrincipalName class.
For example, when printing a debug log for "sname", from the name of
"sname", I think it a name of the principal, but the output also include
It's really confusing to mix the name of a principal and realm of a
principal in the same PrincipalName class.
For example, when printing a debug log for "sname", from the name of
"sname", I think it a name of the principal, but the output also include
the realm of the principal.
When I read the
On 06/12/2012 10:23 PM, Xuelei Fan wrote:
I have not reviewed too much about the fix. But before looking more
updates, I was wondering whether it is good to have PrincipalName to be
paired with Realm in the PrincipalName class.
In RFC4120, realm names and principal names are two different name
c
I have not reviewed too much about the fix. But before looking more
updates, I was wondering whether it is good to have PrincipalName to be
paired with Realm in the PrincipalName class.
In RFC4120, realm names and principal names are two different name
constraints for different purpose. The Princi
Hi Valerie
Here is the webrev:
http://cr.openjdk.java.net/~weijun/6966259/webrev.00/
The patch is quite long, but most of the real changes are in a few classes:
PrincipalName.java:
. All fields are final and non-null non-empty now
. All constructors have a realm argument, including those fr
Max,
Yes, I think the current model that you described sounds error prone. I
don't know the history of the current design.
But I do also prefer the described changes that you have.
I'd expect the refactoring would make the code clearer and more robust.
Valerie
On 06/06/12 17:55, Weijun Wang w
Always just used the API, which takes care of it. Anyway, this looks like as
authoritative a description as any. In particular, it says the first string is
the realm, which matches my intuition of what should be there, since it's the
same ordering as in the DER representation.
http://www.gnu.
On 06/08/2012 02:09 PM, Henry B. Hotz wrote:
Thanks for checking. I was remembering some early discussion of possibilities
that obviously didn't make it to the final version.
I'm also wrestling with an oddball application that stores some data in the
ccache with a principal name without a r
Thanks for checking. I was remembering some early discussion of possibilities
that obviously didn't make it to the final version.
I'm also wrestling with an oddball application that stores some data in the
ccache with a principal name without a realm. The data isn't a ticket though,
so that's
Hi Henry
We haven't supported the anonymous feature in Java yet.
Anyway, if I read RFC6111/6112 correctly, an anonymous principal name
uses well-known values in its nameStrings and nameRealm fields, so they
are still neither null nor empty. This does not conflict with my
proposal. Also, it se
Doesn't this interact with the new anonymity standards?
On Jun 6, 2012, at 5:55 PM, Weijun Wang wrote:
> Hi Valerie
>
> The krb5 PrincipalName class has a realm field and the class says
>
> If null, means the default realm
>
> Ideally this means if the realm of a name is null then this field
Ideally this means if the realm of a name is null then this field can be
null. Otherwise, it must be filled when created.
Should be "if the realm of a name is the default realm".
Hi Valerie
The krb5 PrincipalName class has a realm field and the class says
If null, means the default realm
Ideally this means if the realm of a name is null then this field can be
null. Otherwise, it must be filled when created.
In fact, inside our codes, the field is often filled (usi
20 matches
Mail list logo
