ProtoBuf jar is causing exception when used in web application - protocol-buffers

I am trying to use JBPM v5.4 in my web-application using IBM WebSphere 6.1. JBPM comes with protobuf-java-2.4.1.jar so I added this jar in my web application. But when I start server I got following exception due to this jar. When I remove this jar, everything work fine (except when portbuf functionality is used, java.lang.NoClassDefFoundError occurs, and this is expected).
com.ibm.ws.metadata.annotations.AnnotationException: Annotation processing failed for class: com/google/protobuf/FieldSet.class
at com.ibm.ws.metadata.annotations.AnnotationConfigReader.getAnnotationData(AnnotationConfigReader.java:462)
at com.ibm.ws.metadata.annotations.AnnotationConfigReader.populateModuleData(AnnotationConfigReader.java:247)
at com.ibm.ws.metadata.MetaDataOrchestrator.getModuleData(MetaDataOrchestrator.java:112)
at com.ibm.ws.websvcs.annotations.collector.WASAnnotationCollector.getMDO(WASAnnotationCollector.java:214)
at com.ibm.ws.websvcs.annotations.collector.WASAnnotationCollector.collect(WASAnnotationCollector.java:107)
at com.ibm.ws.websvcs.desc.WSModuleDescriptorImpl.getClassDataObjects(WSModuleDescriptorImpl.java:411)
at com.ibm.ws.websvcs.desc.WSModuleDescriptorImpl.getWARCDOs(WSModuleDescriptorImpl.java:369)
at com.ibm.ws.websvcs.desc.WSModuleDescriptorImpl.containsJAXWSWebServices(WSModuleDescriptorImpl.java:210)
at com.ibm.ws.webservices.admin.deploy.ServiceIndexDataBuilder.getWSData(ServiceIndexDataBuilder.java:48)
at com.ibm.ws.webservices.admin.deploy.ServiceIndexServerTaskImpl.listWebServices(ServiceIndexServerTaskImpl.java:142)
at com.ibm.ws.webservices.admin.deploy.ServiceIndexServerTaskImpl.listWebServices(ServiceIndexServerTaskImpl.java:107)
at com.ibm.ws.webservices.admin.deploy.ServiceIndexServerTask.performTask(ServiceIndexServerTask.java:186)
at com.ibm.ws.management.application.SchedulerImpl.run(SchedulerImpl.java:262)
at java.lang.Thread.run(Thread.java:801)
Caused by: java.util.EmptyStackException
at java.util.Stack.peek(Stack.java:94)
at java.util.Stack.pop(Stack.java:76)
at com.ibm.ws.metadata.annotations.WSSignatureParser.handleGenericGrouping(WSSignatureParser.java:256)
at com.ibm.ws.metadata.annotations.WSSignatureParser.popStack(WSSignatureParser.java:210)
at com.ibm.ws.metadata.annotations.WSSignatureParser.parseSignature(WSSignatureParser.java:63)
at com.ibm.ws.metadata.annotations.WSClassAdapter.visit(WSClassAdapter.java:100)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at com.ibm.ws.metadata.annotations.AnnotationConfigReader.getAnnotationData(AnnotationConfigReader.java:440)
at com.ibm.ws.metadata.annotations.AnnotationConfigReader.populateModuleData(AnnotationConfigReader.java:247)
at com.ibm.ws.metadata.MetaDataOrchestrator.getModuleData(MetaDataOrchestrator.java:112)
at com.ibm.ws.websvcs.annotations.collector.WASAnnotationCollector.getMDO(WASAnnotationCollector.java:214)
at com.ibm.ws.websvcs.annotations.collector.WASAnnotationCollector.collect(WASAnnotationCollector.java:107)
at com.ibm.ws.websvcs.desc.WSModuleDescriptorImpl.getClassDataObjects(WSModuleDescriptorImpl.java:411)
at com.ibm.ws.websvcs.desc.WSModuleDescriptorImpl.getWARCDOs(WSModuleDescriptorImpl.java:369)
at com.ibm.ws.websvcs.desc.WSModuleDescriptorImpl.containsJAXWSWebServices(WSModuleDescriptorImpl.java:210)
at com.ibm.ws.webservices.admin.deploy.ServiceIndexDataBuilder.getWSData(ServiceIndexDataBuilder.java:48)
at com.ibm.ws.webservices.admin.deploy.ServiceIndexServerTaskImpl.listWebServices(ServiceIndexServerTaskImpl.java:142)
at com.ibm.ws.webservices.admin.deploy.ServiceIndexServerTaskImpl.listWebServices(ServiceIndexServerTaskImpl.java:107)
at com.ibm.ws.webservices.admin.deploy.ServiceIndexServerTask.performTask(ServiceIndexServerTask.java:186)
at com.ibm.ws.management.application.SchedulerImpl.run(SchedulerImpl.java:262)
at java.lang.Thread.run(Thread.java:801)
at java.util.Stack.peek(Stack.java:94)
at java.util.Stack.pop(Stack.java:76)
at com.ibm.ws.metadata.annotations.WSSignatureParser.handleGenericGrouping(WSSignatureParser.java:256)
at com.ibm.ws.metadata.annotations.WSSignatureParser.popStack(WSSignatureParser.java:210)
at com.ibm.ws.metadata.annotations.WSSignatureParser.parseSignature(WSSignatureParser.java:63)
at com.ibm.ws.metadata.annotations.WSClassAdapter.visit(WSClassAdapter.java:100)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at com.ibm.ws.metadata.annotations.AnnotationConfigReader.getAnnotationData(AnnotationConfigReader.java:440)
... 13 more
What is happening actually and what should I do to resolve it?
UPDATE
I created an empty webapp with only protobuf-java-2.4.1.jar in it's WEB-INF/lib folder. Server throws same exception on start up. But when I deploye the application in tomcat 6.33 and it starts without any exception.
UPDATE
When I deployed the application on my testing server, it worked.
Here are my testing and development machines environment specific information
Testing
OS: Linux
WebSphere: v6.1.0.29
Java: J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223-20060504 (JIT enabled)
Development
OS: Windows 7
WebSphere: v6.1.0.9
Java: J2RE 1.5.0 IBM J9 2.3 Windows Vista x86-32 j9vmwi3223-20070426 (JIT enabled)

