Develop Reference

Algorithm constraints check failed on signature algorithm: MD5withRSA

Today I want to use the HttpClient to call Hybris interface in the AEM. But I get the error message "java.security.cert.CertPathValidatorException: Algorithm constraints check failed on signature algorithm: MD5withRSA".
In this line throw a exception "java.security.cert.CertPathValidatorException: Algorithm constraints check failed on signature algorithm: MD5withRSA".
httpClient.executeMethod(request);
I changed the below there properties to empty in the java.security file(C:\Program Files\Java\jdk1.8.0_191\jre\lib\security\java.security), but it doesn't work.
jdk.certpath.disabledAlgorithms
jdk.tls.disabledAlgorithms
jdk.jar.disabledAlgorithms
MY JDK Version : jdk1.8.0_191
Is anyone know how to fix it?
Thanks,
Forrest

Aside: the jdk.jar.disabledAlgorithm property is not relevant to this issue.
Make certain you've actually changed the file as seen by the program.
Modern versions of Windows (IIRC since Vista, maybe Seven) don't like files under \Program Files and \Program Files (x86) being written by anything but an installer program. One thing they do at least sometimes is 'virtualize' such writes, to a different file hidden somewhere under per-user %appdata%. Search and you'll find lots of similar problems and frustrations.
Call Security.getProperty() to check the setting actually seen in your program.
If you can't fix the setting in the standard file, you can override it in another file (put somewhere more convenient) by setting sysprop (not secprop) java.security.properties=filename or by calling Security.setProperty() early in your program (before the JSSE/PKIX classes are loaded). See:
Relaxing SSL algorithm constrains programatically
Java - Lock down TLS version in java.security, but allow per app override via launch config?
Alternatively, JDK doesn't really need to be in \Program Files*. I put it in another top-level directory and don't have these issues.
And of course tell whoever is responsible for the server they are way behind the times :-)

Hi #dave_thompson_085,
Thanks to your replay. I have fixed this issue with the below steps.
I Used command "where java" to check which JDK is I am really using.
I reinstalled that JDK.
I removed MD5 from "jdk.certpath.disabledAlgorithms", removed MD5withRSA from "jdk.tls.disabledAlgorithms"
removed "C:\Program Files (x86)\Common Files\Oracle\Java\javapath;" from path of the System variables
restart the computer, then this issue is fixed.
Thanks,
Forrest

logstash cannot find log4j2.properties file

I have been trying to setup a proof of concept elasticsearch/kibana/logstash environment, but it is not working at the moment.
The LOGSTASH_HOME is:
c:\_work\issues\log4j_socketappender\logstash-5.0.1\
In the console log of logstash I found the following line:
Could not find log4j2 configuration at path /_work/issues/log4j_socketappender/logstash-5.0.1/config/log4j2.properties. Using default config which logs to console
You can see logstash is trying to look for log4j2.properties in the right location but it does not contain the "c:" part
I tried adding the path to the config\jvm.options
-Dlog4j.configurationFile=c:\_work\issues\log4j_socketappender\logstash-5.0.1\log4j2.properties
but it did not work.

Eventually I fixed it by adding the following line into bin\setup.bat
42. SET JAVA_OPTS=%JAVA_OPTS% -Dlog4j.configurationFile=%LS_HOME%\config\log4j2.properties

Two things come to mind:
Try specifying the full path with -Dlog4j.configurationFile=c:\_work\issues\log4j_socketappender\logstash-5.0.1\log4j2.properties
Also, is the properties file using the new Log4j2 properties syntax? An old log4j 1.2-style properties file will not work. (Although I would expect a different error message in that case.)

as you can see here
create an Environment Variable in Windows LS_SETTINGS_DIR and set it to:
/c:/logstash-5.0.1/config
(notice - leading forward slash and all slashes are unix style not Windows style backslashes)
or to invoke logstash with
--path.settings=/c:/logstash-5.0.1/config/
(again note position and direction of slashes)
I hope that this helps someone avoid the Googling and testing I have just done!

Java File does not exists but File.getAbsoluteFile() exists

Does anyone encountered the case when a java.io.File doesn't exist but the calling getAbsoluteFile() method on the file instance returns a file that does exist. And why this happen?
Note
I am on Linux plus Oracle Java runtime with version 1.7.0_95-b00
I've passed in a JVM option -Duser.dir=/path/to/somewhere when
launching the tomcat instance

You should probably not mess around with user.dir. Rather, change to that directory before launching the Tomcat.
File.getAbsoluteFile() is assuming that user.dir is the directory you are really in, but you aren’t.
Based on your observation, I think File.exists() is mapped directly to stat on the operating system level. And File.getAbsoluteFile() is just new File(System.getProperty("user.dir"), getPath()).
Under the assumption that user.dir is the operating system’s current working directory, these two implementations are correct and reasonable. But in your case, they differ, and this (assumed) implementation can explain what you are experiencing.

How to open file with default application in SWT?

I have for example .pdf file (path to that file). How to open this file in default application (probably Acrobat Reader) from SWT application (for example on Button click) ?

