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