On Apr 3, 2009, at 4:44 PM, Lloyd Chambers wrote:
> I don't see it as naming at all, which is why I raised the issue.
>
i.c.
> Public or private is a boolean choice that also imputes other meaning.
>
these are two domains we come predefined with.
> A command domain would allow logical groupings of any number, the
> meaning/intent is an orthogonal issue.
right, so that's what we have if I understand you correctly.
> A command domain could also imply the contract between client and
> server which might differ for each command domain.
>
ok so what do you exactly propose ?
@Domain(Public.class) and @Domain(Private.class)
instead of
@Visibility(Public.class) and @Visibility(Private.class)
maybe we should do this
@Visbility(Asadmin.class) and @Visibility(Private.class)
would that be more in sync with the current situation, no ?
I have also been struggling with generating or configuring the context
root from the Privacy subclass (here Asadmin and Private), do people
feel the context root should be hardcoded in the code (it is today for
asadmin) or configurable ?
jerome
> Lloyd
>
> On Apr 3, 2009, at 10:55 AM, Jerome Dochez wrote:
>
>>
>> On Apr 3, 2009, at 10:48 AM, Lloyd Chambers wrote:
>>
>>> Instead of visibility why not something like @Domain which
>>> indicates the context root? Then we'd have a generic scoping
>>> mechanism:
>>>
>>> http://localhost:8080/__asadmin/....
>>> http://localhost:8080/__private/....
>>> http://localhost:8080/__mygoodies/....
>> that's exactly what happens behind de scene.
>>
>> what difference does it make if it is triggered by @Domain versus
>> @Visibility. Is this just a question of naming convention ?
>>
>>
>>>
>>> Lloyd
>>>
>>> On Apr 2, 2009, at 10:59 PM, Jerome Dochez wrote:
>>>
>>>> Hi All
>>>>
>>>> Hong asked me if we could add the ability to have private
>>>> commands to v3. Private commands are remote commands that can be
>>>> used by our tools like jsr88client, IDE tools, and GUI but users
>>>> would not have access to using the normal CLI client. The point
>>>> is not to protect or securely prevent commands to be executed by
>>>> random users, it's simply about obfuscating them so users don't
>>>> access them innocently as they won't be supported across
>>>> releases. Please note that the current mechanism could be
>>>> extended to secure invocations but I think it's an overkill at
>>>> this point.
>>>>
>>>> I have just added the feature so to define a new private command
>>>> you just need to annotate your AdminCommand implementation with
>>>> @Visibility annotation and let the system do the rest.
>>>>
>>>> example :
>>>>
>>>> @Service(name="my-private-command")
>>>> @Visibility(Private.class)
>>>> public class MyPrivateCommand implements AdminCommand {
>>>> ...
>>>> }
>>>>
>>>> So far there are only two types of visibility defined in the system
>>>>
>>>> @Visibility(Public.class)
>>>> @Visibility(Private.class)
>>>>
>>>> we could add more to bind commands to even stricter clients like
>>>> for instance @Visbility(MySuperTool.class) but I don't think we
>>>> will have to go that far. If you don't annotate your AdminCommand
>>>> implementation it gets the default visibility of Public.
>>>>
>>>> If you try to invoke a private command from the asadmin CLI, you
>>>> will get a disappointing result but feel free to try. Private
>>>> commands are available on a different context root than the one
>>>> used by the CLI.
>>>>
>>>> Let me know if you have any questions.
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>> Lloyd Chambers
>>> lloyd.chambers_at_sun.com
>>> GlassFish Team
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> Lloyd Chambers
> lloyd.chambers_at_sun.com
> GlassFish Team
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>