We have a strange behaviour calling a java application using an install4j launcher (install4J R5.0.11) on different environments. The launcher uses the scan directory option (for the jar files) to set the CLASSPATH before starting the main class. The CLASSPATH is logged for debugging in our application.
On system 1 the entries of the CLASSPATH are sorted ascending by filename.
On sytem 2 the entries are sorted descending.
This leads to an exception on system 2, because of a wrong order of two jars.
Does the "Scan directory option" take into account system settings (eg. sorting)?
You cannot rely on classpath sorting with the scan directory entries, the behavior is system-specific.
Related
Background:
ProjectA is an Eclipse 4.2.1 java project with numerous junit 4 test classes. Each junit test is run individually at times and therefore has a corresponding run configuration. Each run configuration specifies a configuration folder from ProjectB as a user class path entry.
ProjectA
test
classATest.java (run configuration user class path entry -> ProjectB/config)
classBtest.java (run configuration user class path entry -> ProjectB/config)
...
ProjectB
config *deleted*
ProjectC
config *created*
Question:
If the configuration folder is moved from ProjectB to ProjectC, is there a way to perform a mass update of all the junit run configurations with a new user class path entry.
Constraints:
Maintaining a copy of the configuration folder and contents in ProjectA is not desirable because it is frequently updated. Updating each run configuration by hand is not desirable. Adding the junit test classes to a junit suite and having a single run configuration would possibly work, but in order to run an individual test I would need to run the suite, kill it, and run the individual test from the junit window.
Attempted:
I was unable to find a way to perform this type of update through the eclipse GUI. Maybe manipulating the eclipse files directly would work.
Thanks in advance.
According to this, eclipse stores run configurations in :
<workspace>/.metadata/.plugins/.org.eclipse.debug.core/.launches
So, using a find/replace function in a text editor or linux test manipulation programs it should be trivial to refactor the run configurations with new user class path entries.
Is the Eclipse project Properties > Java Build Path > Libraries tab the analog of the java -classpath definitions? What is the difference between a "build path" and a "classpath"?
The classpath is a Java thing. It's a list of either folders or jar files to consider (in order) when resolving classes to be loaded. It's used by the Java JVM. It can be specified by the CLASSPATH environment variable or java -classpath. It's a list of either Jar files or folders separated by a ":" on Linux/OSX systems or ";" on Windows.
The Eclipse build path is a means to construct this Java classpath from artifacts in the Eclipse environment. The Configure Build Path dialog is used to manipulate a file in your project called .classpath (normally hidden). This dialog allows you to form the Java classpath from Jar files, files you have built, folders, external Jar files and other things. It also controls where the Java Development Tooling (JDT) will locate your compiled files, and other things related to class files. The Eclipse help has pretty good documentation on this.
The classpath is the place in memory where your Class files and other resources (*.properties, *.xml, among many other types of resources) are made available to the programs running within the JVM.
Eclipse's build path is simply a folder where Eclipse will put the result of whatever 'build' process is set up: this process typically includes the compilation of classes, but it could also include other steps, like code generation, depending on plug-ins that might be installed.
Because you might be running your program from within Eclipse, the build path and the Classpath could possibly contain the same resources. However, keep in mind that the 'build path' is a view of your resources from the Operating System file system perspective, the Classpath is a view of your resources from the Java Virtual Machine perspective.
in my Java Eclipse project that contains JUnit tests, I also have a package "resource" that contains all input data used for the tests. But when compiling JUnit tests, the Java compile also data available in resources, so I find the same data in the "bin" folder. Is there a way to avoid this?
thanks.
If you have a particular package within the source path you want to exclude (your resources folder for example), you can right click on the package and select: Build Path > Exclude.
This will tell Eclipse that you don't want to include that package as part of the build.
This is making a couple of assumptions: that you're using Eclipse Helios (because the option might be different in older versions), and that the resources are stored in the same folder as your regular java source files (because if resources is in a folder by itself, you can remove that entire folder from the build by using Build Path > Configure Build Path -> Source tab.
Update:
After the discussion in the comments regarding why you would or would not want to copy resources into the bin directory:
The contents of your bin directory should be ignored and not checked into to a version control system (when using CVS, bin should be an entry in the .cvsignore file)
The resources are only duplicated on your local machine, which is fast and hard discs are big. I'm not sure you should be worrying about this
If you're using Class.getResource to access those resources, they need to be on the classpath somewhere. The bin directory is as good a place as any
So, realistically (barring some unknown, like the files are hundreds of gigabytes or something), I don't think you need to be concerned about excluding these files from the build.
I have DN 2.x on Eclipse RCP (currently Helios).
I'm having trouble Turning the DN LOG on.
I use log4j.properties, where i define all the DataNucleus Categories LOG levels.
It LOGS fine with the "external" enhancer (i just pass the argument on the "VM Arguments" of the RUN configurations -Dlog4j.configuration=file:"...\log4j.properties"), but can't get the log to work on the main app... tried the same approach with no success.
Anyone using DN with eclipse?
I don't use DN. So I can't address your problem, directly. I can say, in general, if you have an application using Log4j, it will search the classpath for files named log4j.properties and log4j.xml. In your case, try moving your log4j.properties file to a place you are 100% certain is in the classpath (like the root folder of all your packages).
From there, if your logging turns on, then you know your properties file isn't in the classpath. However, if your file is definitely in the classpath, then the culprit is likely something else turning off logging application-wide. Do you see logging at all? If not, then this is likely the problem. At that point you need to figure out which Facade you're using: apache commons or SLF4J. Both have the power to replace the logger implementation with NOOP loggers, which ignore all log requests.
With Commons, you have to check the commons-logging.properties file. With SLF4J, you have to check the project dependencies (usually in a lib directory somewhere), insuring that there isn't a NO-OP jar in the list.
When the jars are packaged within EAR/lib, all works fine, but I cannot use this
approach and need to refer to them from the filesystem (maybe using absolute/relative paths)
Also adding the jars to the system classpath (using conf/jboss-service.xml) is not an option.
I have already defined a scoped classloading using loader-repository for the app in jboss-app.xml
Is there a way the scoped classloader for the app can access libraries from outside the EAR structure?
Technically, yes, at least with JBoss 4.2, and with luck it'll work in 5 as well.
This takes advantage of the fact that when JBoss's EARDeployer reads the path of each library in the application.xml file, it resolves the path relative to the base directory of the exploded EAR. If you put in relative paths with the appropriate number of ../ entries, then the path will resolve to anywhere on the filesystem you like, as long as it's navigable as a path relative to where the EAR is deployed (i.e. on windows, it has to be on the same drive).
Be aware, though, this is not standard behaviour, and isn't even guaranteed to work between different versions of JBoss.