List all Java errors in JSP files - java

I used old Eclipse (Helios) and old Tomcat (5.5) for a large web project. After updating to Tomcat 6, this code stopped working:
short foo = 3;
Integer bar = foo;
Apparently, this is invalid code according to the Java language specification[1], and there was a bug in the old Eclipse compiler so it didn't report it. New Eclipse (Kepler) reports it as an error.
I'm not quite sure why it stopped working with new Tomcat since it is using the same Java compiler as the old Tomcat, but the code is invalid and I want to fix it throughout the project.
First I tried validating the entire project in new Eclipse so it would list all .jsp files with this error. However, this validation in Eclipse doesn't seem to work very well since sometimes it detects several (existing) errors in a file and sometimes reports no errors in the same file (without changes, 10 seconds later).
Next thing I tried was to import project to NetBeans (7.4) and try to list those errors here. When I open a file with error, it detects it: "incompatible types: short cannot be converted to Integer". However, when I list all errors in the "Action Items" list, I can't find those errors (although I set the filter to include compiler errors).
I thought that listing all Java errors in all JSP files in a project would be easy, but turned out that it wasn't. How can I do it?
[1] Widening and boxing with java

The solution to this problem is to compile all JSP files in the project (i.e. generate Java files for them) and then inspect errors for generated files.
NetBeans has option to pre-compile all JSP files, but this didn't work for me because it stops after it hits first Java file with errors (maybe there is a way to circumvent this?).
Another solution might be to configure Apache Maven to build entire project, but I didn't try this, because a co-worker came up with a nice quick-n-dirty solution:
Generate a wget request for every JSP file in project and run all these requests. It doesn't matter that wget can't really access the pages since it isn't logged in, it just 'touches' them and forces the Tomcat to generate Java files.
Something like this (linux/cygwin):
find jsp -name '*.jsp' -printf 'http://localhost:8080/App/%p\n' > tmp/urls
wget -q --proxy=off --spider -i tmp/urls

Related

Business Objects 'bcm.jar' error when exporting Java app

I have been working on creating a simple Java desktop app using the RESTful API for Business Objects and have run into an issue. Whenever I run my app in Eclipse in works fine; whenever I export it as a 'Runnable Jar' and select the Library handling option 'Package required libraries into generated JAR' it works fine. However, whenever I try to export it using the Library handling option 'Extract required libraries into generated JAR' I get the following error after running the app:
java.lang.NoClassDefFoundError: Could not initialize class com.businessobjects.bcm.BCM
I have the 'bcm.jar' file added under a 'res' Source Folder and have it added to the Build Path. At one point I added all the JARs under the 'SAP BusinessObjects' java folder, and external folder, but it still throws the error. The problem stems from this line of code:
enterpriseSession = CrystalEnterprise.getSessionMgr().logon(userID, password, CMS, auth);
Would anyone know why I am getting said error? I really want to use the Extract option as it will improve performance as my app becomes larger. Any help resolving this issue would be greatly appreciated :)
EDIT: I would be happy to provide clarification or further detail upon request!
Seems this was introduced in SP04 and SAP has no intent of fixing it as the RESTful API wasn't designed to be used with Desktop apps.
Have you included the cryptojFIPS.jar? Leaving it out can cause the error.

ASM byte code view displays "// couldn't generate bytecode view, no .class file found"

In IntelliJ with the ASM Bytecode plugin installed you can select "Show Bytecode outline" in the popup menu when viewing a class file. Recently my IntelliJ (Community Version 12.1.6) started displaying:
// couldn't generate bytecode view, no .class file found
in the ASM window.
This occurs on various class files across different modules in my project. The strange thing is that I will get this message for one class; but another class in the same module and package works fine.
The entire project compiles fine and all my tests run. I cannot figure out why I get this message for one class and not another.
I have had the same problems after moving to IDEA 12 but my "positive hit rate" for being actually able to view the byte code outline became more stable again after upgrading to version 13. However, the result is still rather dissatisfying. From the logs, I learned that the plugin seems to not being able to find the referred class files even though they exist. It helps to make the project before trying to view the files, but this is not a perfect solution either. I guess, the problems will stay until someone sufficiently annoyed (maybe you?) upgrades the plugin.
What I use for now is simply javap from IntelliJ IDEA. You can add external tools by doing the following:
Settings > External Tools > Add...
Set the javap location for the called program: For example C:\Program Files\Java\jdk7\bin\javap.exe on Windows, depending of your installation path.
Add -v -c $FileClass$ as the parameters (here you can of course set the parameters you actually require).
Set $OutputPath$ as the working directory.
Now you can use javap from the right click menu on the source code view and you can also define a shortcut for the command.
Per Andrey Breslav's comment, the correct resolution to this issue is to use the "Show Bytecode" command in the "View" menu. You must have the source file open for this command to be displayed. You must have compiled the source since the last change for the command to complete successfully.