This looks like a product error, so I recommend opening a PMR with IBM.
As a workaround, you could try moving the problematic JAR to a shared library, and then associate the shared library with the WAR module. This will have the same effect from a class loading perspective as including the JAR in the WAR, but it should prevent the annotation scanner from looking at the JAR.

Related

Vaadin 7 problem after deployment: NoClassDefFoundError

I am running Vaadin 7 with IntelliJ. I am unable to develop my company's project because I am stuck at a problem that occurs after deployment.
The Server tab in IntelliJ says that starting the server and deploying the artifact is successful
Connected to the target VM, address: '127.0.0.1:9009', transport: 'socket'
Connected to server
[2020-01-03 01:33:16,250] Artifact CO:war exploded: Artifact is being deployed, please wait...
[2020-01-03 01:33:18,006] Artifact CO:war exploded: Artifact is deployed successfully
[2020-01-03 01:33:18,006] Artifact CO:war exploded: Deploy took 1,756 milliseconds
After that IntelliJ navigates to http://localhost:8080/company on the browser. It displays a 'HTTP Status 404 - Not Found' error. The console says:
Error in annotation processing: {0}.
java.lang.NoClassDefFoundError: com/vaadin/server/VaadinServlet
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at org.glassfish.web.loader.WebappClassLoader.findClass(WebappClassLoader.java:1089)
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1620)
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1501)
at com.sun.enterprise.deployment.annotation.impl.ModuleScanner.getElements(ModuleScanner.java:295)
at com.sun.enterprise.deployment.archivist.Archivist.processAnnotations(Archivist.java:592)
at com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:461)
at com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:445)
at com.sun.enterprise.deployment.archivist.Archivist.readRestDeploymentDescriptors(Archivist.java:417)
at com.sun.enterprise.deployment.archivist.Archivist.readDeploymentDescriptors(Archivist.java:394)
at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:269)
at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:278)
at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:239)
at com.sun.enterprise.deployment.archivist.ApplicationFactory.openArchive(ApplicationFactory.java:161)
at org.glassfish.javaee.core.deployment.DolProvider.processDOL(DolProvider.java:199)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:223)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:91)
at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:882)
Our company hasn't upgraded to higher Vaadin versions yet, and upgrading Vaadin isn't an option for fixing my problem. I can show you some excerpts of files that might be important, such as pom.xml.
Information recap:
Vaadin 7.7.10
Payara Server 4.1.2.174 on local computer
IntelliJ IDEA 2019.3.1 (Ultimate Edition)
Build #IU-193.5662.53, built on December 18, 2019
Runtime version: 11.0.5+10-b520.17 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 10 10.0
java version "1.8.0_231"
Java(TM) SE Runtime Environment (build 1.8.0_231-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.231-b11, mixed mode)
If you have any idea on what might cause this error, please offer suggestions. I am grateful for your help.
Nine months later the problem started happening on my computer again. My error message starts with
Error in annotation processing: {0}.
java.lang.NoClassDefFoundError: com/vaadin/server/VaadinServlet
Notice how the error Error in annotation processing has a message of {0}. The message for the error is missing.
I looked at numerous articles from the internet. None of the potential causes of NoClassDefFoundError applied to this case I had. My jar-files were generated after the build.
Last time I solved the problem by reinstalling Windows. This time I tried a less severe fix by reinstalling IntelliJ and my Payara server. Also I deleted and re-downloaded my company's GitHub project. After I did these, my builds started working again.
Re-installing IntelliJ could be enough, but I did all of these just in case since I was not certain which piece of software caused the problem.
I am not fully satisfied with this fix as I still do not understand the cause of the problem.

