I tried this example of an embedding war into a jetty.
When I debug on eclipse everything its ok and the webservices is deployed fine in port 8080, but when I make a jar with this program and put into a server (I tried into a tomcat 5.5 and into a jetty 7.4.1) when I start the program, when I started the jetty server appears this exception:
7641 [qtp21021313-35] ERROR configuration.EngineConfigurationFactoryServlet - Unable to find config file. Creating new servlet engine config file: /WEB-INF/server-config.wsdd
7641 [qtp21021313-35] WARN configuration.EngineConfigurationFactoryServlet - Unable to load/create servlet engine config file, attempting internal default (from jar).
Only the default webservices methos are deployed (AdminService and Version)
The wsdd its fine. If I deploy this war into a server it works perfectly
You should run the java code without the servlet container (Tomcat/Jetty), you have the jetty server embedded, that's why in eclipse the code works fine.
Jetty's slogan:
"Don't deploy your application in Jetty, deploy Jetty in your application."
You should check this tutorial:
http://wiki.eclipse.org/Jetty/Tutorial/Embedding_Jetty
For more info:
http://wiki.eclipse.org/Jetty/Howto/Deploy_Web_Applications
Related
Environment details:
Payara 5.2022.2
Windows Server 2019 Enterprise LTSC
Apache Netbeans 14
JDK 17
This is the only machine and environment that produces this error when I try to deploy the same program to it:
The module has not been deployed.
See the server log for details.
BUILD FAILED (total time: 4 seconds)
SEVERE: Exception while loading the app
SEVERE: Exception while loading the app : java.lang.Exception: Virtual server __asadmin already has a web module __admingui loaded at / therefore web module OIUSA_1 cannot be loaded at this context path on this virtual server
From other questions I have gathered that something is wrong with the server-config->Virtual Servers config of Payara, so here are two photos showing the only discernable difference between a working install of Payara, and the Windows Server that gives an error:
Working server:
Not working server:
So, the virtual server named server in the WORKING installation of Payara has a context path of / but the non working version doesn't. I'm not sure how to fix this, since I have tried fully uninstalling, rebooting, and re-installing.
I came up with a solution:
In the glassfish-web.xml of the application configuration set the Context Root = /your_project_name
Then, deploy the application like expected and it should come up. Then enter the admin domain console and navigate to configurations->server-config->virtual servers-> then select the virtual server your application is running on and set the Default Web Module to your application. This will give the same result of running the application in the root folder (/). No deleting stuff from configuration files needed.
I have created some example web service methods and trying to publish in my localhost with Tomcat v8.0. I use Eclipse Java EE IDE for Web Developers with Mars version 4.5.0.
I configured the server Tomcat v8.0. I got the configured server in Eclipe's Servers list. I Start the server. But Eclipse prompts saying
Publishing to tomcat v8.0 Server at localhost..." has encountered a problem.
And the error details shows that Multiple context have a path for /HelloWorldServlet and /com.vogeila.jersy.first. These are the servlet projects I created in my workspace.
You can refer this screen shot:
I followed this answer.
"Server Tomcat v7.0 Server at localhost failed to start" without stack trace while it works in terminal
But It didn't work for my case.
Share your ideas.
The prompted message helped me. The Server.xml file under Servers has multiple entries of <Context> tag. I deleted everything by leaving only one entry. It worked for me.
Delete Existing tomcat server...
Then add new server.. its work for me
I created a spring web application in eclipse, with Tomcat as runtime server.
It worked fine,and I could see my app working using:
http://localhost:8080/MyAppName/
But once I did switch location(from workspace metadata to tomcat location ) in the tomcat server properties of eclipse, application is giving HTTP Status 404 when I am trying to access it by :
http://localhost:8080/MyAppName/
I followed this tutorial to create a sample helloworld web application in eclipse:
http://javapapers.com/spring/spring-mvc-hello-world/
Can someone help me know why this is happening?
I am using tomcat 7 + eclipse luna
I installed Jetty and I run it with ./jetty.sh start, and it is running:
a#a:~/java/jetty/bin$ ./jetty.sh start
Starting Jetty: Already Running!
a#a:~/java/jetty/bin$
But when I go to localhost:8080, I see
Error 404 - Not Found. No context on this server matched or handled
this request. Contexts known to this server are:
Powered by Jetty:// Java Web Server
What am I doing wrong?
Jetty is probably running fine - the 404 is coming from the server. You probably don't have a default web page set to respond to a root request (where something like index.html would be).
Take a look at this: Jetty - Default page for root path
* EDIT 2013-12-22T16:25Z *
If you make changes to your application you'll have to release your war file & bounce the Jetty process unless you've got the Jetty deployment set up to automatically refresh the application.
Take a look at this: Auto-Reloading WAR in Jetty standalone
Attempting to set up jenkins and its container deploy plugin.
However, I am receiving the following stacktrace :
ERROR: Publisher hudson.plugins.deploy.DeployPublisher aborted due to exception
org.codehaus.cargo.container.ContainerException: Failed to deploy [/myHome/jenkins/jobs/myAPP/workspace/target/ROOT.war]
at org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.deploy(AbstractTomcatManagerDeployer.java:111)
at org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.redeploy(AbstractTomcatManagerDeployer.java:187)
at hudson.plugins.deploy.CargoContainerAdapter.deploy(CargoContainerAdapter.java:60)
at hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:86)
at hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:73)
at hudson.FilePath.act(FilePath.java:784)
at hudson.FilePath.act(FilePath.java:766)
at hudson.plugins.deploy.CargoContainerAdapter.redeploy(CargoContainerAdapter.java:73)
at hudson.plugins.deploy.DeployPublisher.perform(DeployPublisher.java:45)
at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:700)
at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:675)
at hudson.maven.MavenModuleSetBuild$RunnerImpl.post2(MavenModuleSetBuild.java:998)
at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:622)
at hudson.model.Run.run(Run.java:1429)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
Caused by: org.codehaus.cargo.container.tomcat.internal.TomcatManagerException: FAIL - Failed to deploy application at context path /ROOT
Which isn't really that helpful, I can deploy manually using tomcat manager, and also copying the war file across using command line options works. But i can not get the automated deploy to work.
I am using a tomcat url of http://localhost:8080/ and the deploy fails when their is no app currently deployed.
Any help gratefully received, thanks.
Just a wild guess but the ROOT context is not: /ROOT but rather / maybe there is something wrong in your config
Its a ContainerExc not fileNotFound; therefore the war file has been located.
URL should be http://localhost:8080
Is userName and Password provided?
Is this userName assigned a role of manager-script?
is the tomcat webapp cleared down once for work and temp folder?
If YES to above all, now run the tomcat without any war fiel present in the webapps folder and open a web broswer to see http://localhost:8080 is accessible.
Now whilst this tomcat running, build the jenkins job and deployment should be fine.