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.
Related
I am trying to run the PHP JavaBridge.war file by placing in wepapps folder and Deploying it from the manager tool but returned with the following error:
FAIL - Application at context path [/JavaBridge] could not be started
What could be the reason behind it?
Server: CentsOS 7
Tomcat: 10.0 Version
This is a possible duplicate of Intellij docker with live update of EAR inside websphere, but that question is 3 years old and the answer "not supported" is maybe outdated.
Via IntelliJ IDEA (2020.3 Ultimate) on Windows 10, I want to deploy an application (EAR) into a Websphere Liberty server which is running in a docker container. This worked with traditional websphere, now we are switching to WLP. Is this possible at all?
The server is up and running. I'm perfectly able to copy the ear to the (mounted) "dropins" folder and the server picks it up, expands it and deploys it without problems.
I'm also able to attach the debugger in IntelliJ to the server and it will stop at breakpoints, it can even successfully update code ("hot swap classes").
What I did already:
I configured ports (7777,8880,9043,9443,9080) to forward 1:1 from the container to my local machine. I can successfully access at least port 9080 through a local browser.
I downloaded Websphere Liberty, Full Java EE 8 Profile, the same version as in the docker container, from IBM official website to my local hard drive, and expanded the zip.
Then I tried to follow the guide https://www.jetbrains.com/help/idea/run-debug-configuration-websphere-server.html and added a Run/Debug Configuration "Websphere Remote", I chose the expanded folder for IntelliJ for the "Application Server" configuration (I know that IntelliJ needed a local installation of Websphere for traditional version, so this may hold true for WLP as well).
I added the EAR-artifact for deployment in the Run Configuration. I copied the server name from the one inside docker and set the connection settings (localhost:9080).
The first try ("Test Connection") resulted in an error from IntelliJ: Error running 'WebSphere Application': JMX file not found: C:\[...]\wlp-javaee8-20.0.0.12\usr\servers\defaultServer\workarea\com.ibm.ws.jmx.local.address
Then I tried and copied this file from my docker container, it had the content
service:jmx:rmi://127.0.0.1/stub/[... some seemingly byte64-encoded string] to the local path. This resulted in a different error: Error connecting to the Application Server: java.rmi.ConnectException: Connection refused to host: 127.0.0.1; nested exception is: java.net.ConnectException: Connection refused: connect
I also tried to use the content of the file com.ibm.ws.jmx.rest.address which was service:jmx:rest://localhost:9443/IBMJMXConnectorREST, (where I replaced the internal host name of the docker container by "localhost"), but that resulted in Error running 'WebSphere Application': java.net.MalformedURLException: Unsupported protocol: rest
If I start the local server on my machine (not in docker), connection works and deployment too. But this is not my aim.
PS: My server.xml contains <applicationMonitor updateTrigger="mbean"/>.
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 need help figuring out why a couple of my web applications are intermittently throwing 404 errors when trying to bring up a JSP. One of them has the JSP accessed directly and the other has a servlet that is forwarding to a JSP. The pages work most of the time, but occasionally will throw a 404. If the user refreshes their browser 1-3 times, the page starts working again without any changes required.
Here is a sample of the error as seen in the web browser (Chrome):
type: Status report
message: /app_root/my_page.jsp
description: The requested resource is not available
The problem seems to be related to recompiling the JSP pages. The .war file and expanded directory haven't changed. There are always three errors in the logs that correspond to each 404 error:
WARNING: Failed to delete generated class file [D:\Apache Software Foundation\Tomcat 7.0\work\Catalina\localhost\app_root\org\apache\jsp\my_005fpage_jsp.class]
May 19, 2015 6:32:24 AM org.apache.jasper.compiler.Compiler removeGeneratedFiles
WARNING: Failed to delete generated Java file [D:\Apache Software Foundation\Tomcat 7.0\work\Catalina\localhost\app_root\org\apache\jsp\my_005fpage_jsp.java]
May 19, 2015 6:32:24 AM org.apache.jasper.compiler.Compiler generateJava
WARNING: Failed to delete generated Java file [D:\Apache Software Foundation\Tomcat 7.0\work\Catalina\localhost\app_root\org\apache\jsp\my_005fpage_jsp.java]
I'm running Java 1.7 on Tomcat 7.0.53. Tomcat is running on a Windows 2008 R2 server.
Here is what I've tried so far, based on the information I've found from google. However, the 404's continue.
Disabled Windows indexing on the entire Tomcat directory
Turned off development mode in my production environment
Increased modificationTestInterval in my QA environment from the default (4 seconds) to 3600 (1 hour) [Note: it is currently set to 0 to try to help me reproduce the issue]
Changed the owner on the Tomcat work directory to be the same id as the id that the service is running as.
I am in the process of getting anti-virus turned off on the work directory to see if that helps.
While this issue is occurring on my prod and QA servers, it doesn't occur for me on my local Tomcat instance. In fact, I have yet to see the problem from my workstation even when running the QA and Prod applications. The issue has only been seen by other people.
The Tomcat container caches .java and .class files generated by the JSP parser, which are used by the web application. Sometimes these get corrupted or cannot be found. This may occur after a patch or upgrade that contains modifications to JSPs.
Solution is to just simply delete the work directory and restart the tomcat
I had the same problem after deploying a .war on our live server. These are the steps that I followed to solve the problem:
1) Shut down the tomcat server
2) Go to <your tomcat directory> -> work -> Catalina -> localhost -> <your project> -> org -> apache -> jsp ->
3) Manually delete both .class and .java
4) Delete the .war file and the deployed folder from the website that is having the issue on the webapps folder.
5) Export a new .war, and put it into the webapps folder.
6) Start up the tomcat service again.
Once the server is finished deploying, it will auto re-generate the deleted files in the "work" directory and the website should be available again without the intermittent 404 error.
I hope it works for you too.
Check the authority of this file or folder. Generally this problem is caused by lack of access to folders.
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