I have a gradle-managed project which I have been working on for the last few years. The code is published to an artifactory instance, which was migrated, company-wide, to AWS recently.
Ever since then I have been facing the following issue whenever I try to do a gradle sync for the project, rendering development impossible:
javax.net.ssl.SSLPeerUnverifiedException: Certificate for artifactory.domain.us doesn't match any of the subject alternative names: [*.domain.space]
I have tried the following:
Updating the intellij IDE to the latest version
Using local gradle distribution instead of built in wrapper (latest version)
Updating my jdk from 8 to 10 and then going back to 8
Copying the certificate of artifactory.domain.us from the browser to the jre's cacerts keystore using the keytool
Enabling and disabling various JVM and gradle VM related to tls and ssl ignore
Since no other developer in my team is facing this issue, it is probably a bad configuration from my end, but I can't figure out what. Please help!
Related
My question is "How do you get a Java Web Start project started in the IntelliJ IDEA IDE?"
First Attempt
IntelliJ's default JavaFX Project Template includes an artifact configuration that (when the native bundle is set to exe) seems to set you up to deploy your application using Java Webstart (or at least test it on your machine).
Once you Build Artifacts, it gives you a .jnlp file, as well as an HTML file containing a link to run the .jnlp file.
Yet! With even the most basic application, it's not getting off the ground.
In order to provide exact detail, I'll include the code for the HTML and .jnlp files as well as a video that shows what happens.
HTML File
.jnlp File
Video
Progress
Swing on Tomcat
I was able to successfully launch a Swing application from the local Tomcat server I just installed using some help from a tutorial—confusingly, using the similar steps of jarring, signing, and putting on webserver with a JavaFX application results in a stupid blocked window even though the file is included in the Exception Site List.
This makes me wonder if it's a signing issue. (I signed the jar with a homemade keystore, but notably without certificate or timestamp—this caused no problems with Swing; could it be causing problems with JavaFX? If I need a more-legitimate certificate and timestamp, how do I get them?)
Surely I'm missing something. What other steps need to be taken to deploy a JavaFX application using Webstart? Is anyone willing to provide a SSCCE?
I have a unity project and contact an API for collecting data.
In the Editor, Android build, iOS build and Windows build everything is working fine. But the build for OSX gives me errors:
SSL: certificate subject name 'com-linweb061' does not match target host name 'ava-trix.com'
But the common name in my certificate is *.ava-trix.com, as you can see here:
https://www.sslshopper.com/ssl-checker.html?hostname=https://ava-trix.com
I have no idea what the problem is here. Can anyone help me out?
I was using Unity 5.3.5 wich, apparently, has an SSL problem for 32-bit OSX builds. So I created a 64bit version and the problem was gone.
I have been looking for a solution to my SVN problem but have not yet found one. We have been using svn for a number of years without problems but I have been unsuccessful adding a new project as of late.
SVN is installed on a central computer we use as a server running Windows 7. We have TortoiseSVN installed on our clients and on the server. To create new projects in the past we would log onto the server and execute svnadmin create [drive]:/archive/new project. We would then create the trunk, tags, and branches folders using the repo-browser. Once that was done we could use TortoiseSVN to import the code on our local machines to create the archive.
Now when I create a new project archive the client computers return the error: "Could not open the requested SVN filesystem". The repo-browser says the same thing. I can perform all of the usual SVN activities from the client computers on all of the existing repositories, just not on any new ones. Also, if I use the repo-browser on the server it works.
What I have done so far is uninstall subversion and TortoiseSVN from the server and reinstalled TortoiseSVN 1.9.4 along with the command line tools and recreated the svn service. I also updated TortoiseSVN to 1.9.4 so there shouldn't be any version conflicts but it still does not work. Since everything works as long as I am on the server I suspect the problem lies in the network access configuration but I don't know what would be different from when it was working.
Also note that when I try to browse the archive with Firefox I can navigate down into the project trees of the older projects but not any new ones. Firefox displays:
<D:error>
<C:error/><m:human-readable errcode="160043">Could not open the requested SVN filesystem</m:human-readable>
</D:error>
Any help will be greatly appreciated.
PS: Access to the repositories on the server is through Apache 2.2
1. Using file-type access to repository over LAN is always The Bad Idea (tm)
2. Source of your problem (except the above) is changing format of repository-storage between version and inability of old versions read directly repositories of new versions: your client's SVN is older, than server-side (and worse - use|know only old format of repo)
Check version on client's hosts (I suppose, they are pre-1.6) and
update to version, compatible with server's version (1.7+ for 1.9.*)
OR
add any real network layer (svnserve is easy and lightweight choice) for accessing repositories (don't use file:/// anymore) - in this case old clients can communicate with fresh repositories
OR
run svnadmin create with additional option --compatible-version and correct version number as ARG
This is Permissions&Ownership Problem. User, under which Apache is running, now can't read filesystem-tree, created by user, used for remote login. Ask local admin "WTF?" and fix errors
How to overcome SVN — could not open the requested SVN file system
SVN Error: Could not open the requested SVN filesystem
Could not open the requested SVN filesystem on windows7 (start from answer HERE!!!)
As mentioned in the Bluemix guide, I tried installing the Bluemix tool plugin on eclipse(Mars) with Java 7 installed on my Ubuntu machine.
1). Through the eclipse market place where Bluemix tool is present and the same fails with the following error when installation is nearly over:
Cannot complete the install because one or more required items could not be found.
Software currently installed: IBM Bluemix Tools 1.0.5.v20150801_1001
(com.ibm.cftools.feature.feature.group 1.0.5.v20150801_1001)
Missing requirement: Bluemix Tools 1.0.6.v20150801_1001
(com.ibm.cftools.branding 1.0.6.v20150801_1001)
requires 'bundle org.eclipse.jst.server.core 0.0.0' but it could not be found
Cannot satisfy dependency:
From: Cloud Tools Branding UI Plugin 1.0.2.v20150801_1001
(com.ibm.cftools.branding.ui 1.0.2.v20150801_1001)
To: package com.ibm.cftools.branding.internal 0.0.0
Cannot satisfy dependency:
From: IBM Bluemix Tools 1.0.5.v20150801_1001
(com.ibm.cftools.feature.feature.group 1.0.5.v20150801_1001)
To: com.ibm.cftools.branding.ui [1.0.2.v20150801_1001]
I checked this exception and found a description about it in the eclipse web page. However, the remedy is missing for this particular problem.
2). Besides I tried to install the same via WASdev, but I ended up with the following error:
No repository found at http://public.dhe.ibm.com/ibmdl/export/pub/software/websphere/wasdev/updates/cloud/V1.0
However, the same page is accessible from any web browser. Also, I have checked my proxies and they are fine.
Please let me know if there is any solution or what I am doing wrong here. Thanks.
Are you using Eclipse for Java EE Developers edition? It is required that edition to satisfy some bundle requirements.
A few pointers:
An Eclipse update site needs to have a site.xml - check if the location actually has one.
Your install error points to a missing jst component. That's Eclipse "core" stuff. So it seems your access to the original Eclipse update site needs to be checked
Check your Eclipse install, do you have rights to all the files?
Hope this helps
As mentioned, the error message you are receiving (not able to resolve "org.eclipse.jst.server.core") is due to the installation process not being able to locate this package. This package is provided by the same Eclipse marketplace entry or DHE update site from which you are installing (and so you should not see this error when installing from our marketplace or update site). I have confirmed that the provided update site URL is correct and installation works as expected on my own Ubuntu installation.
A few other suggestions, or for users that see the same problem:
This may be a hiccup with DHE or with your connection to the update site. I would suggest trying the installation again.
Try a fresh install of Eclipse to ensure that no other dependencies are interfering with your installation. The Java EE package 'Eclipse IDE for Java EE Developers' available for download from Eclipse.org will include the required package that is mentioned in your error message (though as previously mentioned, this should not be necessary as this package is bundled with our update site/marketplace entry).
Ensure you are NOT using the default version of Eclipse available from the Eclipse Software Center, which is often several versions behind.
If this doesn't help, feel free to provide more information about your current installation (version details, method of installation, any other details) to help us reproduce.
I've just installed Worklight 6.0 on Mac OS X Mountain Lion 10.8.4.
I'm trying to build a very simple HelloWorklight app to test the installed environment and I'm getting errors building and deploying it.
I'm getting these errors in Eclipse console:
[2013-07-13 02:11:21] Starting build process: application
'HelloWorklightApp', all environments
[2013-07-13 02:11:21] Application 'HelloWorklightApp' with
all environments build finished.
[2013-07-13 02:11:21] Deploying application
'HelloWorklightApp' with all environments to Worklight Server...
[2013-07-13 02:11:21] Failed to deploy the application to
Worklight server: Worklight module
HelloWorklightProject was not
successfully started. Full details of the error are available from the
Worklight Development Server console.
The Worklight Development Server console in my browser shows:
Application Error
SRVE0777E: Exception thrown by application class
'com.worklight.core.auth.impl.AuthenticationFilter.doFilter:110'
javax.servlet.ServletException: Worklight Project not initialized
at com.worklight.core.auth.impl.AuthenticationFilter.doFilter(AuthenticationFilter.java:110)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:194)
at [internal classes]
I'm truly stuck. On the other hand I'm sure it must be something simple to fix it.
Has anyone got an idea how?
I had a similar problem (at least WDS console error looks the same).
A little bit history:
My problems started, when I updated Worklight to version 6 (with version 5 I had no problems). Some compilation erros were fixed by adding Websphere Library to a project. But my custom authentication still wasn't working.
How I fixed it:
open new workspace in Eclipse
import Worklight project
clean project
restart Eclipse
downgrade compiler compliance level (in Eclipse: Window > Preferences > Compiler and set "Compiler compliance level" to lower version)
rebuild project and try to run it
At this point it started to work. I've spend lots of time to find out that compiler stuff, but still I'm not sure which part requires that.
So we had this issue with 2 macs and it took us a solid day and a half to figure it all out.
We went through a lot of reconfiguring, re-downloading eclipse and worklight.
Make sure your config files from the update are correct. (worklight.prop and authConfig)
This is the big one. Install JDK 1.7 and reference the new JRE 7. When we
were running on Oracle JRE 6, we had a ton of errors and even a Java
Heap memory issue.
Once you install it, it may to be tricky to find the actually path to the JRE.
First, go to Eclipse > Pref > Installed JRE's > Add
Then, add a new standard vm. Click Directory on the next pane and browse to the install path of JRE.
We found it in [name of your HD] > Library > Java > JavaVirtualMachines > jdk1.7.0_25.jdk > Contents > Home > jre
It should load everything it needs and you can click the check box of the new JRE. For good measure, I changed the compiler to 1.7 as well.
The jdk folder may have a slightly diff name depending on what update you have. Hopefully this helps.
I got the same error after deploy an new app deployment.
What I've done on Server is:
delete all application
delete all extra configuration between new server instance and my current instance. In my case it was: applicationMonitor and shared librairy
clean
restart
After that I managed to deploy my application normally
window -> show view -> servers -> server configuration -> HTTP EndPoint -> host
By default the host will be *. Try to change the host as your local machine ip address. for example host = . After changing the host, close the server.xml and then try to rebuild the project.