I have a requirement in which my front-end screen creates an XSD at run time.
After which i need to create Java Classes for the same then zip it into an war file.
all this needs to be done at run time and within JVM.
I have researched on this and found that xjc( xjc -p foo myschema.xsd ) tool command. Unfortunately it seems that the tool cannot be run from inside my java application.
There is an Process API to run the tool from Java, but i think it will make it OS dependent.
Please help me.
I need to generated Java Source Code or direct Binaries(Class Files) from XSD at run time and package the same to an EAR.
You can definitely run the tool from your Java program, just like any other application can be invoked that way.
You can even supply the current working directory when executing the Process.
As long as you don't do anything OS dependent, then you won't make your application OS dependent. This is particularly relevant when supplying the paths. If they are relative, then use Linux style paths (and avoid spaces in the paths) to stay safe.
Once you do that, you can group the *.java and *.class files and Jar them using regular Java tools. From there, you can use some API to load the EAR into your Java EE environment.
Related
I want to run a jar file in both unix and windows without have to call it directly with java like:
java -jar myjar.jar parameters
i want :
myjar.jar parameters
I've been reading allready -
Running a JAR file without directly calling `java`
Which seems like a very nice hack for unix .
Howerver , this wont work in windows.
I'm looking for a uniform solution that will work both on unix and windows , but I'm not sure there is such.
The solution has to be only once , and it has to include changes related to the jar only ,and not the operation systems - because this is a file to I'm suppling to a client.
What you are asking can't be done: Windows will load executable files only in the PE/COFF format used in .exe in .dll files.
What you can do instead is supply the users a "wrapper" program that starts the actual Java program. You could create the wrapper in C, which has several benefits: you can set an icon on the executable and associate the program with file types in the Windows Explorer. Batch files are a popular alternative; they are easier to create.
You can provide a script that starts your application for both Unix (.sh) and Windows (.bat). This seems to be the preferred approach for many companies. An example would be JBoss Server where a run.bat is provided for Windows and a run.sh is for Unix. These scripts set the appropriate environment variables, classpath, etc and then call java.
You can write your own bash and batch/powershell scripts. As for windows, you can try Launch4J. It should be easier than writing elaborate scripts from scratch.
Be aware that you can only provide wrappers to make the execution simpler (one click). Java has to be run anyway. Either explicitly, by the user, or as part of a script. You can't do without it.
Currently I have been deploying my application as a .jar file, because users of every OS can just double click it. However I now need to increase the max heap size, and the only way to do that is to pass a command-line argument (-Xmx1g) to the JVM. I wish it was possible to include this in the jar manifest, but it's not.
So now I am forced to include a .bat or .csh with the .jar that has the arguments. It seems like there is a better way to do this right? I don't think that Webstart is a good option because the .jar is meant to run in a user's directory where it writes out files. The application is a desktop GUI app.
Unfortunately it is not possible to specify vmargs in the manifest file inside your jar, so you need a workaround like :
Create a script that launch the jar file with specified vm args
Wrap your jar inside an executable that will work as a launcher
Compile your Java code into native binary
The first solution can be easily implement using a batch or an shell script for example, while for the second solution there are several alternatives that can be useful as for example the aforementioned and native Java Web Start and launch4j that is a Cross-platform Java executable wrapper.
The third solution can be implemented in some situations and if your code is compatible with the GNU classpath library, in this case you could compile into native binary using GCJ .
Webstart seems like a good way to achieve that, and if you have the right permissions, nothing prevents you from reading from / writing to the user's file system.
It also provides several interesting "features", including:
the possibility to push upgrades to the user transparently
checking that the user is using the right version of the JRE
In your case, you would just need to use the following syntax:
<j2se version="1.7+" java-vm-args="-Xmx1g" href="http://java.sun.com/products/autodl/j2se"/>
How can I get mcc to recognize imports from user-provided Java libraries, or to simply ignore unresolvable imports?
I have a Matlab codebase that I'm building with the Matlab Compiler, but the build is breaking because mcc is erroring out when it encounters import statements for Java classes that were in JARs on Matlab's dynamic classpath. I am including all the JAR files on the classpath with the mcc -a option. The code works in the IDE, and I think it will work in the deployed app, if it will only allow me to build. (Works under R2009b, which ignores these imports in non-MCOS classes.)
Here's a simple repro. This file is in the same dir as guava-11.0.1.jar from Google Guava.
%file hello_world_with_import.m
function hello_world_with_import
import com.google.common.base.Stopwatch;
disp('Hello, world!');
end
Running it in Matlab works fine. But building it fails. (The javaaddpath here is not strictly necessary in the example, because bad imports by themselves are not an error in plain Matlab. Just showing how it works in practice, and how I wish mcc picked up on it.)
>> javaaddpath('guava-11.0.1.jar');
>> hello_world_with_import()
Hello, world!
>> mcc -m -a guava-11.0.1.jar hello_world_with_import
Error: File: C:\Temp\import_test\hello_world_with_import.m Line: 3 Column: 8
Arguments to IMPORT must either end with ".*"
or else specify a fully qualified class name: "com.google.common.base.Stopwatch" fails this test.
Unable to determine function name or input/output argument count for function
in MATLAB file "hello_world_with_import".
Please use MLINT to determine if this file contains errors.
Error using mcc
Error executing mcc, return status = 1 (0x1).
This is in Matlab R2011b on Windows.
Some background on my environment. My app has about 40 JARs on the dynamic classpath which are a mix of third party libraries and our own Java code. It's deployed to 50+ users on a mix of single-user and multi-user Windows machines. And there are other groups that may be deploying other MCR apps to the same users and machines. On any machine, different MCR apps may be run concurrently by the same or different users. We do weekly releases, and (mostly due to changes in our own Java code) at least one JAR file changes about every other release. I need a mechanism that will work in this environment.
Any suggestions? Anybody know a good way to get mcc to add stuff to its java classpath in the compilation step, or just ignore bogus imports? My fallback plan is to go through the codebase and remove all the imports for Java classes, which is kind of a pain.
UPDATE 12/2/2012: I heard from MathWorks that this is fixed in Matlab R2012b. (But I'm no longer using Matlab so can't personally verify it.)
UPDATE 12/09/2014: I'm using Matlab again (R2014b), and the Matlab Compiler now includes JARs that are on the dynamic classpath in the compiled program's dynamic classpath. It doesn't seem to automatically include the JAR files in the archive, though; you must manually include them using an mcc command line switch, or adding them as "additional included files" in the Matlab Compiler app.
The code executing in the MATLAB IDE works because the guava jar file has been added to the "dynamic" classpath via the javaaddpath method. However, when you use MCC to invoke the MATLAB Compiler, it does not rely on the dynamic java classpath, but the "static" java classpath which is defined in:
$MATLABROOT/toolbox/local/classpath.txt
If you add an entry for your JAR file here, then MCC will be able to resolve the IMPORT line in your M-File.
So to test this, I downloaded the guava jar file and tried the steps above. Works like a charm.
Also, If you read the "Troubleshooting" section for the MATLAB Compiler, this exact situation is documented:
http://www.mathworks.com/help/toolbox/compiler/brtm1xm-8.html
Quoting from the link: "The import statement is referencing a Java class () that MATLAB Compiler (if the error occurs at compile time) or the MCR (if the error occurs at run time) cannot find.
To work around this, ensure that the JAR file that contains the Java class is stored in a folder that is on the Java class path. (See matlabroot/toolbox/local/classpath.txt for the class path.) If the error occurs at run time, the classpath is stored in matlabroot/toolbox/local/classpath.txt when running on the development machine."
You just have to put import statements in a separate .m file.
so from:
javaaddpath 'c:\some.jar';
import com.something.Element;
...interesting stuff...
There will be a do_imports.m:
import com.something.Element;
And in original .m:
javaaddpath 'c:\some.jar';
do_imports
...interesting stuff...
And then it will compile and work. No need to mess around with system-wide classpaths.
Here is an extract from the link
http://blogs.mathworks.com/desktop/2009/07/06/calling-java-from-matlab/
MATLAB maintains a path for Java classes separate from the search path. That means even if you have a .class or .jar file on the MATLAB path, unless you use javaaddpath you will not be able to use it. To see what is currently on the path use javaclasspath. Running this command you will show you a long list of files that ship with matlab called the Static Class Path and then you'll see the Dynamic Class Path. The dynamic class path is where classes added to the path with javaaddpath will be placed. They can be removed with javarmpath and have to actively reloaded each session of matlab.
I have a Java application installed. The jar is bundled into an .exe file using Launch4J. Now I want to create a patch for this application.
If I create another jar containing only updated files, how can I refer it in the original code?
I have java application installed. ..Now I want to create a patch for this application.
This is one of the strengths of the Java Web Start launch technology that comes with the J2SE. Simply update the Jar on the server, and the next time the app. launches, it will be updated.
The update can be honed for your use-case, configured to be done lazily or eagerly, before or after launch, or even programatically controlled using the JNLP API's DownloadService.
..And the jar is bundlled into an .exe file ..
'Unfortunately', JWS works on Windows, ..and Mac., and *nix - so you may have to expand your horizons.
BTW - I have no idea how to do the same with Launch4J, but then, that is really the wrong question. I aim to provide an answer to the right question, which is "How do I deploy & update a Java rich client?". ;)
I've never worked with Launch4J, however I think you should try to affect the classpath. JRE always loads the classes from the classpath. From this point of view, jars have no added value and just serve as a containers for your *.class files and resources.
Now, if you succeed to configure your tool to do something like:
classpath = C:\Temp\my_patch_path;$your_current_classpath
then its enough to put your changed files into C:\Temp\my_patch_path (of course preserving the package structure). JRE will load your classes first in this case.
Hope, this helps
Mark
It is might not be possible to do this without changing the contents of the exe.
I want to evaluate a software solution where multiple people have submitted JAR files to perform a task on Windows.
Is it possible to check whether the JAR file performs any additional unwanted behaviors besides those it claims to perform on your machine?
First, you can use a JVM set with SecurityManager to do run your application in a way that it can have limited access to sensitive functions.
You can also set up a "sandbox" so the jar cannot have permissions outside of the sandbox... you could use chroot or a similar tool in a linux/unix environment.
1. You could use software from Sysinternals:
http://technet.microsoft.com/en-us/sysinternals/bb842062
You can see is program's writing or deleting something from hard drive with HardMon, or monitor any changes with RegMon... Check out their website, they have much programs and you can monitor practically everything!
2. Or you could install Sandboxie:
http://www.sandboxie.com/
and then run you program within sandbox ("virtual filesystem"). When you run a program inside of sandbox, you can see what files did the program make, and the best thing is that any changes that the program did will be undone when it exists, so it can't harm your system. :)
3. Also, you could try to decompile JAR file:
http://www.google.hr/search?sourceid=chrome&ie=UTF-8&q=java+decompiler
Yes and No. By default java programs can do the same things any native program on your system can do. This includes deleting and replacing any file it can access, depending on your operating system and your user privileges this may affect system critical files.
It is possible to restrict what java applications can do, applets and webstart programs usually are secured this way. Alternatively you can run any program as a different/restricted user or in a sandbox to limit the damage it can do.
If you do not trust the library/program always run it in one of the restricted environments mentioned above. It may crash if it does something it should not do, but it will be unable to do any damage.
I tried the solution from jensign.com and it looks like it restricts almost everything. The .jar application that I used to test wasn't even able to download a website. However I'm not an expert at this stuff so I can't tell if it is a 100% safe solution.
The JAR'd application can be launched under fully restrictive sandbox conditions (very similar to Java applet default security sandboxing):
java -jar -Djava.security.manager PropsFrame.jar
cite from jensign.com
Try a decompiler, like Java Decompiler:
http://jd.benow.ca/
It decompiles the .jar file, and shows you the source, though keep in mind it might be copyrighted:
By the way, why don't you ask for them to submit the source code as well, instead of just the .jar files?
Basically, .jar files are like souped-up zip files, and I believe even WinRAR can open .jar files. A quote from their site:
Java Archive File (a compressed file
for applets and related files) (.JAR)
Short for Java Archive, a file format
used to bundle all components required
by a Java applet. JAR files simplify
the downloading of applets since all
the components (.class files, images,
sounds, etc.) can be packaged into a
single file. Additionally, JAR
supports data compression, which
further decreases download times.
JAR file support is the same as ZIP
file support. JAR = ZIP + manifest.
The Microsoft VM supports uncompressed
and compressed JAR levels 0 and 1, but
not signed JAR.
WinRAR provides basic operations for
JAR files created by other tools: view
contents, extract files, show comments
and archive information.
You can use the convert function to
convert .jar files into .rar format.
You do not need to have any external
programs to handle these formats.
After extracting with WinRAR, you can view the source by following this link as an alternate method to JD.