Re: Default permission: "*" or "-"

 > Bordet, Simone wrote:
 >
 > Hi,
 >
 >>> Jeremy Boynes wrote:
 >>>
 >>> Eamonn, can you confirm the intent here is that an empty
 >>> pattern in part
 >>> of the name should be treated as "-" i.e.
 >>> "Foo" == "Foo#-[-]" == ("Foo", null, null)
 >>> "#Bar" == "-#Bar[-]" == (null, "Bar", null)
 >>> "[x:x=x]" == "-#-[x:x=x]" == (null, null, "x:x=x")
 >>
 >>Jeremy there is one important thing to understand which is
 >>the difference between NEED and HAVE permission.
 >>
 >>The NEED permission is built by your implementation depending
 >>on the MBean
 >>server method called whereas the HAVE permissions are the
 >>ones specified in the policy file for example.
 >>
 >>Then "null" or "-" is usually used when building the NEED
 >>permission whereas
 >>"empty" or "*" are used when defining the HAVE permissions.
 >>
 >>In other words, "empty" or "*" implies "null" or "-" but only
 >>"null" or "-" implies "null" or "-".
 >
 >
 > The difference between NEED and HAVE is not so important, since
 > MBeanPermission does not any have possibility to distinguish
 > these 2 modalities.
 >
 > The real question here is if
 >
 > "Foo" == "Foo#*[*:*]"

The answer is yes <"Foo" == "Foo#*[*:*]">.

Maybe I did not explain myself clearly. What I meant to say was
that any empty or missing or ommitted value in a HAVE permission
means "*", and "-" should not be used in HAVE permissions.

In a NEED permission you cannot have a missing or ommitted value
because the NEED permission is always built programmatically by the
implementation so you can only have null (or "-") or "" (or "*") or
a concrete (not wildcard) value.

 > or not.
 >
 > There is one possible answer and does not depend on NEED or HAVE.
 >
 > From my point of view, specifying in the policy file (which is the only
 > interesting thing)
 >
 > permission MBeanPermission "Foo", "*";
 >
 > means that I grant permission to access all Foo MBeans, all methods, under
 > any ObjectName and for all MBeanServer operations.
 > Therefore my answer is yes.

I agree with you and this is true in the spec and the RI.

 > The use of the nilcard "-" is not to be done in policy files, and not to be
 > used anywhere in user code.

I agree with you.

 > Only implementations need to specify nilcards in MBeanPermissions, and I
 > think must do so in an explicit way.
 >
 > The spec says ("Foo", null, null) == "Foo#-[-]".
 >
 > I would have preferred that the specification said
 >
 > ("Foo", null, null) == "Foo#*[*:*]"
 >
 > but there it is (and I think it's a mistake).

This is just a convention we had to choose to define the meaning of a null
value in a NEED permission.

We had 2 possibilities:

(1) null in NEED permission means "-"

or

(2) null in NEED permission means "*"

We finally implemented (1) but I don't think this was a mistake. In fact, I
see more precise to associate "null" with "nothing allowed" than "null" with
"all allowed".

Okay I stop now, it is just my opinion.

Regards,
Luis

 >> > Also, can you confirm that method parts ending in "*" would be a valid
 >> > extension (assuming the TCK tests pass of course).
 >>
 >>IMHO this breaks portability and thus should be avoided.
 >
 >
 > I agree.
 >
 >
 >>Regards,
 >>Luis
 >>
 >> > Simone, are you OK with me first redoing the MX4J tests so
 >> > the RI passes and then changing MX4J to match?
 >
 >
 > I'm not sure.
 > I think MX4J behaves correctly when parsing the permission name passed as a
 > string, while only the interpretation between MX4J and RI in case of 4-args
 > constructor is different.
 > Although I think RI interpretation is wrong, I think there is no other
 > choice than adequate MX4J, since now RI is in J2SE.
 >
 > Jeremy, can you confirm the problems you have in the tests are only because
 > of the 4 args constructor ?
 >
 > Simon


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click