Am using this link as a reference so that I can be able run a GAE project locally. Am using the Google Plugin for eclipse.
When I click the button Run, i get WARNINGS in the console.
objc[1622]: Class JavaLaunchHelper is implemented in both
/Library/Java/JavaVirtualMachines/jdk1.7.0_60.jdk/Contents/Home/bin/java
and
/Library/Java/JavaVirtualMachines/jdk1.7.0_60.jdk/Contents/Home/jre/lib/libinstrument.dylib.
One of the two will be used. Which one is undefined.
-server must be followed by an argument for servletContainerLauncher[:args] Google Web Toolkit 2.6.0 DevMode
[-[no]startServer] [-port port-number | "auto"] [-whitelist
whitelist-string] [-blacklist blacklist-string] [-logdir directory]
[-logLevel level] [-gen dir] [-bindAddress host-name-or-address]
[-codeServerPort port-number | "auto"] [-server
servletContainerLauncher[:args]] [-startupUrl url] [-war dir] [-deploy
dir] [-extra dir] [-workDir dir] [-sourceLevel [auto, 1.6, 1.7]]
module[s]
and
where -[no]startServer Starts a servlet container serving the
directory specified by the -war flag. (defaults to ON) -port
Specifies the TCP port for the embedded web server (defaults to 8888)
-whitelist Allows the user to browse URLs that match the specified regexes (comma or space separated) -blacklist
Prevents the user browsing URLs that match the specified regexes
(comma or space separated) -logdir Logs to a file in the
given directory, as well as graphically -logLevel The level
of logging detail: ERROR, WARN, INFO, TRACE, DEBUG, SPAM, or ALL
-gen Debugging: causes normally-transient generated types to be saved in the specified directory -bindAddress Specifies
the bind address for the code server and web server (defaults to
127.0.0.1) -codeServerPort Specifies the TCP port for the code server (defaults to 9997) -server Specify a different
embedded web server to run (must implement ServletContainerLauncher)
-startupUrl Automatically launches the specified URL -war The directory into which deployable output files will be written
(defaults to 'war') -deploy The directory into which
deployable but not servable output files will be written (defaults to
'WEB-INF/deploy' under the -war directory/jar, and may be the same as
the -extra directory/jar) -extra The directory into which
extra files, not intended for deployment, will be written -workDir
The compiler's working directory for internal use (must be writeable;
defaults to a system temp dir) -sourceLevel Specifies Java
source level (defaults to auto:1.7) and module[s] Specifies
the name(s) of the module(s) to host
Without much clarity from you about your set up I can see that you need to clean up your Java installation.
It is complaining about finding a choice between two possibly different, but probably identical, classes called "JavaLaunchHelper".
You have one here :
{JAVAHOME}/Contents/Home/bin/java
You have another one here :
{JAVAHOME}/Contents/Home/jre/lib/libinstrument.dylib.
I believe it is also hinting that you fix it in the command line you use to launch Eclipse.
-server must be followed by an argument for servletContainerLauncher[:args]
If I were you I would try renaming the first of the two options temporarily, from ...
{JAVAHOME}/Contents/Home/bin/java
... TO ...
{JAVAHOME}/Contents/Home/binTEMP/java
Suck it and see, as they say in England. That might get you going, while borking up a whole bunch of other things.
Really, you need to read up on JAVA_HOME, JAVA_PATH and JavaLaunchHelper and how they must be prepared for your operating system. Having JRE and JDK both in your path can lead to all kinds of confusing behaviour.
Related
I'm trying to connect to my HDFS instance running on Cloudera. My first step was enabling Kerberos and creating Keytabs (as shown here).
In the next step i would like to authenticate with a keytab.
Configuration conf = new Configuration();
conf.set("fs.defaultFS", "hdfs://cloudera:8020");
conf.set("hadoop.security.authentication", "kerberos");
UserGroupInformation.setConfiguration(conf);
UserGroupInformation.loginUserFromKeytab("hdfs#CLOUDERA", "/etc/hadoop/conf/hdfs.keytab");
FileSystem fs = FileSystem.get(conf);
FileStatus[] fsStatus = fs.listStatus(new Path("/"));
for (int i = 0; i < fsStatus.length; i++) {
System.out.println(fsStatus[i].getPath().toString());
}
It fails with the following error
java.io.IOException: Login failure for hdfs#CLOUDERA from keytab
/etc/hadoop/conf/hdfs.keytab:
javax.security.auth.login.LoginException: Unable to obtain password
from user
The question is: how do I correctly handle the keytab? Do i have to copy it to my local machine?
When running a Hadoop client on Windows to reach a kerberized cluster, you need a specific "native library" (i.e. DLL).
As far as I can tell there is no good reason for that, because that lib is not actually used outside of some automated regression tests (!?!) so it's a pain inflicted to Hadoop users by Hadoop committers.
To add extra pain, there is no official build of that DLL (and of the Windows "stub" that enable its use from Java). You must either (a) build it yourself from source code -- good luck -- or (b) search the internet for a downloadable Hadoop-for-Windows runtime, and pray that is does not contain any malware.
The best option (for 64-bit Windows) is here: https://github.com/steveloughran/winutils
...and the ReadMe explains why you can reasonably trust that run-time. But if you are stuck with an older 32-bit Windows, then you are on your own.
Now let's assume you deployed that run-time on your Windows box under
C:\Some Dir\hadoop\bin\(the final bin is required; the embedded space is just extra fun)
You must point the Hadoop client to that run-time with a couple of Java properties:
"-Dhadoop.home.dir=C:/Some Dir/hadoop" "-Djava.library.path=C:/Some Dir/hadoop/bin"
(note the double quotes around Windows args as a whole, to protect embedded spaces in the paths, which have been translated to Java style for extra fun)(in Eclipse, just stuff these props under "VM Arguments", quotes included)
Now, there's the Kerberos config. If your KDC is your corporate Active Directory server, then Java should find the config parameters automatically. But if your KDC is a standalone "MIT Kerberos" install on Linux, then you have to find a valid /etc/krb5.conf file on the cluster, copy it on your Windows box, and have Java use it with an additional property...
"-Djava.security.krb5.conf=C:/Some Other Dir/krb5.conf"
Then let's assume you have created your keytab file on a Linux box, using ktutil (or an Active Directory admin created it for you with some AD command) and you dropped the file under C:\Some Other Dir\foo.keytab
Before anything else, if the keytab is for a real Windows account -- i.e. your own account -- or a Prod service account, then make sure that keytab is secure!! Use the Windows Security dialog box to restrict access to your account only (and maybe System, for backups). Because that file could enable anyone, on any machine, to authenticate on the cluster (and any Kerberos-enabled system, including Windows).
Now you can try to authenticate using
UserGroupInformation.loginUserFromKeytab("foo#BAR.ORG", "C:/Some Other Dir/foo.keytab");
If it does not work, enable the Kerberos debug traces with both an environment variable
set HADOOP_JAAS_DEBUG=true
...and a Java property
-Dsun.security.krb5.debug=true
(in Eclipse, set these in "Environment" and "VM Arguments" respectively)
Do you have set proper permissions?
chown hdfs:hadoop /etc/hadoop/conf/hdfs.keytab
chmod 440 /etc/hadoop/conf/hdfs.keytab
We are using WLS server instance running as windows service (Setting Up a WebLogic Server Instance as a Windows Service) and we facing some class collision, therefore we set up -verbose:class parameter to see CL resource details.
But after server restart it doesn't wrote the JRE process output to file specified in System property parameter:
-Dweblogic.Stdout="d:\Oracle\Middleware\user_projects\domains\myWLSdomain\
stdout.txt"
I searched for any verbose output as e.g.:
[Loaded java.lang.Object from C:\Java\jdk1.7.0_75\jre\lib\rt.jar]
but I didn't find any. Therefore I checked windows registry key generated by WL_HOME\server\bin\wlsvc script, if contains all our specified parameters and also searched if is possible to specify verbose output by any next JRE parameter, but without result.
After some searching in registry I found that WLSVC generated system service parameters keys at following location:
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\{service_name}\Parameters]
..
"Log"=
..
one of parameters is Log sub-key, when I set it properly, JRE process started to use specified location for logging all details.
I have downloaded commom-daemon tool and used with a java application. I have created a bat file as shown below
set SERVICE_NAME=sample
set PR_INSTALL=D:\commons-daemon-1.0.15-bin-windows-signed\prunsrv.exe
REM Service log configuration
set PR_LOGPREFIX=%SERVICE_NAME%
set PR_LOGPATH=D:\logs
set PR_STDOUTPUT=D:\logs\stdout.txt
set PR_STDERROR=D:\logs\stderr.txt
set PR_LOGLEVEL=Error
REM Path to java installation
set PR_JVM=C:\Java\jre7\bin\client\jvm.dll
set PR_CLASSPATH=D:\commons-daemon-1.0.15-bin-windows-signed\Daemon.jar
REM Startup configuration
set PR_STARTUP=auto
set PR_STARTMODE=jvm
set PR_STARTCLASS=com.SomeService
set PR_STARTMETHOD=start
REM Shutdown configuration
set PR_STOPMODE=jvm
set PR_STOPCLASS=com.SomeService
set PR_STOPMETHOD=stop
REM JVM configuration
set PR_JVMMS=256
set PR_JVMMX=1024
set PR_JVMSS=4000
set PR_JVMOPTIONS=-Duser.language=DE;-Duser.region=de
In cmd , I install the service using the command
prunsrv.exe //IS//sample
After this, a service named sample become available in the list of services and when I tried to start it it shows:
Windows could not start the sample on Local Computer. For more information review the System event log. If this is a non-Microsoft service, contact the service vendor and refer to the server specific
error code 1
UPDATED
When I run
prunsrv.exe //ES//sample
it shows
The data area passed to a system call is too small.
Failed to start service
Can any one help me in this?
I had the same problem. In my case (not yours exactly), the problem was the jvm.dll path, because the variable %JAVA_HOME% has spaces. So to solve this, I modify the assignment
set CG_PATH_TO_JVM=%JAVA_HOME%\jre\bin\server\jvm.dll
to
set CG_PATH_TO_JVM="%JAVA_HOME%\jre\bin\server\jvm.dll"
and that's all.
Also, you could check the variables assignment with this command:
prunmgr//ES//yourservicename_as_in_windows
To help others troubleshooting.
If you look at:
https://commons.apache.org/proper/commons-daemon/procrun.html
There is a parameter:
--LogPath
which defaults to:
%SystemRoot%\System32\LogFiles\Apache
A log file is generated there which contains some additional error messages and possibly useful information.
The original questioner changed the log path to:
set PR_LOGPATH=D:\logs
So looking there would be the appropriate thing to do in their case.
I also had this cryptic error message 'The data area passed to a system call is too small.' with no further information in either the startup log or the Windows/System32/LogFiles/Apache/ logs on Win 8/Server 2008.
I had renamed my packages and the --StartClass and --StopClass parameters were wrong.
I agreed with OscarSan that a space in %JAVA_HOME% could cause the "error code 1" problem. I solve this problem by re-installing JDK 1.8 to change the installation path from C:\Program Files Java\jdk1.8.0_144 to C:\Java\jdk1.8.0_144. Problem solved.
I have been trying to use a home grown test tool and after doing an update to Centos 6.4, I am no longer able to run the tcl based tool. I am getting the following error and I have no internet access on this server. Kindly advise how do I solve this problem?
Thanks
"XpUtils::iload -d /usr/local/testtool/repo/package/linux-glibc2.3-x86_64/lib/tcljava1.4.1 tclblend" failed:
couldn't load file "/usr/local/testtool/repo/package/linux-glibc2.3-x86_64/lib/tcljava1.4.1/libtclblend.so": libjava.so: cannot open shared object file: No such file or directory
while executing
"error "\"XpUtils::iload -d $dir tclblend\" failed:\n $errMsg""
(procedure "loadtclblend" line 168)
invoked from within
"loadtclblend /usr/local/testtool/repo/package/linux-glibc2.3-x86_64/lib/tcljava1.4.1"
("package ifneeded java 1.4.1" script)
invoked from within
"package require java"
("eval" body line 1)
invoked from within
"eval package require $pkg"
("foreach" body line 2)
invoked from within
"foreach pkg $pkgList {
set ::${pkg}Version [eval package require $pkg]
}"
(file "/usr/local/testtool/testtool" line 165)
If you read the error message trace, you'll see that it says that this is all caused by:
libjava.so: cannot open shared object file: No such file or directory
The first steps would then be to ensure that you've got a version of Java actually installed, to check that it includes the file libjava.so, and that the file has been indexed by the system shared library catalog.
It might also be worth checking that all its dependencies are also present and that you've got the architecture for the Tcl library and the Java library matched (e.g., both 32-bit) as those can cause odd failures when they go wrong.
I'm using java system logging in tomcat 7, but no logging statements get written to the log. I've added this file to my WEB-INF/classes. The log file "new-xyz-test" gets created (so I have at least some of the config right) but its empty - no log statements get printed to it.
handlers=java.util.logging.ConsoleHandler, org.apache.juli.FileHandler
org.apache.juli.FileHandler.level=ALL
org.apache.juli.FileHandler.directory=${catalina.base}/logs
org.apache.juli.FileHandler.prefix=new-xyz-test-
java.util.logging.ConsoleHandler.level=ALL
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
com.xyz.level=ALL
com.xyz.handlers=org.apache.juli.FileHandler
To configure JULI in the web applications you need have a logging.properties file in the WEB-INF/classes directory. If you use the default handlers, you may lose messages. You need to specify a prefix for the handler in your file.
handlers=1FILE.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
.handlers=java.util.logging.ConsoleHandler
1FILE.org.apache.juli.FileHandler.level=FINEST
1FILE.org.apache.juli.FileHandler.directory=/app-logs
1FILE.org.apache.juli.FileHandler.prefix=file-1
java.util.logging.ConsoleHandler.level=FINE
java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter
com.xyz.level=INFO
com.xyz.handlers=1FILE.org.apache.juli.FileHandler
com.abc.level=INFO
com.abc.handlers=java.util.logging.ConsoleHandler
A
handler prefix (e.g. 1FILE.) starts with a number, then has an arbitrary string, and ends with a period (.).
See more in Logging in Tomcat
Arguments in the JVM
If you are not running the Tomcat from the startup.sh or startup.bat, you need to specify:
The location of the general logging.properties for Tomcat (in the conf directory of Tomcat)
The manager org.apache.juli.ClassLoaderLogManager. This is important because allows you to configure
for each web application different loggin options. By default, a JVM process can only have a single configuration file.) ,
Similar to the next (I'm using eclipse):
-Djava.util.logging.config.file="C:\Users\Paul\workspaces\utils\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\conf\logging.properties" -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
By default, java.util.logging read the file that is included in the JDK or JRE, e.g.:
"C:\Software\jdk1.7.0_17\jre\lib\logging.properties"
Setting Tomcat Heap Size (JVM Heap) in Eclipse, for how to add arguments in the VM
are you sure that you write to the correct logger , i.e. Logger.getLogger("com.xyz")?
I think that you may got wrong when you wrote in logging.properties:com.xyz.level=ALL com.xyz.handlers=org.apache.juli.FileHandler in the case that you actually write to the logger Logger.getLogger(com.xyz.YourClass.class), that because in the logging properties file you should write the logger name which is in your case com.xyz.YourClass