Remove web-fragment.xml from core jar.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Couple javamelody-core-1.55.0.jar with webapp
2. Try to configure the filter programatically from spring boot app.
3. Recognize that the filter is already configured because of the 
web-fragment.xml

What is the expected output? What do you see instead?
Expected: Only the programmaticaly configured flter is active.
Actual: Two filters a registered.

What version of the product are you using? On what application server, JDK,
operating system?
Java JDK 1.8, Tomcat 8

Please provide a jar that doesnt include the webfragment and provide a separate 
jar which contains it.

Original issue reported on code.google.com by simon.bu...@infinit-group.de on 1 Mar 2015 at 6:08

[GoogleCodeExporter]

Multiplying javamelody artifacts is not a good solution.

And it happens that spring boot 1.2 uses Servlet 3.1.
So, the filter from web-fragment.xml is used and as documented for Servlet 3.1 
you don't need to configure the filter in web.xml or programmaticaly.
Just don't configure it programmaticaly.

If you still need to define javamelody parameters, you have a number of options:
- system properties,
- or context parameters: servletContext.setInitParameter or context-param in 
web.xml or Parameter in context xml file of Tomcat
See https://code.google.com/p/javamelody/wiki/UserGuide#6._Optional_parameters

Closing as invalid for the reason above.

Original comment by evernat@free.fr on 14 Mar 2015 at 2:33

• Changed state: Invalid

[GoogleCodeExporter]

Ok, with the configuration part but what if i want a different mapping path or 
disable the session listener? Maybe i want to map the filter only to /api 
requests etc?

Original comment by simon.bu...@infinit-group.de on 16 Mar 2015 at 9:41

[GoogleCodeExporter]

If you want a different mapping path, for example only /api, you can use the 
url-exclude-pattern javamelody parameter to exclude every http requests except 
/api.

In javamelody, you are currently not supposed to disable the session listener 
and I would say that there is no reason to disable it and to enable only the 
MonitoringFilter. This seems like a crude argument but that's how it works for 
the better.

Original comment by evernat@free.fr on 16 Mar 2015 at 11:36