Why are some linux commands not executable in Citrus like PWD - citrus-framework

I am connecting to Linux server using SFTP protocol using citrus FTP component. the following command that was provide in the documentation was executing fine.
<send endpoint="ftpClient">
<message>
<payload>
<ftp:command>
<ftp:signal>MKD</ftp:signal>
<ftp:arguments>test</ftp:arguments>
</ftp:command>
</payload>
</message>
</send>
but when I provide another command like PWD as shown below
<send endpoint="ftpClient">
<message>
<payload>
<ftp:command>
<ftp:signal>PWD</ftp:signal>
<ftp:arguments></ftp:arguments>
</ftp:command>
</payload>
</message>
</send>
I am getting error. but when i execute the above command using SSH protocol the command was executing fine
<send endpoint="sftpClient">
<message>
<payload>
<ftp:command>
<ftp:signal>pwd</ftp:signal>
<ftp:arguments></ftp:arguments>
</ftp:command>
</payload>
</message>
</send>
I am unable to figure out the problem and another thing is how execute two commands in a sequence using citrus ftp component for example ex: I want to move to a particular path and have see the size of files in that path for this we have to use "CD" command first and next we have "ls -l" how can I achive this using citrus.
Here is the stack trace of the error
TEST FAILED ssh_connection_Test <com.consol.citrus.samples.todolist> Nested exception is:
com.consol.citrus.exceptions.CitrusRuntimeException: Failed to read ftp XML object from source
at com.consol.citrus.ftp.message.FtpMarshaller.unmarshal(FtpMarshaller.java:120)
at com.consol.citrus.ftp.message.FtpMessage.getCommand(FtpMessage.java:429)
at com.consol.citrus.ftp.message.FtpMessage.getPayload(FtpMessage.java:384)
at com.consol.citrus.ftp.client.FtpClient.send(FtpClient.java:108)
at com.consol.citrus.actions.SendMessageAction.doExecute(SendMessageAction.java:125)
at com.consol.citrus.actions.AbstractTestAction.execute(AbstractTestAction.java:42)
at com.consol.citrus.TestCase.executeAction(TestCase.java:234)
at com.consol.citrus.TestCase.doExecute(TestCase.java:153)
at com.consol.citrus.actions.AbstractTestAction.execute(AbstractTestAction.java:42)
at com.consol.citrus.Citrus.run(Citrus.java:403)
at com.consol.citrus.testng.AbstractTestNGCitrusTest.invokeTestMethod(AbstractTestNGCitrusTest.java:124)
at com.consol.citrus.testng.AbstractTestNGCitrusTest.run(AbstractTestNGCitrusTest.java:108)
at com.consol.citrus.testng.AbstractTestNGCitrusTest.run(AbstractTestNGCitrusTest.java:70)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.testng.internal.MethodInvocationHelper.invokeHookable(MethodInvocationHelper.java:212)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:707)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
at org.testng.TestRunner.privateRun(TestRunner.java:767)
at org.testng.TestRunner.run(TestRunner.java:617)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
at org.testng.SuiteRunner.run(SuiteRunner.java:240)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
at org.testng.TestNG.run(TestNG.java:1057)
at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:111)
at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:204)
at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:175)
Caused by: org.springframework.oxm.UnmarshallingFailureException: JAXB unmarshalling exception; nested exception is javax.xml.bind.UnmarshalException
- with linked exception:
[org.xml.sax.SAXParseException; lineNumber: 2; columnNumber: 37; cvc-enumeration-valid: Value 'PWD' is not facet-valid with respect to enumeration '[OPEN, ABOR, ACCT, ALLO, APPE, CDUP, CWD, DELE, EPRT, EPSV, FEAT, HELP, LIST, MDTM, MFMT, MKD, MLSD, MLST, MODE, NLST, NOOP, PASS, PASV, PORT, PWD, QUIT, REIN, REST, RETR, RMD, RNFR, RNTO, SITE, SMNT, STAT, STOR, STOU, STRU, SYST, TYPE, USER]'. It must be a value from the enumeration.]
at org.springframework.oxm.jaxb.Jaxb2Marshaller.convertJaxbException(Jaxb2Marshaller.java:909)
at org.springframework.oxm.jaxb.Jaxb2Marshaller.unmarshal(Jaxb2Marshaller.java:782)
at org.springframework.oxm.jaxb.Jaxb2Marshaller.unmarshal(Jaxb2Marshaller.java:751)
at com.consol.citrus.ftp.message.FtpMarshaller.unmarshal(FtpMarshaller.java:95)
... 36 more

