0

I got a new project which I wanted to work with in Intellij. As local server we use Tomcat 7.0.68 and JDK 1.8.

This is my configuration in tomcat.

lib/catalina/org/apache/catalina/startup/Authenticators.properties:

NIGHTSHIFT=com.glit.swidA9O.v1.authenticator.NightShiftAuthenticator

conf/catalina.properties:

common.loader=${catalina.base}/lib,${catalina.base}/lib/*.jar,/Users/Administrator/dev/server/apache-tomcat-7.0.68/shared/nightShift/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar

conf/context:

<Valve className="com.glit.swidA9O.v1.authenticator.NightShiftAuthenticator" changeSessionIdOnAuthentication="true"/>

<Loader className="org.apache.catalina.loader.VirtualWebappLoader"
        virtualClasspath="/Users/Administrator/dev/PROJECT/config;/Users/Administrator/dev/PROJECT/data"/>

conf/server.xml

<Engine name="Catalina" defaultHost="localhost">

  <!--For clustering, please take a look at documentation at:
      /docs/cluster-howto.html  (simple how to)
      /docs/config/cluster.html (reference documentation) -->
  <!--
  <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
  -->
  <Realm className="com.glit.swidA7U.v1.realm.NightShiftRealm" roleClassNames="com.glit.swidBS0.v1.shared.principals.NightShiftGroup" userClassNames="com.glit.swidBS0.v1.shared.principals.NightShiftUser"/>

  <!-- Use the LockOutRealm to prevent attempts to guess user passwords
       via a brute-force attack -->
  <Realm className="org.apache.catalina.realm.LockOutRealm">
    <!-- This Realm uses the UserDatabase configured in the global JNDI
         resources under the key "UserDatabase".  Any edits
         that are performed against this UserDatabase are immediately
         available for use by the Realm.  -->
    <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
           resourceName="UserDatabase"/>
  </Realm>

  <Host name="localhost"  appBase="webapps"
        unpackWARs="true" autoDeploy="true">

    <!-- SingleSignOn valve, share authentication between web applications
         Documentation at: /docs/config/valve.html -->
    <!--
    <Valve className="org.apache.catalina.authenticator.SingleSignOn" />
    -->

    <!-- Access log processes all example.
         Documentation at: /docs/config/valve.html
         Note: The pattern used is equivalent to using pattern="common" -->
    <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
           prefix="localhost_access_log." suffix=".txt"
           pattern="%h %l %u %t &quot;%r&quot; %s %b" />

  </Host>
</Engine>

Our problem

Inside our local tomcat server we want to use a specific library called "NightShift". Unfortunately every time we try to build our application with intellij/tomcat we get this error somehow:

Complete stacktrace

Which is funny because if we try to build the application with eclipse tomcat runs smoothly and can actually build the project properly.

Those are the settings for Intellij/Tomcat we made:

first

second

third

These are my vm-options (actually I don't even know if you need this but just in case):

-DLOG4J2-ROOT=/Users/Administrator/dev/PROJECT/data/logs
-Djava.security.auth.login.config=/Users/Administrator/dev/PROJECT/config/NightShift-config/common/NightShiftJAAS.conf
-Dpu8.config.path=/Users/Administrator/dev/PROJECT/config/NightShift-config
-Dpu8.configuration.id=A7U
-Dpu8.environment=ide
-Djava.util.logging.config.file=/Users/Administrator/dev/PROJECT/config/NightShift-config/log-config.properties
-Djava.security.manager
-Djava.security.policy="/Users/Administrator/dev/server/apache-tomcat-7.0.68/conf/catalina.policy"

This is what our tomcat looks like:

fourth

Inside "shared" is a folder called "nightshift" and there are all the neccessary .jar files which we mentioned in the catalina.properties file.

Inside our artifacts we didn't include the "nightshift" jars, cause we want it installed in tomcat and not in our application.

mkrieger1
  • 19,194
  • 5
  • 54
  • 65
  • 1
    The **complete** stacktrace (with nested exceptions) should explain the cause of the exception. – Stephen C Feb 05 '19 at 22:58
  • Hi Stephen :) Ups! I totally forgot to put the whole stacktrace. I edited my post and added a link which should navigate everybody to a stacktrace.txt file. It contains everything the compiler printed me out. – Luca Archidiacono Feb 05 '19 at 23:11

1 Answers1

1

There appears to be a problem with your application's logging initialization:

 Caused by: java.util.NoSuchElementException
    at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:365)
    at java.util.ServiceLoader$LazyIterator.access$700(ServiceLoader.java:323)
    at java.util.ServiceLoader$LazyIterator$2.run(ServiceLoader.java:407)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:409)
    at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
    at com.glit.swidPV4.v1.common.log.LogFactory.getInstance(LogFactory.java:32)
    at com.glit.swidPV4.v1.common.log.LogFactory.getLog(LogFactory.java:42)
    at com.glit.swidA7R.v1.businessdelegate.VerifierBDFactory.<clinit>(VerifierBDFactory.java:29)
    ... 75 more

It looks like it is looking for a service provider that doesn't exist, and then failing to deal with that properly. That leads to a runtime exception which cascades into other things.

  1. Look at the source code for com.glit.swidPV4.v1.common.log.LogFactory to figure out what what it is looking for.

  2. Figure out why it is missing. My guess would be a missing / misplaced JAR file or a missing / misplaced config file.

  3. Fix it.

  4. (Maybe) fix the LogFactory code to be more resilient ... or to throw a custom exception rather than just bombing out with an obscure NoSuchElementException.

Figuring out remotely where JAR and config files should be for your particular case is too difficult. But this is just standard Java / Tomcat troubleshooting ... once you have figured out what is causing the problem.


Unfortunately every time we try to build our application with intellij/tomcat we get this error:

One "solution" would be to switch to using Maven or something to build WAR files, and test / deploy them by hand rather than relying of the "shiny" Intellij integration stuff.

(You shouldn't be hot deploying into a production server anyway. That's poor practice. You are one mistake away from trashing your production env. And if this is just a dev / test environment, it is a good idea to get into the habit of doings things the right way in dev.)

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216