Reading attribute with CLI fails

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Reading attribute with CLI fails

ChrisRamsdale
Hi everyone,
I'm trying to read the "development" attribute of the web subsystem
using the command line interface.
Since the attribute is part of a group (jsp-configuration), I cannot
read it using the standard syntax.

"jsp-configuration" => {
    "development" => false,
     . . . .. . .      
}

[standalone@localhost:9999 subsystem=web]
:read-attribute(name="development")
{
    "outcome" => "failed",
    "failure-description" => "No known attribute development",
    "rolled-back" => true
}

or

[standalone@localhost:9999 subsystem=web]
:read-attribute(name="jsp-configuration/development")
{
    "outcome" => "failed",
    "failure-description" => "No known attribute development",
    "rolled-back" => true
}

Anyone can enlight me how to read this attribute successfully ?
Thank you very much!
Chris

--
http://www.fastmail.fm - Send your email first class

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Reading attribute with CLI fails

Heiko Braun


I was complaining about tis a while ago as well.
With the current model structure you cannot easily read any single attribute 
of the jsp-configuration.

Brian, Remy: any ideas how this could be improved?
Some thoughts about a generic config container have been on the table before.
Similar to system  and other properties (See my other email about key/value pairs)

  /subsystem=web/config=development:read-resource()

Alternatively it could become a specific sub resource,
so that  read/write attribute operations might apply:

  /subsystem=web/config=jsp:read-attribute(name=development)


If you ask me, i'd prefer the later.


Ike

On Jul 22, 2011, at 1:44 PM, ChrisRamsdale wrote:

Hi everyone,
I'm trying to read the "development" attribute of the web subsystem
using the command line interface.
Since the attribute is part of a group (jsp-configuration), I cannot
read it using the standard syntax.

"jsp-configuration" => {
   "development" => false,
    . . . .. . .       
}

[standalone@localhost:9999 subsystem=web]
:read-attribute(name="development")
{
   "outcome" => "failed",
   "failure-description" => "No known attribute development",
   "rolled-back" => true
}

or

[standalone@localhost:9999 subsystem=web]
:read-attribute(name="jsp-configuration/development")
{
   "outcome" => "failed",
   "failure-description" => "No known attribute development",
   "rolled-back" => true
}

Anyone can enlight me how to read this attribute successfully ?
Thank you very much!
Chris

--
http://www.fastmail.fm - Send your email first class

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Reading attribute with CLI fails

Brian Stansberry
On 7/22/11 7:03 AM, Heiko Braun wrote:

>
>
> I was complaining about tis a while ago as well.
> With the current model structure you cannot easily read any single
> attribute
> of the jsp-configuration.
>
> Brian, Remy: any ideas how this could be improved?
> Some thoughts about a generic config container have been on the table
> before.
> Similar to system and other properties (See my other email about
> key/value pairs)
>
> /subsystem=web/config=development:read-resource()
>
> Alternatively it could become a specific sub resource,
> so that read/write attribute operations might apply:
>
> /subsystem=web/config=jsp:read-attribute(name=development)
>
>
> If you ask me, i'd prefer the later.
>

Agreed. Anywhere we can use resources instead of complex attributes,
that's better. Stefano will be looking into that for the transaction
subsystem. Emanuel and I are doing some work in that area now on messaging.

There's an implementation issue of how to deal with child resources when
they are really part of the required configuration associated with a
service controlled by the parent resource, but Stefano, Emanuel and I
worked out what seems to be a workable solution to that on Wednesday.

>
> Ike
>
> On Jul 22, 2011, at 1:44 PM, ChrisRamsdale wrote:
>
>> Hi everyone,
>> I'm trying to read the "development" attribute of the web subsystem
>> using the command line interface.
>> Since the attribute is part of a group (jsp-configuration), I cannot
>> read it using the standard syntax.
>>
>> "jsp-configuration" => {
>> "development" => false,
>> . . . .. . .
>> }
>>
>> [standalone@localhost:9999 subsystem=web]
>> :read-attribute(name="development")
>> {
>> "outcome" => "failed",
>> "failure-description" => "No known attribute development",
>> "rolled-back" => true
>> }
>>
>> or
>>
>> [standalone@localhost:9999 subsystem=web]
>> :read-attribute(name="jsp-configuration/development")
>> {
>> "outcome" => "failed",
>> "failure-description" => "No known attribute development",
>> "rolled-back" => true
>> }
>>
>> Anyone can enlight me how to read this attribute successfully ?
>> Thank you very much!
>> Chris
>>
>> --
>> http://www.fastmail.fm - Send your email first class
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email] <mailto:[hidden email]>
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Reading attribute with CLI fails