The error information you are giving is not related to the PWD signal. It fails because you send the signal ls -ltr which is not a supported signal when using the FTP client.
In case you want to list the files with FTP on the server you need to use the LIST signal.
Please do not mix up SSH and FTP commands and signals. Of course you can also open a SSH session and fire up the list files command with ls. But then you need to use the Citrus SSH client.

Related

When parsing the typeAliases tag with package as a subtag in the mybatis framework, a parsing error occurs. I used jdk9 as a development environment

Environment Configure
jdk9
mybatis v3.5.4
MacOS
Description
When I was studying Mybatis, I encountered confusing questions. The configuration in question is as follows:
<configuration>
<typeAliases>
<package name="com.xxx.entity" />
</typeAliases>
</configuration>
The code to start mybatis is as follows:
// the var of CONFIG_LOCATION is the url for mybatis configure
Reader config = Resources.getResourceAsStream(CONFIG_LOCATION);
SqlSessionFactory sqlSessioinFactory = new SqlSessionFactoryBuilder().build(config);
When parsing the typeAliases tag, if the subtag is package, an exception will be thrown:
Error building SqlSession.
The error may exist in SQL Mapper Configuration
Cause: org.apache.ibatis.builder.BuilderException: Error parsing SQL Mapper Configuration. Cause: java.nio.file.InvalidPathException: Nul character not allowed: com/akamonk/ruixun/entity/Cart.class/����5+ " # $ %
at org.mybatis#3.5.4/org.apache.ibatis.exceptions.ExceptionFactory.wrapException(ExceptionFactory.java:30)
at org.mybatis#3.5.4/org.apache.ibatis.session.SqlSessionFactoryBuilder.build(SqlSessionFactoryBuilder.java:80)
at org.mybatis#3.5.4/org.apache.ibatis.session.SqlSessionFactoryBuilder.build(SqlSessionFactoryBuilder.java:64)
at s2.project/com.akamonk.ruixun.listener.ContextLoader.initContext(ContextLoader.java:39)
at s2.project/com.akamonk.ruixun.listener.ContextLoader.main(ContextLoader.java:59)
Caused by: org.apache.ibatis.builder.BuilderException: Error parsing SQL Mapper Configuration. Cause: java.nio.file.InvalidPathException: Nul character not allowed: com/akamonk/ruixun/entity/Cart.class/����5+ " # $ %
at org.mybatis#3.5.4/org.apache.ibatis.builder.xml.XMLConfigBuilder.parseConfiguration(XMLConfigBuilder.java:121)
at org.mybatis#3.5.4/org.apache.ibatis.builder.xml.XMLConfigBuilder.parse(XMLConfigBuilder.java:98)
at org.mybatis#3.5.4/org.apache.ibatis.session.SqlSessionFactoryBuilder.build(SqlSessionFactoryBuilder.java:78)
... 3 more
Caused by: java.nio.file.InvalidPathException: Nul character not allowed: com/akamonk/ruixun/entity/Cart.class/����5+ " # $ %
at java.base/sun.nio.fs.UnixPath.checkNotNul(UnixPath.java:91)
at java.base/sun.nio.fs.UnixPath.normalizeAndCheck(UnixPath.java:81)
at java.base/sun.nio.fs.UnixPath.<init>(UnixPath.java:69)
at java.base/sun.nio.fs.UnixFileSystem.getPath(UnixFileSystem.java:280)
at java.base/jdk.internal.module.Resources.toSafeFilePath(Resources.java:138)
at java.base/jdk.internal.module.Resources.toFilePath(Resources.java:97)
at java.base/jdk.internal.module.ModuleReferences$ExplodedModuleReader.find(ModuleReferences.java:384)
at java.base/jdk.internal.loader.BuiltinClassLoader$2.run(BuiltinClassLoader.java:408)
at java.base/jdk.internal.loader.BuiltinClassLoader$2.run(BuiltinClassLoader.java:403)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/jdk.internal.loader.BuiltinClassLoader.findMiscResource(BuiltinClassLoader.java:402)
at java.base/jdk.internal.loader.BuiltinClassLoader.findResources(BuiltinClassLoader.java:333)
at java.base/java.lang.ClassLoader.getResources(ClassLoader.java:1457)
at org.mybatis#3.5.4/org.apache.ibatis.io.VFS.getResources(VFS.java:171)
at org.mybatis#3.5.4/org.apache.ibatis.io.DefaultVFS.list(DefaultVFS.java:105)
at org.mybatis#3.5.4/org.apache.ibatis.io.DefaultVFS.list(DefaultVFS.java:153)
at org.mybatis#3.5.4/org.apache.ibatis.io.VFS.list(VFS.java:200)
at org.mybatis#3.5.4/org.apache.ibatis.io.ResolverUtil.find(ResolverUtil.java:220)
at org.mybatis#3.5.4/org.apache.ibatis.type.TypeAliasRegistry.registerAliases(TypeAliasRegistry.java:130)
at org.mybatis#3.5.4/org.apache.ibatis.type.TypeAliasRegistry.registerAliases(TypeAliasRegistry.java:125)
at org.mybatis#3.5.4/org.apache.ibatis.builder.xml.XMLConfigBuilder.typeAliasesElement(XMLConfigBuilder.java:164)
at org.mybatis#3.5.4/org.apache.ibatis.builder.xml.XMLConfigBuilder.parseConfiguration(XMLConfigBuilder.java:109)
... 5 more
At this time, the content of module-info.java is as follows
open module mybatis.test {
requires org.mybatis;
requires java.sql;
}
There is a strange phenomenon, when I remove the module-info.java from the project, mybatis will not have problems when parsing typeAliases.Therefore, my bold guess is caused by JDK9. But I don't know how to solve it and the specific cause of the problem

