Develop Reference

how to add jsf com.sun.faces in websphere 9

I want to start my app using com.sun.faces jsf and primefaces dependency in websphere 9.
The part of pox.xml:
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-api</artifactId>
<version>2.1.13</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-impl</artifactId>
<version>2.1.13</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.primefaces</groupId>
<artifactId>primefaces</artifactId>
<version>6.2</version>
</dependency>
I added jsf-impl-2.2.8-30.jar and jsf-api-2.2.8-30.jar to shared libs in WebSphere (Enterprise Applications > app_name > Shared library references, for application and for module) and got exception in log:
Could not invoke an operation on object: WebSphere:name=ApplicationManager,process=server1,platform=proxy,node=OPOLSKYNode01,version=9.0.0.9,type=ApplicationManager,mbeanIdentifier=ApplicationManager,cell=OPOLSKYNode01Cell,spec=1.0 because of an mbean exception: com.ibm.ws.exception.RuntimeError: java.lang.RuntimeException: com.ibm.ws.cdi.CDIRuntimeException: com.ibm.ws.cdi.CDIDeploymentRuntimeException: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:
Exception 0 :
javax.enterprise.event.ObserverException
at java.lang.J9VMInternals.newInstanceImpl(Native Method)
....
Caused by: java.util.ServiceConfigurationError: com.sun.faces.util.cdi11.CDIUtil: Provider com.sun.faces.util.cdi11.CDIUtilImpl not a subtype
...
Later I found that there was a warning written in websphere (Enterprise Applications > app_name > JSP and JSF options):
Version 9.0 and later nodes use the MyFaces JSF implementation, even if SunRI is selected in a mixed-cell environment. For more configuration information, read about JavaServer Faces in the product documentation.
And I tried to add a shared libraries with mojarra-jsf-impl-2.0.0-b04.jar and mojarra-jsf-api-2.0.0-b04.jar
but got:
com.ibm.ws.classloader.CompoundClassLoader#bce1c60f[war:isclite/isclite.war]
Local ClassPath: C:\Program Files\IBM\WebSphere\AppServer\systemApps\isclite.ear\isclite.war\WEB-INF\classes;C:\Program Files\IBM\WebSphere\AppServer\systemApps\isclite.ear\isclite.war\WEB-INF\lib\abdera.client.0.2.2-incubating.jar;C:\Program
...
00000093 annotations W ScannerContextImpl getInputDataForClass Class loader [
com.ibm.ws.classloader.CompoundClassLoader#2d433080[app:isclite]
Local ClassPath: C:\Program Files\IBM\WebSphere\AppServer\systemApps\isclite.ear\lib\batik-all.jar;C:\Program
...
Help me please!
Is it possible to start app with jsf dependency in websphere ?

Jboss 6.4 Infinispan 8.2 and JGroups - ClassNotFoundException

I need some features from Infinispan 8+. Therefore I have updated my company app pom.xml with the newest Infinispan pom.
It was quite straightforward, but the app uses jgroups (or its default config in default-configs/default-jgroups-udp.xml - this location is different from previous versions of infinispan). The default versions have some parameters (and the XSD from Jgroups version 3.6) - so I also bumped jgroups to 3.6.8.Final as it looks like it is the intended version (and the version that does not complain about unknown parameters in default config in infinispan 8.2)
so the pom is the following:
<dependency>
<groupId>org.jgroups</groupId>
<artifactId>jgroups</artifactId>
<version>3.6.8.Final</version>
</dependency>
<dependency>
<groupId>org.infinispan</groupId>
<artifactId>infinispan-core</artifactId>
<version>8.2.0.Final</version>
</dependency>
Anyway - this application starts with no problems using spring-boot with Jetty. I am pretty sure it would start on any application server.
But then I have no choice but to run it on JBoss 6.4.
There I got an exception involving some jboss.as classes (this is kind of unexpected) during the deployment:
Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object of type JGroupsTransport
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:859)
at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:628)
at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:617)
at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:542)
at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:234)
... 141 more
Caused by: java.lang.ExceptionInInitializerError
at org.jgroups.conf.XmlConfigurator.<clinit>(XmlConfigurator.java:35)
at org.jgroups.conf.ConfiguratorFactory.getStackConfigurator(ConfiguratorFactory.java:62)
at org.jgroups.JChannel.<init>(JChannel.java:129)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:419)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:320)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:366)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:190)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
... 146 more
Caused by: java.lang.RuntimeException: java.lang.ClassNotFoundException: org.jboss.as.clustering.jgroups.LogFactory from [Module "deployment.mymodule-5.0.0.0-SNAPSHOT.ear.appName.war:main" from Service Module Loader]
at org.jgroups.logging.LogFactory.<clinit>(LogFactory.java:31)
... 158 more
Caused by: java.lang.ClassNotFoundException: org.jboss.as.clustering.jgroups.LogFactory from [Module "deployment.mymodule-5.0.0.0-SNAPSHOT.ear.appName.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at org.jgroups.logging.LogFactory.<clinit>(LogFactory.java:28)
... 158 more
My guess is that org.jgroups.logging.LogFactory somehow discovers that is is running on a Jboss and tries to use org.jboss.as.clustering.jgroups.LogFactory but this version of Jboss does not have one. (the server directory EAP-6.4.0\modules\system\layers\base\org\jgroups\main contains jgroups version 3.2.X).
Is there any walkaround to use this jgroups version (and so Infinispan 8.2) in Jboss 6.4?
This is (the application) an ear file so I can manipulate jboss-deployment-structure.xml file, but so far I only came with excluding Jboss original jgroups, and this did not help.
<exclusions>
<module name="org.jgroups"/>
</exclusions>

This is currently bug with Infinispan 8 + EAP 6.4 combination. The reason is exactly as #Flavius says in comments. Currently there is discussion where to fix it, but it'll mostly likely be fixed in EAP 6.4. I'm sure it will be done soon.
I can only offer you a working workarounds.
Use WildFly - the issue is not present there anymore
Little nasty workaround, but it works:
Call System.clearProperty("jgroups.logging.log_factory_class"); in the deployment
Include JBoss Logging of version specified in infinispan-bom in your deployment (e.g. add jboss-logging Maven dependency in your pom.xml)
Provide jboss-deployment-structure.xml to your deployment, which excludes the server's JBoss logging, see below:
<jboss-deployment-structure>
<deployment>
<exclusions>
<module name="org.jboss.logging" />
</exclusions>
</deployment>
</jboss-deployment-structure>

Another possibility if none of the above workarounds work (for instance the app uses other log mechanisms) is to implement an own
http://www.jgroups.org/javadoc/org/jgroups/logging/CustomLogFactory.html
The log factory must return a log instance, implementing it for any other logger is straightforward with methods trace/error/debug etc.
Then this logger class can be set with System.setProperty("jgroups.logging.log_factory_class","my.company.logging.MyJgroupsLog");

Resteasy deploy fails randomly on glassfish 4.1

I have a problem with my REST-Application using Resteasy.
When I deploy the application with this dependencies
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-servlet-initializer</artifactId>
<version>3.0.11.Final</version>
</dependency>
as described here in Chapter 3.5 sometimes the server deploys the application correctly and everything works fine.
But sometimes I get
Error invoking ServletContainerInitializer
org.jboss.resteasy.plugins.servlet.ResteasyServletInitializer
java.lang.NullPointerException
at org.jboss.resteasy.plugins.servlet.ResteasyServletInitializer.register(ResteasyServletInitializer.java:109)
at org.jboss.resteasy.plugins.servlet.ResteasyServletInitializer.onStartup(ResteasyServletInitializer.java:80)
at org.apache.catalina.core.StandardContext.callServletContainerInitializers(StandardContext.java:6031)
at com.sun.enterprise.web.WebModule.callServletContainerInitializers(WebModule.java:774)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5929)
at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2286)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1932)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:500)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:406)
at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:243)
at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:329)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:377)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:461)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:227)
at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:84)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2258)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:105)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:1162)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:1147)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
]]
In the sources of ResteasyServletInitializer line 109 is this (with context)
ServletRegistration.Dynamic reg = servletContext.addServlet(applicationClass.getName(), HttpServlet30Dispatcher.class);
reg.setLoadOnStartup(1); //Line 109
reg.setAsyncSupported(true);
reg.setInitParameter("javax.ws.rs.Application", applicationClass.getName());
So I assume this is a Glassfish bug and Glassfish fails to properly return the correct object.
I have not found that this happens with redeployments, after clearing osgi-cache, etc. It seems to be pretty random.
This seems to be related and I tried adding
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
<scope>provided</scope>
</dependency>
But it still fails sometimes although I would say it fails a little bit less often.
The accepted answer from the post is deprecated as by the resteasy reference 3.9. RESTEasy as a ServletContextListener so I do not want to try this.
This seems like avoiding the problem, not solving it.
My Glassfish version is GlassFish Server Open Source Edition 4.1 (build 13).
Please help me with this one.
Cheers

