I'm working in another company's code base for a .jsp based site. Most of the site is straight up .jsp pages, but they have a few .java objects those pages use as well. I've modified one of those objects to add an extra function to it, recompiled, and yet the .jsp pages generate a "Method ... not found in class" error when I try calling it.
Obvious things I've already checked out:
It's not a simple typo in the method name.
The method is public.
I'm passing the one String the method signature demands.
The .java file has been recompiled into a .class file that has overstalled the old one.
The object with the new function was already imported and in use.
I have successfully modified other .java objects on this webserver (though not in this exact folder) and seen the changes take effect.
What else might it be?
Generally you have to explicitly set up hot-code replace in Tomcat, and usually it doesn't support adding method signatures - you may have to get the application redeployed and restarted to see the effects properly.
Here's some links for reference information about it:
Link 1
Link 2
Related
I've mostly only created application for personal use and the rare occasions where I have distributed my code have been in the form of uploading my source code on GitHub. I'm currently finishing up a project and plan on using launch4j to package it up as an exe. However, my application has a handful of png files that I coded in with the unique filepath of my computer. Obviously if my code were to run on any other computer in the world, those files would not be found.
I'm vaguely aware that java does not require the full filepath for a file (ie C:\Users...\file_name.ext) but I've never gotten a program to run correctly unless I write out the filepath like that, so that's been my default up until this point.
The resource system. Think about it: What's the difference between the many class files that comprise your application, and those png files, from an application distribution perspective?
The answer is, essentially, nothing. They are file-like concepts, they might prefer to be shipped in a packaged-up file (a jar file) instead of separately. They must be found at some point halfway through your app's existence (java does not pre-load all classes. It just loads your main class, and then loads whatever is needed the first time you mention any class).
You don't have to hardcode the absolute path to those class files in your app, so they clearly don't suffer from this 'coding filepaths' issue.
Thus, the answer is somewhat obvious: Simply stick those PNG files in the exact same place as your class files, and ask the VM to provide you with the data in them using whatever mechanism it is using itself, as it is doing that exact same job (find resource, obtain data in the resource) all the time, on your class files.
But, how?
You have 2 different methods, and these 2 methods take the same kind of argument, which comes in 2 forms: A grand total of 4 'modes' to choose from.
Pick a method
If the API you have that needs an image file so happens to have an overload that accepts a URL, this is very simple (ImageIcon is one such resource, that's probably what you're passing these PNG files to, so that's great):
URL loadIcon = ContextClass.class.getResource("/icons/load.png");
new ImageIcon(loadIcon);
Quite simple. Sometimes you want to read it yourself directly, and a URL object is rather unwieldy. Sometimes, you want to pass it to an API which does not have a URL overload, but it does have an InputStream overload. Then, you can fetch an InputStream. Given that this is a resource, like all resources, you must safely close it, thus, let's use try-with:
byte[] pngData;
try (var in = ContextClass.class.getResourceAsStream("/icons/load.png")) {
pngData = in.readAllBytes();
}
ContextClass.class is a somewhat exotic java syntax feature: It is an expression that resolves to the java.lang.Class instance of the so-named class. For example, Class<?> c = String.class; is legal java and gives you the class object that represents the class concept of all java.lang.String objects. The class object itself has these getResource methods. Thus, substitute some relevant class that you wrote as context here. Presumably, if you want to load an image in source file MyStatusWindow.java, you'd just use that class: MyStatusWindow.class.getResource.
These methods will look in the same location that the class itself was loaded from. If ContextClass is loaded from a jar, then the system will fetch PNGs from within that jar. If it's loaded from a build dir during development/debug, the png is loaded from there. If you've got some fancypants module system that is loading classes straight from the network, then the PNG will also be loaded from there.
resourceKey
A resourcekey is simply a path. It's not really a path, just - a string with slashes. You can't use .., for example, it's not really a path. You also, weirdly, can't use filenames that include more than a single dot in the name, for historic (read: silly) reasons.
You have 2 variants - classpackage relative and absolute.
.getResource("/icons/load.png") is absolute. .getResource("icons/load.png") is relative. The leading slash is the difference.
If you have:
package com.foo;
public class MyStatusWindow {
...
MyStatusWindow.class.getResource("icons/load.png");
}
And this is all in a jar file (i.e. /com/foo/MyStatusWindow.class is one of the entries listed if you execute jar tvf myapp.jar on the command line), then the above would look in that jar for /com/foo/icons/load.png - the relative form takes the context-class's package and sticks it in front. The absolute form would just look in /icons/load.png, still in the jar (so it's never C:\ - never the root of your disk - it's the root of the classpath entry).
Build systems
Maven, Gradle, and just about every other build system has a proscribed directory structure. The above example should go in src/main/java/com/foo/MyStatusWindow.java, relative to some 'root project dir'. Only java source files are supposed to go there. There's also a resources: src/main/resources/com/foo/icons/load.png, that's where your icon file would go. Then MyStatusWindow.getResource("icons/load.png") will just work, in your build system, and in your IDE, and when you ship it all as a jar file. If it doesn't, you've misconfigured your IDE or have a broken build configuration - and you should fix that. Out of the box, this just works.
I got a Java project from another developer and I found several files with these two names strewn around the source folder:
vssver.scc
filesystem.attributes
I know the first one is from Visual SourceSafe but what about the second? Are these files from Visual SourceSafe too?
It's difficult to search this as Google simply ignores the dot character in between, even if I put the whole thing in quotes.
Edit: File contents are binary but mostly have references to classes from Java and libraries:
After some digging, it looks to be a (presumably obsolete) Netbeans thing. The only real reference I could find is this Netbeans mailing list post from August 2000, which says it was used to store various IDE metadata about each file.
It is created automatically when you modify some attributes of a file
using the IDE itself. [...] Every file (including directories) stores its
attributes in a filesystem.attributes located alongside it (in the
same containing directory). FileUtil.extractJar specially recognizes
filesystem.attributes in a JAR, so if you jar up your directory then
when it is extracted the jarred attributes will be applied to the
extraction folder.
The post mentions a "future reimplementation" using an XML-based filesystem, which I think has happened by now. This later post mentions using the name .nbattrs to replace the old filesystem.attributes. I'm not a NetBeans user, but this seems to be what happened; for instance, I found an example in this gist.
Right now I am trying to accomplish a project on Eclipse Juno and Tomcat 7 that requires to have a "virtual folder" to hold multimedia files (like images, other sub-pages,etc.). I already have some methods to give out the file path in a URI based syntax (lets say I want to access images in /Content/Image) and I want to map that URI to C:\Users\MyUser\Content\image (I am aware that I am binding the project to Windows systems but I will workaround later on in this issue).
Currently my project is called pj, and Eclipse created a context called pj inside the eclipse's tomcat instance (and thats makes a lot of sense). When i test my project with
> http://localhost:8080/pj
it works fine (and it's supposed to).
But there is a problem here: until now I haven't found a way to create a URI in tomcat to actually go to the Content/Image path to grab content to add to my pages (read somewhere that is unhealthy to keep content on WEB-INF folder, so i'm trying to actually get it done the right way). Also read somewhere that to accomplish this objective, I have to do something like this in the contexts:
<context docbase="d:/images" path="/Content/Images"></context>
Also read there that in tomcat, to resolve URIs you have to use contexts to achieve that goal (giving a bridge between the meaning of he URI and it's location in the file system).
Still, as from tomcat 4 (if not mistaken) it is not supposed to fiddle around server.xml, so in ANOTHER attempt to make this right, i try to actually add a context in META-INF inside context.xml with the code shown before. But there is here ANOTHER problem! It seems that adding the path tag makes tomcat go nuts, as said here: http://tomcat.apache.org/tomcat-7.0-doc/config/context.html .
So I am really in a bind here.... What I want to ask is:
What is the best way to actually add an external folder in a web project to fetch multimedia content and
How it is supposed to make it work inside Eclipse?
PS: I am asking this because in one of my methods inside my project I am using the getLoader method to return the InputStream (java.io InputStream NOT Corba) and it return nulls (which means it doesnt find it).
EDIT: Tried to actually fiddle around server.xml by inserting the conext by hand but didn't work, inserting the relative URI doesn't work on the server (local:8080/Content/Image with valid files inside) or going inside my main project and do getstream doesnt work too
After some fiddling around, tweaking, etc. I came up with a workaround for this situation. Like I stated, it IS possible to actually have an outside folder hold all the multimedia and/or pages as you wish. One of the references to that solution is here: http://harkiran-howtos.blogspot.pt/2009/08/map-external-directory-into-your.html .
Still, for some reason, this is not quite possible to make it work inside Eclipse (or I have failed something and wasn´t unable to make it work). But there is an alternate solution for this. It is also feasible to actually have a folder for that purpose INSIDE the web app but OUTSIDE the WEB-INF and META-INF folder. In other words, a folder that is located in the ROOT of the web app.To access those files in that folder you can use something called ServletContext. That context has actually inside all possible references to the folder structure of your web app. To access those files with the context give, you have to use getResourceAsStream from the Servlet context (or use getRealPath if it is necesary and/or you can guarantee that the web app is exploded inside Tomcat). So in other words, to access folders inside the web app but outside the WEB-INF and META-INF you have to use ServletContext and their given methods to get files/streams.
PS: Ty wds for pointing out ServletContext
I made the harkiran's solution work but it's not very good solution.
People discourage use of getRealPath. Mapping external folder is good thing to do for many reasons.
But to do it in Eclipse, you need to go to deployment folder.
In my case it's hidden folder inside Eclipse workspace.
workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/
Inside that folder you shoud make directory structure and file from harkiran's solution. I works until you delete and recreate server in Eclipse.
After that you need to make it again.
I'm very new to Java and JSP.
I am working with a purchased Java web application. When I access the application in my browser, there is a file "mysite.com/app/servlet/com.sample.weblet.server.ClientReader?..." that contains a line of Javascript is erroring out in some browsers. I would like to find the source of that Javascript code so that I can modify it so it will be cross-browser compatible.
I've searched all of the JSP and JS files (which are all in a separate folder, and not packaged into JAR files), but could not find the faulty function.
I dug through the JAR files extensively. I only found class declarations, variable declarations, and empty methods. I have not been able to find any logic whatsoever, and definitely have not come across anything resembling javascript auto-generation. There are no WAR files.
I found com.sample.weblet.server.ClientReader in a jar file.. and it just contained a couple of empty methods, yet again.
I am assuming that this faulty JS code is auto-generated. Does that sound correct?
Is there like one main JAR file that has all of the logic? Would it have this JS code hard-coded into it? What am I missing?
Can anyone direct me, or give me any tips?
My suggestion is you should use firebug to detect the javascript error. If any error occurs, you'll see it under "console" tab in firebug and usually there's a link beside it, click on the link will bring you where the bad code resides.
Also, you can navigate javascript files the page has loaded by clicking the list button under "Script" tab in firebug.
Hope it helps.
In addition to what my title says, I am running into problems because their class file is linked as follows:
"var attributes =
{code:'xx/xxxx/xx/xx/xxx/xxx/xxxxx.class'
width:645,height:443,archive:'xxxxx.jar'}"
First, I naively copied the HTML code and it did show a Java Applet Object, but couldn't load it because it obviously didn't find the class. I tried many different addresses to see if I can download the class, but with no success. Does this mean the class can't be downloaded? I'm in the process of asking for their permission and see if we can get it directly from them.
I also thought of another way. Is it possible to embed their whole page as an iframe AND "crop" it so the iframe only displays the area where the Java Applet is located? If this is possible, it would be the best and easiest way.
You certainly can download the the .jar file - they have to be accessible so that browsers can load them. I'd guess you are trying to get the .class file, but it is within a .jar, so get the .jar instead.