Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of nicolas.deloof@gmail.com
 designates 64.233.182.184 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth;
        b=UL56MGS93VRFYSjm91kXC04d2IOOX5RiAFxq8qNxgBdbguES652hatM7lzP/e5LWuzTZRFGf0lSV0qkfGaHEsDZKuKigisxoyRLrB6+SVR2vrxWUVTF9tSjVv98nVBpsNVEB8VQm2eVur8LsRaAcMYCekfeV1kskmS4IvjO/S8w=
Message-ID: <4c39e3030804180844t24d93613t873d39019149914d@mail.gmail.com>
Date: Fri, 18 Apr 2008 17:44:46 +0200
From: "nicolas de loof" <nicolas@apache.org>
Sender: nicolas.deloof@gmail.com
To: "Jakarta Commons Developers List" <dev@commons.apache.org>,
 sgoeschl@gmx.at
Subject: Re: [Monitoring] What are the plan regarding web frontend for Commons
 Monitoring ....
In-Reply-To: <4808C058.8060104@gmx.at>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_1925_25941341.1208533486620"
References: <48087DAB.1070800@gmx.at>
	 <4c39e3030804180421y780a7a2ch457667cfb89a94bc@mail.gmail.com>
	 <4808B0E0.2060200@gmx.at>
	 <4c39e3030804180743m24ef863pddb6b108b441fb2@mail.gmail.com>
	 <4808C058.8060104@gmx.at>

------=_Part_1925_25941341.1208533486620
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Thanks !