You should be able to use:
Program.launch(file);
to open the file (using the default application or creator). From the javadoc:
Launches the operating system executable associated with the file or URL (http:// or https://). If the file is an executable then the executable is launched. Note that a Display must already exist to guarantee that this method returns an appropriate result.
Note that there are some peculiarities in Program.launch() (or at least there were, though these may have been fixed in more recent versions of the runtime.) I don't really remember the specifics of the bugs, but we do some checks to work around some issues:
If you're on a Unix platform, and you're specifying an absolute path, there may be trouble opening that file. We prefix absolute paths with /. - so that /tmp/foo would be translated to /./tmp/foo - although I don't really remember the specifics of this bug any more than that.
On Windows, if you're trying to open a UNC path - for example \\server\bar - you need to wrap the string in double-quotes. For example: Program.open("\"\\server\bar\"");

Try Desktop.open:
Desktop.getDesktop().open(file);

Maybe this can help to find a decision: we ran into PermGen space trouble upon call Desktop.open() - which is in AWTpackage - out of our SWT application.
So I would prefer Program.launch() over Desktop.open() in a SWT-environment.

Where/how does log4j look for a log4j.properties file?

I'm trying out log4j in a simple test app. I create a new Java project in eclipse and add the log4j JAR (v1.2.16) to my build path. I then create a simple class that prints Hello World. Then I use the log4j Logger class to log a info message. When I run the app, I see the log message, using what I assume is the default appender and layout. Great. What I'm having trouble with is adding my own configuration. This is what I've done:
Created a log4j.properties file with a custom appender and log level and placed it into the src folder (which upon compilation gets copied to the bin folder). Run the app - no change.
I try adding PropertyConfigurator.configure("log4j.properties"). Run the app - no change. No errors, but no change.
What do I have to do to get log4j to load my configuration file?

Look in the manual under the heading Default Initialization Procedure, where you'll find the following:
The exact default initialization algorithm is defined as follows:
Setting the log4j.defaultInitOverride system property to any other value than "false" will cause log4j to skip the default
initialization procedure (this procedure).
Set the resource string variable to the value of the log4j.configuration system property. The preferred way to specify
the default initialization file is through the log4j.configuration
system property. In case the system property log4j.configuration is
not defined, then set the string variable resource to its default
value "log4j.properties".
Attempt to convert the resource variable to a URL.
If the resource variable cannot be converted to a URL, for example due to a MalformedURLException, then search for the resource from the
classpath by calling
org.apache.log4j.helpers.Loader.getResource(resource, Logger.class)
which returns a URL. Note that the string "log4j.properties"
constitutes a malformed URL. See
Loader.getResource(java.lang.String)
for the list of searched locations.
If no URL could not be found, abort default initialization. Otherwise, configure log4j from the URL. The
PropertyConfigurator
will be used to parse the URL to configure log4j unless the URL ends
with the ".xml" extension, in which case the
DOMConfigurator
will be used. You can optionaly specify a custom configurator. The
value of the log4j.configuratorClass system property is taken as the
fully qualified class name of your custom configurator. The custom
configurator you specify must implement the Configurator interface.

Argh. I discovered the problem was that eclipse had imported the wrong Logger class. It had imported java.util.logging.Logger which of course has it's own configuration that is different from log4j. Oh well, hope somebody else does this and gets it solved by reading this question.

You can enable log4j internal debugging by setting the log4j.debug system property. Among other things, this will cause log4j to show how it is configuring itself.
You can try explicitly setting the URL to the configuration file with the log4j.configuration system property.
See also: this question.

The problem may be in the classpath, if the classpath was defined.
The reason it wasn't loading (in my case): There was a conflicting log4j.properties file in one of my jars, and it was overloading the one in my classpath.
In short, if your log4j.properties file isn't loading, there might be another one somewhere else overriding it.
Just thought I'd throw this in too, in case anyone else runs into this. I just spent the last 5 hours trying to figure out why my default log4j.properties wouldn't load.

log4j.properties should be in your classpath. The "src folder" which is copied to the "bin folder" (I assume you are speaking of a Eclipse setup here), normally belongs to your classpath, so it should be found (are you placing it at the top of the "src" folder, right?)

I know this is a couple of months old, but I feel the need to point out that the scr folder isn't "copied" to the bin folder, nor is it part of your runtime classpath....(build path is not runtime classpath!). Eclipse compiles the source files in the src folder to the bin (or whatever you like) folder. It's the bin folder that is part of your runtime classpath.
Just wanted to point this out as these threads are often read by very junior programmers as well, and I'm always frustrated that most of them don't grasp the finesse of the Java classpath, and hence make avoidable mistakes against it.

Just throwing it out there to anyone who is struggling to get log4j.properties filed loaded.
I fixed mine by adding the following line:
-Dlog4j.defaultInitOverride=TRUE
Turns out using that JVM parameter, it possible to tell Log4j not to use the Default Initialization Procedure and create your own.
I struggled with mine. I did from clean JAR build to entire REPO pull, nothing work. Combination of that and clean up of class file made it work.