Adding custom handler to jetty throws ClassNotFoundException

I am trying to inject a custom handler to jetty.
I have written the handler in my application code which is packaged as a war.
package com.foo.bar
import javax.servlet.http.{HttpServletRequest, HttpServletResponse}
import org.eclipse.jetty.server.Request
import org.eclipse.jetty.server.handler.AbstractHandler
// scalastyle:off println
class CustomJettyHandler extends AbstractHandler {
override def handle(target: String, baseRequest: Request,
request: HttpServletRequest, response: HttpServletResponse): Unit = {
println("This is a custom jetty handler")
}
}
// scalastyle:on println
I have then injected this handler in the jetty.xml file:
<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure_9_3.dtd">
<Configure id="Server" class="org.eclipse.jetty.server.Server">
........
........
<Call name="insertHandler">
<Arg>
<New id="CustomJettyHandler" class="com.foo.bar.CustomJettyHandler"/>
</Arg>
</Call>
........
I am now running jetty in standalone mode. Note that I am passing the location where CustomJettyHandler.class resides to jetty-start.jar.
java -server -Dorg.eclipse.jetty.util.log.class=org.eclipse.jetty.util.log.StdErrLog -jar lib/jetty-start.jar OPTIONS=All --lib=lib/* --lib=webapps/root/WEB-INF/classes/com/foo/bar/* etc/jetty.xml etc/jetty-jmx.xml --debug
In my application logs, I can see jetty loading my custom handler to its classpath but then eventually failing because of ClassNotFoundException. Can someone point out where could this be going wrong?
.......
rawlibref = webapps/root/WEB-INF/classes/com/foo/bar/*
expanded = webapps/root/WEB-INF/classes/com/foo/bar/*
getPaths('webapps/root/WEB-INF/classes/com/foo/bar/*')
Using relative path pattern: glob:**/webapps/root/WEB-INF/classes/com/foo/bar/*
Found [webapps/root/WEB-INF/classes/com/foo/bar/CustomJettyHandler.class] /Users/...path_to_application.../webapps/root/WEB-INF/classes/com/foo/bar/CustomJettyHandler.class
Adding classpath component: /Users/...path_to_application.../webapps/root/WEB-INF/classes/com/foo/bar/CustomJettyHandler.class
.......
.......
.......
URLClassLoader.url[33] = file:/Users/...path_to_application.../webapps/root/WEB-INF/classes/com/foo/bar/CustomJettyHandler.class
Loaded 34 URLs into URLClassLoader
class org.eclipse.jetty.xml.XmlConfiguration - 9.4.24.v20191120
Command Line Args: /var/folders/z5/dmt38gq54kxcrrzpgvbl5m_c0000gp/T/start_6046998329479549547.properties /Users/...path_to_application.../etc/jetty.xml /Users/...path_to_application.../etc/jetty-jmx.xml
2020-05-27 14:46:13.676:INFO::main: Logging initialized #477ms to org.eclipse.jetty.util.log.StdErrLog
2020-05-27 14:46:13.934:INFO:oeju.TypeUtil:main: JVM Runtime does not support Modules
2020-05-27 14:46:14.007:WARN:oejx.XmlConfiguration:main: Config error at <Call name="insertHandler"><Arg>| <New id="CustomJettyHandler" class="com.foo.bar.CustomJettyHandler"/>| </Arg></Call> java.lang.ClassNotFoundException: com.foo.bar.CustomJettyHandler in file:///Users/...path_to_application.../etc/jetty.xml
2020-05-27 14:46:14.007:WARN:oejx.XmlConfiguration:main:
java.security.PrivilegedActionException: java.lang.ClassNotFoundException: com.foo.bar.CustomJettyHandler
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1837)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.eclipse.jetty.start.Main.invokeMain(Main.java:218)
at org.eclipse.jetty.start.Main.start(Main.java:491)
at org.eclipse.jetty.start.Main.main(Main.java:77)
Caused by:
java.lang.ClassNotFoundException: com.foo.bar.CustomJettyHandler
at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at org.eclipse.jetty.util.Loader.loadClass(Loader.java:64)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.newObj(XmlConfiguration.java:1028)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.itemValue(XmlConfiguration.java:1638)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.value(XmlConfiguration.java:1539)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.access$500(XmlConfiguration.java:369)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration$AttrOrElementNode.getList(XmlConfiguration.java:1768)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration$AttrOrElementNode.getList(XmlConfiguration.java:1744)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.call(XmlConfiguration.java:919)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:512)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:454)
at org.eclipse.jetty.xml.XmlConfiguration.configure(XmlConfiguration.java:354)
at org.eclipse.jetty.xml.XmlConfiguration.lambda$main$0(XmlConfiguration.java:1874)
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1837)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.eclipse.jetty.start.Main.invokeMain(Main.java:218)
at org.eclipse.jetty.start.Main.start(Main.java:491)
at org.eclipse.jetty.start.Main.main(Main.java:77)
Where did you get this command line from?
java -server \
-Dorg.eclipse.jetty.util.log.class=org.eclipse.jetty.util.log.StdErrLog\
-jar lib/jetty-start.jar\
OPTIONS=All \
--lib=lib/* \
--lib=webapps/root/WEB-INF/classes/com/foo/bar/* \
etc/jetty.xml \
etc/jetty-jmx.xml \
--debug
That's not valid for use with Jetty 9.x's start.jar
Some advice
don't use XML directly on the java command line, that's the responsibility of the start.jar and the jetty-home module system (order is SUPER IMPORTANT).
Your choices of etc/jetty.xml and etc/jetty-jmx.xml is an incomplete list of xmls. (you are missing all dependent XML files)
don't edit the standard Jetty XML files, leave them be, otherwise you'll complicate upgrades later. Use XML to inject your behavior instead (see below for example)
OPTIONS is not supported by Jetty 9.x (that's old school Codehaus / Jetty 6 behavior)
Your usage of --lib= is discouraged, it only supports fully qualified paths to jars or directories with exploded class trees (not relative paths, no globs supported).
-Dorg.eclipse.jetty.util.log.class=org.eclipse.jetty.util.log.StdErrLog is a harsh way of setting up logging. Create a jetty-logging.properties files and make sure it's present on the classpath.
Example contents of jetty-logging.properties
org.eclipse.jetty.util.log.class=org.eclipse.jetty.util.log.StdErrLog
org.eclipse.jetty.LEVEL=INFO
#org.eclipse.jetty.deploy.LEVEL=DEBUG
Do this instead.
Create an injection based XML for your new handler.
my-handler.xml
<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure_9_3.dtd">
<Configure id="Server" class="org.eclipse.jetty.server.Server">
<Call name="insertHandler">
<Arg>
<New id="CustomJettyHandler" class="com.foo.bar.CustomJettyHandler" />
</Arg>
</Call>
</Configure>
Next create your jetty-base directory properly (for jetty's start.jar)
# Create your "jetty-base" directory
$ mkdir /path/to/myjettybase
$ cd /path/to/myjettybase
# Establish the basic files / directories / modules that you want to use
# You can find the configuration in start.ini or start.d/*.ini
$ java -jar /path/to/jetty-home/start.jar --add-to-start=http,jmx,deploy,ext,resources
# Copy your custom handler JAR into place
$ cp /path/to/my-handlers.jar /path/to/myjettybase/lib/ext/
# Copy your custom handler XML into place
$ cp /path/to/my-handler.xml /path/to/myjettybase/etc/
# Ensure that the custom handler XML is loaded into the jetty instance at the right point in the XML load order by declaring it to be used in a custom INI
$ mkdir start.d
$ echo "etc/my-handler.xml" >> start.d/my-handlers.ini
# Copy your jetty-logging.properties into place
$ cp /path/to/my-jetty-logging.properties /path/to/myjettybase/resources/jetty-logging.properties
# verify that your configuration looks sane (including the server classpath)
$ cd /path/to/myjettybase
$ java -jar /path/to/jetty-home/start.jar --list-config
# run your instance
$ cd /path/to/myjettybase
$ java -jar /path/to/jetty-home/start.jar
But that's not all, seeing as you seem to want to use jetty-home from a maven-style project (or project layout), you can do that too!
An example project showing this can be found at ...
https://github.com/jetty-project/servlet-error-page-handling
That maven project is also a valid jetty-base directory suitable for execution by a jetty-home archive somewhere else on your machine.

Running groovy scripts with matlab

I wrote a groovy script that I need to execute on matlab. I added the groovy-all.jar file to matlab's JavaClassPath, and I'm able to run a few commands, such as adding jars to groovy ClassPath by creating a groovy console object.
javaaddpath('C:\Users\rx49\Desktop\DoseWatch\QC_Project\Script_QA_images\groovy-all-2.4.7.jar');
javaaddpath('C:\Program Files\Java\jre1.8.0_91\lib\rt.jar');
console=groovy.ui.Console();
pth='C:\Users\rx49\Desktop\DoseWatch\QC_Project\Script_QA_images\file.groovy';
script = javaObject('java.io.File', pth)
console.loadScriptFile(script);
THe console.loadScriptFile function only take as argument a java.io.File object. So I created one through the matlab javaObject function. When I execute the code below, matlab sends me the following error :
??? Java exception occurred:
java.lang.NullPointerException: Cannot invoke method edt() on null object
at org.codehaus.groovy.runtime.NullObject.invokeMethod(NullObject.java:91)
at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:48)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
at org.codehaus.groovy.runtime.callsite.NullCallSite.call(NullCallSite.java:35)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:57)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
at groovy.ui.Console.loadScriptFile(Console.groovy:649)
Error in ==> run_script at 7
console.loadScriptFile(script);
I have no idea if this will work, I don't have Matlab, or your script, but it feels like you should be able to do:
javaaddpath('C:\Users\rx49\Desktop\DoseWatch\QC_Project\Script_QA_images\groovy-all-2.4.7.jar');
pth='C:\Users\rx49\Desktop\DoseWatch\QC_Project\Script_QA_images\file.groovy';
shell = groovy.lang.GroovyShell();
matrix = shell.run(javaObject('java.io.File', pth));

java classpath wildcard behaviour

I've used the java -classpath wildcard expansion feature previously and successfully. I'm currently experiencing a strange problem with it.
The wildcard is supposed to expand to every jar in the named folder. Here's a quote from Oracle:
Class path entries can contain the basename wildcard character *,
which is considered equivalent to specifying a list of all the files
in the directory with the extension .jar or .JAR. For example, the
class path entry foo/* specifies all JAR files in the directory
named foo. A classpath entry consisting simply of * expands to a
list of all the jar files in the current directory.
This is a link to Oracle doc on Java 6 on the subject of classpath.
The behaviour I am seeing contradicts this. Here are 3 runs. The first explicitly names the jar and so it works. The others use a wildcard and fail. Why? This matters to me because I rely on wildcards (elsewhere) and so an understanding of this unexpected behaviour is important to me.
#!/bin/bash
printf "The EV is...\n"
echo $CLASSPATH
printf "The working directory is...\n"
pwd
printf "Directory listing...\n"
ls
printf "END of directory listing.\n"
printf "Test with named jar.\n"
java -javaagent:../sizeof/sizeof.jar -classpath ./testsizeof.jar info.zqxj.test.Tester
printf "Test with star.\n"
java -javaagent:../sizeof/sizeof.jar -classpath * info.zqxj.test.Tester
printf "Test with dot slash star.\n"
java -javaagent:../sizeof/sizeof.jar -classpath ./* info.zqxj.test.Tester
The output:
The EV is...
The working directory is...
/home/b/Documents/workspace/testsizeof
Directory listing...
bin run.sh src testsizeof.jar
END of directory listing.
Test with named jar.
40
Test with star.
Exception in thread "main" java.lang.NoClassDefFoundError: run/sh
Caused by: java.lang.ClassNotFoundException: run.sh
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
Could not find the main class: run.sh. Program will exit.
Test with dot slash star.
Exception in thread "main" java.lang.NoClassDefFoundError: //run/sh
Caused by: java.lang.ClassNotFoundException: ..run.sh
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
Could not find the main class: ./run.sh. Program will exit.
Solution, double quote the classpath argument. Example: -classpath "*" This is necessary on the command line as well as inside a bash script.
A subsequent addendum:
Furthermore, note that -classpath "~/folder/*" fails but -classpath ~/folder/"*" is good. Quote the wildcard but do not quote the ~. It seems that you need the operating system to interpret ~ but you need to quote the * wildcard because you want to pass it to java for expansion in Java-fashion.
Note also that you should not ask java to expand *.jar because that will have an unintended result. The Java spec says that the correct wildcard is just the * alone.

Deploy to remote server using scp in NANT script

I am trying to copy a file to a remote server using scp task in Nant.Contrib .
I have used the following code to do that:
<target name= "QADeploy"description="gthtyb" >
<loadtasks assembly="C:\nantcontrib-0.85\bin\NAnt.Contrib.Tasks.dll" />
<echo message="htyh"/>
<scp file="D:\SourceTest\redist.txt" server="\\10.4.30.19" user="xxx:uuuu">
</scp>
</target>
But I am getting an error: scp failed to start. The system cannot find the file specified.
The code is as follows:
Then I have downloaded pscp.exe and modified the code as below:
<target name= "QADeploy"
description="gthtyb" >
<loadtasks assembly="C:\nantcontrib-0.85\bin\NAnt.Contrib.Tasks.dll" />
<echo message="htyh"/>
<scp file="D:\SourceTest\redist.txt" server="\\10.4.30.19" user="xxx:uuuu" program="C:\pscp\pscp.exe">
</scp>
Now I am getting the following error:
[scp] ssh_init:host does not exist
External Program Failed:C:\pscp\pscp.exe
can u please help whats the best way to copy a file to a remote server using Nant. I am using this code to deploy files to a remote server.
Thanks
You don't have to put two backslashes behind the IP of your server.
<scp file="D:\SourceTest\redist.txt" server="10.4.30.19" user="xxx:uuuu" program="C:\pscp\pscp.exe">
Also note that without the "path" parameter, the default destination folder is "~".
Update: it is the username that is crashing the pscp.exe program. Remove the ":" from your username or try with a different one.
it seems like there is some weirdness on how pscp parses paths in windows. The following should fix ssh_init:host does not exist problem:
-upload
pscp some.file user#[remote-host-or-ip]:/some/path/
-download
pscp user#[remote-host-or-ip]:/some/path/some.file some.file