Anybody know anything about Java Beans...

[schueymcfee]

and packages?

An update of tomcat and the compiler has thrown up somebody else's problem that has now become mine

Main problem is that productbean.class hasn't been included in the package and is now causing problems. I only have productbean.class, I don't have productbean.java, so I can't make any changes. I wanted to know if I can just throw productbean.class into the package and then repack?

TIA

>>> Edited by schueymcfee on Monday 19th July 23:22

[rebelstar]

You might be able to throw the class into the webapps/<some dir>/WEB-INF/classes directory and see if it works. You'll need to create a directory structure under there based on the package name of the class though.

If you want the java source, see if one of the java decompilers can produce it for you directly from the class file. I recommend this one: http://kpdus.tripod.com/jad.html

[schueymcfee]

rebelstar said:

You might be able to throw the class into the webapps/<some dir>/WEB-INF/classes directory and see if it works. You'll need to create a directory structure under there based on the package name of the class though. If you want the java source, see if one of the java decompilers can produce it for you directly from the class file. I recommend this one: http://kpdus.tripod.com/jad.html

That was excellent, thankyou so mcuh for that link. Okay I decompiled the class and it doesn't look like there's any paths I need to change.

The package is at org.apache.jsp and the bean files are being imported as

import productbean;

I've unpacked the package and there only appears to be the folders org and apache - no JSP. So where should I put these beans and how should they be referenced in pages?

Something like import org.apache.productbean; ?

It something I've never come across before!

Thanks again.

[schueymcfee]

rebelstar said:

You might be able to throw the class into the webapps/<some dir>/WEB-INF/classes directory and see if it works. You'll need to create a directory structure under there based on the package name of the class though.

I forgot to mention - the files are already in that directory, but because they haven't been included in the package the compiler isn't happy.

[anonymous-user]

There appears to be a bit of confusion here...

Firstly, I'd just check the case of everything - usually classes are Capitalised so I'd expect it to be ProductBean and ProductBean.class with the corresponding import being import ProductBean;

A Java Bean - this is just a Java class that conforms to a number of guidelines, mainly - zero args constructor and get/set/is methods for properties.

A Package - this is a namespace that allows there to be two different classes with the same name as long as they're in different packages. I.e. the class java.lang.reflect.Array and the interface java.sql.Array are both called Array, but are unique when you include the package (java.lang.reflect and java.sql respectively).

A Java Archive - this is what I suspect you're referring to as a package. A file with the extension .jar - it's basically a zip file containing (mainly) compiled classes (.class files). This has the benefit of wrapping related classes up into one file for distribution.

Either within a jar file, or just in the classpath of the java application, classes need to be placed within a folder structure relating to the package structure of the classes.

So, the file contianing the class com.sap.sdn.Reporter needs to be placed in either:
WEB-INF\classes\com\sap\sdn\Reporter.class
or:
inside a jar file (a zip file zipping up the same path com\sap\sdn\Reporter.class) that is then placed inside the WEB-INF\lib directory.

For everything to match up, the import statemen of import productbean suggests that the product bean class hasn't actually been put into a package. So, the class file should be placed in WEB-INF\classes\productbean.class and if you were to decompile productbean.class you shouldn't see a package ...; statement.

However, if decompiling it shows package com.company.store; or something at the beginning then you need to:
Place the class file in WEB-INF\classes\com\company\store\productbean.class
Change the code calling the class (a jsp file?) to import com.company.store.productbean

Hopefully this will clear a few things up.

[schueymcfee]

LexSport said:

There appears to be a bit of confusion here... Firstly, I'd just check the case of everything - usually classes are Capitalised so I'd expect it to be ProductBean and ProductBean.class with the corresponding import being import ProductBean; A Java Bean - this is just a Java class that conforms to a number of guidelines, mainly - zero args constructor and get/set/is methods for properties. A Package - this is a namespace that allows there to be two different classes with the same name as long as they're in different packages. I.e. the class java.lang.reflect.Array and the interface java.sql.Array are both called Array, but are unique when you include the package (java.lang.reflect and java.sql respectively). A Java Archive - this is what I suspect you're referring to as a package. A file with the extension .jar - it's basically a zip file containing (mainly) compiled classes (.class files). This has the benefit of wrapping related classes up into one file for distribution. Either within a jar file, or just in the classpath of the java application, classes need to be placed within a folder structure relating to the package structure of the classes. So, the file contianing the class com.sap.sdn.Reporter needs to be placed in either: WEB-INFclassescomsapsdnReporter.class or: inside a jar file (a zip file zipping up the same path comsapsdnReporter.class) that is then placed inside the WEB-INFlib directory. For everything to match up, the import statemen of import productbean suggests that the product bean class hasn't actually been put into a package. So, the class file should be placed in WEB-INFclassesproductbean.class and if you were to decompile productbean.class you shouldn't see a package ...; statement. However, if decompiling it shows package com.company.store; or something at the beginning then you need to: Place the class file in WEB-INFclassescomcompanystoreproductbean.class Change the code calling the class (a jsp file?) to import com.company.store.productbean Hopefully this will clear a few things up.

