In our application we encounter very sporadic run time exceptions which crash our message processors (which are stand-alone java processes running on Java 8). The processors, at the time of this exception, generally try to execute a web service call.
The exception are
java.lang.Error: Failed to create new instance of com.sun.xml.internal.ws.api.streaming.XMLStreamWriterFactory$1
at com.sun.xml.internal.ws.api.streaming.ContextClassloaderLocal.createNewInstance(ContextClassloaderLocal.java:63)
..
Caused by: java.lang.IllegalArgumentException: Unable to access unsupported property javax.xml.stream.isRepairingNamespaces
at weblogic.xml.stax.ConfigurationContextBase.check(ConfigurationContextBase.java:90)
The strange thing is, the whole application is running without errors 99.9% of the time: the above exceptions happen quite infrequently (ca. every couple of days). After a crash, the processors are restarted automatically, and again operate perfectly fine, until the same exception occurs again after a seemingly random interval.
So far we could not correlate this with any misbehavior on the part of the JVM or the host the application is running on.
Does anyone have any pointers as to why such an unsupported property javax.xml.stream.isRepairingNamespaces exception could appear sporadically?
We're running jdk1.8.0_66 on Red Hat 4.8.5-4. Web service interfaces are generated using JAX-WS.
Edit:
I can't share the classpath (lots of internal info, sorry). We do have the Weblogic full client in there though: wlfullclient-12.1.3.jar. It defines an XML factory via ServiceLoader
META-INF/services/javax.xml.stream.XMLOutputFactory --> weblogic.xml.jaxp.RegistryXMLOutputFactory
Where as xml-apis-1.4.01.jar (also on classpath) contains javax/xml/stream/XMLOutputFactory.class (related to the exception thrown in ConfigurationContextBase).
Could this be part of the problem?
You have to change the class path order. At first point all the axis2 jars and then point the weblogic.jar in class path. Hope it will solve your issue.
I encountered this problem yesterday after making some significant changes to my code. This particular post is the ONLY information I can find by googling this particular error -- always a bad sign. After hours and hours of fruitless deep debugging, comparing the original working version of the code with the new non-working version, I decided to start backing out my code changes to see where/when the problem originated. Well, after backing out pretty much every single code change, the problem was still happening. I finally realized that this problem was perhaps external to the code. It turns out that at some point, I had added an extraneous library: wstx.jar to my lib directory. Once I removed that lib, everything worked great. So apparently it was utilizing the wrong classes to try to perform this operation.
Not sure if that is of any assistance to you, but even if not, I thought someone someday might stumble onto this and find it to be useful.
Related
I am getting an error in Weblogic. I am running Weblogic 14.1.1 with OpenJDK 11.0.2. I am running on Red Hat Linux Enterprise version 8.4. This is a required platform stack, so I can't update any of these.
The error I am receiving is "Could not check file size to determine chunk rotation". It shows up in the Weblogic log after about 7-10 days of running. And it just keeps printing out, filling up the log.
I found the error message in the following Java class in OpenJDK:
https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/master/src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecorder.java
The class name is PlatformRecorder.java. And the error is on line 442 in method periodicTask().
try {
if (SecuritySupport.getFileSize(currentChunk.getUnfishedFile()) > Options.getMaxChunkSize()) {
rotateDisk();
}
} catch (IOException e) {
Logger.log(JFR_SYSTEM, WARN, "Could not check file size to determine chunk rotation");
}
As you can see, it is in a catch block for an IOException. Unfortunately, they do not print out the detail of the Exception in the log.
This seems to be part of Java Flight Recorder (JFR). I am not familiar with this, but my understanding is that it is not supposed to be enabled by default. But Weblogic/OpenJDK does appear to be running it (since I am getting that error).
Since this error doesn't show up until Weblogic has been running for about a week, it almost sounds like there is some resource that is unavailable or is being "used up" after a certain amount of time. I did check the disk space, and I saw nothing out of the ordinary. I also found some ".jfr" files under the Weblogic directory structure, but they were all empty.
I thought maybe I could replace the default implementation of this class with one of mine where I print out the exception detail to maybe give me a clue. But these seem to be in Java modules. And I'm uncertain how to replace a native Java class in a module with one of mine.
The other thought is maybe there is some profiling going on in Weblogic that is causing this to be started. But I'm not sure how to turn all profiling off (or if that would even be a good thing to do). But I obviously can't recycle Weblogic once a week in production because this error keeps showing up.
Does anybody have any ideas on what could be causing this error? Or maybe how to determine some more detail, like how to override a built-in class in a Java module, or some other idea? Has anybody else even seen this error? I could not find it mentioned anywhere else.
Thanks for any help in troubleshooting this issue.
Just wanted to follow up on this question. As Emannuel stated, Weblogic does not support OpenJDK. Because of licensing issues, we split the project into 2 parts. One part is OpenJDK, and the other part is Weblogic, which comes with the Oracle JDK license. So everything that runs inside Weblogic will use the Oracle JDK that comes with the Weblogic license. The rest of the project will use OpenJDK.
While it is not an ideal solution, using the Oracle JDK for the whole project was cost prohibitive, so splitting the project was the only solution acceptable for the client.
I'm very new to java. starting from yesterday! i installed eclipse and imported spring libraries inside it. but a weird problem happened. in import statement there was an error telling The type org.springframework.context.ApplicationContext is not accessible. after running the project another error happened (related to same subject ApplicationContext cannot be resolved to a type).
Anyway! i was confused. it took one day for me. searching forums such as stackoverflow and googling didn't resolve my problem. suddenly i saw a popup message in eclipse suggesting some solutions. ignoring some worthless one of them was adding module to module-info.java file. unbelievably that solved the problem! strangest thing was that i never saw this solution in related forums! and most annoying thing is that what if i never saw that popup? where did i do a mistake? and why this solution doesn't exist on the internet?
Lots of thanks!
Java modules are a new feature of Java 9; they allow you to specify exactly which dependencies you need for your program, hence allowing greater control of the size of your application - no need to bring along library code you don't use. That seems to imply that you need to explicitly say what you want, I guess so that you realise that you are pulling in more modules.
So the reason that you don't see much information about modules in general is that they are comparatively new and doubt that I'm alone in being a long-standing Java developer who has never seen a module-info file!
I wonder whether Eclipse gave you some options when you were creating your project and you inadvertently took an option meaning "yes I want the extra control of doing mocules and I don't mind doing a bit more work."
I have a Rails 3.2.13 application written in JRuby (1.7.12). I'm developing on Mac OS X 10.10 (though the problem was also evident on 10.9). I have both JDK 1.6 and 1.7 installed. I'm serving the application via torquebox 3.1.1.
If I start the application connecting to my local postgres database, I have no issues. But I need to debug a problem that requires connecting to Oracle. I then switch my adapter to oracle-enhanced and making sure I have ojdbc6.jar and ojdbc7.jar in $JRUBY_HOME/lib. When I start the application via torquebox, I get errors like this:
14:47:58,242 ERROR [org.torquebox.core.runtime] (pool-8-thread-1) Error during execution: ENV['RAILS_ROOT']=RACK_ROOT
ENV['RAILS_ENV']=RACK_ENV
require %q(org/torquebox/web/rails/boot)
: org.jruby.exceptions.RaiseException: (NoMethodError) undefined method `blame_file!' forjava.lang.StackOverflowError:Java::JavaLang::StackOverflowError
I realize the blame_file! error is a separate thing. The StackOverflowError that's the cause of that error is what I care about. It's getting into a failing loop when trying to load necessary files, like rails/boot in this case.
However! When I run "rails console" it works fine and I can load data from the database.
I'm convinced as a result of being able to load the console that this is a problem with torquebox somehow, but I don't know what, nor how to fix it.
Is there any helps anyone can give me? Has anyone seen something like this before? Thanks.
(Edit, I found a locally cached copy of ojdbc7.jar in the app, which explains my original errors with 1.6. I've edited this post to reflect the current situation.)
Try looking at https://github.com/jruby/jruby/issues/976 to work around the blame_file problem and then hopefully you'll get a more useful error message.
Maybe then you'll get something be able to diagnose something similar to:
Error while loading java Class in Jruby application
I got some help on irc.freenode.net/#torquebox. After some confusion about the stack output vs. my stack size, it was suggested that I scale that back some. I set it from 4096m (yes, I realize now that that's ridiculous) to 2048k, and it works.
We don't know why Java crapped out in this specific way, but the end result is that with a smaller stack size, it works now.
I have googled far and wide and not found any references to this issue, so any help would be much appreciated.
I can regularly generate an illegal access error when using the Java Less compiler (https://github.com/marceloverdijk/lesscss-java), but not on my development machine - only on Heroku (and dokku it seems - same issue there). The compiler calls compile on some javascript code, which goes through the optimiser, and fails with the following stack trace:
java.lang.IllegalAccessError: tried to access method org.mozilla.classfile.ClassFileWriter.getLabelPC(I)I from class org.mozilla.javascript.optimizer.BodyCodegen$ExceptionManager
at org.mozilla.javascript.optimizer.BodyCodegen$ExceptionManager.endCatch(Codegen.java:4051)
at org.mozilla.javascript.optimizer.BodyCodegen$ExceptionManager.removeHandler(Codegen.java:3952)
at org.mozilla.javascript.optimizer.BodyCodegen.visitTryCatchFinally(Codegen.java:3705)
at org.mozilla.javascript.optimizer.BodyCodegen.generateStatement(Codegen.java:1897)
at org.mozilla.javascript.optimizer.BodyCodegen.generateStatement(Codegen.java:1873)
at org.mozilla.javascript.optimizer.BodyCodegen.generateStatement(Codegen.java:1858)
at org.mozilla.javascript.optimizer.BodyCodegen.generateBodyCode(Codegen.java:1289)
at org.mozilla.javascript.optimizer.Codegen.generateCode(Codegen.java:306)
at org.mozilla.javascript.optimizer.Codegen.compileToClassFile(Codegen.java:166)
at org.mozilla.javascript.optimizer.Codegen.compile(Codegen.java:75)
at org.mozilla.javascript.Context.compileImpl(Context.java:2377)
at org.mozilla.javascript.Context.compileReader(Context.java:1296)
at org.lesscss.LessCompiler.init(LessCompiler.java:295)
at org.lesscss.LessCompiler.compile(LessCompiler.java:357)
at org.lesscss.LessCompiler.compile(LessCompiler.java:450)
This is particularly odd since the method it fails to call is public (https://github.com/mozilla/rhino/blob/master/src/org/mozilla/classfile/ClassFileWriter.java#L1260-L1268).
As mentioned, I think this has something to do with the Heroku environment, since I cannot replicate this on my development machine.
Any ideas would be gratefully received.
I resolved this by excluding the offending dependency from my build in project.clj, since it wasn't actually needed itself. I'm still not sure why this problem only manifested itself in some environments, but it is now resolved at least.
I'm getting the following NullPointerException while trying to use the Play FBConnect module:
Caused by: java.lang.NullPointerException
at tags.fbconnect.FBConnectTags._button(FBConnectTags.java:26)
at tags.fbconnect.FBConnectTags$_button.call(Unknown Source)
at /app/views/main.html.(line:17)
at play.templates.GroovyTemplate.render(GroovyTemplate.java:203)
This seems to be the line where its occurring: https://github.com/rbamba/play-fbconnect/blob/master/app/tags/fbconnect/FBConnectTags.java#L26
Unfortunately I'm not sufficiently familiar with Play modules to debug this myself.
edit: In response to a comment, I believe the fbconnect module is correctly configured, since this is being reported earlier in the log:
13:12:13,225 INFO ~ Module fbconnect is available (/home/****/play-1.1.1/modules/fbconnect-0.3)
edit2: I've actually got it to progress past this point on my local machine, but still getting this NPE on my production server.
I can't see anything specifically wrong with the plugin code. To explain a little of what is going on,
// the line of code with the error
String url = Play.plugin(FBConnectPlugin.class).session().getLoginUrl(scope);
Lets break this down a little
Play.plugin(FBConnectPlugin.class)
This line asks Play to return the initialised plugin, from the list of plugins configured within Play. If the Plugin is not set up, then it returns null. This is the most likely reason for the error.
.session()
This simply gets the session object from the FBConnectPlugin, which is a statically created object, so will not be null.
.getLoginUrl(scope);
This builds the URL up. This method is not called, otherwise you would see it in the stack trace.
Therefore, the problem is that you have not configured the plugin correctly. Check over the documentation again to make sure why it has a problem. Alternatively, you may want to check out the FbGraph module. I installed this a few days ago, and have a Facebook app up and running already. It is very simple, and the documentation is excellent.
The answer is a little long-winded, but as you said you did not understand how modules worked, I thought it was worth explaining.
I spoke to Regis Bamba, one of the programmers who works on fb-connect.
I eventually decided to use the fbgraph module instead, and I'd probably recommend this to anyone thinking of using fb-connect because its more powerful, and seems to be better maintained. Even Regis recommended using it :-)
Regardless, here is what Regis suggested to get rid of the "java.net.URISyntaxException":
The solution is to manually replacing it with its encoded value, before encoding the whole string.
The getAuthUrl() function in FBConnectSession.java should be:
public String getAuthUrl(String authCode){
return "https://graph.facebook.com/oauth/access_token?client_id=" +
WS.encode(id)+"&redirect_uri=" +
WS.encode(Router.getFullUrl("FBConnect.callback")) +
"&client_secret="+WS.encode(secret)+"&code="+WS.encode(authCode.replace("|","%7C"));
}