We Keep Coding

java.lang.NoSuchMethodError: org.jboss.logging.Logger.getMessageLogger in Tomcat(Ubuntu 16.04)

I 'm getting this exception when I am trying to deploy the .war file in Tomcat
java.lang.NoSuchMethodError: org.jboss.logging.Logger.getMessageLogger(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/Object;
at org.hibernate.ejb.Ejb3Configuration.<clinit>(Ejb3Configuration.java:142)
at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:55)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:63)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:47)
Please be aware that:
-The same .war file is already working on a different Server(Linux OpenSuse)
-I copied the Tomcat folder(all the server's) from the old server(OpenSuse) to the new server(Ubuntu 16.04). This way the files are the same.
-The JVM is the same in both of the servers.
-The exception does not happen during Development time(in Eclipse).
My questions are:
-Some people have suggested me to change my maven pom files. Does it make sense? Because as I said the .war is already working on the OpenSuse server.
-Should I be able to deploy the same.war without any change. Shouldn't I?

There is at-least one of the libraries missing in the server you are getting the error.
Check all libraries in the $PATH variables you are using in the server its working.
Hope this Helps!
Regards,
Eby

Tomcat/JNI: Loading native libraries outside of application

I'm tasked with integrating a collection of native libraries into a web application running in a Tomcat7 container.
I already found out that in order to be able to restart the application without restarting the whole server I must load the libs using the Tomcat "shared"-loader, outside the actual application.
For that I followed the accepted answer in this SO question: Shared JNI library (.so) in Tomcat - UnsatisfiedLinkError, but no luck so far.
As described I created a small "DLLBootstrapper" java class for loading the libs, compiled it and put it in "CATALINA_HOME/shared/lib" next to the libs I'm loading.
In the "catalina.properties" I set the path of the "shared.loader" to that folder.
However when I try to obtain the "DLLBootstrapper" in my application using Class.forName("msm.DLLBootstrapper"); I get a java.lang.ClassNotFoundException: msm.DLLBootstrapper.
What am I missing here?
Edit:
Sorry, forgot to mention java.library.path is set to the CATALINA_HOME/shared/lib folder.

org.apache.axiom.om.util.AXIOMUtil cannot be resolved

I'm trying to generate some stubs for a WSDL (using xmlbeans) and keep running into some issues. I'm using the following page:
http://axis.apache.org/axis2/java/core/docs/userguide-creatingclients-xmlbeans.html
The only part of these steps that I'm skipping is the "client.java" part because I already have another project ready I want to plug the resulting jars into. A quick run down of my steps are as follows:
My WSDL is a crmonline instance, so I run something like this:
C:\Work\aaa2>WSDL2Java -uri
https://mycrmorgname.crm.dynamics.com/XRMServices/2011/Organization.svc?wsdl
-p crmsdk -d xmlbeans -s -o c:\mystubfolder
I build the project using "ant"
In my "client" project I reference the 2 jars created in .\build\lib
My project builds fine once I add all my axis2 / apache references etc, but when I launch it through playframework I get errors when I hit the first page. The first error seems to be:
17:48:45,289 ERROR ~ Error in ControllersEnhancer.
controllers.ProfileController.editProfile has not been properly enhanced
(fieldAccess javassist.expr.FieldAccess#212ca458).
or something similar to that. Scrolling down through the error I can see that I'm getting this:
The file /app/models/MyDynamicsClient.java could not be compiled.
Error raised is : org.apache.axiom.om.util.AXIOMUtil cannot be resolved
Now, I haven't even hit any of my web services yet, or even instantiated any of my classes ... I'm at a loss as to why this is happening. Or to be more accurate, what exactly am I messing up! Am I missing a reference to something? Doing a search on AXIOMUtil tells me this should be in Axiom-api (version I have is Axiom-api-1.2.10.jar). I have this referenced and doesn't seem to help. Or maybe I'm doing something else wrong someplace?
Some details on versions:
Axis2 1.5.4
Apache-ant 1.8.3
Any help would be very much appreciated!!

Ok, after trying a lot of different things and rereading the sites/instructions I realised what I was doing wrong. Or at least I figured out a couple of things that I started to do differently that fixed the problem.
Firstly, I was using jar files from another sample project for the apache http components. I don't know if this had an impact, but I downloaded a fresh version of this anyway and referenced those JARS instead.
Also, instead of creating jars in my "stub" project and referencing those I copied all the generated stubs/classes directly into the existing client project. I have a feeling this might have been what fixed my problem. Or maybe a mix of this and the previous step I did!
So my new steps are as follows:
Ensure you have all the correct versions downloaded for required components. In my case I have the following:
Apache Axis 2 v 1.5.4
Apache HTTP components client 4.1.3
Apache-ant 1.8.3
Copy all the JARS from the Axis2 and HTTP Components libs into your client project and reference them.
Use WSDL2Java to create your stubs and classes within it's own project.
Ensure the project builds using Ant
Copy all the generated class files within the src folder into the source folder of your client.
Fix any other reference isssues and Build
Thankfully this got me going.

How to track down JAR with corrupt JAR Index that cause InvalidJarIndexException in Tomcat in Eclipse

I am working with development of an application which, among other pieces of code, contains a number of servlets. The development environment I use is Eclipse (3.2.1, which is rather old) in which I run a Tomcat server (5.5.23, rather old as well) using the Eclipse Tomcat Wrapper plug-in for the task. All this runs on a RedHat 5.2 Linux system.
The Java runtime I use is JDK 1.6.0(21), which I upgraded to (from a previous JDK 1.5 version) quite recently and as far as I can recall, the software combination above (together with the application I'm working with) did actually work: I could start the Tomcat server, it got up without errors or complaints and the application's servlets were available on port 8080.
However, something has changed somewhere (could be in the application jarfiles themselves, I'm suspicious of essentially everything on the host to be the root cause of this). Now, when I try to start up the Tomcat server, I get the error sun.misc.InvalidJarIndexException in the console output. This happens for the following classes and methods:
org.apache.commons.modeler.Registry registerComponent (happens 3 times)
org.apache.catalina.core.StandardServer initialize (happens once)
org.apache.catalina.connector.Connector start (happens twice)
I did find this stack overflow question regarding how to find the JAR of a Java Class useful and I did run find /usr -name \*name-of-suspected-jar\*.jar a few times to track down a number of suggested offending JARS. I also tried to check the runtime configuration of the Tomcat server in Eclipse, but could really not match the JAR files on the system with the CLASSPATH of neither the Tomcat runtime setup (or with the CLASSPATH used in the environment when starting Eclipse). That effort probably requires some more rigor on my part but before doing that (and that is why I right now don't post all the gory details regarding CLASSPATHs here), I did a read up on exactly what InvalidJarIndexException really is about.
So, JAR files may contain an optional INDEX.LIST file which contains information about what classes (and methods?) to find in the JAR file. The idea is to short-circuit the search throughout all JARS in the CLASSPATH which is useful in a number of circumstances. Problem is when the INDEX.LIST file happens to be corrupt (or, is believed to be corrupt), that causes the loading of the class to be completely given up (the class loader does not fall back to searching all JARs in the CLASSPATH) and the error InvalidJarIndexException to be thrown. To make things more messy, the order in which JARs are searched might affect how the class loader treats the INDEX.LIST file: the INDEX.LIST file of one JAR might refer to other JARS and if those referred to JARS are not in sync with the first JAR's INDEX.LIST file, the class loader fails with this InvalidJarIndexException error.
So (according to this StackOverflow question), it seems like this error can be thrown not only because a JAR file has a corrupt INDEX.LIST, it seems it can even be thrown on a JAR even if the JAR has a valid INDEX.LIST or legitimately is lacking a INDEX.LIST simply because a previously searched JAR has confused the class loader. (To put in another way, as things are, this exception might be thrown even for "innocent" non-corrupted JAR files due to offenders elsewhere on the system).
So, after writing a mere novel, here comes my main set of questions:
What is the best way to track down the precise .jar file for which each InvalidJarIndexException is thrown?
What is the best way check if a randomly picked .jar file has an INDEX.LIST file and if so, if said file is valid (that is, non-corrupt)? What tools exist for this task?
Is there an efficient way to automatically deduce the search order of .jar files? I can try to follow the CLASSPATH manually but to be honest, that is error prone and tedious.
Is there an efficient way to figure out what .jar file there is in a search order which might confuse the class loader to accuse innocent, non-corrupt .jar files later in the search to have incorrect INDEX.LIST files?
Disclaimer: I know I run old versions software (even if I have the latest updates of my Redhat 5.2 installed though) and I know a knee-jerk reaction for many people is to suggest that I don't put any effort whatsoever in debugging this but instead upgrade to a more recent version of Tomcat, Eclipse and Linux (Java is recent though). The reason I would prefer not to is that after looking into things, I've found it rather messy to do an upgrade or to try to install a separate modern Tomcat or Eclipse next to the RHEL5.2 provided Tomcat/Eclipse I use today. Also, I consider this kind of troubleshooting an opportunity to learn some useful nitty gritty details about Java and it's associated tools and features. Figuring out how the class loading works and what causes it to throw this InvalidJarIndexException on my system would be very educating!
(But if this troubleshooting fails, I'll seriously consider to use a modern Linux, Eclipse and Tomcat... I promise)

Take the following steps to diagnose the problem:
Add an exception breakpoint in Eclipse (it's the J with an
exclamation mark icon), and set it to halt for caught and uncaught
exceptions, of type InvalidJarIndexException.
Start debugging your program.
Eclipse will halt at your exception breakpoint, when the InvalidJarIndexException is thrown. Even without the source for URLClassPath, you will still be able to inspect the variables on the stack leading to the exception, including the name of the class that URLClassPath is attempting to locate. Knowing the name of the class should significantly narrow the list of JAR's you need to examine.
Perhaps you've locally added a new class to a package and the contents of that package are described by the index file in a stale JAR on your classpath?

Try Tattletale which is a good reporting tool for jars. What I have done in this case was to eliminate INDEX.LIST from jars one by one until I did not get InvalidJarIndexException any more

WebSphere App Server Not Compiling JSP/Tag Libs

This is a problem that only occurs on application update (only tested through Admin Console, not CLI). Also, this is only happening on our development environment, which is identical to our prod env. On uninstall/install, everything is compiled properly. However, this is a large application and it takes long enough to do an update--we do not want to uninstall/install everytime (esp. during dev. builds).
JSP .java and .smap files are being generated, but not .class. On prod, there is no .smap--only .java and .class. If the JSPs would compile, we believe the tag libs would be compiled also.
Has anyone faced this problem, or know what we are possibly overlooking?
WAS Version: 6.1.0.17
EDIT: This is only happening for one JSP and the tag library its using. We're trying to trouble shoot the issue. Let you know if we figure anything out. We think it may be an issue with the .SMAP file per this fix
SOLUTION

Solution:
Problem was: WAS had debugging enabled. This generated .smap files (source mappings) instead of .class files. Once we discovered this, we disabled the debugging service under the Admin Console (Application Servers > server1 > Debugging Processes > uncheck 'Start service'). I don't know why this created a bug upon an update only, but, whatever the case, the problem is solved.

One suggestion:
Have you checked that your environment has a JAVA_HOME pointing to a JDK and not just a JRE. The JRE doesn't have javac, so there won't be any way to compile .java files created at runtime by the JSP compiler into .classes?
EDIT: Also, perhaps this link may help?

I haven't worked with taglibs, but I can tell you this:
the application server checks timestamps. be very very sure that the "modified" timestamps of the JSP files are reasonable from the point of view of the application server (say, are not in the future)
Hope this helps you solve the problem...