Jason T. Greene
If we allow value types then all of our interfaces need to know how to handle them. Forcing all subsystems to not use them is an incomplete solution (unless we remove the notion altogether).

Sent from my iPad

On Jul 22, 2011, at 9:25 AM, Brian Stansberry <[hidden email]> wrote:

> On 7/22/11 7:03 AM, Heiko Braun wrote:
>>
>>
>> I was complaining about tis a while ago as well.
>> With the current model structure you cannot easily read any single
>> attribute
>> of the jsp-configuration.
>>
>> Brian, Remy: any ideas how this could be improved?
>> Some thoughts about a generic config container have been on the table
>> before.
>> Similar to system and other properties (See my other email about
>> key/value pairs)
>>
>> /subsystem=web/config=development:read-resource()
>>
>> Alternatively it could become a specific sub resource,
>> so that read/write attribute operations might apply:
>>
>> /subsystem=web/config=jsp:read-attribute(name=development)
>>
>>
>> If you ask me, i'd prefer the later.
>>
>
> Agreed. Anywhere we can use resources instead of complex attributes,
> that's better. Stefano will be looking into that for the transaction
> subsystem. Emanuel and I are doing some work in that area now on messaging.
>
> There's an implementation issue of how to deal with child resources when
> they are really part of the required configuration associated with a
> service controlled by the parent resource, but Stefano, Emanuel and I
> worked out what seems to be a workable solution to that on Wednesday.
>
>>
>> Ike
>>
>> On Jul 22, 2011, at 1:44 PM, ChrisRamsdale wrote:
>>
>>> Hi everyone,
>>> I'm trying to read the "development" attribute of the web subsystem
>>> using the command line interface.
>>> Since the attribute is part of a group (jsp-configuration), I cannot
>>> read it using the standard syntax.
>>>
>>> "jsp-configuration" => {
>>> "development" => false,
>>> . . . .. . .
>>> }
>>>
>>> [standalone@localhost:9999 subsystem=web]
>>> :read-attribute(name="development")
>>> {
>>> "outcome" => "failed",
>>> "failure-description" => "No known attribute development",
>>> "rolled-back" => true
>>> }
>>>
>>> or
>>>
>>> [standalone@localhost:9999 subsystem=web]
>>> :read-attribute(name="jsp-configuration/development")
>>> {
>>> "outcome" => "failed",
>>> "failure-description" => "No known attribute development",
>>> "rolled-back" => true
>>> }
>>>
>>> Anyone can enlight me how to read this attribute successfully ?
>>> Thank you very much!
>>> Chris
>>>
>>> --
>>> http://www.fastmail.fm - Send your email first class
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email] <mailto:[hidden email]>
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
> --
> Brian Stansberry
> Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Reading attribute with CLI fails

Heiko W.Rupp
In reply to this post by Brian Stansberry
> Agreed. Anywhere we can use resources instead of complex attributes,
> that's better. Stefano will be looking into that for the transaction

Well, there are two orthogonal things here:

- using resources instead of attributes
- using lists/maps of attributes instead the heavily nested constructs we have now.

  Heiko


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Reading attribute with CLI fails

Heiko Braun
In reply to this post by Jason T. Greene


Can you elaborate on this?
I don't understand what you mean ...

On Jul 23, 2011, at 2:26 PM, Jason Greene wrote:

If we allow value types then all of our interfaces need to know how to handle them


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Reading attribute with CLI fails

Heiko Braun
In reply to this post by Heiko W.Rupp

It's not going to replace attributes in general.
But in certain cases (i.e. key value pairs) it makes sense.

Anything that could benefit from implicit operations (add,remove, etc)
would need to be addressable (/foo=bar). 

Ike  


On Jul 23, 2011, at 9:47 PM, Heiko W.Rupp wrote:

- using resources instead of attributes
- using lists/maps of attributes instead the heavily nested constructs we have now.


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Reading attribute with CLI fails

Jason T. Greene
In reply to this post by Heiko Braun
Not every complex structure in the DMR tres is addressable. You can have a single attribute that contains multiple values (like passing a map Iin Java, a struct in C etc).

Read-description is supposed to describe the structure of these complex attributes using VALUE_TYPE

Sent from my iPad

On Jul 25, 2011, at 5:09 AM, Heiko Braun <[hidden email]> wrote:



Can you elaborate on this?
I don't understand what you mean ...

On Jul 23, 2011, at 2:26 PM, Jason Greene wrote:

If we allow value types then all of our interfaces need to know how to handle them

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Automagic Interfaces

Heiko Braun