2008/4/18, Siegfried Goeschl <sgoeschl@gmx.at>:
>
> Hi Nicolas,
>
> +) that sounds cool ...
>
> +) I have some code generating proper monitor names based on method
> invocations (see
> http://people.apache.org/~sgoeschl/presentations/jamon-20070717.pdf<http://people.apache.org/%7Esgoeschl/presentations/jamon-20070717.pdf>- "Example - Performance Monitor") - you might need this stuff ... :-)
>
>
> Cheers,
>
> Siegfried Goeschl
>
>
>
> nicolas de loof wrote:
>
> >
> >
> >    please consider the following scenario
> >
> >    +) adding commons-monitoring integration by using
> >    AOP/interceptor/events/whatever - so the application is not aware
> >    of being monitored - cool
> >    +) in the same non-intrusive manner I would like to gather the
> >    data using a browser - just adding two entries in the web.xml and
> >    nothing else
> >
> >
> > I have the same goal !
> >
> > -> web.xml to setup web monitoring + reporting servlet
> > -> spring-aop or aspectJ to have code instrumented
> >
> >    To further clarify my point
> >
> >    +) due to security considerations it could be an issue to add
> >    commons-monitoring to a secure application although it might
> >    materialize as transitive dependency (thx to maven) - no need to
> >    tell operations
> >    +) exposing servlets is a problem already - you enable them in the
> >    integration environment and they will find their way to production
> >    somehow (Murphy is one of my best friends)
> >    +) asking project management/operations to approve a few cool
> >    javascript libraries (flot, jquery) ranges from difficult to
> >    impossible .... how can I ensure that those libraries are safe
> >    regarding security, cross-site scripting, ...
> >    +) even more funny - I would like to have access using lynx or w3m
> >    (aka desperate developer looking at a HTML page over three SSH
> >    connections on the terminal) ... :-O
> >
> >
> > to secure the servlet, you can enable j2ee security !
> >
> > the servlet can produce a nice JS-enhanced web UI, but the generated
> > HTML is just HTML table - you can even get infos as txt if you need
> >  scripts, css and images are all included in the JAR. There is no
> > required maven dependency Nothing more to install on your application than
> > the commons-monitoring jar
> >
> >    In short - I'm focused on a simple and secure deployment - just a
> >    jar containing the stuff, a servlet plus resources found in the
> >    classpath and nothing else for the core distribution. I'm
> >    perfectly fine having a  more functional frontend but  not all
> >    user can carry the burden associated with it.
> >
> >    Cheers
> >
> >    Siegfried Goeschl
> >
> >
> >    PS: A tiny bit of community building - I added a colleague of mine
> >    as recipient - try to convince her to help with commons-monitoring
> >    .... ;-)
> >
> >    nicolas de loof wrote:
> >
> >        The current code has a servlet to expose the monitored datas,
> >        based on request parameters :
> >
> >
> >        /monitoring/monitors --> all monitors in the repository, with
> >        all counters/gauges and all stats, using an output format
> >        detected based on request "Accept" HTTP header
> >
> >        /monitoring/monitors?format=html --> same but force output to
> >        html. Support html, xml, txt, js, and flot (see later)
> >
> >        /monitoring/monitorsFromCategory/web --> same, but only
> >        monitors from the category "web"
> >        /monitoring/monitorsFromSubsystem/web --> same, but only
> >        monitors from the category "web"
> >
> >        adding some other parameter allow to tweak the output :
> >
> >        ?role=performances --> only the "performances" counter will be
> >        included
> >
> >        ?role=performances&role=failures --> only the "performances"
> >        and "failures" counters will be included
> >
> >        ?performances.unit=ms  --> "performances" counter stats will
> >        be formatted with ms as unit (default is ns)
> >
> >        ?performances.columns=mean,max,standardDeviation  --> Only
> >        render the requested statistics
> >
> >
> >        Using all those parameters, you can build custom URLs to get
> >        the expected report.
> >
> >
> >        There is also another servlet, the WebUIServlet, that defaults
> >        output to HTML and extend the generated HTML with nicer CSS
> >        and inclusion of jquery javascript library to enable table
> >        sorting.
> >
> >        The "flot" format is also used with jQuery to enable graphing
> >        (based on the flot JS library).
> >
> >        A RepositoryDecorator is used to enable history on the
> >        repository, on a period + history-size basis. This enable a
> >        new URL on MonitoringServlet :
> >        /monitoring/history/monitor/category/subsystem/name
> >
> >        This will return a table of the monitor (with all it's
> >        counters & stats) for every historized period.
> >        Using ?format=flot will return a JavaScript objet to be used
> >        by the flot library to render a graph.
> >
> >        Same roles/units/columns filterring can be used to customize
> >        the output
> >
> >        !! Please note the flot ouput is early experimental and not
> >        yet stable !!
> >
> >
> >        Il plan to split the project into modules :
> >
> >        - core for monitoring infrastructure
> >        - webui-lite for the jquery based web UI
> >        - webui-X for a more advanced web ui, maybe based on GWT or
> >        anything else to have a cool monitoring UI.
> >
> >
> >
> >        Take a look in the SVN source at the src/main/webapp WAR
> >        configuration, this is used for testing /demonstrating purpose.
> >
> >
> >        Thanks for feedback,
> >
> >        Nicolas,
> >
> >
> >
> >        2008/4/18, Siegfried Goeschl <sgoeschl@gmx.at
> >        <mailto:sgoeschl@gmx.at> <mailto:sgoeschl@gmx.at
> >        <mailto:sgoeschl@gmx.at>>>:
> >
> >           Hi folks,
> >
> >           what are the current plans to add a web frontend to Commons
> >           Monitoring?
> >
> >           Based on my JAMON experience
> >
> >           +) the web frontend required additional libraries
> >           +) the jamon library and JSP/web resources were always out
> >        of sync
> >           and broke the web application
> >
> >           Would it be possible/feasible to implement the
> >        visualization using
> >           a plain-vanilla servlet and have more elegant
> >        implementation using
> >           JSP/Taglibs as an optional part? Using a servlet I can
> >        enable the
> >           web frontend by just updating the web.xml ...
> >
> >           Cheers,
> >
> >           Siegfried Goeschl
> >
> >
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> >           To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >        <mailto:dev-unsubscribe@commons.apache.org>
> >           <mailto:dev-unsubscribe@commons.apache.org
> >        <mailto:dev-unsubscribe@commons.apache.org>>
> >           For additional commands, e-mail:
> >        dev-help@commons.apache.org <mailto:dev-help@commons.apache.org>
> >           <mailto:dev-help@commons.apache.org
> >        <mailto:dev-help@commons.apache.org>>
> >
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

------=_Part_1925_25941341.1208533486620--