Struts and JSF question

[Mete Kural]

Hello Struts developers,

I was having an email correspondance with someone and he asked me these questions 
below. It is about JSF and whether JSF is adequate by itself or needs to be coupled 
with a web framework like Struts to be better. I want to hear what your opinions are 
regarding why JSF together with Struts is better than JSF alone.

>Struts is well used now because it introduced the idea of MVC2, but Struts 
>has not a good design, it is not extendable and it is too Heavy; webwork for 
>example is much better. Using Struts with portlets is really a bad idea. We 
>now provide a bridge to embedded existing Struts applications into portlets. 
>But if you start from scratch do not use Struts. 
> 
>Our home made framework is really dedicated to portlets, we will slowly move 
>to use JSF (alone NOT coupled with STruts)  in portlets and maybe extends 
>JSF to get a better suppport of portlets specificities. 
> 
>I bet that JSF will replace all web frameworks very quickly, it is so 
>powerfull and there is nothing Struts can do that JSF can do in a nicer 
>way;) 
> 
>Why do you insist on Struts, any other arguments or suggestions? 

Thanks,
Mete


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

[Mete Kural]

>If we do things right, IMHO workflow support system(s) should be a layer on top
>of the foundational request handling capability, so you can use it if you need
>it but it doesn't get in the way if you don't.

I think I agree here. Isn't workflow something that the business tier implements in a 
properly designed application? Since a workflow is based on business rules specific to 
an organization, why should the webapp front-end deal with workflow issues, and not 
leave it up to the business tier?

Thanks,
Mete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

[Mete Kural]

Hi Craig,

>A completely different way to consider using JSF would be to build a RenderKit
>that took input like this and generated the corresponding HTML (or whatever)
>markup, starting from the exact same components as the standard HTML RenderKit.
> In the JSF release, there is the very beginnings of an example how this can be
>done, which uses XUL as the input templating language.  Fleshing something like
>this out could leverage the fact that Mozilla has already popularized this as a
>technology for defining page layout, as well as some amount of interactivity.

I have a question here. I've been thinking of ways of how JSF and XSLT could be 
leveraged together, with or without leveraging JSP. Let's say we have an application 
where the Action classes make lots of calls to SOAP services and sometimes receive 
fairly large XML documents. In the case of large XML responses, converting the XML to 
POJOs may turn out to be unnecessary processing, where as you can simply do an XSLT 
transformation over the XML response to generate the final markup output. So what 
would be an efficient way to leverage both JSF and XSLT here? Could this be a good 
strategy:

"Implement a RenderKit and JSF components that take XML documents as the business 
object input (instead of JavaBeans, Maps, etc.) and uses XSLT to generate the 
device-specific markup output. Then if you are using JSP as the templating system, 
implement a JSP taglib to call these components. If you're using another templating 
engine, write a tag library specific to that templating system and call your 
components."

>Craig

Mete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

[Mete Kural]

>The "dynamic field" use case comes up all the time, but I have trouble 
>getting my head around it. What would be helpful would be a example 
>application that people could play with. You can take thought 
>experiments only so far :)

Yeah you're right. There needs to be an example application. We have a new project 
where we need to have this dynamic forms ability so hopefully we can come up with some 
example application for others to take a look at.

>My first question would be how would anything (never mind Struts) 
>address this use case?

We don't yet know exactly how (since we haven't built the framework yet). But it'll 
surely involve a lot of Introspection and Reflection APIs.

>-Ted.

-Mete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

[Mete Kural]

>For a given form/action, the framework will be supplied with the FQCN of the
>DTO/VO.  From there, it can determine what the fields of the form will be.  The
>form bean validation/descriptor XML will provide the validation information and
>any conversion rules as needed to format/parse between the value object and the
>string representation for the form bean.

That sounds very interesting. I think there is interest in having support for dynamic 
forms where the fields of the form are determined dynamically rather than hardcoded in 
the JSP. What are the ideas on how to handle dynamic field names (and number of 
fields) in Struts 2.0? 

Let's say that we are designing a dynamic customer information editing form. Every 
user has different preferences on what fields they want to edit or allowed to edit. 
Action class accesses a web service and receives a SOAP response with exactly those 
fields that are fit for this user. How could Struts assemble the form dynamically and 
pre-populate the customer information and then validate it when the user submits?

Regards,
Mete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

[Mete Kural]

>I am thinking of fliping sides on FormBean as interface, I am now 
>leaning against formbeans being an interface. FormBean is a concept 
>(properties that map to form elements), plus this idea of XML as a 
>FormBean. It could be a List or String or anything.