Not sure if we are on the page wrt to this discussion.
(you lost me somewhere) but here are my thoughts about the value type descriptions
and automagic interfaces:

Instead of using the VALUE_TYPE descriptions to get to know the inner structure of a complex attribute,
we could aim for a more simple approach: turn complex attributes into sub resources.

This is not possible straight away and has certain implications:

Sub resources need to be addressable

Consider the "jsp-configuration" of subsystem web for instance.
it's not addressable per se, but it easily can be made addressable:

/subsystem=web/config=jsp:read-resource
/subsystem=web/config=jsp:read-attribute(name=development)

What do we gain?  implicit operations for a the sub resource:
(add, remove, read/write-arribute, etc)

With this we are much closer to automagic interfaces,
then the burden parse & analyze some half-baked description of the structures at hand.

Why "half-baked"? Well, IMO the current description of types and constraints are straight forward 
and easy to understand, but far from be descriptive enough to automagically generate interfaces.

It's still very hard to generate human interfaces from proper xml schema descriptions
and the DMR descriptions don't cover the detail and descriptiveness of xml schema yet.
And in my opinion the shouldn't.  

We better stick to our simple & straight forward mantra
and improve/refactor the current model descriptions like described above before puling the sledgehammer.

Ike

On Jul 25, 2011, at 1:21 PM, Jason Greene wrote:

Not every complex structure in the DMR tres is addressable. You can have a single attribute that contains multiple values (like passing a map Iin Java, a struct in C etc).

Read-description is supposed to describe the structure of these complex attributes using VALUE_TYPE

Sent from my iPad

On Jul 25, 2011, at 5:09 AM, Heiko Braun <[hidden email]> wrote:



Can you elaborate on this?
I don't understand what you mean ...

On Jul 23, 2011, at 2:26 PM, Jason Greene wrote:

If we allow value types then all of our interfaces need to know how to handle them

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Automagic Interfaces

David Bosschaert
FWIW, it might also be an idea to consider using XML Schema as the
master of everything and fill the gaps in there with xs:appinfo tags.

A good while ago I developed a graphical editor for Eclipse that was
purely based on schema. It rendered the GUI dynamically based on the XML
Schema [3]. For certain things there was no holder in XML Schema, and in
those cases XML-Schema appInfo annotations were used. For an example see
[1] and for more details see [2].

While not everybody likes the looks of XML and XML Schema, there are a
number of benefits associated with the approach.

* While the GUI that I wrote at the time dynamically dealt with the XML
Schema, the parsing code in the runtime was actually generated java and
hence high-performance. Similarly, the XML parsing code that is
currently in AS7, could be generated from such an XML schema I think,
without losing performance.
* The XML Schema contains the documentation which you can use for both
online and printed documentation.
* When changing/extending/maintaining, the only thing needed was to add
an extra piece of XML schema in, which was quite quick and straightforward.
* But, possibly the biggest advantage is that there is only a single
source of the configuration metadata, which means nothing (parser, gui,
documentation) ever gets out of sync.

Anyway, just a thought. At the time when this project was used (during
my IONA days) people quite liked the approach...

Cheers,

David

[1]
http://wiki.eclipse.org/STP/Policy_editor_documentation#Further_Customizations
[2] http://wiki.eclipse.org/STP/Policy_Component/XEF_Reference
[3] Note that something that is represented as XML Schema doesn't have
to be represented as XML at runtime. You could use it for the runtime
model that AS7 has today...

On 25/07/2011 12:50, Heiko Braun wrote:

>
>
> Not sure if we are on the page wrt to this discussion.
> (you lost me somewhere) but here are my thoughts about the value type
> descriptions
> and automagic interfaces:
>
> Instead of using the VALUE_TYPE descriptions to get to know the inner
> structure of a complex attribute,
> we could aim for a more simple approach: turn complex attributes into
> sub resources.
>
> This is not possible straight away and has certain implications:
>
> *Sub resources need to be addressable*
>
> Consider the "jsp-configuration" of subsystem web for instance.
> it's not addressable per se, but it easily can be made addressable:
>
> /subsystem=web/config=jsp:read-resource
> /subsystem=web/config=jsp:read-attribute(name=development)
>
> What do we gain?  implicit operations for a the sub resource:
> (add, remove, read/write-arribute, etc)
>
> With this we are much closer to automagic interfaces,
> then the burden parse & analyze some half-baked description of the
> structures at hand.
>
> Why "half-baked"? Well, IMO the current description of types and
> constraints are straight forward
> and easy to understand, but far from be descriptive enough to
> automagically generate interfaces.
>
> It's still very hard to generate human interfaces from proper xml
> schema descriptions
> and the DMR descriptions don't cover the detail and descriptiveness of
> xml schema yet.
> And in my opinion the shouldn't.
>
> We better stick to our simple & straight forward mantra
> and improve/refactor the current model descriptions like described
> above before puling the sledgehammer.
>
> Ike
>
> On Jul 25, 2011, at 1:21 PM, Jason Greene wrote:
>
>> Not every complex structure in the DMR tres is addressable. You can
>> have a single attribute that contains multiple values (like passing a
>> map Iin Java, a struct in C etc).
>>
>> Read-description is supposed to describe the structure of these
>> complex attributes using VALUE_TYPE
>>
>> Sent from my iPad
>>
>> On Jul 25, 2011, at 5:09 AM, Heiko Braun <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>>
>>>
>>> Can you elaborate on this?
>>> I don't understand what you mean ...
>>>
>>> On Jul 23, 2011, at 2:26 PM, Jason Greene wrote:
>>>
>>>> If we allow value types then all of our interfaces need to know how
>>>> to handle them
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email] <mailto:[hidden email]>
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Automagic Interfaces

