I'm I using the plugin correctly?
I have a war which deploys fine to tomcat but when I try to deploy it to glassfish it throws the exceptions below. Its probably important to note that I'm running Jenkins on the same glassfish instance as I'm trying to deploy to locally.
I'm using the deploy plugin with the following settings:
war/ear file: **/daf-1.0.0-BUILD-SNAPSHOT.war
context: daf
container: Glassfish 3.x
GlassFish admin port: 4848
GlassFish hostname: 127.0.0.1
I have added a comment to JIRA here: https://issues.jenkins-ci.org/browse/JENKINS-11030?focusedCommentId=179452#comment-179452
[#|2013-05-31T11:46:32.180-0400|WARNING|glassfish3.1.2|hudson.model.AbstractBuild|_ThreadID=105;_ThreadName=Executor #1 for master : executing daf-deploy-master #3;|Publisher hudson.plugins.deploy.DeployPublisher aborted due to exception
org.codehaus.cargo.util.CargoException: Cannot communicate with the server
at org.codehaus.cargo.container.spi.deployer.AbstractJsr88Deployer.redeploy(AbstractJsr88Deployer.java:126)
at hudson.plugins.deploy.CargoContainerAdapter.deploy(CargoContainerAdapter.java:64)
at hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:90)
at hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:77)
at hudson.FilePath.act(FilePath.java:904)
at hudson.FilePath.act(FilePath.java:877)
at hudson.plugins.deploy.CargoContainerAdapter.redeploy(CargoContainerAdapter.java:77)
at hudson.plugins.deploy.DeployPublisher.perform(DeployPublisher.java:47)
at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:802)
at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:774)
at hudson.model.Build$BuildExecution.post2(Build.java:183)
at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:724)
at hudson.model.Run.execute(Run.java:1600)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:237)
Caused by: javax.enterprise.deploy.spi.exceptions.TargetException: Error getting required modules
at org.glassfish.deployapi.SunDeploymentManager.getModules(SunDeploymentManager.java:313)
at org.glassfish.deployapi.SunDeploymentManager.getRunningModules(SunDeploymentManager.java:200)
at org.codehaus.cargo.container.spi.deployer.AbstractJsr88Deployer.findTargetModule(AbstractJsr88Deployer.java:350)
at org.codehaus.cargo.container.spi.deployer.AbstractJsr88Deployer.redeploy(AbstractJsr88Deployer.java:122)
... 16 more
Caused by: java.lang.ClassCastException: org.glassfish.deployapi.TargetImpl cannot be cast to org.glassfish.deployapi.TargetImpl
at org.glassfish.deployapi.SunDeploymentManager.getModules(SunDeploymentManager.java:300)
... 19 more
javax.enterprise.deploy.spi.exceptions.TargetException: Error getting required modules
at org.glassfish.deployapi.SunDeploymentManager.getModules(SunDeploymentManager.java:313)
at org.glassfish.deployapi.SunDeploymentManager.getRunningModules(SunDeploymentManager.java:200)
at org.codehaus.cargo.container.spi.deployer.AbstractJsr88Deployer.findTargetModule(AbstractJsr88Deployer.java:350)
at org.codehaus.cargo.container.spi.deployer.AbstractJsr88Deployer.redeploy(AbstractJsr88Deployer.java:122)
at hudson.plugins.deploy.CargoContainerAdapter.deploy(CargoContainerAdapter.java:64)
at hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:90)
at hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:77)
at hudson.FilePath.act(FilePath.java:904)
at hudson.FilePath.act(FilePath.java:877)
at hudson.plugins.deploy.CargoContainerAdapter.redeploy(CargoContainerAdapter.java:77)
at hudson.plugins.deploy.DeployPublisher.perform(DeployPublisher.java:47)
at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:802)
at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:774)
at hudson.model.Build$BuildExecution.post2(Build.java:183)
at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:724)
at hudson.model.Run.execute(Run.java:1600)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:237)
Caused by: java.lang.ClassCastException: org.glassfish.deployapi.TargetImpl cannot be cast to org.glassfish.deployapi.TargetImpl
at org.glassfish.deployapi.SunDeploymentManager.getModules(SunDeploymentManager.java:300)
... 19 more
Related
I am running my Wordpress site hosted in AWS EC2 [Amazon Linux2 AMI].
I have a pipeline to deploy the latest source from Github.
The codebuild buildspec file is as follow: [Mentioned only related part]
version: 0.2
phases: install:
runtime-versions: php: 7.4
Codebuild project in cloudformation is like this:
Image: 'aws/codebuild/amazonlinux2-x86_64-standard:3.0'
Using above configuration, deployment is going without problem and problem happens when I update like below: [Mentioned only related part]
In cfn template:
Image: 'aws/codebuild/amazonlinux2-x86_64-standard:4.0'
In buildspec: runtime-versions: php: 8.1
Validation script in deployment hooks runs some validation commands to check RDS connection and it fails:
LifecycleEvent - ValidateService Script - deploy_hooks/validate_service.sh [stdout]OK SO FAR
[stderr]mysqlcheck: Got error: 1045: Access denied for user 'root'#'10.37.253.207' (using password: NO) when trying to connect
After deployment, I loginto the ec2 instance and below WP cli command fails as well:
$ wp db check
These above problems does not occur when I roll back to previous state of the PHP version.
In cfn template:
Image: 'aws/codebuild/amazonlinux2-x86_64-standard:3.0'
In buildspec:
runtime-versions: php: 7.4
What might be the problem ?
Reference:
https://docs.aws.amazon.com/codebuild/latest/userguide/build-env-ref-available.html
https://docs.aws.amazon.com/codebuild/latest/userguide/available-runtimes.html#linux-runtimes
** UPDATE:
Codedeploy is failing to deploy DB endpoint , password and other information in wp-config.php file when codedeploy is executed by codepipeline.
If I terminate the ec2 instance, the auto-scaling will launch a new instance for me and deployment is triggered by the codedeploy and the deployment is success. I can access the site.
Does it mean that executing Codedeploy through Codepipeline is the problem?
I don’t know what is going on.
I reinstalled my Computer and updated Meteor. I had some permission problems in a earlier problem I could fix that tho. Meteor is normally running if I don't want to deploy it. Deploying used to work just fine btw.
mup.cmd deploy --settings settings.json
Building App Bundle Locally
Started TaskList: Pushing Meteor App
[82.165.207.55] - Pushing Meteor App Bundle to the Server
[82.165.207.55] - Pushing Meteor App Bundle to the Server: SUCCESS
[82.165.207.55] - Prepare Bundle
[82.165.207.55] - Prepare Bundle: SUCCESS
Started TaskList: Configuring App
[82.165.207.55] - Pushing the Startup Script
[82.165.207.55] - Pushing the Startup Script: SUCCESS
[82.165.207.55] - Sending Environment Variables
[82.165.207.55] - Sending Environment Variables: SUCCESS
Started TaskList: Start Meteor
[82.165.207.55] - Start Meteor
events.js:183
throw er; // Unhandled ‘error’ event
^
Error: read ECONNRESET
at _errnoException (util.js:1022:11)
at TCP.onread (net.js:615:25)
What does that mean? I couldn’t find any solution for my problem online. Do you know what is wrong?
This error can happen if your IP address cannot SSH. Make sure your IP
hasn't changed, or change your rules/IP in the security groups of the
service you are using.
There was another case of this recently here mup setup : Error: Timed out while waiting for handshake
But I don't think he sorted it out. He has also reported it on the mup issues list
You can also enable debugging and set mup to be verbose like this:
DEBUG=mup* mup <command> --verbose
(docs at http://meteor-up.com/docs.html)
I use maven plugin for eclipse and tomcat plugin for maven. When I use it to "clean tomcat7:deploy" my hello.war to the Tomcat 8 server on localhost it works fine. I can go to localhost:8080/hello/hello and see "Hello!" page.
But when I deploy to Ubuntu server 15.10 in my local network and go to 192.168.1.2:8080/hello/hello I get Apache Tomcat 404 error. Though tomcat manager shows that deployment went fine and my app is working.
My thoughts were that something wrong with tomcat server on ubuntu, but when I deploy other apps to the same tomcat server on ubuntu, they work as they should. Then I thought the problem is inside my "hello" app. But if it was so, I wouldn't be able to successfully run it on my localhost tomcat server!
When I read logs on Tomcat on Ubuntu server they say:
06-Mar-2016 10:00:00.369 INFO [http-nio-8080-exec-5] org.apache.catalina.core.ApplicationContext.log Manager: deploy: Deploying web application '/hello'
06-Mar-2016 10:00:00.370 INFO [http-nio-8080-exec-5] org.apache.catalina.core.ApplicationContext.log Manager: Uploading WAR file to /var/lib/tomcat8/webapps/hello.war.tmp
06-Mar-2016 10:00:18.022 INFO [localhost-startStop-3] org.apache.catalina.core.ApplicationContext.log No Spring WebApplicationInitializer types detected on classpath
So it seems like it can't find my Bootstrap.class class that implements Spring WebApplicationInitializer interface. Though when I check folder /var/lib/tomcat8/webapps/hello/WEB-INF/classes it contains all classes it should.
I checked logs on localhost, and they do not complain about this.
So at the end it seems that Tomcat 8 on Ubuntu server can not find mentioned WebApplicationInitializer.
I've read answers to similar questions here on stackoverflow and tried, but most of them are dealing with eclipse server settings, my problem here is different I think.
What to do and where to look?
EDIT:
When I manually deploy hello.war via /manager on localhost, everything is ok. Inside localhost.2016-03-06.log I have:
06-Mar-2016 11:34:33.081 INFO [http-nio-8080-exec-51] org.apache.catalina.core.ApplicationContext.log Spring WebApplicationInitializers detected on classpath: [by.hello.configuration.Bootstrap#19087f1e]
06-Mar-2016 11:34:33.544 INFO [http-nio-8080-exec-51] org.apache.catalina.core.ApplicationContext.log Initializing Spring root WebApplicationContext
06-Mar-2016 11:34:34.026 INFO [http-nio-8080-exec-51] org.apache.catalina.core.ApplicationContext.log Initializing Spring FrameworkServlet 'springDispatcher'
I can go to localhost:8080/hello/hello and see "Hello!" greeting.
When I do the same with Ubuntu server's tomcat /manager inside logs I have:
06-Mar-2016 11:36:06.555 INFO [http-nio-8080-exec-14] org.apache.catalina.core.ApplicationContext.log No Spring WebApplicationInitializer types detected on classpath
06-Mar-2016 11:36:06.559 INFO [http-nio-8080-exec-14] org.apache.catalina.core.ApplicationContext.log HTMLManager: list: Listing contexts for virtual host 'localhost'
I used to compile project using JDK1.8 environment.
Now I recompiled project using JDK1.7, my Ubuntu server's Tomcat8 started to recognize Bootstrap.class which implements WebApplicationInitializer interface.
So, the answer for me was:
Check your tomcat's JVM version at the bottom of Tomcat /manager/html page.
Recompile your project using appropriate JDK version.
When deploy application server WildFly 8.1.0, the following error occurs .
Thu Oct 01 13:31:07 GMT+300 2015
Failed to enable rest-api-0.1-SNAPSHOT.war.
Unexpected HTTP response: 500
Request
{
"address" => [("deployment" => "rest-api-0.1-SNAPSHOT.war")],
"operation" => "deploy"
}
Response
Internal Server Error
{
"outcome" => "failed",
"failure-description" => {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"rest-api-0.1-SNAPSHOT.war\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"rest-api-0.1-SNAPSHOT.war\".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of deployment \"rest-api-0.1-SNAPSHOT.war\"
Caused by: java.lang.RuntimeException: JBAS018757: Error getting reflective information for class org.eclipse.jetty.server.handler.IdleTimeoutHandler$1 with ClassLoader ModuleClassLoader for Module \"deployment.rest-api-0.1-SNAPSHOT.war:main\" from Service Module Loader
Caused by: java.lang.IncompatibleClassChangeError: Implementing class"}},
"rolled-back" => true
}
And only on one machine to the other all right and runs deploying and enable it. What could be the reason of it?
server.log
Looks like the program you are deploying throws an IncompatibleClassChangeError. Causes for that error are discussed here. You should try to follow these steps:
Undeploy the old build
Clean the build
Stop Wildfly
Delete all temporary sources
Start WildFly
Build the application
Deploy the build
Error getting reflective information for class org.eclipse.jetty.server.handler.IdleTimeoutHandler$1 with ClassLoader ModuleClassLoader for Module \"deployment.rest-api-0.1-SNAPSHOT.war
This means, somehow, there is some Jetty class. IT really smells when in a deployment made for WildFly or any JEE compliant server in general, there is a class from package org.eclipse.jetty*.
Please try removing that dependency. I hope you're using JAX-RS for your REST API.
I think you miss here the right Jboss-deplyoment-structure.xml
I'm doing an app with JHipster 1.4.0 using Eclipse.
In dev profile, no problem, but when i switched to prod profile, there's an error in build :
Description : Plugin execution not covered by lifecycle configuration: com.github.trecloux:yeoman-maven-plugin:0.2:build (execution: run-grunt, phase: generate-resources)
Resource : pom.xml
Path : /myapp
Location : line 444
Type : Maven Project Build Lifecycle Mapping Problem
I'm new to Eclipse and i didn't find a solution on forums. If someone can help...
Thanks !
I just had a same issue, and this was because I had another process using the same port number as Grunt (port 9001).
Can you check your Grunt error message? I had:
Running "connect:test" (connect) task
Fatal error: Port 9001 is already in use by another process.