XML as a FormBean! That got my attention...

Say we want to populate customer information where a user can edit it like in an Excel 
spreadsheet. If the Action accesses a web service and receives a SOAP response and 
some XML objects in the SOAP response, sometimes it is too much processing to convert 
XML to Java objects if it is a lot of XML (for example: If the web service returns a 
list of 50 customers with detailed info). In such cases it may make more sense to do 
an XSLT transformation over the XML objects and render the form. Any suggestions on 
how this could be done in Struts 2.0?

Thanks,
Mete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Struts 2.0 as a Portlet framework

[Mete Kural]

Hi All,

A huge Struts 2.0 discussion on the struts-dev list has started. Everybody is putting 
in their ideas of how Struts 2.0 ought to be like. I encourage all Portal/Portlet 
developers to participate in that discussion in struts-dev and provide their insight 
on how Struts 2.0 could become a good portlet framework.

Sorry for the cross-posting. I thought it was substantial news that portal/portlet 
developers may be interested in.

Thanks,
Mete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: JSR-168 and Struts

[Mete Kural]

Hello Struts and Pluto developers, 

There was a thread about developing JSR-168 support into Struts 2.0 in the pluto-dev 
list and we thought it might be best to continue this thread on both lists, pluto-dev 
and struts-dev synchronously. Below is the last email in the thread send by Scott 
Weaver to the pluto-dev list. Please "reply all" so that your emails will go to both 
groups.

Thanks,
Mete

Scott's message:

-- Original Message --
From: "Weaver, Scott" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Date:  Wed, 29 Oct 2003 15:33:03 -0500

Hi Martin,

> -Original Message-
> From: Martin Cooper [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 29, 2003 3:16 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Pluto and Struts
> 
> On Wed, 29 Oct 2003, Weaver, Scott wrote:
> 
> > Maybe it's just me, but I tried to build the contrib stuff in the CVS
> for struts a while back as I wanted to start taking a look at.  However, I
> could never get it built.  There were deps I had never heard of, nor did I
> know were to get them.
> 
> If you could let me know what you're having problems with, I'll try to
> help you through getting it all built. The chances are that anything you
> haven't heard of comes from Jakarta Commons or the Commons Sandbox. (For
> example, 'chain' is currently in the sandbox.)

I know most of the stuff in commons proper, I don't think that's were my issue lies.  
I am pretty sure it was chain that I couldn't find and, at the time, I am not sure it 
was available, even within commons-sandbox.  I don't remember the specific issues as 
this was around 2 months ago when I last tried.

> 
> I was actually having the same problem but from the other side of the
> coin, as it were. I need to build 'chain' against the Portlet API, but I
> couldn't get Pluto to build, and couldn't figure out the deps for that.
> (BTW, since Pluto's build.xml depends on ant-contrib, '-projecthelp'
> doesn't work until that's configured, which is quite mysterious until you
> look at the build file itself. ;)
> 

Try "build driver", there are custom ant tasks that get included when you call the 
"build" script.  

I really don't do much at all with Pluto portal implementation in that my focus, 
concerning Jetspeed, is the core Pluto container itself.  That is were I spend most of 
my time in regards to Pluto.

That being said, there should be no fork in development to support either Pluto Portal 
or Jetspeed 2.  In fact, if we do this correctly, the whole thing should be 
transparent to the Struts portlet app and that app should be easily portable to any 
other JSR-168 portal.

p.s.

I have no issues whatsoever with joining the Struts-dev mailing list, however, I think 
it might be in the best interest of all involved that we cross-post to both struts-dev 
and pluto-dev.

I look forward to working with you.

Regards,
** 
| Scott T Weaver |
| <[EMAIL PROTECTED]>| 
| Apache Jetspeed Portal Project |
| Apache Pluto Portlet Container |
**



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Building the Struts /contrib code in the CVS

[Mete Kural]

Hello Struts developers,

Scott Weaver from the Jetspeed and Pluto projects wrote that he tried to build the 
code in the /contrib folder of the Struts CVS and faced some problems. I think he 
wants to take a look at the struts-chain code in order to figure out how it's going to 
work in a portlet environment. I am copying his email below:

-- Original Message --
From: "Weaver, Scott" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Date:  Wed, 29 Oct 2003 13:37:48 -0500

