https://bz.apache.org/bugzilla/show_bug.cgi?id=66171
--- Comment #14 from Felix Schumacher ---
Thanks for the PR. It looks promising to me. (Must have misunderstood your
second comment ;))
I personally think it is a good thing to have dependencies removed, when they
are duplicated (we have that
https://bz.apache.org/bugzilla/show_bug.cgi?id=66171
--- Comment #13 from PJ Fanning ---
I have done a PR that is just a POC showing that xalan can probably be removed.
https://github.com/apache/jmeter/pull/721
I can continue work on this POC - but I would like to know if it is worthwhile.
It
https://bz.apache.org/bugzilla/show_bug.cgi?id=66171
--- Comment #12 from Vladimir Sitnikov ---
> Noone benefits from keeping a project alive when there are not enough
> maintainers
The CVE is trivial to fix, and it would help A LOT of users who depend on xalan
today. They will be able to
https://bz.apache.org/bugzilla/show_bug.cgi?id=66171
--- Comment #11 from PJ Fanning ---
https://lists.apache.org/thread/2qvl7r43wb4t8p9dd9om1bnkssk07sn8
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=66171
--- Comment #10 from PJ Fanning ---
Xalan is being putting in the ASF attic. The PMC is inactive. Noone benefits
from keeping a project alive when there are not enough maintainers. Java
runtime XPath support and Saxon are very valid
https://bz.apache.org/bugzilla/show_bug.cgi?id=66171
--- Comment #9 from Vladimir Sitnikov ---
I just wonder: is xalan-j really that bad?
What if we just fix the CVE in question and release a newer Xalan version?
Then **everybody** would benefit from that.
--
You are receiving this mail
https://bz.apache.org/bugzilla/show_bug.cgi?id=66171
--- Comment #8 from PJ Fanning ---
https://docs.oracle.com/javase/9/docs/api/javax/xml/xpath/XPath.html#evaluateExpression-java.lang.String-org.xml.sax.InputSource-
was only added in Java 9 but would do exactly what you need - see
https://bz.apache.org/bugzilla/show_bug.cgi?id=66171
--- Comment #7 from Felix Schumacher ---
Another problem I found, is that we guess the return of xpath expressions. The
standard XPath api has no such capability. At least, I haven't found it yet.
Such guessing takes place in
https://bz.apache.org/bugzilla/show_bug.cgi?id=66171
--- Comment #6 from Felix Schumacher ---
I tried to get rid of the xalan dependency by removing it from the usual places
in the gradle files, but it seems that other libraries build steps (ant?) have
dependencies on them and bring xalan back
https://bz.apache.org/bugzilla/show_bug.cgi?id=66171
--- Comment #5 from PJ Fanning ---
Without xalan, it looks like XPathUtil would need to be rewritten - the 3
imports starting with
https://github.com/apache/jmeter/blob/master/src/core/src/main/java/org/apache/jmeter/util/XPathUtil.java#L52
https://bz.apache.org/bugzilla/show_bug.cgi?id=66171
--- Comment #4 from Vladimir Sitnikov ---
We have public class PropertiesBasedPrefixResolver extends
org.apache.xml.utils.PrefixResolverDefault, so we have non-trivial usage of
xalan. It does not sound like "just remove runtime-only
https://bz.apache.org/bugzilla/show_bug.cgi?id=66171
Felix Schumacher changed:
What|Removed |Added
Status|NEEDINFO|NEW
--- Comment #3 from Felix
https://bz.apache.org/bugzilla/show_bug.cgi?id=66171
--- Comment #2 from PJ Fanning ---
I'm a member of the ASF Security committee and I'm just trying to nudge PMCs to
keep their dependencies up to date. I do a lot of PRs for ASF teams but I'm
getting to the stage where I'm getting a bit fed up
https://bz.apache.org/bugzilla/show_bug.cgi?id=66171
Felix Schumacher changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #1 from Felix
14 matches
Mail list logo
