i am trying run the websphere liberty profile server from the command line. I am following the steps told here : https://developer.ibm.com/wasdev/downloads/liberty-profile-using-non-eclipse-environments/
I have created the server with the name server1.
But when the extraction completes and I try to start the server using the command : server start server1
the server throws an error : CWWKE0054E: Unable to open file C:\wlp\wlp\usr\servers\server1\logs\C:\Users\Furquan\AppData\Local\Temp\\ihp_custom_batches.log.. Now I know this cant be a valid path, but I dont know where and how to change it. Please help !!
This error is related to the LOG_FILE environment variable that you have defined in your environment by some other program. To solve that, you have the following opions:
Remove LOG_FILE env variable, if it is no longer needed by your system
If you cant do that, override it via server.env file, that you can create in the wlp\usr\servers\serverName directory with the following content:
LOG_FILE=console.log
As last resort (this is not recommended, will make your installation NOT SUPPORTED and in certain installations might get overwritten by updates) - modify the server.bat command line script - in the script find the following section:
if not defined LOG_FILE (
set X_LOG_FILE=console.log
) else (
set X_LOG_FILE=!LOG_FILE!
)
And after the line set X_LOG_FILE=!LOG_FILE! just add another line that will override it with the default like this set X_LOG_FILE=console.log
In general, I'd recommend second solution (with the server.env file), as it is the most portable and will work in any environment.
I have the similar problem for IBM Support Assistant V5. After I deleted %LOG_FILE% from Environment Variables, it worked.
Related
I am using JDK 11.0.6 version and hybris 1905, I am able to build setup successfully but when I start server I am getting below error
FATAL | wrapper | The argument
'1905\hybris\bin\platform\tomcat/conf/wrapper.conf' is not a valid
property name-value pair.
What is the reason for this?
In the path, there must be a folder specified with space in the name like: "hybris 1905" so try removing this space. rename it to something like: "hybris_1905" then run ant clean all command and then start the server.
When developers received above error message, they should check complete path. Even folder name should not have any space, else you will get this error message.
For example,
C:\projects\abc xyz\hybris\ will give this error.(Wrong approach)
C:\projects\abcxyz\hybris\ will resolve the issue.(Correct approach)
Note: While working on Hybris project, we should not give any space for folder/directive name and we should avoid giving long folder/directive name.
I tried running the example command on Mac from the command line, but it fails to run. I'm wondering what file is not found. My desktop directory does, in fact, exist. Am I missing some configuration or something?
I just downloaded all the dcm4che-5.12.0 code and sample scripts and executed the command from the example when using the --help option.
The example command is what I tried, and is shown in the attached screenshot. I'm not sure what is missing, and it's not exactly clear.
Any guidance will be appreciated, thanks!
According to the documentation, you have to provide a file and not a directory name to the --dicomdir option (with two "-" by the way):
--dicomdir <file> specify path to a DICOMDIR file of
a DICOM File-set into which
received objects are stored and
from which requested objects are
retrieved
Actually, the example from the documentation reads as follows:
Example: dcmqrscp -b DCMQRSCP:11112 --dicomdir /media/cdrom/DICOMDIR
=> Starts server listening on port 11112, accepting association requests
with DCMQRSCP as called AE title.
On a particular server (Windows 2012 server R2) I am having trouble creating a temp file. I get the following error everytime I try.
java.io.IOException: The system cannot find the path specified
at java.io.WinNTFileSystem.createFileExclusively(Native Method)
at java.io.File.createTempFile(Unknown Source)
etc..
The error happens everytime the following code is ran:
InputStream inputStream = portalBean.createPDF( sessionID, foCode );
Things I have tried
Changed the java.io.tmpdir variable on the fly. System.setProperty("java.io.tmpdir", "C:\\");
Added -Djava.io.tmpdir=c:\\temp to the webnetwork lax file to an unrestricted location.
I tried setting the webNetwork service to run as a specified user with rights to temp files e.g. the Administrator.
Made sure I have free disk space and I cleaned out the c:\windows\temp folder.
Made sure the tmp environment variables were set to their default values.
I also tried running the service from a command prompt which was opened with the Run As Administrator option.
And the IOException lingers still. I have another server running the same code without issue (Windows Server 2012).
Does anyone else have any Ideas of what else I can try to resolve this issue? And or any tips on how I can debug the issue more thoroughly to get a grasp of what is going on?
One tool you can use to debug this is process monitor from system internal tool kit. The step is: add a filter to only monitor your process (I think it is javaw.exe in your case), after the error happens, go through the file activities in the process monitor log, you can find how the process is finding files and which directories the process searched. If the process is searching in the wrong directory, you can find it from the log.
I just used this tool to figure out a JVM crash problem today.
Based on the description of your problem, I guess the path variable of the process is changed in the middle of your code, with another tool process explore you can view the path variable of the process, it might help.
Try and create instead a directory somewhere under your home directory:
final Path tmpdir = Paths.get(System.getProperty("user.home"), "tmp");
Files.createDirectories(tmpdir);
System.setProperty("java.io.tmpdir", tmpdir.toAbsolutePath().toString());
Then try and Files.createTempFile() in there.
Note that if Files.createDirectories() refers to an existing file which is not a directory, you'll get a FileAlreadyExistsException.
When I run "ant debug" from the command line, I get the following error message:
[apkbuilder] keytool error: java.io.FileNotFoundException: \stulab2\folderRedir
ection$.android\debug.keystore (The system cannot find the path specified)
BUILD FAILED
e:\programs\java\android-sdk\tools\ant\build.xml:919: The following error occurred while executing this line:
e:\programs\java\android-sdk\tools\ant\build.xml:930: The following error occurred while executing this line:
e:\programs\java\android-sdk\tools\ant\build.xml:295: com.android.sdklib.build.ApkCreationException: Unable to get debug signature key
at com.android.sdklib.build.ApkBuilder.getDebugKey(ApkBuilder.java:277)
A very long stack trace follows.
The problem is that I am on a public computer and do not have write access to the folder where Ant expects to find .android\debug.keystore. Some research found the following in the Android documentation:
If necessary, you can change the location/name of the debug keystore/key or supply a custom debug keystore/key to use. However, any custom debug keystore/key must use the same keystore/key names and passwords as the default debug key (as described above). (To do so in Eclipse/ADT, go to Windows > Preferences > Android > Build.)
Unfortunately, this doesn't explain how to change the locationof the debug keystore using the command-line tools.
Several months ago, someone asked basically the same question here on stackoverflow: How can I specify location of debug keystore for Android ant debug builds?. The best answer so far is to rewrite the -do-debug target. From what I can tell, I would also need to set the properties specified.
One problem with this answer is that it uses the same properites as the release build does. Also, it would be nice to simply set the correct properties rather than rewriting (and debugging) the whole -do-debug target. Does anyone know if there are properties that can be set to specify the location of the debug.keystore file?
In .bashrc, set the ANDROID_SDK_HOME environment variable to the location of your Android SDK installation. For example:
export ANDROID_SDK_HOME="/home/myusername/path/to/androidsdk"
Then, in a new shell, running ant debug creates a ${ANDROID_SDK_HOME}/.android/debug.keystore file.
Alternatively, without changing the variable globally, you can simply run:
ANDROID_SDK_HOME="/home/myusername/path/to/androidsdk" ant debug
Please see the passage "RMI Registry Issue" of this article for the background on Java Update 1.6.0_29 first.
If I understand correctly (I'm german), the update introduces a bug in the rmiregistry which fails to work with the file: pattern in the codebase.
I.E. the following won't work any more with 1.6.0_29:
-Djava.rmi.server.codebase="file:myproject/bin/ ..."
We are currently using the feature of having a codebase with file: syntax. Does anyone know a workaround for making this work?
Note: No, we do not want to start a local webserver or ftp server.
Update:
On Naming.bind this exception is thrown:
java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.lang.ClassNotFoundException: access to class loader denied
at sun.rmi.server.UnicastServerRef.oldDispatch(UnicastServerRef.java:400)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:248)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
I had the same problem, and can confirm that downgrading JDK to earlier version solves the problem. I know, it's not a solution you're looking for, but at least it makes it to work.
Take running in windows as an example:
Step 1. In C:\Users\Jimmy.java.policy (create it if not exist), append below content:
grant { permission java.security.AllPermission; };
Of course "C:\Users\Jimmy\" is the user home, please change to your home accordingly.
Adding AllPermission is just for quick resolving your issue. you'd better config a more accurate FilePermission here.
Step 2. Start rmiregistry:
C:\JDK\bin>rmiregistry -J-Djava.rmi.server.codebase=file://C:/workspaces/MyLab/target/classes/
(Please note codebase must ended with "/")
Step 3. Run your server and client program.
References:
http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/codebase.html
http://docs.oracle.com/javase/7/docs/technotes/guides/security/spec/security-spec.doc3.html
http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/enhancements-7.html
It looks like there is no workaround because it is a bug, so wait for the fix
See details at
https://bugzilla.redhat.com/show_bug.cgi?id=751203
Code fix
http://icedtea.classpath.org/hg/icedtea6/rev/67df573b0734
If you do not need dynamic code downloading (in which case you can use ftp codebase) the solution is simply to set CLASSPATH environment variable to the path to your jar file:
Windows:
set CLASSPATH="path_to_jarfile"
Linux (batch):
CLASSPATH="path_to_jarfile"
export CLASSPATH
Best place to do it is in some script that invokes the RMI server.
Setting class path in the command line (-cp option) when starting RMI server does not help because it does not affect rmiregistry classpath!
If you start the rmiregistry in the working directory of your project, it works.
So essentially working directory of your project and current directory for rmiregistry should be same.
I recently encountered this issue as well. I can confirm that when using the file: protocol the rmiregistry must either:
be started in the root of the directory containing the shared classes; or
set the classpath to point to the shared classes or shared class jar; or
use a protocol other than file:// (I set up ngnix and served the jar from that).
Maybe not what you want, but you could resolve this with classpath rather than codebase. The client JVM will work fine if you add the required classes to its classpath. If you are using the file: URL scheme, then the classes must already be available on the localhost.
I had the same problem but I couldn't change the JDK version. Turns out you can solve it by running/starting the rmiregistry from the same directory as your code base, which in my case was target/classes. So cd project/target/classes and then run rmiregistry &