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/14 23:03:49 UTC
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>
Re: Bad Matching - Sub Application Names
Posted by Eddie Bush <ek...@swbell.net>.
Ditlinger, Steve wrote:
>If I may further illustrate the problem:
>
>We have two subapps, /foo & /foo/bar, defined in the web.xml.
>
config/foo and config/foo/bar? Are those your init-param names? I
honestly don't know for certain if this is/isn't possible, but my
inference is that it isn't.
>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
>
That's not what I'd expect it to say, but I haven't examined the source
super-closely either.
>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
>
I haven't looked at how it matches the pattern. This sounds like a bug
to me though (I'm guessing your eg type-in was a type-o -- you said
dothis.do and the error says doThis.do).
>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.
>
... strange.
>The questions are these:
>1) Why doesn't /foo-bar fail in the same way that /foo/bar and /foobar fail?
>
I think /foo/bar is invalid. /foobar should be legitimate (as I
understand it) though.
>2) Why does /foo/bar work with 1.1b1, but not with 1.1b2?
>
Good question.
>WRT question #2, we can't find any difference in the subapp matching code
>between the two versions.
>
>Steve
>
... quoting from o.a.s.a.ActionServlet
public static void selectApplication(HttpServletRequest request,
ServletContext context) {
// Acquire the path used to compute the module
String matchPath = (String)
request.getAttribute(RequestProcessor.INCLUDE_SERVLET_PATH);
if (matchPath == null) {
matchPath = request.getServletPath();
}
// Match against the list of module prefixes
String prefix = "";
String prefixes[] = getApplicationPrefixes(context);
for (int i = 0; i < prefixes.length; i++) {
if (matchPath.startsWith(prefixes[i])) {
prefix = prefixes[i];
break;
}
}
// Expose the resources for this module
selectApplication(prefix, request, context);
}
I think what's getting you into trouble is the startsWith(). It would
seem to me that, since you may have similarly-named modules (why not?)
the prefix should be compared for equality instead. Otherwise, you're
really cutting down your name-space. Maybe I'm missing something
obvious here, but that kind of looks like a bug to me. I should
probably dig into the source further ... and some debugging calls and
really watch it close. I'm guessing you've probably already done that
though - sounds like you at least tried as many permutations of the path
as you could think of.
Regards,
Eddie
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>