I ended up avoiding this issue by ensuring the application WAR did not include RESTEasy.
So I build two wars now: one with RESTEasy (as required for deploying on Tomcat and Wildfly), another without (for deploying on Glassfish). That seems better than requiring changing the Glassfish install, but accomplishes the same: avoids having two JAX-RS implementations installed.

NoSuchMethodError on startup in Java Jersey app

I've been getting a very strange error when trying to start a Jersey app on Tomcat. The same code works on other computers. I tried reinstalling tomcat, all my maven dependencies, even Eclipse and Java itself, no luck. It seems like a bad Jersey version is being loaded, I think?
Any pointers in the right direction will be appreciated.
Here's the effective pom: http://pastebin.com/NacsWTjz
And the actual pom: http://pastebin.com/H6sHe4ce
2015-02-13 13:43:40,870 [localhost-startStop-1] ERROR org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/middleware-server] - StandardWrapper.Throwable
java.lang.NoSuchMethodError: javax.ws.rs.core.Application.getProperties()Ljava/util/Map;
at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:304)
at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:285)
at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:311)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:170)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:358)
at javax.servlet.GenericServlet.init(GenericServlet.java:158)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1231)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1144)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1031)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4901)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5188)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1409)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1399)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

Note: Please see above comments for further discussion and tips.
This error usual means that you have a both a JAX-RS 1 and JAX-RS 2 jar on the classpath. Jersey 2 uses JAX-RS 2 (javax.ws.rs-api-2.0.1.jar), but if you have the jsr311-api.jar also, which is JAX-RS 1, there is a javax.ws.rs.core.Application in each jar. But the jsr311-api Application doesn't have the method getProperties() (hence NoSuchMethodError).
I've come to the conclusion that all you need to do is add the above exclusion to the swagger dependency. The Jackson 2.0 provider (which depends on JAX-RS 1) seems to be overridden by a 2.4.1 provider (which uses the new version). So we don't need to add it ourselves. When it's overridden, it seems to leave behind the jsr311-api.jar. So if we exclude it, no one can attempt to use it, which looks to be the current problem
<dependency>
<groupId>com.wordnik</groupId>
<artifactId>swagger-core_2.10</artifactId>
<version>1.3.11</version>
<exclusions>
<exclusion>
<groupId>javax.ws.rs</groupId>
<artifactId>jsr311-api</artifactId>
</exclusion>
</exclusions>
</dependency>

