Been helped through this uphill battle by some very smart Java and JBoss experts, and I appreciate it. I finally got the EJBs to deploy on the new JBoss AS 7 without error. Yah! Now, however, I need to know the next step in addressing those beans from my application. I have read a lot and found conflicting examples, unfortunately. My code is thus:
DodsrUserSessionEJB o = ( DodsrUserSessionEJB) ctx.lookup("/dodsr/"+ejbName+"/remote");
This works on JBoss 6. What should the new one look like to work on AS 7?
Perhaps I spoke too soon. There are still 94 errors in the log file, many of which have the name "beans" in them, like remoting3-jboss-beans.xml. Even though the log says that my EAR file was deployed could some or any of these error prevent me from connecting to them?
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 have a legacy codebase, a Java app that runs on Glassfish3. It deploys & runs fine on two app servers that were already there when I arrived.
I'm trying to setup a local instance, using Docker. When I deploy the WAR in the Docker Glassfish, it deploys fine. When I try to open the login page, it throws an exception (from the JSP compilation):
"java.lang.String cannot be converted to org.slf4j.Marker"
There isn't much more information, except suggestions to enable debug & verbose flags during compilation.
Same WAR deploys & runs without this error on the existing app servers.
My guess is that there's a configuration difference that I'm not aware of. Another angle I'm looking at is the logger implementation provided by the application server. Either way - so far I haven't been able to figure out what's the difference between the instances, or even how to figure out the difference in configuration/deployment.
Java EE isn't my natural habitat, so any ideas on what I should be looking at would be greatly appreciated.
For future reference -- the solution was to search the codebase for log warn/error/info/debug/trace calls with more than 3 parameters, and changing them from ("...", "...", "...", "...") to ("...", new Object[]{"...", "...", "..."})
I am having trouble with an installation of Wildfly 9. Before now, everything has been fine and running smoothly. I've since made one small change to standalone.xml (turned up logging level to TRACE for one of the deployed packages, that's it).
Wildfly is running as a service.
Here's what's happening:
Made change to standalone.xml
Restarted the service
Noticed that none of my jars are deploying even though the deployment scanner is on
Create .dodeploy files to deploy the jars
Every single one fails
Change to standalone.xml is reverted, despite clearing the cache
So, I then try to deploy just ojdbc7.jar. This is the error message I am getting:
"{\"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available.\" => {
\"Services that were unable to start:\" => [\"jboss.deployment.unit.\\\"ojdbc7.jar\\\".PARSE\"],
\"Services that may be the cause:\" => [
\"jboss.jdbc-driver.ojdbc7_jar\",
\"jboss.remoting.remotingConnectorInfoService.http-remoting-connector\"
]}}"
At first, I thought I may have something else listening on port 8080. I checked, and I definitely don't. I don't really know what else this problem could be.
I am also at a complete loss to explain how my standalone.xml change is not being picked up. It seems like it's cached somewhere and I just don't know where. I have cleared the cache and it just keeps coming back.
Apologies if this seems a little vague - if anyone needs any clarification or more information I'll be happy to oblige.
Well, at least it seems as tapestry issue.
I'm getting an exception when trying to access a specific page:
org.apache.tapestry.PageNotFoundException:
Page 'ASpecificPage' not found in application namespace.
Seems like some pages are found, and some are not, I'm new to this project, and so far cannot say is there any difference between them.
The error still occurs, even when whole jboss-4 instance, along with the deployed application, is copied from my coworkers' computers and run, whereas they do not experience such problems. Supposedly there is no other application-specific configuration, and it's all contained within the server instance.
Any ideas? Even not Tapestry-related? I tried using same java version, with update number precision, but in vain. Like, where should I start to debug?
EDIT:
I'm new to tapestry, so if anything is missing or just inaccurate, just let me know. Some details:
the application is deployed as war, copied to deploy directory,
unexploded
there are other jars copied as well, not sure if they are relevant
when searching for ASpecificPage, it seems that there is only a java
class (i.e. ASpecificPage.java), and there is missing appropriate
.html file
when searched in code, I found occurences like:
clearPopUp(cycle);
ASpecificPage page=(ASpecificPage) cycle.getPage("ASpecificPage");
page.show(cycle, ASpecificPage.TAB_2);
Any other details needed?
We have been using tomcat 7.0.19 successfully in embedded mode. However recently due to some fixes in our area of concern we decided to move to tomcat 7.0.32. Most things work as expected with same code and newer version, however the war deployment for some reason has'nt worked well. I have a couple of servlets registered with my tomcat. Facing below 2 issues,
Has something changed from 7.0.19 to 7.0.32 from embedded tomcat behavior. To detail this out let me explain the behavior difference, with 7.0.19, i could deploy my application and when i hit the "host:port/contextpath" it loaded the applications start page (i.e. welcome page, this page is UI centric and does not need a server intervention, so none of my servlets get called). However with 7.0.32 the same url results in my servlet being called.
So to debug the problem, i commented most of my code so that i have a vanilla tomcat implementation, just the very basic stuff, i.e. setting the engine name, default host, setting host properties, adding a connector (nio, with default properties) and deploying a war. No servlets and other things, just to check if the very basic stuff works. To my surprise when i ran this code it still failed with the same problem within my servlet, how did that happen, now that my code is commented it does not register any servlets, still where does it find it from? Does embedded tomcat store some old references, which are not getting cleaned on subsequent runs? I tried changing the port, but that too didn't help.
I am hitting the wall here, not able to understand this wierd behavior, if i figure out #2, only then can i make some progress on #1.
Thanks in advance,
Vikram
Figured out what the problems were.
In reverse order,
2 - This actually was a weird behavior with the vanilla embedded tomcat code too invoking the servlets which never were registered in the first place. The problem here was with eclipse, for some reason it picked up the old reference of my class. The moment i ran the same code from outside of eclipse i.e. via command prompt, things were back to normal.
1 - This problem was related to web deployment, in my code i was additionally setting my classloader into WebappLoader and eventually adding my application jars into it. This for whatever reasons worked fine with 7.0.19, however did not with 7.0.32, the moment i externalized all my jars to be loaded during application startup via classpath this problem too was resolved.
Thanks,
Vicky