I am trying to upgrade 0.14.0 sshd-core and 0.11.0 sshd-sftp to 2.8.0 version.
Unfortunately I found that there are a lot of implementation changes, but I did not find a migration guide before version 2.0.0 (It would be great if someone could provide me with a migration guide from 0.11.0/0.14.0 to 2.0.0)
The main problem I have is the lack of FileSystemView and SshFile since the previous version has file system independence and we use the ability for the root sub-directory of both Windows and Unix to be '/'.
Now, when I try to run sftp server on Windows the Windows file system always redirects me to 'C:\'.
I would be extremely grateful for some ideas on how I can migrate to the new version given the file system problem.
Related
I am dealing with a vulnerable jar(jstl-1.2.jar). My application is very old and runs on IBM websphere 5.1. Since jstl-1.2 does not have any non-vulnerable version available, I want to add this jar in the shared library of the websphere.
My doubt is, if I remove the har from application package and add it to websphere shared library, will the application work?
What a dedication... WAS 5.1 :-) You really need to upgrade to the newer version. This one is unsupported for ages... Try OpenLiberty which is open source version of latest WebSphere Liberty lightweight server.
Also get migration toolkit for binaries that will scan your ear and show you list of required changes.
You can also use WebSphere migration Eclipse plugin that will help you migrate your sources in Eclipse.
This approach is much more beneficial than trying to hack jstl, as you will get to supported version and also get rid of old vulnerabilities.
I have a ubuntu machine and have java-11 installed. My whole project consists of integrating a Hadoop cluster to work with Apache Drill and Apache Superset. I initially got Apache Drill running with Java -11. Then when configuring the Hadoop Cluster the documentation stated that Hadoop only supports java-8. So I downloaded java-8 through Oracle and changed the JAVA_HOME to the Java-8's path.
Then Hadoop worked fine. But then going back to drill it didn't work. I assume it must be due to the two java versions conflicting. I checked out websites like https://novicestuffs.wordpress.com/2017/04/25/how-to-uninstall-java-from-linux/ only to realize that if I follow them I would be completely removing java-8 and java-11 from my machine
Therefore is there a way I can permanently remove java-11 but keep java-8 in my system?
I have been looking all over the Oracle website for the library(jars) for the Oracle WebCenter Content Remote Intradoc Client (12.2.1) and all I can find is the API reference but not the jar files to download. We are upgrading an application that is currently using the 11g version of RIDC but I would prefer to use the newer version rather than the older one. I can find references to a 12.2.1 version in a lot of Oracle documentation but that is it.
Any help is greatly appreciated.
I maintain a Maven repo here. You can download the JAR file directly from there via the Files tab.
You find it on your WCC server, under .../oracle_common/ucm/Distribution/RIDC/
We've updated our buildserver (Atlassian Bamboo) to Java 8 (JDK).
Since then our integrationtests are failing because our started product does not open any port.
We are building with maven and as part of the integrationtest we are starting our builded product. Our product is a Rest-Api based in an OSGI (equinox) and Jetty.
I tried a lot of things, but nothing helped me to get the product start properly in the maven build.
When I log in on my remote machine and start the product manually everything works fine.
Some more information:
Our buildserver runs as a windows service and our product is written in plain Java.
Presumably you are affected by one or more of the issues discussed in Custom AMIs will not start anymore in Bamboo Cloud (BAM-16291), notably that Bamboo is not compatible with JDK8u60 yet:
Joda-time, one of the libraries used by Bamboo is not compatible with
8u60. We've fixed this problem, but the fix has not been rolled out
yet. Known breakages include S3 interaction and CodeDeploy plugin.
Most/All participants got things working again by downgrading to JDK8u45, as also recommended in Atlassian's most recent update:
Use JDK 8u45. The latest JDKs are incompatible with some 3rd party libraries we're using.
Try to match the layout and scripts of our stock images as closely as possible. This will make it easier for us to provide help if
anything goes wrong.
Choose Oracle if you have the choice between Oracle and OpenJDK flavor of JDK.
I've developed a number of servlets (OSGi plugins) running under a patched Domino 8.5.3 server.
I'd like to do some basic encryption/decryption of data and I'd like to avoid the "InvalidKeyException : Illegal Key Size" error which is resolved by upgrading the local_policy.jar & US_export_policy.jar files in notes\jvm\lib\security directory.
I'm not sure if Domino relies on the files that are shipped by IBM in the Domino Installer and if upgrading these files cause an issue.
I can log a support call with IBM if this isn't a common requirement.
Thanks in advance :-)
It's been a long time since I did, and I didn't write it down, but yes upgrading those files will resolve the problem. As I recall, there were updated JARs I got from IBM. There may also be something you need to do with the java.policy file as well.