Issue 153 in urlrewritefilter: Context forwarding requires contexts to be available on start of .war with filter

95 views
Skip to first unread message

urlrewri...@googlecode.com

unread,
Dec 5, 2013, 8:17:19 AM12/5/13
to urlre...@googlegroups.com
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 153 by michal.a...@schibsted.pl: Context forwarding requires
contexts to be available on start of .war with filter
http://code.google.com/p/urlrewritefilter/issues/detail?id=153

What steps will reproduce the problem?
1.Make a simple .war with only one dependency of urlrewritefilter;
configure rules to forward between different contexts
2. Upload above one .war, with some other that the request is to be
forwarded to, under Tomcat
3. Try to ask the server for a response

What is the expected output? What do you see instead?

The expectation is that the request is correctly forwarded to provided
context and sample data correctly returned. It works sometimes but
sometimes does not. The point is that the filter is validating it's rules
against existing contexts. Unfortunately it may happen that these contexts
are not yet being started. But, as far as I know, there is no possibility
to guarantee the start order of contexts...

What version of the product are you using? On what operating system?
Tomcat 7, windows

Please provide any additional information below.
Maybe the validation can be postponed till first request ? or be configured
to be disabled ?
Till now we have to redploy the .war file with filter after all contexts
have been already started...


--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

Doru Moisa

unread,
Feb 18, 2014, 3:26:44 AM2/18/14
to urlre...@googlegroups.com, codesite...@google.com, urlrewri...@googlecode.com
Hi all,

I am also affected by this behavior. I have a webapp which has about 20 forwards to ~8 different contexts which are not all available when the appserver is (re)starting. The ones that are not yet started when tomcat loads the webapp - will sometimes respond with 404 (if the filter-mapping dispatcher is only enabled for REQUEST), and sometimes go into infinite loops (if the filter-mapping dispatcher is enabled for REQUEST and FORWARD).

It can be solved by manually reloading the webapp when the others are fully loaded, or via some hacks in tomcat's server.xml (specify the webapps in the right order in a <Host> node).

However, it would be nice to have control of what happens when a specific forward context is not yet available, like re-checking it's availability.

Cheers!

urlrewri...@googlecode.com

unread,
Jun 3, 2014, 5:04:06 PM6/3/14
to urlre...@googlegroups.com

Comment #1 on issue 153 by lor...@gmail.com: Context forwarding requires
contexts to be available on start of .war with filter
http://code.google.com/p/urlrewritefilter/issues/detail?id=153

Is this issue fixed? I still see this issue in 4.0.3 build

lorcel gao

unread,
Jun 3, 2014, 5:05:04 PM6/3/14
to urlre...@googlegroups.com, codesite...@google.com, urlrewri...@googlecode.com
Is this issue fixed?  I still see this issue in 4.0.3 build?

urlrewri...@googlecode.com

unread,
Jun 10, 2015, 8:38:10 AM6/10/15
to urlre...@googlegroups.com

Comment #2 on issue 153 by Wolfgang...@googlemail.com: Context forwarding
requires contexts to be available on start of .war with filter
https://code.google.com/p/urlrewritefilter/issues/detail?id=153

Same behaviour under JBoss EAP 6.4. Context forwarding sometimes happens
sometimes not, depending on deployment order. Is there any way to work
around this issue? Can someone give a hint where in the code this
validation is taking place?

urlrewri...@googlecode.com

unread,
Jun 22, 2015, 2:58:36 PM6/22/15
to urlre...@googlegroups.com

Comment #3 on issue 153 by michal.a...@schibsted.pl: Context forwarding
requires contexts to be available on start of .war with filter
https://code.google.com/p/urlrewritefilter/issues/detail?id=153

The workaround that I've applied is to have separate .war containing only
rules for context forwarding and to ensure while deploying that the one is
touched (re-deployed) after all apps started

Wysłane z iPhone'a

urlrewri...@googlecode.com

unread,
Jun 22, 2015, 3:16:12 PM6/22/15
to urlre...@googlegroups.com

Comment #4 on issue 153 by michal.a...@schibsted.pl: Context forwarding
requires contexts to be available on start of .war with filter
https://code.google.com/p/urlrewritefilter/issues/detail?id=153

Just to be clear - the .war with rules is the root context (ROOT.war)

urlrewri...@googlecode.com

unread,
Jun 23, 2015, 6:18:30 AM6/23/15
to urlre...@googlegroups.com

Comment #5 on issue 153 by Wolfgang...@googlemail.com: Context forwarding
requires contexts to be available on start of .war with filter
https://code.google.com/p/urlrewritefilter/issues/detail?id=153

re-deployment wasn't easy to do in JBoss EAP, since my EAR file contains >
300 sub-modules.
The way I worked around this issue was by subclassing UrlRewriteFilter and
performing a lazy-init of the filter on first access.

See implementation attached in LazyInitUrlRewriteFilter.java

Attachments:
LazyInitUrlRewriteFilter.java 1.1 KB
Reply all
Reply to author
Forward
0 new messages