RE: Default permission: "*" or "-"

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#*[*:*]"

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.

The use of the nilcard "-" is not to be done in policy files, and not to
be used anywhere in user code.
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).

>  > 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_ide95&alloc_id396&op=click