org.apache.axiom.om.util.AXIOMUtil cannot be resolved

I'm trying to generate some stubs for a WSDL (using xmlbeans) and keep running into some issues. I'm using the following page:
http://axis.apache.org/axis2/java/core/docs/userguide-creatingclients-xmlbeans.html
The only part of these steps that I'm skipping is the "client.java" part because I already have another project ready I want to plug the resulting jars into. A quick run down of my steps are as follows:
My WSDL is a crmonline instance, so I run something like this:
C:\Work\aaa2>WSDL2Java -uri
https://mycrmorgname.crm.dynamics.com/XRMServices/2011/Organization.svc?wsdl
-p crmsdk -d xmlbeans -s -o c:\mystubfolder
I build the project using "ant"
In my "client" project I reference the 2 jars created in .\build\lib
My project builds fine once I add all my axis2 / apache references etc, but when I launch it through playframework I get errors when I hit the first page. The first error seems to be:
17:48:45,289 ERROR ~ Error in ControllersEnhancer.
controllers.ProfileController.editProfile has not been properly enhanced
(fieldAccess javassist.expr.FieldAccess#212ca458).
or something similar to that. Scrolling down through the error I can see that I'm getting this:
The file /app/models/MyDynamicsClient.java could not be compiled.
Error raised is : org.apache.axiom.om.util.AXIOMUtil cannot be resolved
Now, I haven't even hit any of my web services yet, or even instantiated any of my classes ... I'm at a loss as to why this is happening. Or to be more accurate, what exactly am I messing up! Am I missing a reference to something? Doing a search on AXIOMUtil tells me this should be in Axiom-api (version I have is Axiom-api-1.2.10.jar). I have this referenced and doesn't seem to help. Or maybe I'm doing something else wrong someplace?
Some details on versions:
Axis2 1.5.4
Apache-ant 1.8.3
Any help would be very much appreciated!!
Ok, after trying a lot of different things and rereading the sites/instructions I realised what I was doing wrong. Or at least I figured out a couple of things that I started to do differently that fixed the problem.
Firstly, I was using jar files from another sample project for the apache http components. I don't know if this had an impact, but I downloaded a fresh version of this anyway and referenced those JARS instead.
Also, instead of creating jars in my "stub" project and referencing those I copied all the generated stubs/classes directly into the existing client project. I have a feeling this might have been what fixed my problem. Or maybe a mix of this and the previous step I did!
So my new steps are as follows:
Ensure you have all the correct versions downloaded for required components. In my case I have the following:
Apache Axis 2 v 1.5.4
Apache HTTP components client 4.1.3
Apache-ant 1.8.3
Copy all the JARS from the Axis2 and HTTP Components libs into your client project and reference them.
Use WSDL2Java to create your stubs and classes within it's own project.
Ensure the project builds using Ant
Copy all the generated class files within the src folder into the source folder of your client.
Fix any other reference isssues and Build
Thankfully this got me going.

Incompatible magic value 1008813135

I am writing a Java applet and embedding it in a web page.
It used to run Mac and Windows in different browsers without problem.
I was using NetBeans on the Mac to build the .jar file the applet used.
For some reason or another I decided to load the project on the Windows' NetBeans - I started getting the following error on the Windows machine when accessing the web page from any browser:
java.lang.ClassFormatError: Incompatible magic value 1008813135 in class file
Fearing that it must have been my decision to open the project on Windows that caused this error - I tried to build from the Mac's NetBeans - but the error persisted.
I started a while new project on the Mac and imported the existing source code: still same problem.
I was doing some reading about this error and it seems that the magic number expected is 0xCAFEBABE in hex which is 3405691582 in decimal, not 1008813135. So it looks like the Mac version of Java doesn't produce this file header any more? Hoe can that be? I didn't do any updates or anything.
Yes, 0xCAFEBABE is the usual first 4 bytes of a Java file.
1008813135 is <!DO in Latin encoding, which is, in all probability, the start of <!DOCTYPE....
It is therefore likely the start of a 404 error, or some other error page.
I have not experienced this problem, but Googling this error yields several possible solutions:
forum.sun.com - Java Applet Development - Incompatible magic value 1008813135 in class file MyApplet
Thanks God the problem is solved.
Its the Java cache, so the solution go to Java Control Panel, "General" tab, and under "Temporary Internet Files" click "Settings", then click "Delete Files". Try using the applet again.
"Incompatible magic value 1008813135" Error?
The problem is now solved: I found out that the website host I was using didn't support .jar files at all. I mass-uploaded the files with my ftp program and didn't notice that it ignored the .jar files completely.
Errors on java initialization
Alright, so it was an apache configuration issue, removed this line from my httpd.conf file:
# DefaultType application/x-httpd-php
Fixed the issue.
If you are using Spring security or some sort of custom Servlet Filters, make sure, that the archive or codebase location is in "permitAll" access. This was to problem in my case
I was facing the same problem.The reason in my case was all dependency library that Applet uses was not signed and also applet not able to locate them.
So i Have added all the dependent library along with main applet in jsp file like below :
app.archive = '/esense/resources/lib/Applet.jar, /esense/resources/lib/jasypt-1.7.jar, /esense/resources/lib/mysql-connector-java-5.1.30.jar, /esense/resources/lib/runtime-api-1.0.jar';
I have also signed all the jar.
Hope this may work in your case.
The incompatible magic number is the first four bytes of a html file that has some error message in it, probably a message that the file isn't found.
I encountered this phenomenon when I didn't take case sensitivity into account in the codebase element of the applet tag. Things worked well on Windows, but the internet server I was using was running UNIX where filename case sensitivity is important. Making the case of all file and directory names in the code and codebase elements solved the problem.
I just clicked on maven->update project->include snapshot release in my spring boot and it worked.

WebSphere App Server Not Compiling JSP/Tag Libs

This is a problem that only occurs on application update (only tested through Admin Console, not CLI). Also, this is only happening on our development environment, which is identical to our prod env. On uninstall/install, everything is compiled properly. However, this is a large application and it takes long enough to do an update--we do not want to uninstall/install everytime (esp. during dev. builds).
JSP .java and .smap files are being generated, but not .class. On prod, there is no .smap--only .java and .class. If the JSPs would compile, we believe the tag libs would be compiled also.
Has anyone faced this problem, or know what we are possibly overlooking?
WAS Version: 6.1.0.17
EDIT: This is only happening for one JSP and the tag library its using. We're trying to trouble shoot the issue. Let you know if we figure anything out. We think it may be an issue with the .SMAP file per this fix
SOLUTION
Solution:
Problem was: WAS had debugging enabled. This generated .smap files (source mappings) instead of .class files. Once we discovered this, we disabled the debugging service under the Admin Console (Application Servers > server1 > Debugging Processes > uncheck 'Start service'). I don't know why this created a bug upon an update only, but, whatever the case, the problem is solved.
One suggestion:
Have you checked that your environment has a JAVA_HOME pointing to a JDK and not just a JRE. The JRE doesn't have javac, so there won't be any way to compile .java files created at runtime by the JSP compiler into .classes?
EDIT: Also, perhaps this link may help?
I haven't worked with taglibs, but I can tell you this:
the application server checks timestamps. be very very sure that the "modified" timestamps of the JSP files are reasonable from the point of view of the application server (say, are not in the future)
Hope this helps you solve the problem...

Categories