I have the same JSF war deployed in two environments, both environments are apparently identical (Weblogic 10.3.3). There is no entry in the web.xml for javax.faces.VALIDATE_EMPTY_FIELDS.
In one of the environments, the validators are getting invoked on empty fields and in the other they are not.
The JSF war and the application code is EXACTLY the same.
The JSF Specification version is 2.0 and Implementation Version is 1.0.0.0_2-0-2. I know I can add the parameter javax.faces.VALIDATE_EMPTY_FIELDS in web.xml to ensure identical behavior in all environments, but I want to know why they have a different default behavior? Is it possible that it could be something related to presence of JSR 303 validation in one environment and not in another? How do I check this?
JSR 303 validation is auto enabled if the implementation jar is on the classpath.
Related
I'm in the process of converting a rather large Grails 2 application to Grails 4. It uses the Shiro plugin, which I have upgraded to version 4.3 (compile "org.grails.plugins:grails-shiro:4.3"). In one large GSP (which has always worked OK), the Shiro taglib is now causing the following error:
Error executing tag <shiro:isLoggedIn>: No SecurityManager accessible to the calling code, either bound to the org.apache.shiro.util.ThreadContext or as a vm static singleton. This is an invalid application configuration.
The SecurityManager is initialized OK in Bootstrap.groovy, and in another simple test page, shiro:isLoggedIn works fine. So my question is why might the SecurityManager not be available in this use of the taglib? What should I be looking out for?
I'm not a Grails person, but one common reason folks see this problem is that the ShiroFilter did not process the request (or the filter is not configured early enough in the chain).
What happens is the ShiroFilter creates a Subject (the user) and associates it and the SecurityManager with the request thread. Other API (like the tag lib) would use that Subject and/or SecurityManager.
Check your servlet filters, maybe compare them with the old version with the new version and see what has changed.
G'day John, I look after the grails shiro plugin. That error occurs in the taglib because for some reason I'm trying to track down, the ThreadContext doesn't appear to be available. That means the SecurityUtils goes looking for a static security Manager which isn't normally set in web applications.
So basically it's a bug, and hopefully I'll fix it shortly (help welcome).
I’m trying to understand how the Convention plugin determines when to do URL interpretation. In some REST Plug-in examples I see PrefixBasedActionMapper configured with ”/rest:rest,:struts” and it seems that Convention is only applied to the rest mapper and not the DefaultActionMapper. Is this correct? Either way, under what conditions does the Convention plugin kick in for requests?
I’ve been googling like a mad-man these last two days and can’t seem to find any explanation. Inspecting the plugin source didn't give any insights either.
They are different. Convention Plugin is not about URL/action mapping. It just search java classes and create action configs from them.
However, you can tell the plugin to search specific root packages using the property struts.convention.action.packages. e.g.
<constant name="struts.convention.action.packages" value="com.mycompany.myactions.myconvention.*"/>
We are migrating our application from JSF (MyFaces, Trinidad) 1.2 to JSF (MyFaces, Trinidad) 2.0. I have done the all basic changes like updating the XMLNS for Faces-Config, updating the Web.xml to support 3.0, removed Facelets, el-api, el-ri Jars.
When I set the classloaderMode to PARENT_LAST in Websphere 8.5.5 for picking our MyFaces & Trinidad jar, I'm getting the below error.
A java: URL name was used, but Naming was not configured to handle java: URL names. The likely cause is a user in error attempting to specify a java: URL name in a non-J2EE client or server environment. Throwing ConfigurationException
But I'm NOT getting the same exception when I set the classloaderMode to PARENT_FIRST. How can I resolve this problem? Please help me.
The error sounds like you have include WAS JNDI classes in your WAR, which when combined with PARENT_LAST causes the JDK JNDI to use those uninitialized classes rather than the ones included with WAS. You should not repackage WAS JARs in your application.
Grails 2.0 changed with the way it uses grails.serverURL for development and test environments (as described in the manual). However, I've had several problems with serverURL in regard to production deployment on Tomcat. There seem to be several options for serverURL (production mode):
(Added) this setting is just "smoke and mirrors", because Tomcat and Jetty have methods to control how the URL is handled for the App, down to the "App" level.
Use it to specify the server (as is pointed out as a "TODO" in Config.groovy)
Don't use it as indicated here by one of the Grails contributors, i.e. "It should always be safe to remove the serverURL property and let Grails generate urls relative to the current running app." It's not clear if this extends to production or not (when not generating emails).
Use another method instead, namely grails.app.context, which is not documented in Grails 2.0 manual, but is described in certain references, here and here.
Can you please clarify the correct use of serverURL and app.context, both for Jetty and Tomcat (production mode)?
Thanks
Good question! I was just looking for the correct way to get the actual serverURL without explicitly needing to configure it in Config.groovy (in a Grails 2.1 application).
Since Grails 2.0, there is a super-useful class called LinkGenerator that you can use virtually anywhere, for example in a Service:
import org.codehaus.groovy.grails.web.mapping.LinkGenerator
Class MyService {
LinkGenerator grailsLinkGenerator
String serverUrl() {
// Generate: http://localhost:8080/link-generator
grailsLinkGenerator.serverBaseURL
}
}
Thanks to Mr. Haki for blogging about this!
So the basic idea of the grails.serverURL configuration parameter is to allow the createLink method to know what URL you want when creating absolute links. If no grails.serverURL configuration parameter is specified, it will default to http://localhost:8080 (unless server.port is specified, then 8080 will be whatever) ...
The application context tells Jetty/Tomcat to run the application in a different root. For example, specifying
grails.app.context="/myApp"
will set your application root to "/myApp". In production mode, the application context is handled by the web container and this directive is ignored. The choice to configure your production jetty or tomcat instances to run your application in a different context is entirely dependent on what your technical requirements are.
So the real thing to consider is, in your application are you creating a lot of absolute links in your GSPs where you need to define a "production" serverURL? If not, then you don't need to specify it; if you are, then you'll need to specify it.
As a personal preference, the first thing that I always do after creating a new grails project is go into the config and change the grails.app.context to "/" ... It makes mirroring a production environment much easier for me.
Hope this clears things up!
I'm writing a Grails app which I'd like 3rd parties to augment at runtime. Ideally they would be able to add a JAR/WAR to the webapp directory which contains new domain, controller and service classes, new views, and other content.
Is there a simple way to do this within grails? Would it be simplest to create a startup script which copies the new classes etc. into the relevant directories and then updates grails.xml and web.xml?
You will be able to do this in version 2 of grails in which plugins will be also OSGI plugins http://jira.codehaus.org/browse/GRAILS/fixforversion/15421
It seems that the Grails plugins will actually fit quite well for this: http://www.grails.org/Understanding+Plugins
A plugin can do just about anything... One thing a plugin cannot do though is modify the web-app/WEB-INF/web.xml or web-app/WEB-INF/applicationContext.xml files. A plugin can participate in web.xml generation, but not modify the file or provide a replacement. A plugin can NEVER change the applicationContext.xml file, but can provide runtime bean definitions