Hi everybody, a refactoring I did in 4.3M1 exposed something that could be a big issue and which consists in having internal classes exposed in configuration files. In particular, the refactoring I did moved the REST servlet and application to an internal package and, hence, in the web.xml the servlet and application definitions now contain the FQN of classes that are in an internal package (org.xwiki.rest.internal.XWikiRestletJaxRsApplication and org.xwiki.rest.internal.XWikiRestletServlet) Looking at configuration files, we've found that this was already done in the past. In the web.xml there are other components that are implemented by internal classes: the set character encoding filter (org.xwiki.container.servlet.filters.internal.SetCharacterEncodingFilter), and the request restorer filter (org.xwiki.container.servlet.filters.internal.SavedRequestRestorerFilter) There are also some internal classes in struts-config.xml and maybe also somewhere else. Configuration files should be considered as user files, so putting there internal classes should be considered an error which could cause potential upgrade problems. So we should discuss about the following topic 1) Clearly define which configuration is to be considered "internal" (the distinction is not always obvious) 2) How to fix the fact that we have internal classes exposed in "user" configuration files. Personally, I considered the web.xml an "internal" configuration file but I understand that this could bring problems in the case of automatic updates (since web.xml is not easily replaceable). The criteria I was using was that if you have to specify class names in a config file, then it is internal. But this poses some issue for standard configuration files (xwiki.cfg and xwiki.properties) which contain class FQNs (though almost all of them come from the old core and could be replaced by more class-agnostic component hints) Anyway this is an open issue that need to be discussed. Thanks, Fabio