Sub Application Names...

["Malani, Prakash" <PM...@ebuilt.com>]

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
o foobaz configured in web.xml as application

However the following does work:
o foo-baz

Any ideas, thoughts, suggestions?

Thanks,
-Prakash


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Sub Application Names...

[Eddie Bush <ek...@swbell.net>]

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>