I'm trying a simple example of URL rewriting, but it's not working for me. I'm using Seam 2.2.0 deployed to JBoss 5.1.0.
My pages.xml contains:
<page view-id="/html/index.xhtml">
<rewrite pattern="/home" />
</page>
and
<page view-id="/html/common/redirect.xhtml" action="#{redirectAction.redirect}">
<rewrite pattern="/link" />
...
My components.xml contains:
<web:rewrite-filter view-mapping="*.seam"/>
As far as I can tell from the documentation, that should be all I need. However, none of the internal links appear different, and if enter the URL: http://mysite/home or mysite/link?param=something, I just get a 404 page. What am I missing?
I had the same problem when I tried to move from the Tuckey Rewrite Filter to Seam. After some trial and error I finally noticed that I had a page.xml for the view I but added the pattern in the main pages.xml. The former seems to overwrite the latter.
From the seam documentation:
"The view-mapping parameter must match the Servlet mapping defined for the Faces Servlet in the web.xml file. If omitted, the rewrite filter assumes the pattern *.seam."
I don't know why you approach is not working. But don't forget that you can use viewName.page.xml file for the same purpose.
For an example since the name of your page is index.xhtml you have to create the index.page.xml file inside the same folder which contains the index.xhtml file(in your case inside the html folder).
In index.page.xml file add this.
<rewrite pattern="/home" />
As you are already doing your component.xml file should contain the line
<web:rewrite-filter view-mapping="*.seam"/>
Deploy again and it should work.
Related
I have written below rule in my urlrewrite.xml file of my struts application which is using tuckey filter 4.0. We have a requirement in our application that a url of type say http:localhost:8080/tgld/viewTopic?guidelinename=A&topicFile=B needs to be replaced by URL of type http:localhost:8080/tgld/etg/topicFile . some kind of masking for the original URL as it looks shaby with so many parameters. URLrewrite jar 4.9 is already in WEB-INF and my http://localhost:8080/rewrite-status page is loading fine.
here tgld is the application context and viewTopic is my action name
it will be great if someone will help us here
<rule>
<from>/viewTopic/*</from>
<to>/etg/$2</to>
</rule>
Please Change the rule as below
<rule>
<from>^/viewTopic?guidelinename=(.*)&topicFile=(.*)$</from>
<to type="redirect">/tgld/etg/$2</to>
</rule>
The title should explain the biggest part :)
I should be able for example to access http://www.someurl.com:8080/index.jsp but instead I get HTTP Status 404 - /index.jsp
Now why do I assume I should be able to serve static content (ie not be redirected to custom controller but to default servlet handler in stead.)?
Because I have added the following element to my mvc dispatcher servlet config:
<mvc:default-servlet-handler />
I have read that in some case the name of the default server cannot be guessed and I have looked it up in the file: ̣*~/tomcat7/conf/web.xml .*
The default servlet is specified by a name "default". So I tried adding:
<mvc:default-servlet-handler default-servlet-name="default"/>
But to no avail...
I have one spring dispachter servlet mapped to '/'.
I have two controllers mapped to, one controller is mapped to '/' and one is mapped to '/todo'
The controllers work fine.
I thought the controller mapped to '/' could be the culprit so I removed that controller but to no avail.
Anybody an idea? And is it possible to have a controller mapped to '/' and still serve a page like /index.jsp??
Arf, I had put my static resources under the webapp/WEB-INF folder instead of the webapp folder. Now it seems te be working fine ... :)
I want to create simple app, that would use css and js. But I can't reach that static content... I've found some solutions, but I wasn't able to modify them for my solution :(
Would be anybody please so kind and could show some explicit solution (where to add/modify something and what exactly to add/modify) ?
my app structure in navigator:
http://i.nahraj.to/f/gNc.jpg
Content of web.xml and servlet-context.xml http://pastebin.com/fVcNZPst
I'm running my app on tomcat server.
The home.jsp page is correct, because when I rewrite it to home.html and open it via web browser, it shows correctly. I would really appreciate any help.
There are a few issues in your structure:
a. You have put <resources mapping="/resources/**" location="/resources/" /> for mapping your resources, this would map anything with uri starting with /resources/ to locations under your webapp, in your structure that would be src/main/webapp/resources, you however don't have that folder.
b. If you want your files from webapp/css, webapp/img, webapp/js to be available either you can move them into src/main/webapp/resources folder and access them with say /resources/js/test.js uri or just put this entry into your servlet-context.xml file also - <mvc:default-servlet-handler /> - if you are interested I have provided more details here
I'd like to be able to do cross-context request forwarding in Tomcat with the Tuckey URLRewrite filter. For example, I'd like to be able to route an incoming request with an SEO-/user-friendly URL like http://example.com/group-elements/300245/some-descriptive-text, where "group-elements" isn't the name of a deployed application, to a URL mapped to a Java Spring controller method for application 'foo', like http://example.com/foo/app/group/300245/elements. I'm using Tomcat 7.0.27 and URLRewrite 3.2.0; I'm working with Java Spring 3.1 web applications.
The URLRewrite 3.20 documentation notes an optional 'context' attribute for the 'to' filter parameter element:
If your application server is configured to allow "cross context" communication then this attribute can be used to forward (and only forward, not redirect or other "to" types) requests to a named servlet context.
On Tomcat, for instance, the application contexts in the server configuration (server.xml or context.xml) need the option crossContext="true". For instance, the two applications mentioned before ("app" and "forum") have to be defined as:
<Context docBase="app" path="/app" reloadable="true" crossContext="true"/>
<Context docBase="forum" path="/forum" reloadable="true" crossContext="true"/>
Given that and the original discussion about the feature, the 'context' attribute seems to be what I'm looking for. However, I haven't been able to properly enable cross-context request forwarding.
Here's my 'Context' entry application 'foo' in conf/server.xml:
<Context docBase="foo" path="/foo" reloadable="true" crossContext="true"/>
I have my urlrewrite.xml file and web.xml file in webapps/ROOT/WEB-INF/. Here's what they look like:
urlrewrite.xml:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 3.2//EN"
"http://tuckey.org/res/dtds/urlrewrite3.2.dtd">
<urlrewrite>
<rule>
<from>baz</from>
<!-- Note: this 'to' element's value has an error. See the edit at bottom of this post for corrected version. -->
<to context="foo">/foo/app/group/300245/elements</to>
</rule>
</urlrewrite>
web.xml:
<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_5.xsd" version="2.5">
<filter>
<filter-name>UrlRewriteFilter</filter-name>
<filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
<init-param>
<param-name>logLevel</param-name>
<param-value>WARN</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>UrlRewriteFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
</web-app>
The rule defined above in urlrewrite.xml is intentionally basic and hard-coded. In this case I'm simply trying to get the cross-context aspect of the rule working before developing the regular expressions in 'to' and 'from'.
When I request http://example.com/baz with that rule in place, Tomcat returns a 404 error saying "The requested resource (/baz) is not available." I've tried a few variations in the 'to' filter parameter, but nothing has worked yet. And I haven't been able to find any examples of how 'context' should be used.
Any ideas on how I could get this kind of cross-context request filtering to work? Is it even possible? I imagine I might be able to achieve what I'm trying to do by renaming foo.war to ROOT.war or changing the root application as mentioned here, but I'd like to try doing this via URLRewrite unless doing so is infeasible or a bad idea on its face.
If showing more of my configuration would help, please let me know. Thanks in advance for any input.
Edit:
Thanks to Christopher Schultz for the helpful answer. In my case, the problem was caused by two things: 1) not having a context.xml file in webapps/ROOT/META-INF, and 2) having an error in the 'to' element in the URL rewrite rule in webapps/ROOT/WEB-INF/urlrewrite.xml.
The fix involved putting a proper context.xml file in webapps/ROOT/META-INF. For reference for anyone else that encounters this problem, that file ended up looking like this:
webapps/ROOT/META-INF/context.xml
<?xml version='1.0' encoding='utf-8'?>
<Context docBase="ROOT" path="/" reloadable="true" crossContext="true" />
As Schultz mentions, it's only necessary for a context with crossContext="true" to be defined for the context implied in the 'from' element in a given URL rewrite rule (here, that's ROOT). It is not necessary to explicitly define a context for the application in the 'to' URL rewrite rule. In other words, you shouldn't need to manually create a context.xml file for that application -- so continuing the example above, you would not need to manually define and put a context.xml file into webapps/foo/META-INF/.
Schultz's answer reflects the recommendations for defining a context in the official Tomcat documentation: http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Defining_a_context.
The problem was also caused by the fact that the URL rewrite rule in my initial post had an error. The correct version should have been:
urlrewrite.xml:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 3.2//EN"
"http://tuckey.org/res/dtds/urlrewrite3.2.dtd">
<urlrewrite>
<rule>
<from>baz</from>
<!-- Note: the use of '/app' instead of '/foo/app/' below -->
<to context="foo">/app/group/300245/elements</to>
</rule>
</urlrewrite>
If your (real) webapp is deployed to /foo and you want to on-the-fly rewrite URLs like /group-elements/baz to forward (not redirect) to /foo/app/group/300245/elements, then you're going to have to deploy your rewrite filter to one of two places: /group-elements or /.
The above configuration appears to be deploying to ROOT (which is /) but then mapping the URL /baz to /foo/app/group/300245/elements. Instead, you probably want this:
<rule>
<from>/group-elements/baz</from>
<to context="foo">/foo/app/group/300245/elements</to>
</rule>
It looks like you were trying to hit http://example.com/baz which I would have expected to work. The last bit of magic is going to be making the ROOT context cross-context (note that your webapp does NOT need to be cross-context: only the urlrewrite one does). You can change the ROOT webapp to be cross-context by addint crossContext="true" to webapps/ROOT/META-INF/context.xml.
Finally, you should really stop putting <Context> elements in server.xml: leaving them in there basically means you need to restart Tomcat in order to change your webapp deployments.
After the comments I come do this possible conclusion:
I think you are mixing the concepts of a reverse proxy with cross-context. Cross-context is method to share data between two web-applications within the same application server. A reverse-proxy like 'Apache http' can rewrite a url to pass it to a certain server behind it, effectively hiding any unwanted parts or performing other operations like load-balancing.
The infrastructure would be: client --> reverse proxy --> application server
Using:
Spring Web 3.0.5
JSTL 1.2.0
Apache Tiles 2.1.4
Resin 3.1.9
template1: imports jsp for url1
main jsp: imports /my/simple/url2
imported jsp: jsp page without imports nor includes
tiles:
logical view for url1: url1.view (extends tempate1)
logical view for url2: url2.view (is a jsp page)
Now here's what's happening:
When accessing /my/simple/url1: goes to a controller and command which then results to
rendering a template (template1), that imports main jsp
Upon seeing import for /my/simple/url2, dispatches a request for this url
This, in turn, goes to another controller using another command and renders another jsp (aka: imported jsp)
After execution of controller for url2, I expect that url2.view will be rendered and appended to main jsp. But instead of this, template1 is again rendered which results to a loop.
Did anyone experience this problem before? I'm not really sure what's happening.
Ok, so I'm not sure that this will work for for earlier versions of Tiles and Spring (currently using Spring 3.1 and Tiles 2.2.2), but here it goes anyway.
I realized that for some reason, when you do an import using the core tag library within a tiles template, and let's say that import in turn calls a Spring MVC controller, it will cause an infinite loop. The way that I got around this was by doing the following:
Add an attribute in the tiles definition of the layout that will reference a jsp containing the code to do the import. Let's say for example:
<definition name="cti.layouts.fooBarLayout" template="/WEB-INF/views/layouts/foo-bar-layout.jsp">
<put-attribute name="body" value="/WEB-INF/views/some-body.jsp"/>
<put-attribute name="foo" value="/WEB-INF/views/my-import.jsp"/>
</definition>
In this example, you want to add the import code inside of my-import.jsp. You can use the core JSTL tag <c:import>
Inside of foo-bar-layout.jsp, add in a tiles:insertAttribute tag wherever you want this imported page to go. Reference the name of the attribute (in this case 'foo'):
<tiles:insertAttribute name="foo"/>
Now you can extend from this layout without worry about an infinite loop. Not sure why this is working as I don't understand what the underlying implementation is doing, but for some reason, tiles does not allow a dynamic import to be used inside of a template page.
Hope this helped.
I had the same problem and resolved by using the absolute URI of the tile. This triggeres a 'clean' request to the server and isn't aware of the current tile rendering.
I used the import because I required a more dynamic url.
So for the sample case:
<c:import url="/path/to/the/import/jsp/or/controller"/>
becomes
<c:import url="http://localhost:8080/mycontext/path/to/the/import/jsp/or/controller" />
Of course you need to update the baseURI to your applicable situation.
This avoided the recursion happening when combining tiles with c:import
Beware: This triggers a new HTTP-request to your server.