java.lang.NoClassDefFoundError: org.springframework.context.support.ClassPathXmlApplicationContext

What I am trying to achieve is to upload Temenos T24 Design Studio web services on Axis2.
Unfortunately, I am getting a Class not found error when uploading the service using "aar" (Axis2 archive) file.
I have already deployed Axis2 1.4.4 on IBM Websphere 9.
Note : There has been certain conflicts while deploying Axis2 application on IBM websphere JAX-WS, which I have used this guide to resolve them;
https://www-01.ibm.com/support/docview.wss?uid=swg21315686
Below is the error I am getting;
=================================
This Web axisService has deployment faults
Error: java.lang.NoClassDefFoundError: org.springframework.context.support.ClassPathXmlApplicationContext at com.temenos.services.designstudioinstaller.DesignStudioInstallerServiceSpringContext.loadServiceContext(DesignStudioInstallerServiceSpringContext.java:27)
You have to remove the following jar files from the t24lib directory:
t24-EB_ResourceProviderService-ejb.jar
t24-EB_ResourceProviderService-ProxyAdaptor.jar
t24-EB_ResourceProviderService-jws.aar
t24-EB_ResourceProviderService-provider.jar
t24-EB_ResourceProviderService-tafj-jws.aar
t24-EB_ResourceProviderService-tafj-provider.jar
For any service component such as EB_ResourceProviderService, only the below jars must be present within the t24lib directory:
EB_ResourceProviderService.jar
t24-EB_ResourceProviderService-Data.jar
t24-EB_ResourceProviderService-t24service.jar
Restart the application server after removing them and the axis2 should deploy successfully.
I had similar error deploying axis2.war inflated with Temenos aar files on JBoss EAP 7.1 and it was solved by removing the duplicated .jar and .aar files in t24lib:
[INFO] The t24-EB_ResourceProviderService-tafj-jws.aar service, which is not valid, caused java.lang.NoClassDefFoundError: org/springframework/context/support/ClassPathXmlApplicationContext
at com.temenos.services.resourceprovider.ResourceProviderServiceSpringContext.loadServiceContext(ResourceProviderServiceSpringContext.java:27)

Springboot Strange Resource Loading Behavior

I'm working on a springboot 1.5.1 application that I'm trying to load a WSDL included in my resources directory in the wsdl directory. Depending on where my application executes I'm getting different results (command line, intellij, cloud foundry) and I can't seem to get all three to work at the same time.
I've tried several ways of locating the resource:
From prior to the migration to springboot we had this (worked in IntelliJ but not java -jar myboot.jar):
this.getClass().getResource("/wsdl/my.wsdl");
I switched it to the typically more correct version and got it to work in IntelliJ and java -jar but not Cloud Foundry:
this.getClass().getClassLoader().getResource("/wsdl/my.wsdl");
I switched it to use the Spring Resource Loader version and it worked in IntelliJ and CloudFoundry but not java -jar:
#Value("classpath:/wsdl/my.wsdl")
private Resource wsdlResource;
wsdlResource.getURL();
On the command line what I've noticed is that it seems to be thinking that BOOT-INF/classes is a JAR file (Note the ! after classes):
Caused by: javax.xml.ws.WebServiceException: Failed to access the WSDL at: jar:file:/C:/dev/redacted/build/libs/redacted.jar!/BOOT-INF/classes!/wsdl/my.wsdl. It failed with:
JAR entry BOOT-INF/classes!/wsdl/my.wsdl not found in C:\dev\redacted\build\libs\redacted.jar.
From looking at IntelliJ's URL, it's referring to the actual source folder which explains why it seems to always work.
What is causing this and how might I universally load these class path resources successfully with springboot?

FHIR build fails with NoSuchMethodError: net.sf.saxon.Configuration.newConfiguration()