>Maybe it's just me, but I tried to build the contrib stuff in the CVS for struts a 
>while back as I wanted to start taking a look at.  However, I could never get it 
>built.  There were deps I had never heard of, nor did I know were to get them.  
 
Can you assist him on this? Thank you..

Mete
 
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Where is Struts 2 going?

[Mete Kural]

Great! I read the whiteboard. Do you know when the development for the portlet related 
aspects of Struts 2.0 may begin. I know that there are some Jetspeed developers who 
are interested in contributing to a project that aims to turn Struts into a portlet 
framework. I think that adding more committers to Struts that are coming from a 
portal/portlet background would be of great benefit to the development of Struts 2.0. 
Unfortunately, I am under-skilled for that, but I can refer some individuals to you 
who have the skills from the Jetspeed project, if you wish.

Regards,
Mete

-- Original Message --
From: David Graham <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
Date:  Tue, 16 Sep 2003 10:27:33 -0700 (PDT)

>--- Mete Kural <[EMAIL PROTECTED]> wrote:
>> Hello Struts developers,
>> 
>> What will the role of the JSR-168 Portlet specification be for Struts 2?
>> Will Struts 2 be a hybrid framework for both portlet applications and
>> plain servlet applications?
>
>That's the current goal.  If we design the request processor chain
>properly, Struts will be flexible enough to support future technologies
>rather than just Portlets and Servlets.
>
>David
>
>> 
>> Thanks,
>> Mete
>> 
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>> 
>
>
>__
>Do you Yahoo!?
>Yahoo! SiteBuilder - Free, easy-to-use web site design software
>http://sitebuilder.yahoo.com
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Where is Struts 2 going?

[Mete Kural]

Hello Struts developers,

What will the role of the JSR-168 Portlet specification be for Struts 2? Will Struts 2 
be a hybrid framework for both portlet applications and plain servlet applications?

Thanks,
Mete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Struts 2.x series

[Mete Kural]

> Struts 2.x series would be based on 
> Servlet 2.4 / JSP 2.0, but that's it

Also for the Struts 2.x series, is there any inclination among the rest of the Struts 
developers to realize this goal statement that Craig mentioned:

"I believe that we should aim for the following ideal state -- a Struts application 
shoud be usable either as a webapp or as a portlet, with little (ideally no) changes.  
Therefore, I believe that we'd build
whatever it takes to support this into the standard Struts distribution, which would 
then be used in both environments."

Should Struts 2.x aim to be a portlet framework as well?

Mete



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts for Portlets (requesting your opinions)

[Mete Kural]

>Agree. I just read Craig "ideal view" and I think this view may be a 
>good start.

I think so too. I will re-state Craig's "ideal goal" below for others to catch up:

"I believe that we should aim for the following ideal state -- a Struts application 
shoud be usable either as a webapp or as a portlet, with little (ideally no) changes.  
Therefore, I believe that we'd build whatever it takes to support this into the 
standard Struts distribution, which would then be used in both environments."

I would like to ask everybody what their opinions are about this topic. Is it 
technically possible for Struts to enable the same application to be turned into a 
webapp or a portlet at the switch of a button? Could the fundamental differences 
between a webapp and a portlet not allow such a possibility?

Mete

-- Original Message --
From: BaTien Duong <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
Date:  Wed, 13 Aug 2003 12:24:47 -0600

