Hi,
I agree with Sergey, this is something CXF should *not* directly deal with.
Btw, I recently worked on a similar integration issue in JBossWS and
made it possible to override the DestinationRegistryImpl#getTrimmedPath
method [1]; that could possibly be used by the user here to provide a
custom DestinationRegistry that properly deals with his edge case (I
have something similar in JBossWS integration with Apache CXF).
Cheers
Alessio
[1] https://issues.apache.org/jira/browse/CXF-5523
On 20/02/14 22:14, Sergey Beryozkin wrote:
Hi
It is not a CXF bug and I don't think CXF should start messing with
replacing whatever HttpServletRequest container returns.
We can end up with the inconsistency introduced into the flow, example, CXF
will remove the 'redundant' "/", then the code injected with
HttpServletRequest will see a "//", this can also be hidden but I doubt we
can hide the actual request URI.
In fact, when we have something like "//cxf" then how we can even know "/"
is redundant, it can be a context itself, a single "/", "//" is a perfectly
valid path component value, meaning if we get rid of the first "/" we can
end up reporting a wrong context, "/cxf".
What happens when you see HttpServletRequest reporting "//cxfservices", how
do you see it affecting the actual invocation ?
Sergey
--
View this message in context:
http://cxf.547215.n5.nabble.com/BaseUrlHelper-bug-cxf-2-5-x-2-7-x-or-Servlet-Container-bug-tp5740261p5740271.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
Alessio Soldano
Web Service Lead, JBoss
