Ask Questions and Find Answers
Important:
Ask is now read-only. You can review any existing questions and answers, but not add anything new.
But - don't panic! While ask is no more, we've replaced it with discuss - the new Liferay Discussion Forum! Read more here here or just visit the site here:
discuss.liferay.com
RE: How do you configure Liferay 7.2 to use LiberalScreenNameValidator?
Hi,
I'm in the progress of updating our (fairly big) code base from 6.1.1 to 7.2.0. I'm making good progress, but having a bit of trouble with this issue, even though it seems like it should be very simple.
On Liferay 6.1.1 we had this in our portal-ext.properties:
users.screen.name.validator=com.liferay.portal.security.auth.LiberalScreenNameValidator
Now I'm reading in the 7.2 portal.properties that:
# This property is not read by the portal except for portal properties
# overridden by liferay-hook.xml. It remains here only as a reference.
So then how to you configure the portal to use it?
I've tried creating a hook with "blade create -t war-hook" and setting it in the portal.properties there, but getting the following exception on deploy:
...
Caused by: java.lang.ClassNotFoundException: com.liferay.portal.kernel.security.auth.LiberalEmailAddressValidator cannot be found by sch-hook_7.2.0.1
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:508)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:419)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:411)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150)
at java.lang.ClassLoader.loadClass(Unknown Source)
at com.liferay.portal.kernel.util.InstanceFactory.newInstance(InstanceFactory.java:56)
at com.liferay.portal.kernel.util.InstanceFactory.newInstance(InstanceFactory.java:27)
at com.liferay.portal.kernel.util.ProxyFactory.newInstance(ProxyFactory.java:55)
at com.liferay.portal.kernel.util.ProxyFactory.newInstance(ProxyFactory.java:46)
at com.liferay.portal.kernel.deploy.hot.BaseHotDeployListener.newInstance(BaseHotDeployListener.java:78)
at com.liferay.portal.deploy.hot.HookHotDeployListener.initPortalProperties(HookHotDeployListener.java:1660)
Maybe I can avoid that by coping the class into my hook, but is that really the right way?
Other stuff I've tried:
- Looking in the control panel to see if it now can be configured there. Can't find anything.
- Poked around in the gogo shell to see if anything can be done there. Not getting anywhere.
- Looked through the 6.2 / 7.0 / 7.1 / 7.2 "Breaking Changes" pages. Can't find find anything relevant.
I'm in the progress of updating our (fairly big) code base from 6.1.1 to 7.2.0. I'm making good progress, but having a bit of trouble with this issue, even though it seems like it should be very simple.
On Liferay 6.1.1 we had this in our portal-ext.properties:
users.screen.name.validator=com.liferay.portal.security.auth.LiberalScreenNameValidator
Now I'm reading in the 7.2 portal.properties that:
# This property is not read by the portal except for portal properties
# overridden by liferay-hook.xml. It remains here only as a reference.
So then how to you configure the portal to use it?
I've tried creating a hook with "blade create -t war-hook" and setting it in the portal.properties there, but getting the following exception on deploy:
...
Caused by: java.lang.ClassNotFoundException: com.liferay.portal.kernel.security.auth.LiberalEmailAddressValidator cannot be found by sch-hook_7.2.0.1
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:508)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:419)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:411)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150)
at java.lang.ClassLoader.loadClass(Unknown Source)
at com.liferay.portal.kernel.util.InstanceFactory.newInstance(InstanceFactory.java:56)
at com.liferay.portal.kernel.util.InstanceFactory.newInstance(InstanceFactory.java:27)
at com.liferay.portal.kernel.util.ProxyFactory.newInstance(ProxyFactory.java:55)
at com.liferay.portal.kernel.util.ProxyFactory.newInstance(ProxyFactory.java:46)
at com.liferay.portal.kernel.deploy.hot.BaseHotDeployListener.newInstance(BaseHotDeployListener.java:78)
at com.liferay.portal.deploy.hot.HookHotDeployListener.initPortalProperties(HookHotDeployListener.java:1660)
Maybe I can avoid that by coping the class into my hook, but is that really the right way?
Other stuff I've tried:
- Looking in the control panel to see if it now can be configured there. Can't find anything.
- Poked around in the gogo shell to see if anything can be done there. Not getting anywhere.
- Looked through the 6.2 / 7.0 / 7.1 / 7.2 "Breaking Changes" pages. Can't find find anything relevant.
Hi,
You can write your own ScreenName Validator service ,
You can write your own ScreenName Validator service ,
@Component(
immediate = true, property = {"service.ranking:Integer=100"},
service = ScreenNameValidator.class
)
public class CustomScreenNameValidator implements ScreenNameValidator{
@Override
public String getAUIValidatorJS() {
return null;
}
@Override
public String getDescription(Locale locale) {
return "CustomScreenNameValidator";
}
@Override
public boolean validate(long companyId, String screenName) {
//You Custom Validation
return true;
}
}
Thanks Mohammed, I guess I'll do that.
It just seems kind of silly when Liferay already includes LiberalScreenNameValidator.
It just seems kind of silly when Liferay already includes LiberalScreenNameValidator.
Hi Lars, The comment also specifies that you can use an environment variable to set the value
# Env: LIFERAY_USERS_PERIOD_SCREEN_PERIOD_NAME_PERIOD_VALIDATOR # #users.screen.name.validator=com.liferay.portal.security.auth.DefaultScreenNameValidator #users.screen.name.validator=com.liferay.portal.security.auth.LiberalScreenNameValidator
Have you tried that? I don't think you should have to create your own copy of that validator class as has been suggested just to have the same behaviour.
I can't seem to find a configuration for it either, even looking through the source, so now I am wondering if perhaps this is an oversight?
At the very least you should be able to do this --
So that you don't have to write any logic, just wrap what liferay provides to bump the priority using the service ranking. Again though, this must either be a well hidden configuration or an oversight because this is not the norm at all.
At the very least you should be able to do this --
@Component(
immediate = true, property = {"service.ranking:Integer=100"},
service = ScreenNameValidator.class
)
public class CustomScreenNameValidator extends LiberalScreenNameValidator {
@Override
public boolean validate(long companyId, String screenName) {
return super.validate(companyId, screenName)
}
}
So that you don't have to write any logic, just wrap what liferay provides to bump the priority using the service ranking. Again though, this must either be a well hidden configuration or an oversight because this is not the norm at all.
Hi Andrew,
I haven't tried the environment variable, as that just looks like another way of setting a portal property that isn't read anyway. I guess I might be wrong on that, but I really don't think so.
Yeah, I implemented a solution very similar to your suggestion.
But like you I'm still wondering if this is an oversight or if we're just missing a configuration somewhere...
I haven't tried the environment variable, as that just looks like another way of setting a portal property that isn't read anyway. I guess I might be wrong on that, but I really don't think so.
Yeah, I implemented a solution very similar to your suggestion.
But like you I'm still wondering if this is an oversight or if we're just missing a configuration somewhere...
Hey Lars,
It might be worth it to open a ticket at issues.liferay.com to let Liferay know. If you do open that ticket, can you update this thread with the link to the issue so that anyone else who comes along with the same question has a breadcrumb to follow (maybe even to an answer)?
It might be worth it to open a ticket at issues.liferay.com to let Liferay know. If you do open that ticket, can you update this thread with the link to the issue so that anyone else who comes along with the same question has a breadcrumb to follow (maybe even to an answer)?
Just ran into the same problem, but the solution is simple:
1. Create a war hook and specify your own properties file in the portal-properties element of liferay-hook.xml.
2. In the properties file specify: users.screen.name.validator=com.liferay.portal.kernel.security.auth.LiberalScreenNameValidator
3. Add the com.liferay.portal.kernel.security.auth package to the DynamicImport-Package section of your liferay-plugin-package.properties file.
1. Create a war hook and specify your own properties file in the portal-properties element of liferay-hook.xml.
2. In the properties file specify: users.screen.name.validator=com.liferay.portal.kernel.security.auth.LiberalScreenNameValidator
3. Add the com.liferay.portal.kernel.security.auth package to the DynamicImport-Package section of your liferay-plugin-package.properties file.
While this will circumvent the "com.liferay.portal.kernel.security.auth.LiberalEmailAddressValidator cannot be found" error the desired service will still not be utilized.
The issue will be fixed here - https://issues.liferay.com/browse/LPS-111288
The issue will be fixed here - https://issues.liferay.com/browse/LPS-111288
Copyright © 2025 Liferay, Inc
• Privacy Policy
Powered by Liferay™