>Agree. I just read Craig "ideal view" and I think this view may be a 
>good start.
>
>BaTien
>DBGROUPS
>
>Mete Kural wrote:
>
>>>Struts-Tiles-Portal-Portlet framework and container.
>>>
>>>
>>
>>I think that there is a big difference between the framework used to build a portal 
>>server and a "portlet framework". I see that Struts+Tiles is a very good framework 
>>to build a portal server, but it seems to me that the ways in which Struts would be 
>>used as a framework for building a portal server are very different than Struts 
>>being used as a "portlet framework".
>>
>>IMHO, Struts developers should focus on making Struts an efficient portlet 
>>framework. Portal server developers could tweak Struts in their own ways in order to 
>>use it as a framework for building their portal server, but I don't see the need for 
>>standardization in this area. Standardization is rather necessary in the are of 
>>using Struts as a portlet framework.
>>
>>What are your opinions?
>>
>>-Mete
>>
>>-- Original Message --
>>From: BaTien Duong <[EMAIL PROTECTED]>
>>Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
>>Date:  Wed, 13 Aug 2003 11:02:44 -0600
>>
>>  
>>
>>>Greetings:
>>>
>>>I am very interested in this discussion, and will have more time to 
>>>think of the overall structure after the release of JSR-168 Reference 
>>>Implementation (Pluto).
>>>
>>>At a cursory level, i see Struts provides very simple and elegant flow 
>>>controllers of what-to-do and how-to-do based on standard Servlet 
>>>container. Tiles is an elegant dynamic templating engine, also based on 
>>>standard Servlet container. I see JSP tiles as a plus rather than a 
>>>short-coming since J2EE has JSP as its dynamic page assembling.  JSR-168 
>>>portal/portlet containers are official extension of Servlet container. 
>>>It seems not a very major issue to make Struts and tiles a 1-2 punch for 
>>>JSR-168 portal/portlet containers. Tiles context may be refactored into 
>>>Portlet context. Tiles already has a facility to dynamically generate 
>>>tile attributes for changing the page assembling. This is probably what 
>>>the JSR-168 authors mention that "Portlet can act as controller, fill a 
>>>bean with data, and include a JSP to render the output". See this pattern?
>>>
>>>The effort is valuable, since many Struts Plug-ins can be parts of our 
>>>tools. I see Jetspeed is too heavy, not simple and elegant enough to 
>>>realize the potential of JSR-168 and WSRP. We can learn many designs 
>>>
>>>
>>>from Jetspeed to bring them into this new portal/portlet framework with 
>>  
>>
>>>simple and elegant design infrastructure. I hope many designers and 
>>>developers interested in this relevant topic: 
>>>Struts-Tiles-Portal-Portlet framework and container.
>>>
>>>BaTien
>>>DBGROUPS
>>>
>>>Mete Kural wrote:
>>>
>>>
>>>
>>>>Hello Struts developers,
>>>>
>>>>I wanted to get your opinions on how Struts should be used as a portlet framework. 
>>>>I think that it would be great if a portlet framework was part of the standard 
>>>>Struts distribution in the near future. JSR-168 which defines standard portlets 
>>>>will be finalized pretty soon (a month?), although the specificati

Re: Struts for Portlets

[Mete Kural]

>Struts-Tiles-Portal-Portlet framework and container.

I think that there is a big difference between the framework used to build a portal 
server and a "portlet framework". I see that Struts+Tiles is a very good framework to 
build a portal server, but it seems to me that the ways in which Struts would be used 
as a framework for building a portal server are very different than Struts being used 
as a "portlet framework".

IMHO, Struts developers should focus on making Struts an efficient portlet framework. 
Portal server developers could tweak Struts in their own ways in order to use it as a 
framework for building their portal server, but I don't see the need for 
standardization in this area. Standardization is rather necessary in the are of using 
Struts as a portlet framework.

What are your opinions?

-Mete

-- Original Message --
From: BaTien Duong <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
Date:  Wed, 13 Aug 2003 11:02:44 -0600

>Greetings:
>
>I am very interested in this discussion, and will have more time to 
>think of the overall structure after the release of JSR-168 Reference 
>Implementation (Pluto).
>
>At a cursory level, i see Struts provides very simple and elegant flow 
>controllers of what-to-do and how-to-do based on standard Servlet 
>container. Tiles is an elegant dynamic templating engine, also based on 
>standard Servlet container. I see JSP tiles as a plus rather than a 
>short-coming since J2EE has JSP as its dynamic page assembling.  JSR-168 
>portal/portlet containers are official extension of Servlet container. 
>It seems not a very major issue to make Struts and tiles a 1-2 punch for 
>JSR-168 portal/portlet containers. Tiles context may be refactored into 
>Portlet context. Tiles already has a facility to dynamically generate 
>tile attributes for changing the page assembling. This is probably what 
>the JSR-168 authors mention that "Portlet can act as controller, fill a 
>bean with data, and include a JSP to render the output". See this pattern?
>
>The effort is valuable, since many Struts Plug-ins can be parts of our 
>tools. I see Jetspeed is too heavy, not simple and elegant enough to 
>realize the potential of JSR-168 and WSRP. We can learn many designs 
>from Jetspeed to bring them into this new portal/portlet framework with 
>simple and elegant design infrastructure. I hope many designers and 
>developers interested in this relevant topic: 
>Struts-Tiles-Portal-Portlet framework and container.
>
>BaTien
>DBGROUPS
>
>Mete Kural wrote:
>
>>Hello Struts developers,
>>
>>I wanted to get your opinions on how Struts should be used as a portlet framework. I 
>>think that it would be great if a portlet framework was part of the standard Struts 
>>distribution in the near future. JSR-168 which defines standard portlets will be 
>>finalized pretty soon (a month?), although the specification draft is pretty much 
>>stable hereafter.
>>
>>I have two main questions:
>>
>>1) My first question is technical. How do you think portlet support would be best 
>>added to Struts? Which classes should be extended? Are there necessary changes at 
>>the core classes of Struts in order to provide an efficient framework for building 
>>portlets?
>>
>>2) Second question is about how a Struts-based or Struts-like portlet framework 
>>should be distributed. Should it be part of the core Struts distribution? Should 
>>there be two different Struts distributions within the Struts project: "Struts for 
>>Webapps" and "Struts for Portlets"? Or should it be a seperate Jakarta project?
>>
>>I look forward to hearing your opinions.
>>
>>Thank you very much.
>>Mete
>>
>>-
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>.
>>
>>  
>>
>
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Struts for Portlets