jtgreene
Administrator
In reply to this post by Heiko Braun
On 7/25/11 6:50 AM, Heiko Braun wrote:

>
>
> Not sure if we are on the page wrt to this discussion.
> (you lost me somewhere) but here are my thoughts about the value type
> descriptions
> and automagic interfaces:
>
> Instead of using the VALUE_TYPE descriptions to get to know the inner
> structure of a complex attribute,
> we could aim for a more simple approach: turn complex attributes into
> sub resources.

It's a good argument (although I don't completely agree) for the
configuration model. However we still need complex structures (and a way
to describe them) for runtime operations. So my argument is that all of
our tools need to be able to understand ad-hoc request/responses anyway.

>
> This is not possible straight away and has certain implications:
>
> *Sub resources need to be addressable*
>
> Consider the "jsp-configuration" of subsystem web for instance.
> it's not addressable per se, but it easily can be made addressable:
>
> /subsystem=web/config=jsp:read-resource
> /subsystem=web/config=jsp:read-attribute(name=development)
>
> What do we gain? implicit operations for a the sub resource:
> (add, remove, read/write-arribute, etc)

In this particular example I agree, however there are still some issues

1) Breaking compatibility
2) Address-ability is not so useful for runtime and read-only values
3) Singletons lead to making up k-v pairs
4) Some things (admittedly not extremely common) can only be modified in
an atomic group of values.
>
> With this we are much closer to automagic interfaces,
> then the burden parse & analyze some half-baked description of the
> structures at hand.
>
> Why "half-baked"? Well, IMO the current description of types and
> constraints are straight forward
> and easy to understand, but far from be descriptive enough to
> automagically generate interfaces.

Well we should figure out what the gaps are. It could be that some are
incomplete.
>
> It's still very hard to generate human interfaces from proper xml schema
> descriptions
> and the DMR descriptions don't cover the detail and descriptiveness of
> xml schema yet.
> And in my opinion the shouldn't.

Well a ironically good chunk of schema is a vast array of features to
human maintenance and control of the document. The descriptions we have
been creating are intended to be read by machines, so redundancy for
example is less of a concern.

We also want to use them for request validation at some point to make
operation implementations less work and more consistent and catch more
errors.

As mentioned above this is already a must have for runtime ops, and we
already went through a lot of trouble to provide them for the model. I
mean the whole rationale was to support dynamic interfaces. It would be
a shame if we fall short.

>
> We better stick to our simple & straight forward mantra
> and improve/refactor the current model descriptions like described above
> before puling the sledgehammer.

Hmm wouldn't it be more destructive to drastically change everything and
break compatibility. I mean I agree we should do it in a few areas, but
if the goal is not use a sledgehammer then we should just leave the warts.

> Ike
>
> On Jul 25, 2011, at 1:21 PM, Jason Greene wrote:
>
>> Not every complex structure in the DMR tres is addressable. You can
>> have a single attribute that contains multiple values (like passing a
>> map Iin Java, a struct in C etc).
>>
>> Read-description is supposed to describe the structure of these
>> complex attributes using VALUE_TYPE
>>
>> Sent from my iPad
>>
>> On Jul 25, 2011, at 5:09 AM, Heiko Braun <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>>
>>>
>>> Can you elaborate on this?
>>> I don't understand what you mean ...
>>>
>>> On Jul 23, 2011, at 2:26 PM, Jason Greene wrote:
>>>
>>>> If we allow value types then all of our interfaces need to know how
>>>> to handle them
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email] <mailto:[hidden email]>
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


--
Jason T. Greene
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev