As the title says.
I tried adding com.liferay.portal.servlet.filters.monitoring.MonitoringFilter=false to my portal.properties but it still seems to be enabled. (getting a response already commited exception on it).
And since it only occurs at the customer and we're not monitoring the performance it seems best to turn it off.
Any input is appreciated.
(liferay-6.0.5)
Be extra extra sure that the portal-ext.properties you mention (you didn't refer to portal.properties, right) is really picked up - there will be a log entry at startup stating which portal-ext.properties is being read.
Put your portal-ext.properties in LIFERAY_HOME, that's the same folder that also has the tomcat, data and deploy folders (if you're on the tomcat bundle).
Also, on Windows, make sure that Windows shows also the extensions. I can't count how many times people created portal-ext.properties.txt and wondered why it wasn't picked up. (this file is only renameable on the command line, not in Explorer, if you have the "hide extension of known files" on.
I am experiencing the same issue as you and can confirm that the IllegalStateException will still occur even the monitoringFilter is disabled. The exception seems to occur on the filterChain, not actually on the MonitoringFilter. See http://issues.liferay.com/browse/LPS-13853
Related
Very general question here:
I have Liferay 6.1.1 ga2 set up on my Oracle WebLogic 12c.
It works fine on my local, but when I deploy it onto our development server, I lose all write permissions.
E.g., changing the theme/color scheme, creating web content, pages, and saving changes to most things
I try to import LARs however it is saying it is not permitted
I'm not seeing any errors in the logs, and the control panel messages are even telling me my content was created or change successfully (besides the LARs0, but everything stays the same.
Any reason(s) why my changes aren't showing up? I'll surely give a bounty if I can get pointed in the right direction here
Given your description, I'd recommend checking OS issues, like write access to various folders, like temporary folders etc.. I guess that Liferay has proper permissions to the whole database (it's rare to have incomplete access) and can write to all tables. And you're operating on a portal-wide admin account, right?
Unrelated to LAR import, changes will not show up if you have workflow enabled - then you'd find the changes in the list of tasks that need approval.
As staging has quite an obvious UI in 6.1, I assume you don't have staging activated, otherwise you just need to publish. In order to see new portlets, make sure that the "Edit Controls" checkbox in your dockbar is checked. This has bitten me more than once.
if you're running a cluster, make sure that you have set it up correctly, e.g. that you don't see cached content on your node.
Can you confirm that you can see the options to change on the UI, just that your changes aren't persisted?
Also, please note that Weblogic 12c is not on the "supported Appservers" list for Liferay 6.1, it's there for Liferay 6.2 only (probably due to release date). This doesn't mean that it shouldn't run, just that it's not tested for your version. Further, there's a GA3 release for 6.3 already, so you might want to check if it's a problem that's fixed in GA3.
I modified settings for a Community Site inside Liferay.
Trying to poke and play with Liferay's CMS.
Added this setting= Staging: Remote Live
And now I get this error:
javax.servlet.jsp.JspException:
org.apache.velocity.exception.MethodInvocationException: Invocation of
method 'runtime' in class com.liferay.taglib.util.VelocityTaglib threw
exception org.apache.jasper.JasperException:
javax.servlet.ServletException: javax.servlet.jsp.JspException:
ServletException in '/html/portlet/staging_bar/view.jsp':
com.liferay.portal.NoSuchLayoutSetBranchException: No LayoutSetBranch
exists with the key {groupId=13309, privateLayout=false, master=true}
at VM_liferay.vm[line 91, column 24]
Can anyone help with what can I change programmatically to be able to get into the app again? I cannot even get to localhost:8080, it gives me this error.
I'm still using the default HSQL database.
think it might be related to this: http://issues.liferay.com/browse/LPS-18606
It looks like the one we had some time ago.
Site crashed after modifying it's settings in Control Panel. After some investigation we've found up that a setting branchingPublic=true affected that.
First of all, find out which site (community) have You modified. For example it is "community1".
In database find the row of this site:
SELECT * FROM group_ WHERE friendlyurl like '%community1%'
And check there what settings it has in column: "typesettings". I recommend copy them to have a backup.
We have changed branchingPublic=true to branchingPublic=false. And restarted the Liferay Portal.
It helped to start running again.
Although Liferay Support didn't reproduce this, I believe it may help You or someone else.
If that doesn't help, try playing with other settings, maybe some other affects the crash. At last you can try remove them all. Just an idea for You!
Kind Regards!
Starting yesterday I have been unable to connect to our Perforce server. Expanding the depot gives the message "//depot ". Funny because I connected just fine last week and the folks sitting next to me can connect without problems.
IT says nothing the settings have not changed and no errors are being reported. It doesn't help that IT is multiple time zones away!
I'm hoping someone here has seen a similar problem and can tell me which switch to flip.
SOLVED: Using P4Win or P4V there are no errors. BUT using the command line p4.exe I get the error "protected namespace - access denied". Passed this onto IT and perforce mysteriously works again. Sounds like I got my permissions disabled and then re-enabled. No-one has owned up to anything but at least I'm up and running again!
Funny that I had to go to the command line before I got an error message.
"protected namespace - access denied" - means you have no permissions for the specified path. You should see this message in P4V output window if you have the detailed logging enabled.
One possibility is an administrator may have accidentally introduced a typo in your username whilst editing a group or the protection table, or removed you from a group, essentially removing your access (but easy to restore). The spec depot keeps changes to perforce server control files so an administrator could check to see what went wrong, but the spec depot does not tell you which administrator changed it. The spec depot must be created before the event.
After deploying an upgrade to a particular feature which contains ghostable page template, the page starts returning a 404 response.
In the SharePoint log, I get the following
Cannot get ghost document: Features\FeatureName\SubFolder\PageName.aspx
Unknown SPRequest error occurred. More information: 0x80070002
I am able to get the page working by going through SharePoint Designer and deleting the file, then deactivating/activating the feature on that site.
I've attempted resetting the web to its definition with no change.
I would like to have a programmatic solution, whether it be fixing something in the feature's configuration or an update program.
I was able to work-around the problem by
Adding a snip of code to the feature deactivating event to delete the file in question from SitePages.
SPFolder sitePagesFolder = web.GetFolder("SitePages");
foreach (SPFile file in sitePagesFolder.Files)
if (file.Name == "pagename.aspx")
file.Delete();
And using a utility, go through all the affected webs, re-activating the feature in question, which causes the 'orphaned or whatever' file to be removed, replacing it with the current version's
I don't understand the inner workings of the issue completely, but it seems that when the feature is deleted/reinstalled, sometimes the associated, ghosted file is orphaned, leading to this issue.
Is it possible that the upgrade deleted the file from the file system? cause this is the likely reason. go to the feature folder and see if the file is still there. the feature folder would be under template\features under 12/14 (depending on SP version)
Everything works fine for most accounts 100% of the time but here and there some users who are able to access a subsite fine one day are greeted with a standard 404 the next. This can last for an hour or two days, it's really inconsistent.
I check the iis logs and it says the status is also a 404 for these requests, nothing else looks unusual. Sharepoint logs have nothing for the timestamps either.
Correct me if I am wrong but if it was a permission issue an access denied message would be shown.
It is not the individual computer because when a user is having this problem and I can log in with their account and I also get the 404 error although I am on the exact site with another account in another browser at exactly the same time, and it works perfect.
Any suggestions would be greatly appreciated, I've done a fair amount of searching but can not find a similar situation or help anywhere.
Since the information is very strict at the moment, I will throw a few questions that might lead you towards the problem.
Are we on a loading balance setup? The intermittent 404 might be cause by one of the servers Web FrontEnds not correctly serving requests.
Are we running out of disk space in the SQL Server machine? This might cause it
Are the blogcache or site caches enabled? Some routines may break them
Do we have Anti-Virus on the server? (it HAS to be asked :p)
We get very high packet loss between the servers? (The error would be different though)
Something that might occur very often is when you have, say, custom code a DLL on the GAC or the bin folder, and since you could be on loading balance the second server does not have this DLL in its own GAC or BIN folder. Sharepoint usually raises 404s when assemblies are not found too, not only requests.
This seems like a longshot, but... could those SharePoint sites be throwing a 404 HttpException? It seems like you'd see that in the SharePoint logs, too, so it's even more unlikely.
At any rate, is your SharePoint logging level set to an appropriately verbose level to debug weird stuff like this?
Are people checking in & publishing master page changes when new CSS files and/or other includes (script files, etc.) are not yet published at all? I've seen this cause a 404 a few times when users forget to check before they publish.
I have had to write custom code within a SharePoint context and I had those 404 errors as well. The solution, in my case, was to ensure that the block of code executing had these 2 conditions met:
1) Run with elevated privileges, regardless of the fact that it is a 404 this was part of the solution.
2) web.AllowUnsafeUpdates = true; This line of code needed to be added even though it was wrapped within an elevated privileges block.
Once these were added the issue did not occur. This was happening on both load and non-load balanced environments.
This reminds me of a strange asp.net bug that I had a few months back.
It was caused by a patch that had been applied (to the framework if I remember correctly)
try downloading this Windows update list tool and have a look at what has changed since the problem started.
I concede that if there was a problem with a patch then its more likely that it would be a consistent error, but it's worth a look.
It was a permission issue, I had figured this out awhile back but basically a few accounts were not setup properly and could not load a fresh copy of the page, when someone else would hit it they would be able to view the cached page fine. Error was never thrown as a permission issue or access denied anywhere but this is what fixed the problem.