[Mete Kural]

Hello Struts developers,

I wanted to get your opinions on how Struts should be used as a portlet framework. I 
think that it would be great if a portlet framework was part of the standard Struts 
distribution in the near future. JSR-168 which defines standard portlets will be 
finalized pretty soon (a month?), although the specification draft is pretty much 
stable hereafter.

I have two main questions:

1) My first question is technical. How do you think portlet support would be best 
added to Struts? Which classes should be extended? Are there necessary changes at the 
core classes of Struts in order to provide an efficient framework for building 
portlets?

2) Second question is about how a Struts-based or Struts-like portlet framework should 
be distributed. Should it be part of the core Struts distribution? Should there be two 
different Struts distributions within the Struts project: "Struts for Webapps" and 
"Struts for Portlets"? Or should it be a seperate Jakarta project?

I look forward to hearing your opinions.

Thank you very much.
Mete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: composable RequestProcessor

[Mete Kural]

Hello Struts developers, 

I noticed this discussion on how to design the next generation of the Struts 
RequestProcessor and it got me interested. I have one question to you guys about this 
subject. Can the next version of RequestProcessor be designed in such a way that it 
will enable developers to write portlet applications (JSR-168 compliant) that are 
based on Struts, as well as servlet applications? 

At this time, one needs to tweak Struts and extend it in certain ways in order to 
write portlet applications based on Struts. Everybody is doing this in their own 
propriotary way. It would be great if these extensions were part of the standard 
Struts distribution. 

I think Struts would be a good choice as a framework in portlet environments as well 
as it has been in servlet environments. 

I welcome your comments. 

Thanks, 
Mete 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

not working in 6/25, 6/26, 6/27 Nightly builds

[Mete Kural]

Hello Struts Committers,

Just wanted to inform you that  tag is
not working in the 6/25, 6/26, 6/27 nightly builds.
Any instance of it throws this exception:

javax.servlet.ServletException: Define tag can contain
only one of name attribute, value attribute, or body
content

Even the struts-exercise-taglib example app included
in these nightly builds throw the same exception.

Thanks,
Mete Kural


__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

SwitchAction not switching to default sub-app

[Mete Kural]

Hello,

I'm very sorry for sending this mail to this group,
but I've been trying to get a hold on how to
effectively use these sub-apps but I'm confused about
how to switch between sub-apps still after reading the
few messages on the topic already in the archives.
There was no reply to my message to the struts-user
group and I thought maybe you the committers can
illuminate me in this topic.

I have two sub-apps in my web-app: default and
/catalog.

I added the switch action to my action-mappings in the
/catalog sub-app config file i.e.
struts-config-catalog.xml



If I call the /switch action in the /catalog sub-app
it should switch to the default sub-app if the correct
parameters are given.

But when I type this in the address bar of the web
browser:

http://localhost/catalog/switch.do?prefix=&page=/

..I get the directory listing for the /catalog
directory with the first
line starting with "Directory Listing For /catalog/"
and then listing all the jsp files in my /catalog
directory.

Shouldn't it take me to the index page for the default
sup-app, i.e. /index.html (or the directory listing if
there is not welcome-file) ?

I set up the switch action in the default sub-app's
config file as well. When I type this in the address
bar of the browser:
http://localhost/switch.do?page=/&prefix=
It takes me to the index page for the default sub-app
as it should. But why not when I call the switch
action from the /catalog sub-app?

Are my parameters incorrect? I'm giving a zero-length
string prefix for the default sub-app and the URI "/"
for the index page. What do you think I'm doing wrong
here? 

Peace,
Mete


__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: