You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "Ditlinger, Steve" <SD...@ebuilt.com> on 2002/09/15 00:32:31 UTC
RE: Bad Matching - Sub Application Names - Bug?
Here's a little more info:
It all comes down to the search order of prefixes in the method
RequestUtils.selectApplication(HttpServletRequest, ServletContext)
under struts 1.1b1 the search orders, under the various subapp name
combinations, are:
/foo-bar
/foo
--
/foo/bar
/foo
--
/foobar
/foo
under struts 1.1b2 the search orders, under the various subapp name
combinations, are:
/foo-bar
/foo
--
/foo
/foo/bar
--
/foo
/foobar
What happened to change the ordering? It seems dangerous to use
String.startsWith() as the sub application selection mechanism unless you
can guarantee a certain search order (i.e. an order with longer-named subapp
paths first).
Unless this is fixed, there will have to be greater restrictions on the
naming of subapps.
Steve
-----Original Message-----
From: Ditlinger, Steve
Sent: Saturday, September 14, 2002 2:04 PM
To: Struts Users Mailing List
Cc: 'Eddie Bush'; Malani, Prakash
Subject: Bad Matching - Sub Application Names
If I may further illustrate the problem:
We have two subapps, /foo & /foo/bar, defined in the web.xml.
Requests to resources in /foo are processed correctly.
Requests to resources in /foo/bar (e.g. /foo/bar/dothis.do) result in error
message: Invalid path /bar/doThis was requested
If we change the subapp definitions to be /foo & /foobar, then:
Requests to resources in /foo are processed correctly.
Requests to resources in /foobar (e.g. /foobar/dothis.do) result in error
message: Invalid path bar/doThis was requested
If we change the subapp definitions to be /foo & /foo-bar, then:
Requests to resources in /foo are processed correctly.
Requests to resources in /foo-bar are processed correctly.
The questions are these:
1) Why doesn't /foo-bar fail in the same way that /foo/bar and /foobar fail?
2) Why does /foo/bar work with 1.1b1, but not with 1.1b2?
WRT question #2, we can't find any difference in the subapp matching code
between the two versions.
Steve
-----Original Message-----
From: Eddie Bush [mailto:ekbush@swbell.net]
Sent: Friday, September 13, 2002 4:59 PM
To: Struts Users Mailing List
Subject: Re: Sub Application Names...
Malani, Prakash wrote:
>Hi,
>
>How are you doing? I am in the middle of migrating an application from
>Struts 1.1b1 to Struts1.1b2. We have an sub-application named foo and
>another named bar. Everything works great. But the following doesn't:
>
>o foo/baz configured in web.xml as application
>
I don't think you can "nest" sub-applications. Sub-applications (AFAIK)
can only be "one-level deep".
>o foobaz configured in web.xml as application
>
You said nothing about this application. Is this another attempt to
access the one above?
>However the following does work:
>o foo-baz
>
... do you have a top-level directory named foo-baz?
>Any ideas, thoughts, suggestions?
>
>Thanks,
>-Prakash
>
The way I understand sub-applications (I just started in on them
recently too) goes like this:
- Gives you one additional level of name-space
(You can bust /context/ down into /context/app1, /context/app2,
/conext/appN)
- The name you specify for the sub-application is what will be used
as the additional qualifyer
(if you specify config/app1 you will reach that sub-application
at /context/app1)
Mine all seem to be working fine. I was a tad confused on how to switch
among them, but I think I nailed that down today. Here is a bit of a
snippet of my configs and an explaination:
--- struts-default.xml --- (aka struts-config.xml -- I like
struts-<module>.xml names personally)
<struts-config>
...
<global-forwards>
<forward name="toHelp"
contextRelative="true"
path="/help/index.do"
redirect="true"/>
</global-forwards>
...
</struts-config>
--- struts-help.xml --- (my non-default app -- help)
<struts-config>
...
<action-mappings>
<action path="/index"
parameter="/help/moduleindex.jsp"
type="org.apache.struts.actions.ForwardAction"/>
</action-mappings>
...
</struts-config>
--- web.xml --- (Here's where I tell the controller about them)
<web-app>
...
<servlet>
<servlet-name>action</servlet-name>
<servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
<init-param>
<param-name>config</param-name>
<param-value>/WEB-INF/conf/struts-default.xml</param-value>
</init-param>
...
<init-param>
<param-name>config/help</param-name>
<param-value>/WEB-INF/conf/struts-help.xml</param-value>
</init-param>
...
</servlet>
...
</web-app>
That's two seperate sub-applications:
- default - specified by the "config" initialization parameter
- will be "rooted" at /contextRoot/
- help - specified by the "config/help" initialization parameter
- will be "rooted" at /contextRoot/help
Because of the way I have things setup, I could reference the default
sub-application like this:
http://mydomain.com/myContext/index.do
http://mydomain.com/myContext/help/index.do
It's really important to pre-face your pages with actions (like is done
with the index action for the help sub-application above) -- especially
so if you're doing sub-applications. Using actions forces you to go
through the controller, and that's the *only* way you will get the
correct ApplicationConfig object placed into the request. Why do you
care? Well, one of the smaller things would be your resources that you
setup in property files. If you don't get the controller to switch you
to the right sub-app, you probably won't have the right ones being used
by your page. If there are some missing out of the resources the
controller *does* give you, you'll wind up with ... a big ugly mess (tm)
:-) Then there are other things like your plugins, datasources ...
anything sub-application specific may be incorrect if you don't get to
the page through an action.
Hope that sheds some light on your problem ...
Regards,
Eddie
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>