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.
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.
After going through Maven commands on my project, importing the WAR file onto the webapps folder on Tomcat, I'm greeted with a FAIL - Application at context path / could not be started. My WAR file is a ROOT.WAR. Is this a problem with Tomcat's XML configuration? Here's my log of errors, I have no clue which is the crucial error to address.
Here's the console log from Eclipse trying to start the Tomcat server.
http://pastebin.com/JMZqWKhF
Did you actually look at the logfile you posted? The first stacktrace in the incomplete logfile contains:
Caused by: java.nio.file.NoSuchFileException: C:\Program%20Files\Apache%20Software%20Foundation\Tomcat%208.0\webapps\ROOT\WEB-INF\classes\GeoLite2-City.mmdb.gz
...
at com.pethers.afriqcart.service.geoip.CityDatabaseLookupService.loadExternalDatabase(CityDatabaseLookupService.java:59)
at com.pethers.afriqcart.service.geoip.CityDatabaseLookupService.<init>(CityDatabaseLookupService.java:40)
I've omitted a few irrelevant lines, maybe this helps identifying this cause?
As there seems to be a lot more missing from the top of the log it might only be a secondary problem - but that'd be your own problem then... Read your logs
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
I have a Glassfish 3.1.2 cluster.
I have 2 ssh nodes that each have 1 instance.
I added my lib jars in the DAS domains/mydomain/config/mycluster-config/lib/ directory.
When I restart my instances, I see that the jars are copied to each node in the:
nodes/node1/instance1/config/mycluster-config/lib/ directory and
nodes/node2/instance2/config/mycluster-config/lib/ directory.
My application is a JSF 2.2 app with Richfaces 4.3
The problem is that when I deploy my application, the application can't find any of the jars from my libs.
One question would be: How do I set the classpath for the nodes?
I have tried:
export LD_LIBRARY_PATH="/path/to/node1/instance1/config/prodc-config/lib"
and the same on command on the other node.
This did not enable my app to find the libs.
If I deploy my EAR to the standalone domain NOT the cluster then it will deploy without any errors.
When I deploy my app from the web admin console I check availability enabled and make sure the target is pointing to mycluster.
These are some of the errors I am getting:
WELD-000119 Not generating any bean definitions from com.my.domain.Validate because of underlying class loading error
Application was not properly initialized at startup, could not find Factory: javax.faces.context.FacesContextFactory. Attempting to find backup.
The cluster is always able to start.
The instances start and stop just fine.
The full message while deploying my EAR is:
Warning Command succeeded with Warning
"domain/applications/application/my_EAR" created successfully.
WARNING: Command _deploy did not complete successfully on server instance instance1: remote failure:
Failed to load the application on instance instance1.
The application will not run properly. Please fix your application and redeploy.
Exception while shutting down application container : java.lang.NullPointerException. Please see server.log for more details.
WARNING: Command _deploy did not complete successfully on server instance instance2: remote failure:
Failed to load the application on instance instance2. The application will not run properly. Please fix your application and redeploy.
Exception while shutting down application container : java.lang.NullPointerException. Please see server.log for more details.
WARNING: Command _deploy did not complete successfully on server instance instance1: remote failure:
Failed to load the application on instance instance1. The .... msg.seeServerLog
Thank you for any help with my problem.
For GlassFish v3.1.2 I have been using this link: http://docs.oracle.com/cd/E18930_01/html/821-2426/gkrdd.html#gksav
When an app is deployed I have to specify the libraries during deployment. The libraries are relative to the applibs directory. So for a cluster the path would be: ../../config/clustername-config/lib/util.jar
My problem must have been that I did not get the path correct when specifying this directory. That is what I get for not looking close enough the path I was using.
So, short answer: use --libraries when deploying app to a cluster and make sure the path is correct.
I have a Maven project which generates a 413.06 KB jar file. I have to deploy it on Apache Archiva based managed repository. I have tried to deploy different versions, and it created required layout and structure, uploaded some files, even it uploaded that jar with 200~ KB. every time the jar file size changes but always it fails to upload 413.06 KB jar file.
Information:-
I am running standalone Archiva
I have given guest account to Global Repository Manager & "Repository Manager - MYREPO"
I have also tried a separate account in Archiva with "Repository Manager - MYREPO" rights and configured it in maven's settings.xml file to set custom timeout.
I am getting following error
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy
(default-deploy) on project SharedshelfRepository: Error deploying artifact: Transfer error:
The server did not respond within the configured timeout. -> [Help 1]
that might be maven-deploy-plugin issue, resources plugin itself needs several dependencies,try manually jar nad p
What version of Maven are you using? You might try 3.0.4 as it has a different HTTP library. I'm also not sure if there's more context for what was happening when it timed out (it seems more request oriented rather than deploy oriented, and deploy does request some metadata).
I can't see that you'd need to alter the timeout, as none of the defaults should apply to such a small file. How long does it take to fail?