When I try to launch jetty-9.0.3.v20130506 as a user or a service, I get an error as follows:
2013-06-24 00:00:36.927:WARN:oejs.Holder:main:
java.lang.ClassNotFoundException: org.eclipse.jetty.servlets.CrossOriginFilter
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
When I add lib=lib to start.ini, I can run jetty as a user by launching the script. I do not understand how adding this standard location fixes it, but it does.
bin/jetty.sh start
When I try to launch jetty as a service, which uses the same script, it fails with the error given above.
It look like the start script does not use the start.ini when it is launched as a service because it does not process the lib=lib statement that solves the problem.
Can anyone offer a clear explanation as to how I can get jetty to load a CrossOriginFilter using the jars that are in the lib folder.
Alright, this one cause a LOT of pain.
you should not add this to start.ini
lib=lib
you should add this
lib=/<full path to jetty>/lib
When running as a service, the script does not apply the relative path for some reason, like it does with the other arguments in start.ini. Just use the full path.
The only thing I hate about SO is that I usually figure out the problem right after I post.
UPDATE: The solution below, adding servlets to the options, was the way to go. That was easy, but for some reason I did not see that in any other posts about the CrossOriginFilter.
Related
I downloaded the installation pack for TestLink from SourceForge, and I attempted to install it on the server.
When the installation is trying to connect to the database, I get this message:
TestLink setup will now attempt to setup the database:
Creating connection to Database Server:OK!
Connecting to database `testlink`:OK!
==============================================================================
DB Access Error - debug_print_backtrace() OUTPUT START
ATTENTION: Enabling more debug info will produce path disclosure weakness (CWE-200)
Having this additional Information could be useful for reporting
issue to development TEAM.
==============================================================================
#0 database->exec_query() called at [/home/galigeo/testlink/install/installUtils.php:100]
#1 getUserList() called at [/home/galigeo/testlink/install/installUtils.php:267]
#2 create_user_for_db() called at [/home/galigeo/testlink/install/installNewDB.php:420]
Does anybody know how I should proceed from here?
We also tried to download another pack for 1.9.20 from Github, however that one is also stalling.
I got the problem like you and fixed like this:
Access link like https://yourtestlink.com/install
Done anything in these step.
As said in the title, I am attempting to put a CloudWatch Agent (CW agent) on my On-Premise-Server (OPS).
After running this line of code that I got from the AWS User Guide to start the CW agent:
& $Env:ProgramFiles\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1 -m ec2 -a start
I got this error:
****** processing cwagent-otel-collector ******
cwagent-otel-collector will not be started as it has not been configured yet.
****** processing amazon-cloudwatch-agent ******
AmazonCloudWatchAgent has been started
I did/do not know what this was so I searched and found that when someone else had this issue, they did not create a config file.
I did create a config file (named config.json by default) using the configuration wizard and I am still having the issue.
I have tried looking into a number of pages on that user guide, but nothing has resolved the issue.
Thank you in advance for any assistance you can provide.
This message is info and not an error.
CloudWatch agent is bundled with the AWS OpenTelemetry collector agent. They're actually two agents. CloudWatch agent and Otel collector have separate configuration files. If you provide a config for one and not the other, it will only start the one that is configured. This is expected behavior.
Thank you for taking the time to answer. I have since resolved the issue (recently).
Everything from the command I was using to the path where the file resided was incorrect.
Starting over and going through all the steps again with background information helped.
The first installation combined with learning everything for the first time produced the issue.
Anyone having this issue I recommend that when you hit a wall like this you start over. I know it is not what anyone wants to do, but in the end it saved time.
I have stop and restart services(Sharepoint Administration & Sharepoint Timer Service)
I cleaned the Configuration Cache by using mentioned steps.
Summary of the steps to clear the timer job:
Stop SharePoint Timer service on all servers in the farm.
Browse to C:\ProgramData\Microsoft\SharePoint\Config{GUID} where the {GUID} folder contains a bunch of XML files and NOT the files with a “.PERSITEDFILE” extension.
Delete all the XML files
Update the contents of the Cache.ini file to just say “1” (without quotes).
Restart the SharePoint Timer service on each server
Reanalyze the issue in Health Analyzer
Does anyone know why this keeps occurring and how I can stop it?
First of all try and check your ULS Logs and see if there is any error that arise.
Secondly try and maybe check the event viewer on your SharePoint server to see if any errors are shown and make sure you have enough disk space available.
and also you might want to check this :Clearing Timer Services
Let me know if you see any error post it here.
hope it helps.
Yotam.
I am creating a multiple instance setup on my developer edition of ColdFusion. I am running on Maverics. My guide to the process is this article by Rob Brooks-Bilson.
I did everything right. However I get the 'Bad Gateway Error' when I try to ping the ColdFusion Administrator.
I think you might have any of the following issues:
The workermap.properties file for your particular instance (cf10/config/wsconfig/1/) has the instance name spelled wrong.
Recheck the worker.properties file that you have added the content properly. This step is very much prone to copy-paste error. There are two places you need to add your instance name: In the list and then the port configuration (copying from the existing).
There is some glitch in your mod_jk file.
last but not the least please re-check that your server.xml (cf10//runtime/conf/) has been edited properly. Also please check if the value of the port attribute of the SERVER tag and the CONNECTOR tag are different. It happens that due to some glitch they might get generated as the same.
I'm trying to develop a system service, so I use the echo service as a test.
I developed the service by following the directions on the CF doc.
Now the echo node can be running, but the echo gateway failed with the error "echo_gateway - pid=15040 tid=9321 fid=290e ERROR -- Exiting due to NATS error: Could not connect to server on nats://localhost:4222/"
I got into this issue and struck for almost a week finally someone helped me to resolve it. The underlying problemn is something else and since errors are not trapped properly it gives a wrong message. You need to goto github and get the latest code base. The fix for this issue is http://reviews.cloudfoundry.org/#/c/8891 . Once you fix this issue, you will most likely encounter a timeout field issue. the solution for that is to define the timeout field gateway.yml
A few additional properties became required in the echo_gateway.yml.erb file - specifically, the latest were default_plan and timeout, under the service group. The properties have been added to the appropriate file in the vcap-services-sample-release repo.
Looks like the fix for the misleading error has been merged into github. I haven't updated and verified this myself just yet but the gerrit comments indicate the solution is the same as what the node base has had for some time. I did previously run into that error handling and it was far more helpful.