I am using IntelliJ Ideea 13.1.4 and I encountered this error - after I Run / Debug my project, after "Artifact portal-webapp:war exploded: Artifact is deployed successfully"
I get this error but it has been working util now...
Do you Have any idea what should it be?
It appears Idea is trying to wait for your page to return 200 response and then open the external web browser. If this does not happen (e.g. your application returns a redirect due to authentication filters), Idea is just spamming your application with requests and then complains about not being able to open the web page.
I was on production profile but I don't know how I was building until now automatic on dev profile. Now I put a -Pdev to the mvn clean install command I had in a .bat file and all is ok.
Related
We have a situation trying to run jenkins behind apache,
we need to specify a new context path because we already have an instance of jenkins in ./Jenkins, so we try to use the parameter --prefix=/jenkins2/ in order to have the 2 instances separated.
The problem is that with that parameter, when i hit the url http://myserver.com/jenkins2 i have this:
HTTP ERROR 404
Problem accessing /. Reason:
Not Found
Powered by Jetty:// 9.4.z-SNAPSHOT
any help?
In /etc/sysconfig/jenkins or /etc/default/jenkins change the follow line
JENKINS_ARGS=""
to
JENKINS_ARGS="--prefix=/jenkins2"
you can also run in a different por changing JENKINS_PORT in the same file.
Probably yours is not working because the "/" in the end "/jenkins2/"
If you can't find these files, you can check where is viewing the content of /etc/init.d/jenkins, in the line starting with "JENKINS_CONFIG="
If you are not running jenkins as service you can run:
java -jar jenkins.war --prefix=/jenkins2
i've installed jenkins server and run it.
i've installed kenjins control plugin on intellij as described in this lin https://github.com/dboissier/jenkins-control-plugin
try to configure jenkins settings --> test connection gives me [Missing or bad crumb data]
i am using intellij 2016.3 and jenkins server 2.19.4
thanks a lot.
This solution worked for me. Here are the steps:
Generate an API token by going your Jenkins home page > your name in the top right corner click > Configure > "Add new token". Copy this token.
In Intellij Settings > Tools > Jenkins Plugin, fill in server address and username. For password, put in the token copied in step 1 and leave the "crumb data" section empty.
Test connection should succeed now.
CRSF handling has improved these days - you likely don't actually need crumb data, and the error is a misnomer. You may actually need to go to <jenkins-server>/user/<your-user-name>/configure and add an API token. This token is then used as your password in the IDE configuration. See this comment
You may need to get the crumb with the following URL on the browser
http://<jenkins_url>/crumbIssuer/api/json?tree=crumb
And put the crumb value in the Jenkins plugin settings.
You can look at here.
Ran into the same problem. Found the answer (by azharsikander) here: https://github.com/dboissier/jenkins-control-plugin/issues/134.
It's because the current implementation sets .crumb header but Jenkins 2.0 is using Jenkins-Crumb header.
https://github.com/dboissier/jenkins-control-plugin/blob/91ef83f318a7ebe6c50b9395342b24b0f51d542f/src/main/java/org/codinjutsu/tools/jenkins/security/DefaultSecurityClient.java#L45
I have installed MobileFirst 6.3 appcenter console, worklight console successfully, they are operating fine on Tomcat/7.0.57. However when I try to install Operational Analytics, the documentation has the following
http://www-01.ibm.com/support/knowledgecenter/SSHS8R_6.3.0/com.ibm.worklight.installconfig.doc/monitor/c_op_analytics_installation_tomcat.html
I am using tomcat manager http://localhost:8080/html to deploy the war files. logging in as manager, with the manager-gui role.
worklight-analytics.war - deployed with no issues
when I select the worklight-analytics-service.war file and deploy in the GUI, it throws a blank page first, indicating "connection error", and when I refresh the page, on the status bar in Tomcat manager GUI, I get this message - "FAIL - Tried to use command /upload via a GET request but POST is required";
Please provide some direction on what I need to do get this fixed. I am not sure If I have provided all required information - please bear with me and ask, if anything relevant (obviously I can't figure out what is relevant yet) is required to debug.
So I was able to reproduce your error and I saw this in the logs:
java.lang.IllegalStateException:
org.apache.tomcat.util.http.fileupload.FileUploadBase$SizeLimitExceededException:
the request was rejected because its size (57353297) exceeds the
configured maximum (52428800)
It looks like by default, the web UI will only upload WARs of size 50MB or smaller. The analytics service WAR file is larger than this, so that is why this is failing. I was able to increase the limit by modifying the following lines in
/webapps/manager/WEB-INF/web.xml
<max-file-size>100000000</max-file-size>
<max-request-size>100000000</max-request-size>
This will increase the limit to 100MB. After I did this, I was able to successfully deploy the service WAR.
Just as a heads up, once you get the WAR deployed, you'll be presented with the login page. You'll need a tomcat user with the 'worklightadmin' role in order to get past the login screen.
The worklight-analytics-service WAR file does not have a user interface. It is simply referenced by the worklight-analytics WAR file. When both WARs have been deployed, can you see the analytics console? And does data load just fine? If so, then everything is fine. There is only an issue if you are unable to use the user interface provided by the worklight-analytics WAR file.
I have install the Open Daylight Helium according to the document of wiki of installation. But, when I enable the webUI, it always displays "Unable to login" in the webUI.
How can I solve this problem?
This would be easier to answer if you described what you mean by the web UI. Nonetheless vaerify that you are testing the correctports, if you are then you can disable auth by editing org.opendaylight.aaa.authn.cfg
authEnabled=false
Obviously, we need to install feature of odl-dlux-core. And we can login to ODL's Web GUI successfully.
I had the same problem and I got it working by following the answer on this link:
https://ask.opendaylight.org/question/843/unable-to-login-dlux-web-interface-helium-release/
There it says:
Downloading and extracting the pre-build .zip : distribution-karaf-0.2.0-Helium.zip
./distribution-karaf-0.2.0-Helium/bin/karaf (on linux) to start the karaf container
feature:install odl-restconf odl-l2switch-switch odl-mdsal-apidocs odl-dlux-core
Accessing http://localhost:8181/dlux/index.html where localhost is your local ip
log in with user: admin pw: admin
Perhaps there is a problem with the order you have installed your features. I >got the order from dlux-wiki-page where they said that this is the recommended >way of installing features before starting the dlux feature.
To clean your local karaf container you can start the container using the clean >flag like "./distribution-karaf-0.2.0-Helium/bin/karaf clean" or delete the >"distribution-karaf-0.2.0-Helium/data/" folder.
The very first time I'm able to logging in into a web page and after that if I click any link its redirecting to login page.
I see the message in the logs as "Unable to process SMSESSION cookie" and there is no error other than this.
All technologies that I used are tagged for the question.
Could any one help me.
Here is the logic to fix the problem until to get the proper siteminder package:
Due to the siteminder package update, we got into this issue.
The siteminder setup needs to be changed after a MVN build. Hence MVN build will create a conf files every time.
Also every time you do a maven build, the settings go back to the ‘wrong’ one.
So after every maven build, the following steps must be followed:
Brief Steps:
1. In the web server- remove the redirect at the end
2. In the app server - remove the UAA,
3. In the app server - remove the context-param (devSecurityContext.xml part)
4. stop and start both web and app server's .
Detailed Steps:
Go to the config directory of the web instance and remove the line:
Redirect 307 /login.fcc
From this file config/redirects.conf
Go to the web.xml file and remove the UAA filter – i.e. the following lines:
Remove all the filter configurations.
`
In the same file above the UAA modify the context-param – remove the devSecurityContext :
Modify the line:
/WEB-INF/spring-af.xml,/config/spring/context-.xml,classpath:/config/spring/context-.xml,/WEB-INF/devSecurityContext.xml
To
/WEB-INF/spring-af.xml,/config/spring/context-.xml,classpath:/config/spring/context-.xml