We are using jersey-json 1.9 which has a dependency on jersey-core which also happen to have a javax.ws.rs.core.Application class.
So our fix is to exclude the jersey-core from jersey-json:
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-json</artifactId>
<version>1.9</version>
<exclusions>
<exclusion>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-core</artifactId>
</exclusion>
</exclusions>
</dependency>

the problem is related about "com.sun.jersey:jersey-core:jar:1.18.3" (or any 1.* version) because old versions of Jersey didn't have that "public Map getProperties()" method.
And one of your dependencies use Jersey version 1 (you can check that in running mvn dependency:tree and search all jersey-core version used)
Me I have resolved the problem deleting all com.sun.jersey dependancies (old api) and using the new one org.glassfish.jersey API
https://mvnrepository.com/artifact/org.glassfish.jersey.core

org.apache.tomcat.util.bcel.classfile.ClassFormatException: Invalid byte tag in constant pool: 15

I'm porting a webapp from Tomcat 7 to another server with Tomcat 7 but with Java 8.
Tomcat starts successfully but in log catalina.out I get:
org.apache.tomcat.util.bcel.classfile.ClassFormatException: Invalid byte tag in constant pool: 15
at org.apache.tomcat.util.bcel.classfile.Constant.readConstant(Constant.java:131)
at org.apache.tomcat.util.bcel.classfile.ConstantPool.<init>(ConstantPool.java:60)
at org.apache.tomcat.util.bcel.classfile.ClassParser.readConstantPool(ClassParser.java:209)
at org.apache.tomcat.util.bcel.classfile.ClassParser.parse(ClassParser.java:119)
at org.apache.catalina.startup.ContextConfig.processAnnotationsStream(ContextConfig.java:2049)
at org.apache.catalina.startup.ContextConfig.processAnnotationsJar(ContextConfig.java:1931)
at org.apache.catalina.startup.ContextConfig.processAnnotationsUrl(ContextConfig.java:1899)
at org.apache.catalina.startup.ContextConfig.processAnnotations(ContextConfig.java:1885)
at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1281)
at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:855)
at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:346)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5172)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:899)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:875)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:618)
at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1100)
at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1618)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
What could be the problem?

