Board index » jbuilder » JavaHelp problem during deployment

JavaHelp problem during deployment


2006-11-09 09:24:36 PM
jbuilder0
Hi,
I am having problems deploying my java application from within JBuilder. I am working in the JBuilder 2006 Developer environment. My application utilizes the services of the JavaHelp package to provide the user with a help system. For this, I have used the external JAR files by the name of jh.jar and jsearch.jar. When I create an executable JAR file for the application and try running it, everything seems to be functional, except the help system. The help window appears to be blank/empty. Could someone please help me troubleshoot this problem.
Thanks in advance
 
 

Re:JavaHelp problem during deployment

Talha wrote:
Quote
Hi,

I am having problems deploying my java application from within JBuilder. I am working in the JBuilder 2006 Developer environment. My application utilizes the services of the JavaHelp package to provide the user with a help system. For this, I have used the external JAR files by the name of jh.jar and jsearch.jar. When I create an executable JAR file for the application and try running it, everything seems to be functional, except the help system. The help window appears to be blank/empty. Could someone please help me troubleshoot this problem.

Thanks in advance
I think that the problem here is that the Java Help jar files are code
signed and that when you include them within your jar file, you are
importing partially signed jar files (which of course will not work).
Try the following:
(1) Do not include the jh.jar and jsearch.jr files in your
application.jar file. Instead, make a /lib folder directly under your
application.jar file directory path and include it on your classpath.
You could do this with either a batch file or a .sh/bin file for Unix/Mac.
(2) Create a META-INF directory in your /src folder for your project.
Create two empty files named SUN-MCSR.RSA and SUN_MICR.SF files in that
directory
Open the Properties dialog for the application archive and on the
Content page, add those two files to your archive and add the jh.jar,
jh.all files. This should overwrite the two files that javasoft creates
for the signature files (for the code signing).
Good luck!
 

Re:JavaHelp problem during deployment

I tried that and it seems to be working now. Thanks a lot for your help. I appreciate the prompt response.
 

{smallsort}

Re:JavaHelp problem during deployment

I have another question related to this topic. I am creating an executable JAR through JBuilder Developer 2006, and I am wondering if there is any way of forcing it to use a specific JRE that would be bundled along with the application. I need to do this because the applications utilizes the services of the Java3D package from Sun Microsystems, which means that I had to make additions to the existing JRE. I cannot possibly expect every end-user to have a JRE supporting Java3D on their machine, if they have a JRE at all. Please advise me if there is a way around this problem.
Thanks!
 

Re:JavaHelp problem during deployment

Talha wrote:
Quote
I have another question related to this topic. I am creating an executable JAR through JBuilder Developer 2006, and I am wondering if there is any way of forcing it to use a specific JRE that would be bundled along with the application. I need to do this because the applications utilizes the services of the Java3D package from Sun Microsystems, which means that I had to make additions to the existing JRE. I cannot possibly expect every end-user to have a JRE supporting Java3D on their machine, if they have a JRE at all. Please advise me if there is a way around this problem.