Thanks, it has cleared a lot up and I was confused about packages and .jar files!

The ProductBean.class file has not been included in package apart from default which is causing the problem.

My plan is to decompile the current class files and then add the package structure at the beginning (something like bean) and place the source code in the WEB-INF/src directory.

When the source is compiled it should put the class files in the WEB-INF/classes/bean directory right?

Then all I need to do to the JSP files is write import bean.ProductBean;

Am I on the right tracks?

>> Edited by schueymcfee on Tuesday 20th July 13:28

[anonymous-user]

schueymcfee said:

Am I on the right tracks?

On the right tracks

[schueymcfee]

LexSport said:

schueymcfee said: Am I on the right tracks? On the right tracks

Great, thanks for your help.

[schueymcfee]

oh and another question - as I have no experience of Java on the web, when I upload the source files how are they compiled? Do I initiate the compilation or is it done automatically?

[rebelstar]

Generally speaking you have to compile them yourself first, although this is not always the case with jsp files.

If you could give us some more information about what you are trying to do, it might be possible to give some more directed advice.

[schueymcfee]

Okay, it's a long story!! As I said in my first post the file ProductBean.class has not been included in a package, this was okay until now, but now our hosting company have upgraded tomcat the ProductBean.class file has to be included in a package.

The hosting company sent us this message (along with the error message) and some advice:-

"Tonight we had to apply a critical Tomcat security patch and after reviewing all sites on the server, only your was failing to work after the restart.

The error occurs when accessing your homepage:

org.apache.jasper.JasperException: Unable to compile class for JSP

An error occurred at line: -1 in the jsp file: null

Generated servlet error:
[javac] Compiling 1 source file
[javac] /home/combekin/tomcat/work/index_jsp.java:10: '.' expected
[javac] import ProductBean;
[javac] ^
[javac] /home/combekin/tomcat/work/index_jsp.java:11: '.' expected
[javac] import CategoryBean;
[javac] ^
[javac] 2 errors


Since we can't tel what's in those classes, we don't knwo why there is a failure. Please shed some light on this so that we can work to isolate the core cause.

We believe we've identified the problem. Part of the patches tonight included an upgrade of the javac compiler. Apparently the 1.4.x compiler now requires imports within JSPs to be part of packages, of which yours is not. Here's a link to a similar issue on a forum:

www.mainframeforum.com/t611214.html

Additional confirmation:

http://forum.java.sun.com/thread.jsp?forum=31&thread=231550&message=828192

There is nothing to call you on in this situation. A security update required the upgrade to the latest Tomcat 4 engine which happen to correct a hole that permitted you to do something you should have been able to do in the first place (import unpackaged beans). To correct the situation you need to recompile your beans as part of a package, deploy them appropriately and upgrade your JSP code to reflect the packaging.

Be low is a link to Sun's site outlining this requirement:

http://java.sun.com/j2ee/tutorial/doc/information/faq.html#compile

And just so you know, this isn't a JDK 1.3.1 vs 1.4 issue. Your account has always been on machines using JDK 1.4; it just happens to be (as mentioned above) that Tomcat 4.0.x allowed the circumvention of that packaging requirement, whereas it is now strictly enforced in Tomcat 4.1+.

Your code is the problem. You are violating a requirement of the engine that processes your application.

We realized it worked before, but the point is, it shoudln't have as there was bad coding that violated a requirement by Sun. There just happen to be a "bug" in Tomcat that allowed the code to work when it shouldn't have.

The reason only your site failed is because you are the only cusotmer on that server that violates the requirement in their code.

We understand you have no one technical there to fix the problem, but we cannot back rev the changes as they were security patches that fixed a substantial vulnerability that woudl allow a hack to gain root access tot he server (from which the hacker could gain access to all files/data or even initiate a format of the entire harddrive).