The "offical answer" is that Tomcat 7 runs on Java 8, see
http://tomcat.apache.org/whichversion.html ("Java version 6 and later").
However, if annotation scanning is enabled (metadata-complete="true" in web.xml) there are some issues due to BCEL (not able to process the new Java 8 byte codes). You will get exceptions like (at least with Tomcat 7.0.28):
SEVERE: Unable to process Jar entry [jdk/nashorn/internal/objects/NativeString.class] from Jar [jar:file:/usr/lib/jvm/jdk1.8.0_5/jre/lib/ext/nashorn.jar!/] for annotations
org.apache.tomcat.util.bcel.classfile.ClassFormatException: Invalid byte tag in constant pool: 15
at org.apache.tomcat.util.bcel.classfile.Constant.readConstant(Constant.java:131)
If not using annotation scanning, everything works fine, starting release 7.0.53 (updated compiler with better Java 8 support).
(UPDATE 2014-10-17)
If your are using annotation scanning and your own code is not Java 8 based, another solution is to add the following line in /etc/tomcat7/catalina.properties (text added after "ant-launcher.jar" so part of property tomcat.util.scan.DefaultJarScanner.jarsToSkip):
junit.jar,junit-*.jar,ant-launcher.jar,\
jfxrt.jar,nashorn.jar
Tested with Tomcat 7.0.28 and Oracle JDK 8_25 on Debian 7.6.

This was a Tomcat bug that resurfaced again with the Java 9 bytecode. The exact versions which fix this (for both Java 8/9 bytecode) are:
trunk for 9.0.0.M18 onwards
8.5.x for 8.5.12 onwards
8.0.x for 8.0.42 onwards
7.0.x for 7.0.76 onwards

Update to Tomcat 7.0.58 (or newer).
See: https://bz.apache.org/bugzilla/show_bug.cgi?id=57173#c16
The performance improvement that triggered this regression has been
reverted from from trunk, 8.0.x (for 8.0.16 onwards) and 7.0.x (for
7.0.58 onwards) and will not be reapplied.

This issue is happening because you have installed jre1.8.0_101-1.8.0_101-fcs.i58.rpm as well jdk-1.7.0_80-fcs.x86_64.rpm. so just uninstall your jre rpm & restart your application. It should work out.

Unable to process Jar entry [module-info.class] from Jar [jar:file:/xxxxxxxx/lombok-1.18.4.jar!/] for annotations
org.apache.tomcat.util.bcel.classfile.ClassFormatException: Invalid byte tag in constant pool: 19
1.update and append below argument in <root or instance tomcat folder>/conf/catalina.properties
org.apache.catalina.startup.ContextConfig.jarsToSkip=...,lombok-1.18.4.jar
2.clean and deploy the to-be-published project.

To me, upgrading bcel to 6.0 fixed the problem.

For me it worked, by removing the jars in question from the war.
With Maven, I just had to exclude for example
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-jaxb-provider</artifactId>
<version>${resteasy.version}</version>
<exclusions>
<exclusion>
<groupId>com.sun.istack</groupId>
<artifactId>istack-commons-runtime</artifactId>
</exclusion>
<exclusion>
<groupId>org.jvnet.staxex</groupId>
<artifactId>stax-ex</artifactId>
</exclusion>
<exclusion>
<groupId>org.glassfish.jaxb</groupId>
<artifactId>txw2</artifactId>
</exclusion>
<exclusion>
<groupId>com.sun.xml.fastinfoset</groupId>
<artifactId>FastInfoset</artifactId>
</exclusion>
</exclusions>
</dependency>

I've had the same problem when running my spring boot application with tomcat7:run
It gives error with the following dependency in maven pom.xml:
<dependency>
<groupId>org.junit.vintage</groupId>
<artifactId>junit-vintage-engine</artifactId>
</dependency>
SEVERE: Unable to process Jar entry [module-info.class] from Jar [jar:file:/.m2/repository/org/apiguardian/apiguardian-api/1.1.0/apiguardian-api-1.1.0.jar!/] for annotations
org.apache.tomcat.util.bcel.classfile.ClassFormatException: Invalid byte tag in constant pool: 19
Jul 09, 2020 1:28:09 PM org.apache.catalina.startup.ContextConfig processAnnotationsJar
SEVERE: Unable to process Jar entry [module-info.class] from Jar [jar:file:/.m2/repository/org/apiguardian/apiguardian-api/1.1.0/apiguardian-api-1.1.0.jar!/] for annotations
org.apache.tomcat.util.bcel.classfile.ClassFormatException: Invalid byte tag in constant pool: 19
But when I correctly specify it in test scope, it does not give error:
<dependency>
<groupId>org.junit.vintage</groupId>
<artifactId>junit-vintage-engine</artifactId>
<scope>test</scope>
</dependency>

I faced this issue with tomcat 7 + jdk 1.8
with java 1.7 and lower versions it's working fine.
window -> preferences -> java -> installed jre
in my case I changed
jre1.8 to JDK 1.7
and accordingly modify project facet , select same java version as it's there in selected Installed JRE.

I got similar error (org.aspectj.apache.bcel.classfile.ClassFormatException: Invalid byte tag in constant pool: 15) while using aspectj 1.8.13. Solution was to align all compilation into jdk 8 and being careful not to put aspectj library's (1.6.13 for instance) other versions to buildpath/classpath.