Error "com.sun.jersey.core.spi.scanning.ScannerException" seen whilst using Artifactory on WebSphere Liberty Profile

I'm tinkering with a new (to me) tool, JFrog Artifactory, which is a Universal Repository Manager, on IBM WebSphere Liberty Profile (WLP).

My objective is to run Artifactory on WLP within a Docker container.

However, I wanted to ensure that it worked on WLP, before adding the additional "complexity" of Docker.

This is in line with my "Make a change, test a change" approach to life, the universe, and everything.

I'm doing this on my Mac using the latest version of WLP: -

wlp-webProfile7-16.0.0.2.zip

This is my configuration: -

 ~/Downloads/wlp/usr/servers/defaultServer/server.xml

<?xml version="1.0" encoding="UTF-8"?>
<server description="new server">

    <!-- Enable features -->
    <featureManager>
        <feature>webProfile-7.0</feature>
        <feature>adminCenter-1.0</feature>
    </featureManager>

    <classloading useJarUrls="true"/>

    <quickStartSecurity userName="admin" userPassword="password"/>

    <keyStore id="defaultKeyStore" password="Liberty"/>

    <!-- To access this server from a remote client add a host attribute to the following element, e.g. host="*" -->
    <httpEndpoint id="defaultHttpEndpoint"
                  httpPort="9080"
                  httpsPort="9443" />
                  
    <!-- Automatically expand WAR files and EAR files -->
    <applicationManager autoExpand="true"/>

    <remoteFileAccess>
        <writeDir>${server.config.dir}</writeDir>
    </remoteFileAccess>

</server>

and I merely dropped the Artifactory WAR file into the dropins folder: -

 ~/Downloads/wlp/usr/servers/defaultServer/dropins/

-rw-r--r--@ 1 davidhay  staff  37669474 27 Aug 09:39 artifactory.war

However, once I started Liberty: -

~/Downloads/wlp/bin/server start

and tried to access Artifactory: -

https://localhost:9443/artifactory/

things went a bit awry: -

2016-08-27 09:43:16,097 [art-init] [INFO ] (o.a.s.ArtifactoryApplicationContext:404) - Artifactory application context is ready.
2016-08-27 09:43:16,103 [art-init] [INFO ] (o.a.w.s.ArtifactoryContextConfigListener:221) - 
###########################################################
### Artifactory successfully started (6.843 seconds)    ###
###########################################################

2016-08-27 09:43:16,122 [art-init] [ERROR] (o.a.w.s.ArtifactoryContextConfigListener:110) - Could not init org.artifactory.rest.servlet.ArtifactoryRestServlet.
javax.servlet.ServletException: java.lang.reflect.InvocationTargetException
at com.sun.jersey.spi.container.servlet.WebComponent.createResourceConfig(WebComponent.java:728) ~[jersey-servlet-1.19.jar:1.19]
at com.sun.jersey.spi.container.servlet.WebComponent.createResourceConfig(WebComponent.java:674) ~[jersey-servlet-1.19.jar:1.19]
at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:205) ~[jersey-servlet-1.19.jar:1.19]
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:394) ~[jersey-servlet-1.19.jar:1.19]
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:577) ~[jersey-servlet-1.19.jar:1.19]
at javax.servlet.GenericServlet.init(GenericServlet.java:244) ~[com.ibm.ws.javaee.servlet.3.1_1.0.13.jar:na]
at org.artifactory.rest.servlet.ArtifactoryRestServlet.delayedInit(ArtifactoryRestServlet.java:73) ~[artifactory-rest-4.11.2.jar:na]
at org.artifactory.webapp.servlet.ArtifactoryContextConfigListener$1.run(ArtifactoryContextConfigListener.java:108) ~[artifactory-web-application-4.11.2.jar:na]
Caused by: java.lang.reflect.InvocationTargetException: null
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[na:1.8.0_101]
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) ~[na:1.8.0_101]
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[na:1.8.0_101]
at java.lang.reflect.Constructor.newInstance(Constructor.java:423) ~[na:1.8.0_101]
at com.sun.jersey.spi.container.servlet.WebComponent.createResourceConfig(WebComponent.java:724) ~[jersey-servlet-1.19.jar:1.19]
... 7 common frames omitted
Caused by: com.sun.jersey.core.spi.scanning.ScannerException: The URI scheme wsjar of the URI wsjar:file:/Users/davidhay/Downloads/wlp/usr/servers/defaultServer/apps/expanded/artifactory.war/WEB-INF/lib/artifactory-common-4.11.2.jar!/org/artifactory/rest is not supported. Package scanning deployment is not supported for such URIs.

Apparently this is a known issue with certain OSS frameworks such as Hadoop and Jersey :-(

Thankfully, there's a solution …

PM99378: ALLOW LIBERTY PROFILE TO RETURN JAR URLS RATHER THAN WSJAR URLS FROM CLASSLOADERS.

…

Some open source frameworks throw errors when trying to process "wsjar:" URIs and WebSphere Application Server Liberty profile server does not provide a mechanism to return to "jar:" URIs.

The configuration element below can be added to the server.xml

file to enforce the JVM wide usage of "jar:" rather than

"wsjar:".

<classloading useJarUrls="true"/>

…

Once I restarted my server.xml : -

<?xml version="1.0" encoding="UTF-8"?>
<server description="new server">

    <!-- Enable features -->
    <featureManager>
        <feature>webProfile-7.0</feature>
        <feature>adminCenter-1.0</feature>
    </featureManager>

    <classloading useJarUrls="true"/>

    <quickStartSecurity userName="admin" userPassword="password"/>

    <keyStore id="defaultKeyStore" password="Liberty"/>

    <!-- To access this server from a remote client add a host attribute to the following element, e.g. host="*" -->
    <httpEndpoint id="defaultHttpEndpoint"
                  httpPort="9080"
                  httpsPort="9443" />

    <!-- Automatically expand WAR files and EAR files -->
    <applicationManager autoExpand="true"/>

    <remoteFileAccess>
        <writeDir>${server.config.dir}</writeDir>
    </remoteFileAccess>

</server>

and restarted my server, all was well: -