my site uses JSF and the url appears to be, http://mysitename.com/wompower6/faces/home.xhtml
I am using prettyfaces, so if I use the following in pretty-config.xml, i can change the name to http://mysitename.com/wompower6/home
<url-mapping id="home">
<pattern value="/home" />
<view-id value="/faces/home.xhtml" />
</url-mapping>
my questions are
how can i remove the application
name wompower6 , so that the url
becomes mysitename.com/home ?
in my web.xml, i have
<welcome-file>home.xhtml</welcome-file>,
but this does not seem to work. When
i type, mysitename.com, it does not
get mapped to home.xhtml. any clue
here?
how can i remove the application name wompower6 , so that the url becomes mysitename.com/home?
This is a webapp <Context> setting and configuration is dependent on the servletcontainer used. If you're for example using Tomcat, then there are basically 2 options to make your webapp the root webapp.
Rename the WAR file to ROOT.war and Tomcat will by default deploy it on context root.
Set path attribute of <Context> element in Webapp/META-INF/context.xml (or Tomcat/conf/server.xml, depending where you'd like to define it) to an empty String. E.g.
<Context path="" ...>
Other containers support similar constructs. Consult their documentation for detail. If you're using an IDE like Eclipse, then you can also set it in the Web Project Settings property of the project properties (rightclick project and choose Properties). Set the Context root value to just /.
in my web.xml, i have home.xhtml, but this does not seem to work. When i type, mysitename.com, it does not get mapped to home.xhtml. any clue here?
I assume that you're talking about the <welcome-file> setting. This has to point to a physically existing file, not to a virtual URL, such as /faces/*. There are basically two ways to overcome this:
Provide a physically existing /faces/home.xhtml file (it can even be left empty).
Replace the ugly /faces/* URL pattern of the FacesServlet mapping in web.xml by *.xhtml so that it will just kick in on every request for a XHTML file.
<url-pattern>*.xhtml</url-pattern>
This way you don't need to fiddle with /faces/* URL patterns.
Related
I need to allow deployers to specify the path for our Tomcat webapp log4j2 RollingFileLogger. I'd like to use JNDI but can use a plain -D param if I had to. This apache page seems to explain things pretty well.
Only problem is it doesn't work. I will admit to not being particularly experienced in JNDI, but I can't even get a simple JVM param to work. Reading about Property Substitution I got the impression I cannot just put the $${jndi:xxxx} in the filename attribute and that I should use a ${xxx} Property substitution instead. Unfortunately while that property substituion works fine no lookup jndi or env ever resolves.
log4j2.xml:
<Properties>
<Property name="filename">$${jndi:logPath/directory}/ief.log</Property>
</Properties>
....
<RollingFile name="RollingFileLogger" fileName="${filename}" immediateFlush="false" append="true"
Result:
2014-09-16 14:44:46,284 ERROR Unable to create file ${jndi:logPath/directory}/ief.log java.io.IOException: The filename, directory name, or volume label syntax is incorrect
As you can see the property is substituted but the lookup is not done. I am unsure what the context.xml entry should look like. But my best guess is:
<Resource name="logPath"
auth="Container"
directory="/tmp" />
I am using log4j version 2.0 but am fairly certain this is my misunderstanding not a bug. Any help clearing up what I'm doing wrong would be greatly appreciated.
I never found a JNDI browser that would work in Tomcat 7. But it did turn out to be a stupid problem. I defined this as a RESOURCE instead of an ENVIRONMENT. Just for the record the context.xml should look like:
<Environment name="logPath"
auth="Container"
type="java.lang.String"
value="/tmp" />
And log4j2 lookup is then:
<Property name="logName">$${jndi:logPath}/iefrest.log</Property>
<Property name="patternName">$${jndi:logPath}/iefrest</Property>
...
<RollingFile name="RollingFileLogger" fileName="${logName}" immediateFlush="false" append="true"
filePattern="${patternName}-%d{yyyyMMdd-HH}.log.gz">
It is worth noting that the "java:comp/env" (which is clearly documented but misleading to people that don't have a deep knowledge of JNDI - like me) actually maps to the Environment XML element and does not imply a prefix to the name attribute.
From a Log4J2 prespective it is also interesting that the filename attribute is taken EXACTLY as provided. Specifically you cannot say filename="${logName}.log". This will not parse into the desired results. However expected concatenation DOES take place on the filepattern attribute. Inconsistent but not unmanageable.
If you specify $${jndi:logPath/directory}, the lookup will add the prefix java:comp/env/, so the full value that it will look up is java:comp/env/logPath/directory. (This prefix is not added if your jndi lookup key already contains a ':' character.) Perhaps you can use a JNDI browser to see if this gives you the expected value.
Any errors that occur during this lookup will be logged to the status logger at WARN level. Status logs appear in the console. You can enable status logs by specifying <Configuration status="trace" ... in your log4j2.xml configuration file.
I currently have a package on my class path called MyResources with multiple property files that struts uses. Works great:
<constant name="struts.custom.i18n.resources" value="com.company.MyResources"/>
I am trying to move the properties files to a file location, so they can be updated without having to rebuild the package. Is it possible in Struts 2 to refer to this file location?
For example, my new file location with the properties files is:
/g01/properties/
And I would like Struts to use that location for the resource.
Yes, by providing an implementation of ResourceBundleTextProvider and initializing it in your struts.xml configuration file.
The default implementation, com.opensymphony.xwork2.TextProviderSupport defers the text lookup to com.opensymphony.xwork2.util.LocalizedTextUtil.
There are a number of ways to go about this, but if you don't need any of the default S2 behavior, here's the place to start:
<bean type="com.opensymphony.xwork2.TextProvider" name="struts"
class="com.opensymphony.xwork2.TextProviderSupport" scope="default" />
Provide your own ResourceBundleTextProvider implementation that uses whatever configuration management you want, for example, we implemented a DB-backed version (with caching, of course) that allowed translations to live in, and be managed by, a normal DB and I18N front end.
I'll see if I can dig up my original work this weekend and provide a link to a stripped-down solution.
The location of the file cannot be off the class path when you run your app. You should determine which classloader is used to load the resource. Then you should find a way to configure this classloader to be able to use the location as resource. So, it's possible. A short answer.
Im running my sruts 2 (2.1.8.1) applications in a jboss AS (5.1.0-GA). Im placing a.war and b.war in the same /server/default/deploy path and im placing the struts 2 libs in the /server/default/lib path.
There is no error message in the app or the server, but when i type http://localhost:8080/b/ for some reason im getting in the b.jsp page, the messages in the message resources of the application a.
So, my question is:
placing the struts jars in the /lib of the server creates only one instance of the value stack that all the applications have to use the same? If so, what can i do to have different instances for every aplication but keeping the jars in the server paht?
Should i take back the struts jars into the war?
Thanks
im using the struts tag to get the system title
<s:property value="%{getText('system.title')}"/>
this is my configuration for a.war:
/WEB-INF/classes/a-message-resources.properties
system.title=Namefor system A
in the struts.xml i have
<constant name="struts.custom.i18n.resources" value="a-message-resources" />
This is the configuration for b.war
/WEB-INF/classes/b-message-resources.properties
system.title=Namefor system B
in the struts.xml i have
<constant name="struts.custom.i18n.resources" value="b-message-resources" />
I think I might know what is going on here.
The struts.custom.i18n.resources value is tokenized and each token is added to the LocalizedTextUtil.DEFAULT_RESOURCE_BUNDLES. This is a static final list of strings. Before adding an item to the list (such as system.title), list.remove() is called on the same token, removing any prior entries for system.title.
Because this field is static, and because it allows only one entry for each message, whichever of your system.title properties is loaded first is then being overwritten by the next one.
As well, it appears that your JBoss instance is loading this class in a manner that is causing the static variables to be shared. You may be able to configure your JBoss to load this class separately for each app. This might be a good place start.
I am using JSR 303 Bean validation in my JSF 2.0 web application and it works fine with annotations. Now I would like to ignore annotations and configure validation rules using the validation.xml file, so this is what I did (I am using an eclipse dynamic web project) :
Added validation.xml under WebContent/META-INF/validation.xml
<?xml version="1.0" encoding="UTF-8"?>
<validation-config
xmlns="http://jboss.org/xml/ns/javax/validation/configuration"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://jboss.org/xml/ns/javax/validation/configuration validation-configuration-1.0.xsd"
>
<constraint-mapping>META-INF/validation/constraint-mapping.xml</constraint-mapping>
</validation-config>
Then created the file constraint-mapping.xml under WebContent/META-INF/validation/constraint-mapping.xml
<constraint-mappings xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://jboss.org/xml/ns/javax/validation/mapping validation-mapping-1.0.xsd"
xmlns="http://jboss.org/xml/ns/javax/validation/mapping">
<bean class="my.full.path.ValidationMB" ignore-annotations="true">
</bean>
</constraint-mappings>
Having these configurations in place, I suppose the annotations in my bean class ValidationMB shall be ignored, BUT this is not happening!, which makes me assume that the validation.xml file is not being loaded.
any ideas? thanks.
Environment:
Apache Tomcat 7.0.23
javax.faces-2.1.4.jar
hibernate-validator-4.2.0.Final.jar
hibernate-validator-annotation-processor-4.2.0.Final.jar
validation-api-1.0.0.GA.jar
slf4j-api-1.6.1.jar
From the spec: section 4.4.6. XML Configuration: META-INF/validation.xml
Unless explicitly ignored by calling
Configuration.ignoreXMLConfiguration(), a Configuration takes into
account the configuration available in META-INF/validation.xml. This
configuration file is optional but can be used by applications to
refine some of the Bean Validation behavior. If more than one
META-INF/validation.xml file is found in the classpath, a
ValidationException is raised.
To solve my problem I had to create a META-INF folder under the project src folder, which ends in the WEB-INF/classes/META-INF.
The structure of the web application is:
ROOT
|_META-INF -- don't put validation.xml here
|_WEB-INF
|__ classes
|_META-INF
|__validation.xml
But I think that if I pack my web application in a jar file and reuse it in another project It may not work, I will let you know later once I do it.
Try to put your validation.xml directly into the WEB-INF/ directory.
I stumbled across this while looking for something else but wanted to clarify to the OP what is happening. You do in fact need the file to exist at META-INF/validation.xml; however, that is relative to the classpath which is why it worked when you put it under WEB-INF/classes/META-INF/validation.xml.
The cleaner approach is to let the file be put there for you. Your Eclipse project should already be outputting whatever is in your source directory to WEB-INF/classes somehow for you or nothing would be running. But sometimes there are filters on what it outputs so it might excluding something. You might want to check your src dirs and make sure they don't have exclusions.
Just as an example, if you had a Maven war project, all of your java sources would go in src/main/java and the generated classes would end up in the WEB-INF/classes directory. The equivalent happens for src/main/resources which contains non-source files. When I want *.xml, *.properties, etc. to end up in WEB-INF/classes I put them in src/main/resources. For your example I would have a src/main/resources/META-INF/validation.xml file.
Hope this helps anyone else who comes across this and is confused.
This GSP:
<g:link controller="book" action="show" id="5">Example</g:link>
results in this HTML:
Example
This is relative to the HTTP host. If your site is running at http://localhost:8080 that's fine.
During development, an app will more commonly be running at http://localhost:8080/appName.
In such cases, the above link will not work - it will result in an absolute URL of http://localhost:8080/book/show/5 instead of the required http://localhost:8080/appName/book/show/5
What changes are required of the above GSP for the app name to be present in the resulting anchor's href?
The configuration setting grails.app.context should be equal to the context where you want your application deployed. If it's not set, as in the default configuration, it defaults to your application name, like http://localhost:8080/appName. If you want to deploy your app in the root context (e.g. http://locahost:8080/), add this to your Config.groovy:
grails.app.context = "/"
If the context is properly set, the URLs generated by g:link tags will include the context before the controller name.
I found that the meta tag is very useful for getting information in GSP files.
For example, if you want your application name, you can get it like this:
<g:meta name="app.name"/>
You can get any property in your application.properties file like that.
And if you, like me, need to concatenate it to another value, here is my example. Remember that any tag can be used as a method without the g: namespace. For example:
<g:set var="help" value="http://localhost:8080/${meta(name:"app.name")}/help" />
Grails documentation about this is a little poor, but it is here.
For me the single best reason to use <g:link> is that it adds the context if there is one, or omits it if you're running at http://localhost:8080 or in prod at http://mycoolsite.com - it's trivial to just concatenate the parts together yourself otherwise.
The same goes for using g:resource with css, javascript, etc. - it lets you have one GSP that works regardless of what the context is (e.g. 'appName'), since it's resolved at runtime.
I think that is what grails.serverURL is for. You defined this config variable in the Config.groovy, check the configuration documentation for Grails for more details.
Hope this helps!
createLink tag includes your appname / context parameter automatically in the link.
Here is reference doc for it.