[
https://issues.apache.org/jira/browse/SLING-8404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16836999#comment-16836999
]
Hans-Peter Stoerr edited comment on SLING-8404 at 5/10/19 7:48 AM:
-------------------------------------------------------------------
[~kwin]: I agree to what [[email protected]] says. In my specific case
we used the method
org.apache.commons.beanutils.ConvertUtils#convert(java.lang.Object,
java.lang.Class) from commons-beanutils 1.8.3 in our code. After including
sling.xss as a new dependency I suddenly got a compile error that this method
was missing. It took me a while to figure that out, since maven just showed a
dependencency to version commons-beanutils 1.8.3 which we explicitly had in our
pom.xml. Then I discovered that was because the sling.xss jar contains exactly
that class, too, and that appeared in the classpath before commons-beanutils
1.8.3 , so it got loaded instead.
In that artefact I made the workaround that I included the commons-beanutils
dependency before sling.xss in the pom, and made sling.xss optional to not
pollute the downwards artefacts with it's embedded stuff. But that's a brittle
and ugly solution, and I still have all those libraries that are embedded in
the sling.xss jar in this artefact's classpath, which could cause more trouble
later. :(
was (Author: hanspeterstoerr):
[~kwin]: I agree to what [[email protected]] says. In my specific case
we used the method
org.apache.commons.beanutils.ConvertUtils#convert(java.lang.Object,
java.lang.Class) from commons-beanutils 1.8.3 in our code. After including
sling.xss as a new dependency I got a compile error. It took me a while to
figure that out, since maven just showed a dependencency to version
commons-beanutils 1.8.3 which we explicitly had in our pom.xml. Then I
discovered that was because the sling.xss jar contains exactly that class, too,
and that appeared in the classpath before commons-beanutils 1.8.3 , so it got
loaded instead.
In that artefact I made the workaround that I included the commons-beanutils
dependency before sling.xss in the pom, and made sling.xss optional to not
pollute the downwards artefacts with it's embedded stuff. But that's a brittle
and ugly solution, and I still have all those libraries that are embedded in
the sling.xss jar in this artefact's classpath, which could cause more trouble
later. :(
> Provide an API-JAR for the XSS Protection API
> ---------------------------------------------
>
> Key: SLING-8404
> URL: https://issues.apache.org/jira/browse/SLING-8404
> Project: Sling
> Issue Type: Improvement
> Components: XSS Protection API
> Affects Versions: XSS Protection API 2.0.12, XSS Protection API 2.1.8
> Reporter: Hans-Peter Stoerr
> Priority: Minor
>
> The JAR for the org.apache.sling.xss exports only one package,
> org.apache.sling.xss, but embeds loads of dependencies it does not export
> with OSGI. If one needs this as a maven dependency, you get all that unwanted
> stuff in your classpath. In our case it even produced very puzzling compile
> errors, since org.apache.sling.xss included commons-beanutils version 1.7.0,
> and we used a new method from version 1.8.3.
> So, could you please provide an API jar that only contains the
> org.apache.sling.xss package? It's interface is so simple that this wouldn't
> have many dependencies.
> In case someone else has that problem: we worked around that for now by
> setting org.apache.sling.xss to optional and explicitly importing it only
> where that's actually needed in the code. Thus, at least it does not mess up
> the classpaths of the artefacts further down the dependency chain; sometimes
> it had to be included in test scope, though.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
