I am working on Spring3.0, Hibernate 3.2 web application deployed on JBOSS 4.3.
It's live product and getting this exception, when 30k users are utilizing it.
Exception : level=ERROR class=org.directwebremoting.dwrp.DefaultConverterManager No converter found for 'java.lang.StackTraceElement'
Its not generating much log as well and not able to find the same exception on internet.Anybody can tell me or any clue about it.
Why it's coming in production only not in local dev environment.
How much impact can be done of this exception on the system ?
Seems the application generates exceptions under load and tries to send back stack traces from them to the client. DWR is then unable to serialize the stack trace elements.
See here and here for possible DWR configurations that could solve the problem.
Related
I study web application with Spring. My development environment is
SpringToolSuite (ver 3.9.6),
Tomcat (8.5)
JDK (1.8)
I write source like in the textbook and run that code, but error message has been shown:
The full message is this.
**java.lang.IllegalStateException: Illegal access: this web application instance has been stopped already. Could not load []. The following stack trace is thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access.**
The source works properly, but after a few seconds, the following error message comes out.
If you know solution, I hope you let me know.
This is because of application servers like tomcat caching your old application.
Try to restart it.
Right button in your Tomcat in Servers, then 'Clean', and try to running again.
As other users replied, the tomcat is caching the old application
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.
Again, many excellent answers from the fine folks here on SO. I am still unable to connect. But I believe Gimby might have had a good suggestion that there may be something wrong with the server or the beans. According to the log file generated when JBoss started, my beans have been deployed. The administrator of the server is unable to run the admin console for vulnerabilities reasons so there is no way to see if the beans are running. Is there a command line tool that I could point him to for testing? Is there a simple test I could write that would check the beans? I have tried most everything I have found and others have suggested and keep getting various errors. most times being:
javax.naming.CommunicationException: Could not obtain connection to any of these urls: remote://:4647
I've encountered other errors as I have made changes to various files and code but this one is the most frequent. If the call I make to the bean is right, and that is questionable, then how do I tell if the bean is even running or not>
There seems to be some uncleared situations here.
Still I want to ask you, if your bean got a remote interface.
You could use lookup to find your bean on this server.
You also could deploy for example a RESTservice on your jboss server, which look for your bean locally, so you dont have to specify any connection properties, but you would need the jndi name.
Hope this helps a bit, greets Jerome.
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