I'm getting exception while deploying war file in Glassfish server 4 and 5. However I didn't have any issues in Glassfish 3.
The exception is "The lifecycle method [finalizeConfig] must not throw a checked exception. Related annotation information: annotation [#javax.annotatikn.Postconstruct()] on anoted element [public void org.apache.cxf.transport.http_jetty.JettyHTTPServerEngine.finalizeConfig() throws java.security.generalSecurityException, Java.io.IOException] of type [METHOD].
It seems like conflict between jetty http server and cfx transport.
I googled and found some solutions but nothing works.
Tried by removing transport Jettyhttp in cfx bundle.
Tried by upgrading cfx version.
So looking for some perfect solution.
According to the #PostConstruct annotation, it shouldn't be used with methods that throw checked exceptions. GF 4 and 5 validate this and won't allow deployment. Since the error is raised for a Jetty class which you can't fix,you should remove Jetty and all classes that validate this rule from your application completely. There's no way how to configure GF to ignore this.
See also https://stackoverflow.com/a/35428512/784594 for more details.
Related
Currently working an application that is moving from JBOSS 4 (java 6) to JBOSS 7.1 (Java 8). It had no REST WS - only SOAP and worked with Servlets.
I added my WAR containing a basic REST Service (ApplicationPath class with 1 resource class and a web.xml (empty since I'm using RESTEasy implementation which should scan my classes)) to the main EAR.
During deployment, I see no errors in my logs and it says my .war has been deployed and my web context registered.
However, whenever I call one of my resource's endpoint I get the default JBOSS response for Error 404 Not Found (the url is correct though) and when I try to call the same URL but by using PUT or POST I get the message "Http Method POST is not supported by this URL" which is typically an error from Custom Servlets.
Is it possible that another Servlet is listening to my path or taking over things? Even if outside of my web context? How could I investigate/debug this?
The problem came from the old RESTeasy Version - 3.0.7-Final that was being used, which has some known bugs with the #ApplicationPath annotation and web.xml configuration. After using the provided version of RESTeasy from the JBOSS 7 (version 3.6.1-SP2), everything worked like a charm.
I have a Spring-Boot application, which exposes some of its Interfaces to other projects. The basic process of this has been tried and tested within the project structure very often, so this SHOULD not be a "simple" RMI issue like missing serialization or incorrect registry.
This project (coded on java7) and an older project (also java7) are to be deployed in a wildfly 10.x container.
Basically, it is planned that our old application talks to the Spring-Boot application to get specific data sets. When starting the application, the beans are instantiated correctly, and the basic connection seems to be okay. However, when using an entirely valid call, I get this:
ERROR [io.undertow.request] (default task-5) UT005023: Exception handling request to /servlet/Foo: org.springframework.web.util.NestedServletException: Handler processing failed; nested exception is java.lang.NoClassDefFoundError: org/omg/CORBA/COMM_FAILURE
I tried debugging the application, and when using the offending method call, the remote class is being triggered and does its work normally, the return value is as expected and is being returned to the spring context.
The weird thing is this part of the Stack Trace:
java.lang.NoClassDefFoundError: org/omg/CORBA/COMM_FAILURE
at org.springframework.remoting.rmi.RmiClientInterceptorUtils.isCorbaConnectFailure(RmiClientInterceptorUtils.java:229)
at org.springframework.remoting.rmi.RmiClientInterceptorUtils.isConnectFailure(RmiClientInterceptorUtils.java:213)
at org.springframework.remoting.rmi.RmiClientInterceptor.isConnectFailure(RmiClientInterceptor.java:282)
at org.springframework.remoting.rmi.RmiClientInterceptor.doInvoke(RmiClientInterceptor.java:347)
at org.springframework.remoting.rmi.RmiClientInterceptor.invoke(RmiClientInterceptor.java:259)
because when I try to access RmiClientInterceptorUtils.java:229, Eclipse tells me that 229 is not a valid line number. This would lead me to believe that there is a versioning difference in Spring webMVC between server and client. This persisted, even after changing the version number (now using 3.2.8.RELEASE of spring-webmvc), the errors persisted.
I checked if there might be a dependency problem, but CONN_FAILURE is part of rt.jar and should, as far as I know, be present in every java project. Further testing revealed that:
Checked Exceptions are transferred normally
primitive values (like boolean) are transferred correctly
complex Objects cause the exception to be thrown
I'd appreciate any help with this matter, as I am at a loss to explain or correct this.
Thanks.
NOTE:
The general reason for the raised exception has been found - a class was missing the Serializable interface. This does, however, not answer the question why the COMM_FAILURE raised a NoClassDefFoundError, which is something I still would like to know.
I am seeing the following exception in my production WebSphere 8 server log:
WASSession E MTMBuffWrapper getBytes write object exception.
e= java.io.NotSerializableException: org.apache.commons.logging.impl.Jdk14Logger
However the only logging package used in deployed application is java.util.logging.Logger.
I am not seeing any serialization exception in my local RAD server, only in production environment.
Any idea?
You don't see exceptions in RAD because you dont have persistence session enabled or PMI counter collecting the session size (which is probably set on the production).
Although you don't use org.apache.commons.logging.impl.Jdk14Logger in your code there is very high probability that some kind of third party framework that you use in your app is using it.
You have to check what objects you put in the session (search for all session.setAttribute() method calls). You must be putting some third party object into session which is using that logger.
Try to remove commons-logging-1.1.jar from your application, if you have one there.
WebSphere internally uses the commons-logging library, so the conflict rises. We faced a similar problem, also using IBM provided solutions like https://www.ibm.com/support/pages/javaionotserializableexception-thrown-websphere-application-server-community-edition-when-applications-are-stopped did not help. In our case use, the jcl-over-slf4j library solved the problem.
Actually, i Have deployed my web-application on tomcat and when i start the application i am getting the following exception at console:
Warning: validation was turned on but an org.xml.sax.ErrorHandler was not
set, which is probably not what is desired. Parser will use a default
ErrorHandler to print the first 10 errors. Please call
the 'setErrorHandler' method to fix this.
Note:The Same Application runs on WebLogic but Issue is coming in tomcat.
Can anyone tell a solution?
Is there any dependency of the XMLSchema on the application-server?
I'm getting the following exception when starting a Tomcat instance with my web app after upgrading to Hibernate 3.5.0:
org.hibernate.annotations.common.AssertionFailure: Fail to process type argument in a generic declaration. Type: class sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl
at org.hibernate.ejb.metamodel.AttributeFactory$PluralAttributeMetadataImpl.getClassFromGenericArgument(AttributeFactory.java:836)
at org.hibernate.ejb.metamodel.AttributeFactory$PluralAttributeMetadataImpl.getClassFromGenericArgument(AttributeFactory.java:833)
at org.hibernate.ejb.metamodel.AttributeFactory$PluralAttributeMetadataImpl.<init>(AttributeFactory.java:748)
at org.hibernate.ejb.metamodel.AttributeFactory$PluralAttributeMetadataImpl.<init>(AttributeFactory.java:723)
at org.hibernate.ejb.metamodel.AttributeFactory.determineAttributeMetadata(AttributeFactory.java:518)
at org.hibernate.ejb.metamodel.AttributeFactory.buildAttribute(AttributeFactory.java:93)
As this happens on Tomcat startup, I have no idea where to look in my code to prevent that :-(
Putting that error message into google would have shown you any number of explanations, including this JIRA issue:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-5098