We will look to see if we have an old server in the lab that we can bring online for your site temporarily (which will still have the security hole), but you will still need to get the code fixed within the next 7 days (assuming we do have a server that can be used) and you accept full liability of any sensitive data being stolen or lost for not having the necessary security patches installed. The choice is yours. It will take about 3 hours to locate a server and prep it for production use, as well as migrating your data over."

From your advice I've managed to figure out what I need to do (I think), but when I've made the changes to the ProductClass.java file and the .JSP files where do I compile the .java files? On my machine or on the server?

[rebelstar]

You'll compile the java files on your machine and upload/package them yourself. I'm in a bit of a rush at the moment (work) so I can't explain in detail. If you don't have an answer by this evening, I'll see if I can help.

[anonymous-user]

As RebelStar said, on your machine.

Basically, any .java files need to be compiled and placed in the WEB-INF\classses or inside a jar file in the WEB-INF\lib directories.

JSP files are a special case and these are compiled by the servlet engine the first time they're accessed.

So, you'll need to add the package statement to the ProductBean.java file and compile this using javac on your local machine.

Replace the ProductBean.class file with this newly compiled version - making sure to put it in a subdirectory structure that follows the package structure.

Then change the jsp to read <%@page import="package.ProductBean"%>

[schueymcfee]

Yep, got it thanks - it's starting to make sense now!

Just one more problem -- One of the other files CategoryBean.class decompiles with errors:-

Couldn't resolve all exception handlers...

and therefore it won't recompile.

What ways around this problem are there?

Thanks.

Edited to say : Ah, it looks like a known bug in the decompiler!

>> Edited by schueymcfee on Wednesday 21st July 11:20

[schueymcfee]

Nope, tried a different decompiler and it still won't recompile!

I could be in trouble here!

[schueymcfee]

Lol, which brings us back to my first question!

Do you think I'd get away with putting the unchanged CategoryBean.class file in the package structure and then referencing it properly in the JSP files?

[rebelstar]

The problem with resolving exception handlers is something I've seen, but not had the time to look into in any depth.

I think you should be OK to leave the CategoryBean.class file alone; when you're fixing individual classes in jar/war files, it's not usually necessary to compile everything again. Just the class you're modifying. However, I don't know what happens if you just move it to another package. My guess is that it won't work but if I was desperate I'd give it a go.

Is the source code to your application not available from somewhere on the net? Could you upgrade to a more recent version of that and bypass all these problems that way?

[anonymous-user]

To change the package a class is in, it needs to be put in the right place in the folder structure, but it also needs to be compiled with the right package statement in the source code.

If you don't have the source code, there is a workaround possibility, but I haven't tried it myself so can't guarantee it.

Because the problem seems to be having a jsp referencing a class in the default package, you could write simple "wrappers" for each class you're having problems with and reference these wrappers.

To do this, you'd have to do something like the following for each class in question:

package workaround;
import ProductBean;
public class ProductBean2 extends ProductBean {
public ProductBean2() {
super();
}
}

Then you could import the ProductBean2 version of the class. You'd need to change all references to ProductBean2 and might need to add some explicit casts, e.g.
ProductBean p = category.getProduct(i);
goes to:
ProductBean2 p = (ProductBean2)category.getProduct(i);

Might work if you really cant get the code which would definitely be preferable.

[schueymcfee]

Nope, that CatagoryBean.class file is throwing up a problem. I can't get hold of the source either

Looks like I'm going to have to rewrite this entire thing in PHP

The CatergoryBean file has been specially written by the looks of it.

[schueymcfee]

This is the error I get now:-

org.apache.jasper.JasperException: Unable to compile class for JSPNote: sun.tools.javac.Main has been deprecated.
error: Invalid class file format in /home/combekin/public_html/WEB-INF/classes/bean/ProductBean.class. The major.minor version '49.0' is too recent for this tool to understand.

/home/combekin/tomcat/work/products$jsp.java:6: Class bean.ProductBean not found in import.
import bean.ProductBean;
^
error: File /home/combekin/public_html/WEB-INF/classes/bean/CategoryBean.class does not contain type bean.CategoryBean as expected, but type CategoryBean. Please remove the file, or make sure it appears in the correct subdirectory of the class path.

/home/combekin/tomcat/work/products$jsp.java:7: Class bean.CategoryBean not found in import.
import bean.CategoryBean;
^
4 errors, 1 warning