Following instructions at http://wiki.hl7.org/index.php?title=FHIR_Build_Process my FHIR build is failing. I modified the publish.bat to ensure it uses the correct JDK. Running it on Windows 7 64-bit machine with JDK 1.6 (also tried JDK 1.7) and both failing with same error.
Looks like some Saxon JAR hell somewhere. Any ideas?
...validate v2-tables 441sec 755MB
...validate v3-codesystems 443sec 889MB
Reference Platform Validation. 447sec 1067MB
...test adversereaction-example 447sec 1067MB
Exception in thread "main" java.lang.NoSuchMethodError: net.sf.saxon.Configuration.newConfiguration()Lnet/sf/saxon/Configuration
;
at net.sf.saxon.xpath.XPathFactoryImpl.<init>(XPathFactoryImpl.java:33)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at javax.xml.xpath.XPathFactoryFinder.loadFromService(XPathFactoryFinder.java:401)
at javax.xml.xpath.XPathFactoryFinder._newFactory(XPathFactoryFinder.java:222)
at javax.xml.xpath.XPathFactoryFinder.newFactory(XPathFactoryFinder.java:143)
at javax.xml.xpath.XPathFactory.newInstance(XPathFactory.java:185)
at javax.xml.xpath.XPathFactory.newInstance(XPathFactory.java:99)
at org.hl7.fhir.tools.publisher.Publisher.testSearchParameters(Publisher.java:2796)
at org.hl7.fhir.tools.publisher.Publisher.testSearchParameters(Publisher.java:2785)
at org.hl7.fhir.tools.publisher.Publisher.validateRoundTrip(Publisher.java:2759)
at org.hl7.fhir.tools.publisher.Publisher.validateXml(Publisher.java:2656)
at org.hl7.fhir.tools.publisher.Publisher.execute(Publisher.java:378)
at org.hl7.fhir.tools.publisher.Publisher.main(Publisher.java:281)
A workaround... do a fresh build of the publisher tool jar from source.
Following instructions in the build/buildhowto.txt I was able to build the tool jar inside Eclipse, run the Publisher successfully from inside Eclipse and then export it as a fresh tool jar overwriting the one I pulled from SVN. The freshly build one then ran to completion from the command line.
Could be there's just a problem with the version of tools jar out there in SVN at the moment.
For the record I am working with Version 0.12-1953.
You have two classes net.sf.saxon.Configuration in your classpath. One containing the method newConfiguration() and one not.
The method is probably called from Saxon-HE 9.x, and the class net.sf.saxon.Configuration is found in saxon 8.x, while the class should have been found inside Saxon-HE 9.x, where it also is, and does have this method.
So, check your dependencies to see if saxon 8.x is called, and try replacing that with Saxon-HE 9.x, then your problem is solved

java.lang.NoSuchMethodError: EngineConfig.getLogRollingSize()

I am a newbie in BIRT, have installed Eclipse Birt plugin 4.3 and downloaded OSGI birt-runtime-osgi-4_3_0,
i have a standalone program to open the sample report in the birt runtime envt. but i am getting error
at
conf = new EngineConfig();
conf.setEngineHome("C:/birt-runtime-osgi-4_3_0/ReportEngine");
//Create new Report engine based off of the configuration
eng = new ReportEngine( conf ); -----------> Error.
as
Exception in thread "main" java.lang.NoSuchMethodError: org.eclipse.birt.report.engine.api.EngineConfig.getLogRollingSize()I
at org.eclipse.birt.report.engine.api.impl.ReportEngine.intializeLogger(ReportEngine.java:220)
at org.eclipse.birt.report.engine.api.impl.ReportEngine.<init>(ReportEngine.java:134)
at org.eclipse.birt.report.engine.api.impl.ReportEngineFactory$1.run(ReportEngineFactory.java:18)
at org.eclipse.birt.report.engine.api.impl.ReportEngineFactory$1.run(ReportEngineFactory.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.birt.report.engine.api.impl.ReportEngineFactory.createReportEngine(ReportEngineFactory.java:14)
at org.eclipse.birt.report.engine.api.ReportEngine.<init>(ReportEngine.java:71)
at com.pg.o2.test.synch.ReportTest.main(ReportTest.java:33)
,
thought of running a stand alone pgm and start with JBOSS ,
please let me know if anything i have to download or missign jars.
It sounds like the jars in the runtime haven't been referenced in your eclipse project as described here. Are you running the application from eclipse or deploying it and getting these errors. If you're in eclipse go to the project settings and add the jars from the runtime to the build path. If you're getting these while deployed the jars need to go in your lib folder.

Resources