Jerome,
I was thinking (naively perhaps):
@Context("asadmin") // default
@Context("private")
@Context("hello")
...where the value is the context root eg
http://localhost:8080/
asadmin/...
...where the value is the context root eg
http://localhost:8080/
private/...
...where the value is the context root eg
http://localhost:8080/
hello/...
...where the value is the context root eg
http://localhost:8080/
mbean/...
Lloyd
On Apr 3, 2009, at 7:29 PM, Jerome Dochez wrote:
>
> 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
>>
>
>
> ---------------------------------------------------------------------
> 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