Recently one of our Tomcat servers started having trouble deploying WAR files. We have an existing version of the WAR in the webapps directory as well as the unpacked version. When we drop a new version of the WAR file into the webapps directory, it does not unpack the new WAR and the application dies. If I delete the old unpacked version, sometimes it will then unpack the new one. Other times I have to restart Tomcat to get it to restart.
In the catalina log I find the following error:
WARNING: Error during context [/pos] destroy
java.lang.StackOverflowError
at sun.nio.cs.UTF_8$Encoder.encodeLoop(UTF_8.java:575)
at java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:544)
at java.lang.StringCoding$CharsetSE.encode(StringCoding.java:342)
at java.lang.StringCoding.encode(StringCoding.java:378)
at java.lang.String.getBytes(String.java:812)
at java.io.UnixFileSystem.getBooleanAttributes0(Native Method)
at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:228)
at java.io.File.isDirectory(File.java:723)
at org.apache.catalina.startup.ExpandWar.delete(ExpandWar.java:360)
at org.apache.catalina.startup.ExpandWar.delete(ExpandWar.java:361)
at org.apache.catalina.startup.ExpandWar.delete(ExpandWar.java:361)
at org.apache.catalina.startup.ExpandWar.delete(ExpandWar.java:361)
at org.apache.catalina.startup.ExpandWar.delete(ExpandWar.java:361)
at org.apache.catalina.startup.ExpandWar.delete(ExpandWar.java:361)
at org.apache.catalina.startup.ExpandWar.delete(ExpandWar.java:361)
That last line is repeated a few hundred times.
Then there are other errors. I'm happy to paste them in, but I suspect the first error is the most likely culprit.
Any clues what this means?
Once I delete the old unpack and restart if necessary, everything seems fine.
We're running Tomcat 5.5.23 on Red Hat Linux 2.6.18.
This is a bug in Tomcat 5.5.23
https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=620996
upgrade or downgrade.
Bye
Related
I followed this tutorial but at the end I got an 404 Not Found.
http://localhost:8080/TomEE_war_exploded/
The requested resource [/TomEE_war_exploded/] is not available
In Intellij I don't see a mistake. The Apache Tomee runs under windows in ~/software/apache-tomee-plume-8.0.11 and the code in ~/playground/TomEE
Unfortuately I'm not able to understand how the war file will be copied to the ~/software/apache-tomee-plume-8.0.11/webapps directory or where the configuration error exists.
From the log file I'm not really sure that the deployment happend correct:
30-May-2022 16:49:53.486 WARNING [http-nio-8080-exec-4] org.apache.batchee.container.services.ServicesManager.init You didn't specify org.apache.batchee.jmx.application and JMX is already registered, skipping
30-May-2022 16:49:53.486 INFO [http-nio-8080-exec-4] org.apache.openejb.assembler.classic.Assembler.createApplication Deployed Application(path=/home/maggus/playground/TomEE/target/TomEE-1.0-SNAPSHOT)
30-May-2022 16:49:53.664 INFO [http-nio-8080-exec-4] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
[2022-05-30 04:49:53,804] Artifact TomEE:war exploded: Artifact is deployed successfully
[2022-05-30 04:49:53,804] Artifact TomEE:war exploded: Deploy took 823 milliseconds
Does anybody see the mistake?
Thanks,
Markus
I ran into somewhat similar problem today and after sometime I was able to figure it out that it does not deploy at the following Application Context that is configured under Deployment tab in Run/Debug Configurations.
/TomEE_war_exploded
If you try to access http://localhost:8080/TomEE_war_exploded/, it gives 404.
Instead, (in my case) it is accessible at http://localhost:8080/TomEE-1.0-SNAPSHOT/
Where 1.0-SNAPSHOT is the version number defined in pom.xml.
Now in order to find the exact path where it is deployed, you need to go to Tomcat Web Application Manager at the following address:
http://localhost:8080/manager/html
Replace 8080 with the port number on which TomEE is running on your machine.
Default user & password is tomee.
Look under Path and you'll find it. Just click on it, it will be accessible.
I hope it helps.
EDIT: The Workaround
In order to define your own path, you need to update the path in the Artifact Output Directory. See the attached photo.
I am trying to get TeamCity up and running for a CI / CD server. So far I have it connected to my Git repo, it pulls the repo and builds. Great.
Now I am trying to publish it. (My web server is also the CI server and agent).
I keep getting this error:
C:\TeamCity\buildAgent\work\f56e1490ff15a5c4\P4P.Web\P4P.Web.csproj(1373, 5): warning MSB3026: Could not copy "\pagefile.sys" to "C:\inetpub\wwwroot\P4P\build\pagefile.sys". Beginning retry 8 in 1000ms. The process cannot access the file '\pagefile.sys' because it is being used by another process.
It ultimately fails and fails the entire publish process.
C:\TeamCity\buildAgent\work\f56e1490ff15a5c4\P4P.Web\P4P.Web.csproj(1373, 5): error MSB3027: Could not copy "\pagefile.sys" to "C:\inetpub\wwwroot\P4P\build\pagefile.sys". Exceeded retry count of 10. Failed.
C:\TeamCity\buildAgent\work\f56e1490ff15a5c4\P4P.Web\P4P.Web.csproj(1373, 5): error MSB3021: Unable to copy file "\pagefile.sys" to "C:\inetpub\wwwroot\P4P\build\pagefile.sys". The process cannot access the file '\pagefile.sys' because it is being used by another process.
I found this ow SO. I tried downgrading the Microsoft.CodeDom.Providers.DotNetCompilerPlatform and Microsoft.Net.Compilers packages to 1.0.0. I have even tried removing them entirely.
I have looked at all csproj files for references to these packages (including the package.config). Nothing.
I have no idea where to even begin to fix this.
My server is running Windows Server 2012 R2. I installed VS professional.
Any ideas?
I encountered the same issue.
The problem starts when you upgrade the DotNetCompilerPlatform to version 1.0.1.
To work around this issue you can downgrade to version 1.0.0 using the NuGet package manager.
EDIT: If you uninstall Microsoft.CodeDom.Providers.DotNetCompilerPlatform AND Microsoft.Net.Compilers, and then install the DotNetCompilerPlatform (has a dependency on the Microsoft.Net.Compilers package so it will automatically install that) package again the error disappears for good so it seems.
Also check this issue link - error MSB3027: Could not copy "C:\pagefile.sys" to "bin\roslyn\pagefile.sys". Exceeded retry count of 10. Failed
I tried to follow the war generation instructions by changing the warName in build.gradle to moqui-plus-runtime.war and running gradle addRuntime and then gradle deployTomcat. There were no errors in the war build and I checked to see that the war file got installed as ROOT. I did not make any other changes (still using MoquiDevConf and I already had other system parameters in MoquiInit.properties.)
When I startup tomcat8, I don't see any errors in the log file and it says that it is loading moqui-plus-runtime, but when I make any request in the browser, the localhost_access... log shows 404 for any request.
Can you tell me what things I might of missed or how I would go about debugging this - there is very little info in the log files other than the 404 messages.
I followed the following steps to deploy to a Tomcat instance on the same machine. This is from memory as my production machine is currently offline for the next couple of weeks.
Edit tomcatHome to point to correct location
I personally run a gradle cleanAll first to remove old WARs etc
Run gradle build
Optionally run gradle loadProduction to load the production database, alternatively you can run java -Dmoqui.conf=conf/MoquiProductionConf.xml -jar moqui-1.5.3.war -load -types=seed,seed-initial so that you can pick which data types you want to load into production etc.
Stop Tomcat from running, probably optional but the next step deletes files & folders from a deployed tomcat instance.
Run gradle addRuntimeTomcat this task adds your runtime and also copies over the completed WAR into the Tomcat webapps directory if you set the location correctly in step 1.
Start Tomcat
Check Tomcat logs for any startup errors
Hope this helps
When I deploy moqui in tomcat6 by dropping in a war file, I get:
java.io.FileNotFoundException: /log/moqui.log (Permission denied)
Same with error.log.
I start tomcat with: sudo /etc/init.d/tomcat6 start
Is that where the log files should go in the production mode, and, if so, why is it getting this error? Or is there a change that I need make in configuration?
The app still runs.
These errors were caused by a bug in the code because the moqui.runtime system env var had not been set when the Logger was initialized. That is fixed in the master branch in commit #a6cc299.
Hello worklight team and devs!
We are done working on our development project and everything works fine in the local dev server (Tomcat).
Now we are trying to build the project to be deployed to a testing WAS ND 8.0.3 server.
We've been following the manual in the infocenter and modified each required file as needed (worklight.properties and application-descriptor.xml)
We made this changes to the worklight.properties file:
publicWorkLightHostname=working.hostname.com
# http or https
publicWorkLightProtocol=http
# For default port leave empty
publicWorkLightPort=ourport
publicWorkLightContext=/worklight
wl.db.jndi.name=jdbc/WorklightDS
wl.db.type=DB2
wl.db.url=jdbc:db2:Worklight
wl.db.username=wluser
wl.db.password=passwd
We tested the jdbc source in the WAS console and it works perfectly.
We proceed to build the war, adapter and wlapp (ALL) and we get this error:
[2013-05-21 12:48:44] FWLSE4001W: Failed to resolve JNDI name: "jdbc/WorklightDS".
Application may fail to access the database in runtime. If building for remote server - ignore this warning.
[2013-05-21 12:48:44] FWLST0011E: ====== Worklight Project BPMWorklight-project-customization failed to start: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial
[2013-05-21 12:48:44] Activation failed. Bundle didn't start:C:pathto\BPMWorklight-customization.jar
This happens in the developer workstation and if we install Studio in the server, where the jdbc source is created, the same happens.
I guess that Worklight is trying to "obtain" a JDBC source in TOMCAT not WAS, but we are building for WAS, so the build fails and NO files are changed after the error. NO BUILD is executed.
We also tried to execute the build.xml with ANT in studio but we get this error:
Buildfile: C:\Users\Primary User\IBM\Worklight\LIS_SampleCollection\BPMWorklight\build.xml
BUILD FAILED
C:\Pathtofile\BPMWorklight\build.xml:3: Cannot find ../../common.xml imported from
C:\Pathtofile\BPMWorklight\build.xml
Total time: 62 milliseconds
You're help is greatly appreciated!
Thanks a lot!!
Best,
Nicolas E.
If all you require is to deploy the updated-for-WAS .war file in WebSphere, you don't need to do any build operation in Worklight. After updating any file under the server\ folder in Worklight Studio (the Eclipse plug-in), the .war file is automatically being re-created.
The build operation is mainly for creating the binaries and deploying to Worklight Server (database) (again, when using the Eclipse plug-in).
So what I suggest is to:
First update application-descriptor.xml with your context root value in worklightServerRootURL, and keep your .wlapps on the side
Update worklight.properties and save them.
Now you have your app ready to deploy and the .war file ready to deploy.
Move to WAS, deploy the .war file
Hopefully things will work now, so you can load Worklight Console and deploy the .wlapp and .adapter files.
I don't know what you've read in the IBM Information Center, but you can also try going over the following training module from IBM Worklight Getting Started.
Moving from development environment to stand-alone QA and production servers
Notes:
The above is not so convenient, but it is A way to move from your
development environment to another staging environment, or
application server...
The issue might also happen even after following my steps above, and this will indicate that the real issue is in your DB2 declaration in worklight.properties.
I will update this answer tomorrow with some insight regarding the possible DB2 declaration issue.