Call "Java -Jar Myfile.Jar" with Additional Classpath Option

Using ClassLoader.getSystemResource to get file path in JAVA

Problem you have is that SystemClassLoader used to start the program, so given you are trying to search for a resource in a web container such as tomcat, this will NOT work.

If I were you, I would just use the following,

this.getClass().getResource(“/top.txt”)

add properties to individual and insert them all into my file.owl

You didn't say what the namespace you are using is. So I'm going to assume http://example.org/example#, adjust as necessary.

String NS = "http://example.org/example#";

// create ex:Man class
OntClass man = model.createClass( NS + "Man" );

// create individual ex:jack
Individual jack = model.createIndividual( NS + "jack", man );

// create some properties - probably better to use FOAF here really
DatatypeProperty age = model.createDatatypeProperty( NS + "age" );
DatatypeProperty address = model.createDatatypeProperty( NS + "address" );

jack.addProperty( age, model.createTypedLiteral( 50 ) )
    .addProperty( address, model.createLiteral( "France" ) );

Reading properties from tomcat

There are many different ways but it depends on your needs:

To load a property file from $TOMCAT_HOME/conf directory you will need to access it using a java.io.File object since the class loader (as in this.getClass().getClassLoader().getResourceAsStream(...) is just able to load files (and classes) from your class path (under WEB-INF/classes, WEB-INF/lib or $TOMCAT_HOME/lib).

The easiest example to load a file from the Tomcat's config directory would be:

File configDir = new File(System.getProperty("catalina.base"), "conf");
File configFile = new File(configDir, "myconfig.properties");
InputStream stream = new FileInputStream(configFile);
Properties props = new Properties();
props.load(stream);

Notice that this approach will make your code dependent of Tomcat (the loading mechanism depends on the fact of a Tomcat's system property being available). This is something that I wouldn't recommend at all so if you move your property file to a folder inside your classpath then you should be able to load it the way you tried and your application could be deployed in any container.

And, you could configure your properties as JNDI resources but it would be too much hassle to access them.

Moving file with Java changes directory to .eml

The target in Files.move(source, target, options) is the actual target of the move. With REPLACE_EXISTING your call will remove the existing target (your directory) and then move the source to that name.

A directory will only be removed if it's empty*, otherwise the call with throw a DirectoryNotEmptyException.

If you want to move the file to a file with the same name in the directory, you have to append the filename to the target.

The javadoc for move has an example of using newdir.resolve(...) to do exactly what you want.

Converting your original code to follow that example gives me this:

public void moveFile(String source, String targetDir)
{
    Path dirpath = Paths.get(targetDir);

    if (Files.exists(dirpath)) {

        Path target = dirpath.resolve(targetDir);

        try {
            Files.move(Paths.get(source), dirpath.resolve(target), REPLACE_EXISTING);
        }
        catch (IOException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
    }
    else {
        new File(targetDir).mkdir();
        moveFile(source, targetDir);
    }
}

---

* "empty" includes directories that have only meta-files in them; for example on Mac OS X a directory that contains just the .DS_Store metadata file is considered empty.

From the javadoc: " In some implementations a directory has entries for special files or links that are created when the directory is created. In such implementations a directory is considered empty when only the special entries exist."

Java can't find symbol from .class in the same directory

I got this to roughly work. To do so...

for the file ArrayStringLog.java, I removed the implements StringLogInterface because I simply don't have access to that interface. After doing so, I removed the package ch02.stringLogs;. When I compiled this file with the package... still there, I recieved the error: Exception in thread "main" java.lang.NoClassDefFoundError: ArrayStringLog (wrong name: ch02/stringLogs/ArrayStringLog)

Then in MyStringLog.java, I removed the import ch02.stringLogs.*;. I then saved and compiled the code, and ran the TestDriver, to which I received no compilation errors.

This leads me to believe that your error stems from the package statement in ArrayStringLog.java.

---

To finally get a compilation, I put all four files (ArrayStringLog, MyStringLog, StringLogInterface, TestDriver) into the same directory, removed any package... statements, added back implements StringLogInterface to ArrayStringLog.java, compiled each one, and then ran TestDriver with an added toString method from which the output was:

Log: animals

1. dog
2. cat

Here was the test driver:

public class TestDriver {
    public static void main(String[] args) {
        MyStringLog animals = new MyStringLog("animals");
        animals.insert("dog");
        animals.insert("cat");

        System.out.println(animals.toString());
    }
}

To make clear, ArrayStringLog begins with:

public class ArrayStringLog implements StringLogInterface

ECMA TypeError calling Java class from Worklight adapter

I was close, it wasn't CLASSPATH per se, but rather (apparently) Eclipse project settings.

After a week or more of chasing this off and on, I edited the .project file to include certain buildCommand tags that my project didn't have. Adding the following buildCommands to the section allowed my code to launch Java classes from JavaScript after restarting Eclipse.

<buildSpec>
    <buildCommand>
        <name>org.eclipse.jdt.core.javabuilder</name>
        <arguments>
        </arguments>
    </buildCommand>
    <buildCommand>
        <name>org.eclipse.wst.jsdt.core.javascriptValidator</name>
        <arguments>
        </arguments>
    </buildCommand>
    <buildCommand>
        <name>org.eclipse.wst.common.project.facet.core.builder</name>
        <arguments>
        </arguments>
    </buildCommand>
    <buildCommand>
        <name>com.worklight.studio.plugin.WorklightProjectBuilder</name>
        <arguments>
        </arguments>
    </buildCommand>
    <buildCommand>
        <name>org.eclipse.wst.validation.validationbuilder</name>
        <arguments>
        </arguments>
    </buildCommand>
</buildSpec>

The .project file is located in the root of the Worklight project home (e.g. myproject/.project). I figured this out eventually, by running across a working project that did successfully call Java from JavaScript.

See http://www.ibm.com/developerworks/rational/library/server-side-mobile-application-development-1/

I copied the code verbatim to my project and it had the same behavior as my code. I copied my code to that project and my code worked (!!). I then compared the classpaths, which were somewhat different, but it didn't change the behavior. I inspected the .project file and noticed my file didn't have the buildCommand tags above. Instead my file had a number of externalToolBuilding tags, presumably because one of the guys on my team uses an IDE other than Eclipse and his .project became the one in the project. (I think it's Sublime, if it matters).

I don't quite understand all the details of what each of these tags do or exactly how and why Worklight and Eclipse change their behavior because of it (or why they disappeared in the first place). However, it made my code work. It only cost me a week's worth of work (ack!).

I hope this helps someone else in the future.

---

Related Topics