Closed GoogleCodeExporter closed 9 years ago
Original comment by evernat@free.fr
on 19 Feb 2012 at 10:11
For 2, in order to write a report, many parameters are needed: period (or
range), format (html, pdf, xml, json), language, resource, image (with size) or
page wanted and other identifiers, etc.
What you want is a new method with a real HttpServletRequest as parameter?
And the report is not only a simple Stream. There are Content-Type,
Content-Disposition, cookie to remember the period, no-cache headers, etc.
So the added method should have a real HttpServletResponse as parameter?
When would you use this new method? in a servlet?
Original comment by evernat@free.fr
on 10 Mar 2012 at 2:37
[deleted comment]
After more thought about 1, I have added in trunk a servlet filter to customize
styles, icons and other resources in the html reports.
See issue 196.
Original comment by evernat@free.fr
on 10 Mar 2012 at 11:47
Just realized that issue 196 is already closed, so I will post the same comment
from issue 196 to this issue:
Thank you for the addition of this kind of filter which is a step in the right
direction.
However, it feels a little bit like a "hack", only redirecting resources to
some other location.
This solution is also unable to change the colors/layout/size of the RRD graphs
and to change the layout of the html (e.g. to get rid of the <html><body> tags
to be able to "inline" the monitoring into some application output stream, e.g.
from jsps).
Original comment by mineral_...@gmx.de
on 16 Mar 2012 at 5:51
In the initial description for the 2nd subject, you were speaking about
security.
There are options for security written in the user guide, including JavaEE
security constraints:
http://code.google.com/p/javamelody/wiki/UserGuide#16._Security
You can also add a servlet filter: if the users are managed in your application
you can write your own filter, or you can configure a filter with some library
(Apache Shiro or Spring Security come to mind). Then you can add this filter in
your web.xml file before the javamelody filter and using "/monitoring" for its
url-pattern.
Otherwise, it is not planned at the moment to customize RRD graphs or html
reports, except resources with CustomResourceFilter.
Original comment by evernat@free.fr
on 9 Apr 2012 at 2:14
Since the creation of this issue, a few things have been added/enhanced:
- possibility to customize the styles, icons and other resources in the html
reports ( issue 196, documentation at
https://code.google.com/p/javamelody/wiki/UserGuideAdvanced#Customizing_styles,_
icons_and_other_resources_in_the_html_report ).
This can be used to override monitoring.css for example.
- there are now empty customizableMonitoring.css and customizableMonitoring.js
to ease custom styles and js like said above, without overriding all
monitoring.css. For example:
http://demo.javamelody.cloudbees.net/monitoring?resource=customizableMonitoring.
css
- alternative servlet to generate the reports (issue 227),
- possibility to extend the security check to access the reports (issue 256),
- since v1.50, you can add links to custom reports, documentation at
https://code.google.com/p/javamelody/wiki/UserGuideAdvanced#Custom_reports
- since v1.42, the "Desktop" link at the top of the report launch a rich
desktop UI, with some export features, instead of html report. If you are a
Swing dev, you may add your own screens in a customized swing app, source at
https://code.google.com/p/javamelody/source/browse/#svn%2Ftrunk%2Fjavamelody-swi
ng.
- data of the reports can be fetched as xml or json, for example from your own
javascript UI, using the external API:
https://code.google.com/p/javamelody/wiki/ExternalAPI#JSON
- css3 and javascript libraries are better now. And Javascript UIs seem fun
nowadays.
So, I think that this issue can be fixed now.
Html syntax may probably be better for using more css in the reports, submit
patchs as needed.
Colors in graphs can't be changed still (except if there is some css filter
that I don't know of yet).
Original comment by evernat@free.fr
on 4 Aug 2014 at 12:48
Original issue reported on code.google.com by
mineral_...@gmx.de
on 17 Feb 2012 at 9:12