Is there a way to access config defined error level of the application ?
Something like forge.logging.level should be really fine to programatically handle some situations, like debugs (ie, loading the Catalyst lib / enabling debug, etc without having to manually change files but relying on the real error level)
You should be able to see forge.config.modules.logging.level.
Related
I am new to coding. I am trying to create a project in october cms.
My question is regarding the error handling. The errors seem to be too informative, and telling about the file name.
For example
error example
I just want to show the error and not the file. How can this be achieved. So users won't be able to see the file names.
In order to achieve this you need to set debug inside config/app.php to false. This will render a generic page when either a 404 or 500 is hit.
These templates can then be overridden by creating a /500 (server error) and /404 (page not found) in the CMS.
From the docs:
Debug mode
The debug setting is found in the config/app.php configuration file with the debug parameter and is enabled by default.
When enabled, this setting will show detailed error messages when they occur along with other debugging features. While useful during development, debug mode should always be disabled when used in a live production site. This prevents potentially sensitive information from being displayed to the end-user.
The debug mode uses the following features when enabled:
Detailed error pages are displayed.
Failed user authentication provides a specific reason.
Combined assets are not minified by default.
Safe mode is disabled by default.
Important: Always set the app.debug setting to false for production environments.
Source: https://octobercms.com/docs/setup/configuration#debug-mode
I am backing a web app with a Flask API that returns custom error codes. The API runs through Apache and the WSGI module, in daemon mode.
I included a WSGIErrorOverride Off instruction in the Apache conf file for the API (which is supposed to be the default but I included it anyway).
Yet anytime my Flask app returns a custom error code (they work when I run the app using the built-in server), Apache sends an error 500. How can I prevent that?
Thanks to comments by duskwuff and Graham Dumpleton, I found that the problem doesn't come from Apache WSGI but from my Flask app.
More precisely, I was using the Flask-RESTful package, which is in charge, among other things, of transforming my views' return values into actual responses.
When those views are decorated (here with an equivalent of #login_required), those decorators are called by the Flask-RESTful package itself, and when an exception is thrown, something goes wrong.
For some reason, my app returns the custom error when I run the built-in server and an error 500 when I run it over Apache. Not quite sure why yet, I'm guessing Flask-RESTful is doing something that is not WSGI-compliant. I was on the verge of dropping it anyway for other reasons, so I'm OK with this solution.
Update: it looks like the problem does indeed come from Flask-RESTful: https://github.com/flask-restful/flask-restful/issues/372
We are running a Domino 8.5.3 and the server log is constantly issuing these errors:
HTTP JVM:
!err.PersistenceServiceResourceProvider.Errorwritingtopersistedcontenttor!
We have not been able to isloate it to a particular page. Eventually, the HTTP task will crash and we need to reboot the server and recompile all the databases on the server. We are using the CKEditor to generate the HTML content. You help would be most appreciated.
We used to get this exact error a lot which appeared to be caused by inline images uploaded via the CKEditor like Paul mentioned.
I don't know why but we fixed it by changing the directory domino uses for uploads via the
xsp property xsp.persistence.dir.xspupload (formally xsp.upload.directory)
changing it to something like c:\temp rather than the windows default made the problem go away. could have been a co-incidence but may have been something in windows interfering
I haven't seen that error before but it reads like it might be something to do with asking the server to make a lot of data available to the xpages between calls to the server- effectively, session and application scope data.
When running a web deploy to a specific IIS site I get the following error:
Error: The synchronization is being stopped because the maximum number of sync passes '5' has been exceeded even though all the changes could not be applied. This could occur if there are external changes being made to the destination.
At C:\Code\.....\deploy.ps1:185 char:10
+ & <<<< ($appDeployCmd) $type /M:$url /U:$user /P:$pass /A:Basic -allowUntrusted -useCheckSum
+ CategoryInfo : NotSpecified: (Error: The sync...he destination.:String) [], RemoteException
+ FullyQualifiedErrorId : NativeCommandError
Web Deploy is working fine on this environment against other IIS sites and file syncs are also working. I have previously been able to use web deploy to deploy this specific site without issue. All of the sudden out of nowhere, this issue started happening and I can no longer deploy this site.
I'm doing a basic site deploy with a package built from msbuild. I don't think the specifics are that important because as I said this was all working before and currently works against other sites on the same server farm without issues.
The error message says:
"This could occur if there are external changes being made to the destination."
but I'm not sure how to track this down or if it is even the issue to begin with. I've made sure all explorer windows are closed in all remote sessions. I've tried restarting the site and the app pool. The only thing I have not tried is rebooting the server which is not possible at moment.
Any ideas what might be cause this web deploy to fail?
I had the same error and the problem was my dropbox.
I was working directly in my dropbox folder, and when you publish, it causes dropbox to syncronize at the same time, which caused the error.
Disabling dropbox sync while working solved the problem.
I recon the problem also could happen with onedrive, google drive and so on.
We had this problem when converting from a previously adhoc deploy of a service to MSDeploy, and found that if there were files that were either
marked as read-only via the DOS/Windows read-only file attribute.
inaccessible due to ACLs
then we would get the "maximum number of sync passes" error on deploying.
Once we fixed the attributes/ACLs, we were able to sync.
Quick and easy way to resolve this issue is to delete the files in the destination and re-run the web deploy.
The issue seems to revolve around the ACL step of the web deploy, which attempts to change the permissions of your websites files as a safety measure intended to ensure they are not changed during a deployment.
By default Web Deploy sets the ACL of the sites anonymous user to read only while also overwriting Control Panel access to your website.
Source
You can turn of ACL in future to avoid this if you wish, but it's not really worth it. This will also speed up web deploys - but that is a separate issue.
Not really an answer, but one workaround you can try if you are using the Web Deploy dirPath, filePath, or contentPath providers is the ignoreErrors provider setting. If you know that you are consistently hitting a certain error number, you can specify that that error be ignored when it's hit. See the dirPath provider article for full details (and caveats).
In my case I couldn't fix it but realised the deployment worked regardless.
If you are reading this I wouldn't suggest to just assume it worked, and if it did that it deployed fully, but consider that it may be a false alarm!
I have a webapp that I'm trying to use Mondrian within. And I'm getting the following exception when I try to open a connection:
Caused by: mondrian.olap.MondrianException: Mondrian Error:Internal error: Virtual file is not readable: /WEB-INF/olap/mycube.xml
I have tested this cube using a plain J2SE program from the command line, and it works fine. However, when I tried to execute the same cube in my web application I get the error above. My connect string is the following:
jdbc:mondrian:Jdbc=jdbc:mysql://${server.db.host}/HRWarehouse?user=${server.db.username}&password=${server.db.password};Catalog=/WEB-INF/olap/mycube.xml;
This is very similar to what I've found in the Mondrian web application. However, somehow that application has installed the ServletContext in the VFS, but there is exactly zero documentation out there that I can find through google about any sort of special configuration for mondrian in a web application.
I have worked around the issue by setting the path to the schema to be absolute reference instead of relative to webapp context. While this has allowed me to continue testing it is not a suitable solution to the problem. I'm looking for a answer on how to that fix the exception that allows a webapp context relative URL.
I think you need to specify the work file in the Catalog,
`jdbc:mondrian:Jdbc=jdbc:mysql://${server.db.host}/HRWarehouse?user=${server.db.username}&password=${server.db.password};Catalog=file:/path/to/schema.xml;`
I cant recall if it was absolute path or not, try both again.
I would also double check the connection string just to make sure it's written properly. Also, here is a link that might end up helpful if you don't have it already.
Update
Try to add jndi:/ at the beggining of your path:
jndi:/localhost/path/to/file.xml