Thanks!
Several ways to do this.
This is the easiest (but may not always work)
String s=System.getProperty("java.version");
System.out.println(s);
Of course your Java program would have to launch.
Second way is to get all of the environment variables and look for
JAVA_HOME, JRE_HOME:
java.util.Map m=System.getenv();
String java_Check_Path="";
java.util.Set set=m.keySet();
java.util.Iterator i=set.iterator();
int x=0;
while(i.hasNext()){
String name=i.next().toString();
//Look for the JAVA_HOME,JRE_HOME,SDK_HOME values
if(name.equalsIgnoreCase("JAVA_HOME")){
//do something with path info
java_Check_Path=m.get("JAVA_HOME");
}
else if (name.equalsIgnoreCase("JRE_HOME")) {
//do something with path info
java_Check_Path=m.get("JRE_HOME");
}
else if (name.equalsIgnoreCase("SDK_HOME")) {
//do something with path info
java_Check_Path=m.get("SDK_HOME");
}
Of course, your java code would have to lanch here.
It would be best to put this into a batch file (for Windows) or a .sh
file for Linux/Unix to make sure that the program(s) could launch. If
they couldn't, then you could assume no suitable Java version was
located on their desktops. Of course, using a batch or shell script
would not require that you use Java at all; you could just issue the
command: java -version. If that returned nothing back, then it is safe
to assume that no suitable Java version was located on their path
settings or that java was not installed on their desktops.
 

Re:JavaHelp problem during deployment

"Paul Nichols [TeamB]" < XXXX@XXXXX.COM >wrote:
Quote
Talha wrote:
>I have another question related to this topic. I am creating an executable JAR through JBuilder Developer 2006, and I am wondering if there is any way of forcing it to use a specific JRE that would be bundled along with the application. I need to do this because the applications utilizes the services of the Java3D package from Sun Microsystems, which means that I had to make additions to the existing JRE. I cannot possibly expect every end-user to have a JRE supporting Java3D on their machine,
if they have a JRE at all. Please advise me if there is a way around this problem.
>
>Thanks!
Several ways to do this.

This is the easiest (but may not always work)

String s=System.getProperty("java.version");
System.out.println(s);

Of course your Java program would have to launch.

Second way is to get all of the environment variables and look for
JAVA_HOME, JRE_HOME:

java.util.Map m=System.getenv();
String java_Check_Path="";
java.util.Set set=m.keySet();
java.util.Iterator i=set.iterator();
int x=0;
while(i.hasNext()){
String name=i.next().toString();
//Look for the JAVA_HOME,JRE_HOME,SDK_HOME values
if(name.equalsIgnoreCase("JAVA_HOME")){
//do something with path info
java_Check_Path=m.get("JAVA_HOME");
}
else if (name.equalsIgnoreCase("JRE_HOME")) {
//do something with path info
java_Check_Path=m.get("JRE_HOME");
}
else if (name.equalsIgnoreCase("SDK_HOME")) {
//do something with path info
java_Check_Path=m.get("SDK_HOME");
}

Of course, your java code would have to lanch here.

It would be best to put this into a batch file (for Windows) or a .sh
file for Linux/Unix to make sure that the program(s) could launch. If
they couldn't, then you could assume no suitable Java version was
located on their desktops. Of course, using a batch or shell script
would not require that you use Java at all; you could just issue the
command: java -version. If that returned nothing back, then it is safe
to assume that no suitable Java version was located on their path
settings or that java was not installed on their desktops.


Thank you for your prompt response Mr. Nichols. I have read over the options you have suggested, and i believe that these are ways of simply determining whether a client's machine has a Java plotform installed on it. I would love to use is to identify if i need to use a custom JRE, but the problem remains that my application uses Java3D, for which I had to make additions to the existing JRE.
Therefore, I would be very greatful if you could suggest a way in which I can specify a JRE (that I plan to propagate along with my application) for the executable JAR file. A standard JRE/JDK installed from the Sun Microsystems website is insufficient for my application without the addition of the Java3D package. I hope I have explained my problem clearly.
Regards,
Talha
 

Re:JavaHelp problem during deployment

Quote

Thank you for your prompt response Mr. Nichols. I have read over the options you have suggested, and i believe that these are ways of simply determining whether a client's machine has a Java plotform installed on it. I would love to use is to identify if i need to use a custom JRE, but the problem remains that my application uses Java3D, for which I had to make additions to the existing JRE.

Your assumption is correct.. That was what I thought you wanted.
If you want to check for a particular class, then you need to create a
custom class loader or check the class path to see if it exists on the
classpath. You can do this with the
System,.getProperty("java.classpath") and iterate through the results.
However, this does not garantee that the 3D packages will be on the
classpath and even if it is, that you will necessarily see it.
The best way would be to look for the jre path (using the code samples I
provided) and them try loading an instance of that class. If it does not
load, then you could assume that it is not there and install it.
I would use the second option (first post) in this case, and find the
actual jre path. Then install what you need to install from a custom
installer. You could then have your custom installer write a batch file
(for Windows) or a Shell Script (for Unix/Mac) to create a start up
file. Of course, you could, as well, skip the search for the 3D packages
altogether and have your jar files include the 3D jar files instaled in
the directory where your application is installed, and make sure (in
your batch or shell script file) that these jar files reside on your
custom script file's classpath.
Hope this helps ya!!
Quote
Therefore, I would be very greatful if you could suggest a way in which I can specify a JRE (that I plan to propagate along with my application) for the executable JAR file. A standard JRE/JDK installed from the Sun Microsystems website is insufficient for my application without the addition of the Java3D package. I hope I have explained my problem clearly.

Regards,

Talha

 

Re:JavaHelp problem during deployment

"Paul Nichols [TeamB]" < XXXX@XXXXX.COM >wrote:
Quote

>
>Thank you for your prompt response Mr. Nichols. I have read over the options you have suggested, and i believe that these are ways of simply determining whether a client's machine has a Java plotform installed on it. I would love to use is to identify if i need to use a custom JRE, but the problem remains that my application uses Java3D, for which I had to make additions to the existing JRE.
>
Your assumption is correct.. That was what I thought you wanted.

If you want to check for a particular class, then you need to create a
custom class loader or check the class path to see if it exists on the
classpath. You can do this with the
System,.getProperty("java.classpath") and iterate through the results.
However, this does not garantee that the 3D packages will be on the
classpath and even if it is, that you will necessarily see it.

The best way would be to look for the jre path (using the code samples I
provided) and them try loading an instance of that class. If it does not
load, then you could assume that it is not there and install it.

I would use the second option (first post) in this case, and find the
actual jre path. Then install what you need to install from a custom
installer. You could then have your custom installer write a batch file
(for Windows) or a Shell Script (for Unix/Mac) to create a start up
file. Of course, you could, as well, skip the search for the 3D packages
altogether and have your jar files include the 3D jar files instaled in
the directory where your application is installed, and make sure (in
your batch or shell script file) that these jar files reside on your
custom script file's classpath.

Hope this helps ya!!


>Therefore, I would be very greatful if you could suggest a way in which I can specify a JRE (that I plan to propagate along with my application) for the executable JAR file. A standard JRE/JDK installed from the Sun Microsystems website is insufficient for my application without the addition of the Java3D package. I hope I have explained my problem clearly.
>
>Regards,
>
>Talha
>

Thank you Mr. Nichols for your help. I will look into your suggestions and try out the technique that best works for my application. Thanks again!
Talha