asterisk-java-users

[Asterisk-java-users] resolution: question about getting peers using SipShowPeerAction (AMI)

[Robert P. <ro...@ro...>]

Folks,

Well, I feel rather foolish.  It turns out the ManagerResponse already
held all the information I was after, in its HashMap 'attributes' -
accessible via getAttributes().  In this case, the information I'm
after is the same that is returned at the Asterisk console by the
command 'sip show peer [peer name]'.  So while it may have been
unnecessary effort, at least all my fumbling around exposed me to more
of the API and functionality, and I also learned a bit more about
Asterisk in the process.

So, while perhaps the API could be documented in a bit more detail, or
maybe there could be more explicit (or just more) tutorials/docs, hats
off for a great app.


Cheers,

Robert

Re: [Asterisk-java-users] resolution: question about getting peersusing SipShowPeerAction (AMI)

[Martin S. <ma...@be...>]

Hi Robert,

I'm sorry I didn't answer sooner -- with most responses, the response
subclasses (command response, getconfig response, etc) have setters that
are called when traversing the attributes map. This means anything that
isn't an actual data member of the class is always still sitting in the
Map.

For good measure, here's the documentation as it stands regarding the
ManagerResponse and the getAttributes method:
http://asterisk-java.org/development/apidocs/org/asteriskjava/manager/re
sponse/ManagerResponse.html

Would you suggest we make it more explicit in the class summary that the
attributes are what most users would want? We'd welcome that suggestion
and other ones for improving the javadocs :)

Martin Smith, Systems Developer
ma...@be...
Bureau of Economic and Business Research
University of Florida
(352) 392-0171 Ext. 221=20

=20

> -----Original Message-----
> From: ast...@li...=20
> [mailto:ast...@li...] On=20
> Behalf Of Robert Prince
> Sent: Wednesday, August 15, 2007 12:17 PM
> To: ast...@li...
> Subject: [Asterisk-java-users] resolution: question about=20
> getting peersusing SipShowPeerAction (AMI)
>=20
> Folks,
>=20
> Well, I feel rather foolish.  It turns out the ManagerResponse already
> held all the information I was after, in its HashMap 'attributes' -
> accessible via getAttributes().  In this case, the information I'm
> after is the same that is returned at the Asterisk console by the
> command 'sip show peer [peer name]'.  So while it may have been
> unnecessary effort, at least all my fumbling around exposed me to more
> of the API and functionality, and I also learned a bit more about
> Asterisk in the process.
>=20
> So, while perhaps the API could be documented in a bit more detail, or
> maybe there could be more explicit (or just more) tutorials/docs, hats
> off for a great app.
>=20
>=20
> Cheers,
>=20
> Robert
>=20
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and=20
> a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Asterisk-java-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/asterisk-java-users
>=20

Re: [Asterisk-java-users] resolution: question about getting peersusing SipShowPeerAction (AMI)

[Robert P. <ro...@ro...>]

Hey Martin,

No worries about timing :)

I've been thinking a bit about what might help ... while my first
inclination is to say "of course a response should be specific (i.e.,
class/type) to the event it's a response to", that would mean a new
hierarchy/set of subclasses, and could raise the learning curve that
much more for beginners.  It might just be unnecessarily clutter in
the response package.

One alternative is an (abstract?) default ManagerResponse subclass
that provides a bunch of empty methods that can be ignored if you're
not interested in that data/it's not that kind of response, but you
can override those that do have the data you're interested in.  The
methods would ideally cover everything possible from any AMI response
... Also not so pretty.

In terms of documentation, it says in the method comment for
ManagerResponse.getAttributes():  "Returns a Map with all attributes
of this response."  I read that but didn't really get it.  Maybe a
paragraph or two explaining what the attributes Map is and that it's a
catch-all for all the data from the AMI in the class comments/javadoc
would help make that more explicit.

I hope this helps - thanks!


Cheers,

Robert

On 8/15/07, Martin Smith <ma...@be...> wrote:
> Hi Robert,
>
> I'm sorry I didn't answer sooner -- with most responses, the response
> subclasses (command response, getconfig response, etc) have setters that
> are called when traversing the attributes map. This means anything that
> isn't an actual data member of the class is always still sitting in the
> Map.
>
> For good measure, here's the documentation as it stands regarding the
> ManagerResponse and the getAttributes method:
> http://asterisk-java.org/development/apidocs/org/asteriskjava/manager/re
> sponse/ManagerResponse.html
>
> Would you suggest we make it more explicit in the class summary that the
> attributes are what most users would want? We'd welcome that suggestion
> and other ones for improving the javadocs :)
>
> Martin Smith, Systems Developer
> ma...@be...
> Bureau of Economic and Business Research
> University of Florida
> (352) 392-0171 Ext. 221