Re: Re: Re: Url rewriting of .action to .jsp

Sorry that was confusing. A new ModelDriven Interface would be better. ModelFacing from an Implementation perspective: - push the Model object to the top of the stack such that members can be set directly (same as model driven) - register a pre-result listener, which will revert the action class t

Re: Url rewriting of .action to .jsp

2013/9/22 Lukasz Lenart : > You should never ever allow to access JSPs directly! Thus can be > potential security risk! > > What you want to achieve are two actions: > - login-form.action to display login form > - login.action to submit login form to and perform validation/user login There is one

Re: Re: strict DMI, was: Url rewriting of .action to .jsp

Done https://cwiki.apache.org/confluence/display/WW/Action+Configuration#ActionConfiguration-DynamicMethodInvocation 2013/10/1 Christoph Nenning : >> > >> > Would you please have a look at the sample app and tell me what I am > doing >> > wrong? >> > >> > > https://github.com/wolpi/struts2-sample

Antwort: Re: strict DMI, was: Url rewriting of .action to .jsp

> > > > Would you please have a look at the sample app and tell me what I am doing > > wrong? > > > > https://github.com/wolpi/struts2-samples/tree/master/dmiandactionmappingtest > > > > It must be true, if false whole DMI logic is off. > > class="struts2.samples.dmiandactionmappingtest.act

Re: strict DMI, was: Url rewriting of .action to .jsp

2013/9/30 Christoph Nenning : > Finally I continued with my strict DMI tests. > > While creating a sample app I discovered that the above was wrong. It is a > CSRF protection interceptor in the other app which made me think that !add > was blocked by the framework. > > > But I could not get strict

Re: strict DMI, was: Url rewriting of .action to .jsp

> >> > But still: method:add works while !add does not. > >> > >> If you could prepare a small demo app, I'd like investigate that. > >> > >> > > > > I can do so next week, sorry for the delay > > No problem, I'm busy too ;-) > > Finally I continued with my strict DMI tests. While creating a s

Re: Re: Re: Url rewriting of .action to .jsp

@Ken I'm bit lost with your mails, right now I don't know what you want - new Model interfaces or current ModelDriven approach is valid? Maybe start a new discussion? Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ 2013/9/26 Ken McWilliams : > ...more often than not, NOT what I wan

Re: Re: Re: Url rewriting of .action to .jsp

...more often than not, NOT what I want (wrt: "Maybe it's just me but for some reason this is more often than not what I want (I want the model towards the request but not towards the view), so I need to forgo ModelDriven."). Sorry everyone! On Wed, Sep 25, 2013 at 7:39 PM, Ken McWilliams wrote:

Re: Re: Re: Url rewriting of .action to .jsp

Sorry should have read the last couple lines before posting! It was in defense of ModelBacking suggesting that the congruent structure could allow us to publish the action into the stack and then handle it knowing the interface. A certain result type for instance could require a specific backing mo

Re: Re: Re: Url rewriting of .action to .jsp

Not sure if this is the place to bring this up, this is an annoyance coming from ModelDriven may offer a solution... Issue: It's hard to get past the model if you want to add more attributes to the action. Also when using ModelDriven the same view of the action is applied from the HTTP side as the

Re: Re: Re: Url rewriting of .action to .jsp

2013/9/24 Christoph Nenning : >> > But still: method:add works while !add does not. >> >> If you could prepare a small demo app, I'd like investigate that. >> >> > > I can do so next week, sorry for the delay No problem, I'm busy too ;-) Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.

Re: Re: Re: Url rewriting of .action to .jsp

> > But still: method:add works while !add does not. > > If you could prepare a small demo app, I'd like investigate that. > > I can do so next week, sorry for the delay This Email was scanned by Sophos Anti Virus

Re: Re: Re: Url rewriting of .action to .jsp

2013/9/24 Christoph Nenning : > But still: method:add works while !add does not. If you could prepare a small demo app, I'd like investigate that. Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ - To unsubscribe,

Re: Re: Re: Url rewriting of .action to .jsp

> >> > Yeah, I like the idea of strict-DMI. Right now I could not get it > > working > >> > with the convention pulgin, can investigate next week. > >> > >> That's why I want to have programmable configuration in XWork and then > >> XML or Convention configuration via plugins - there strict path h

Re: Re: Re: Url rewriting of .action to .jsp

2013/9/24 Christoph Nenning : >> > Yeah, I like the idea of strict-DMI. Right now I could not get it > working >> > with the convention pulgin, can investigate next week. >> >> That's why I want to have programmable configuration in XWork and then >> XML or Convention configuration via plugins - th

Antwort: Re: Re: Url rewriting of .action to .jsp

> > Yeah, I like the idea of strict-DMI. Right now I could not get it working > > with the convention pulgin, can investigate next week. > > That's why I want to have programmable configuration in XWork and then > XML or Convention configuration via plugins - there strict path how to > add new co

Re: Re: Url rewriting of .action to .jsp

2013/9/24 Christoph Nenning : > Yeah, I like the idea of strict-DMI. Right now I could not get it working > with the convention pulgin, can investigate next week. That's why I want to have programmable configuration in XWork and then XML or Convention configuration via plugins - there strict path

Antwort: Re: Url rewriting of .action to .jsp

> >> Hi all, > >> I'm using DMI to call "input" method extensively, > >> almost in every Edit*Action. > >> I call it with ParamsPrepareParams stack. > >> > >> I fully understand that allowing DMI is a security problem. > >> But maybe some kind of balance could be achevied. > >> White listing with a

Re: Url rewriting of .action to .jsp

Am 23.09.2013 20:32, schrieb Lukasz Lenart: 2013/9/23 Paweł Wielgus : Hi all, I'm using DMI to call "input" method extensively, almost in every Edit*Action. I call it with ParamsPrepareParams stack. I fully understand that allowing DMI is a security problem. But maybe some kind of balance could

Re: Url rewriting of .action to .jsp

2013/9/24 Paweł Wielgus : > One more side note, > if i understand it wright, > in my case (Edit input and execute methods) > wildcard mapping would be better from framework perspective > but it needs to be wriitten in xml configuration. > > Whereas DMI do not require me to write any xml, > but is n

Re: Url rewriting of .action to .jsp

One more side note, if i understand it wright, in my case (Edit input and execute methods) wildcard mapping would be better from framework perspective but it needs to be wriitten in xml configuration. Whereas DMI do not require me to write any xml, but is not first class citizen in terms of framew

Re: Url rewriting of .action to .jsp

Hi Lukasz, i see no problem for me in solution described by You. Off course i'm no security expert here. Best greetings, Paweł Wielgus. 2013/9/23 Lukasz Lenart : > 2013/9/23 Paweł Wielgus : >> Hi all, >> I'm using DMI to call "input" method extensively, >> almost in every Edit*Action. >> I call

Re: Url rewriting of .action to .jsp

2013/9/23 Volker Krebs : > Am 23.09.2013 11:05, schrieb Christoph Nenning: >>> >>> >>> Just a hint: DMI can be dangerous and we think about removing it. >>> >> That would force us to do heavy refactorings in all our applications. > > > Removing DMI completely would break a lot of applications. > Ho

Re: Url rewriting of .action to .jsp

2013/9/23 Paweł Wielgus : > Hi all, > I'm using DMI to call "input" method extensively, > almost in every Edit*Action. > I call it with ParamsPrepareParams stack. > > I fully understand that allowing DMI is a security problem. > But maybe some kind of balance could be achevied. > White listing with

Re: Url rewriting of .action to .jsp

Hi all, I'm using DMI to call "input" method extensively, almost in every Edit*Action. I call it with ParamsPrepareParams stack. I fully understand that allowing DMI is a security problem. But maybe some kind of balance could be achevied. White listing with annotations would not be bad for me also

Re: Url rewriting of .action to .jsp

Am 23.09.2013 11:05, schrieb Christoph Nenning: Just a hint: DMI can be dangerous and we think about removing it. That would force us to do heavy refactorings in all our applications. Removing DMI completely would break a lot of applications. How about white-listing methods ? At the moment

Re: Url rewriting of .action to .jsp

> > Just a hint: DMI can be dangerous and we think about removing it. > That would force us to do heavy refactorings in all our applications. This Email was scanned by Sophos Anti Virus

Re: Url rewriting of .action to .jsp

Just a hint: DMI can be dangerous and we think about removing it. 2013/9/23 Christoph Nenning : > It seems a little late to join this discussion, but anyway here is what I > think. > > > Per default the framework shows validation errors for simple GET requests. > > The easiest way to work around t

Re: Url rewriting of .action to .jsp

It seems a little late to join this discussion, but anyway here is what I think. Per default the framework shows validation errors for simple GET requests. The easiest way to work around that is to add "!input" to the url, like this: login!input.action You can bookmark that and generate link

Re: Url rewriting of .action to .jsp

"You cannot forward to actions" Thanks, that was the idea that was missing from my understanding. Got it working the way I wanted in a minute :) Many thanks - appreciated :) Serdyn du Toit On Mon, Sep 23, 2013 at 8:47 AM, Lukasz Lenart wrote: > 2013/9/22 Serdyn du Toit : > > What I have now

Re: Url rewriting of .action to .jsp

2013/9/22 Serdyn du Toit : > What I have now is as follows: > > > > /admin/login/login.jsp > > class="com.d6.admin.login.AdminUserLoginAction"> > /admin/login/login-form.htm > /admin/dashboard/dashboard.htm > >

Re: Url rewriting of .action to .jsp

Okay, I got the second result working: /admin/dashboard/dashboard.htm Now, just the first one I'm still having problems with as I don't want to redirect /admin/login/login-form.htm On Sun, Sep 22, 2013 at 11:16 PM, Serdyn du Toit wrote: > Thanks guys, > > Just having a bit of trouble

Re: Url rewriting of .action to .jsp

Thanks guys, Just having a bit of trouble getting it 100% - sorry for the trouble (my first Struts project) What I have now is as follows: /admin/login/login.jsp /admin/login/login-form.htm /admin/dashboard/dashboard.htm

Re: Url rewriting of .action to .jsp

You should never ever allow to access JSPs directly! Thus can be potential security risk! What you want to achieve are two actions: - login-form.action to display login form - login.action to submit login form to and perform validation/user login Instead thinking about JSPs behind, think about ac

Re: Url rewriting of .action to .jsp

That's because you are submitting that action. If that's not what you intended, I don't understand what you are trying to achieve. The setting I suggested allows you to rename the .action url extension to .jsp (or .html). (*Chris*) On Sun, Sep 22, 2013 at 1:30 AM, Serdyn du Toit wrote: > Hi

Re: Url rewriting of .action to .jsp

Hi Chris, Not exactly what I'm looking for, If I now type: http://localhost:8080/rf-adminweb/admin/login/login.jsp Then it thinks I'm submitting the form - so my form validation errors get displayed. (ie it thinks I'm submitting the form: http://localhost:8080/rf-adminweb/admin/login/login.

Re: Url rewriting of .action to .jsp

Put the following in your struts.xml configuration file: I actually prefer: since it hides the underlying technology just a bit better and makes a tiny bit harder for someone to guess how to hack it. It's not high security, but every little bit helps. (*Chris*) On Sat, Sep 21, 2013 a

Url rewriting of .action to .jsp

Hi, I have the following Struts action defined in Xml: /admin/login/login.jsp /admin/dashboard/frames.jsp When I submit the page and validation fails my browser has the following Url: http://localhost:8080/webapp/admin/login/login.acti

Re: Struts + redirect=true + Apache Proxy Url Rewriting Problem

It worked like a charm! You just need to add a special connector that handle proxy requests like explained in the link below. Thank you very very much! On Thu, Aug 14, 2008 at 2:08 PM, duschhaube <[EMAIL PROTECTED]> wrote: > Hi, > > I think you can handle this by the tomcat configuration. > > se

Re: Struts + redirect=true + Apache Proxy Url Rewriting Problem

Hi, I think you can handle this by the tomcat configuration. see this link for instructions: http://tomcat.apache.org/tomcat-6.0-doc/proxy-howto.html but i have not test it myself. Miguel Cohnen schrieb: Hi Everybody, First I wanted to say hello to everybody here, as this is my first mail i

Struts + redirect=true + Apache Proxy Url Rewriting Problem

Hi Everybody, First I wanted to say hello to everybody here, as this is my first mail in the list. I also wanted to apologize if my english is not good enough, but i'll do my best! This is the problem I am having: I am building an application using tomcat 5.5 and struts. Let's say that the base

Re: Problem with URL-Rewriting in WebSphere

problem with the virtual host mappings. What port are you using ( http://myhost:9080/xxx/xxx.do)? What version of WAS are you using? Gary > 2007/1/15, Gary VanMatre : > > > > >From: "Roberto Flores" > > > > > > Greetings, > > > > >

Re: Problem with URL-Rewriting in WebSphere

tre : > > > > >From: "Roberto Flores" > > > > > > Greetings, > > > > > > I can't use cookies since this app is for cellphones. On Tomcat there's > > no > > > problem, but in WebSphere enabling only url-rewriting

Re: Problem with URL-Rewriting in WebSphere

OTECTED]>: >From: "Roberto Flores" <[EMAIL PROTECTED]> > > Greetings, > > I can't use cookies since this app is for cellphones. On Tomcat there's no > problem, but in WebSphere enabling only url-rewriting causes 404 errors on > every page transit

Re: Problem with URL-Rewriting in WebSphere

>From: "Roberto Flores" <[EMAIL PROTECTED]> > > Greetings, > > I can't use cookies since this app is for cellphones. On Tomcat there's no > problem, but in WebSphere enabling only url-rewriting causes 404 errors on > every page transition. >

Re: Problem with URL-Rewriting in WebSphere

Subject: Problem with URL-Rewriting in WebSphere > Greetings, > > I can't use cookies since this app is for cellphones. On Tomcat there's no > problem, but in WebSphere enabling only url-rewriting causes 404 errors on > every page transition. > > Upon further inspect

Re: Problem with URL-Rewriting in WebSphere

what is the WebShpere version you are using? Nuwan. - Original Message - From: "Roberto Flores" <[EMAIL PROTECTED]> To: Sent: Monday, January 15, 2007 9:44 AM Subject: Problem with URL-Rewriting in WebSphere Greetings, I can't use cookies since this app

Problem with URL-Rewriting in WebSphere

Greetings, I can't use cookies since this app is for cellphones. On Tomcat there's no problem, but in WebSphere enabling only url-rewriting causes 404 errors on every page transition. Upon further inspection, the jsessionid values generated by WebSphere are drastically different tha

Re: URL-Rewriting suddenly doesn't work any more

lient (this is the default). Set to false if you want to disable the use of cookies for session identifier communication, and rely only on URL rewriting by the application. --so when you move to the new server and take the default you are using cookies in lieu of URL rewrite I took the

Re: URL-Rewriting suddenly doesn't work any more

nt (this > is the default). Set to false if you want to disable the use of cookies > for session identifier communication, and rely only on URL rewriting by > the application. > > --so when you move to the new server and take the default you are using > cookies in lieu of URL rewrit

Re: URL-Rewriting suddenly doesn't work any more

Andreas- Set to true if you want cookies to be used for session identifier communication if supported by the client (this is the default). Set to false if you want to disable the use of cookies for session identifier communication, and rely only on URL rewriting by the application. --so

URL-Rewriting suddenly doesn't work any more

Hello! I've got a very strange problem: I have activated URL-rewriting in webapps/application/META-INF/context.xml with . This has been working fine until today. Suddenly, the server doesn't rewrite the URL's no more - there is no jession-id sent with the URL. Does anybody have

Re: Not getting URL rewriting with

Thanks Richard It works with action=userlogin_display. --- Richard Yee <[EMAIL PROTECTED]> wrote: > According to the documentation if you use href, the value passed will > be > unchanged. It looks like you should use action=userlogin_display > and the property and name attributes to set the

Re: Not getting URL rewriting with

According to the documentation if you use href, the value passed will be unchanged. It looks like you should use action=userlogin_display and the property and name attributes to set the action parameter. -Richard Mon Cab wrote: I have a jsp page called link test (included below), However, the

Not getting URL rewriting with

I have a jsp page called link test (included below), However, the url for *Login Link* is not being rewritten to include the jsessionid. Cookies are disabled on my browser, and jsessionid is being generated for form submissions, but not for links. Am I missing something here? Pleae help. <%

problem on url rewriting and cookies , what is differences

ed our web application to new host) they said : It looks like a bug in tomcat. Please force your application not to do url rewriting and use cookies instead. This should solve your problem. When i ask them about tomcat version they said : its tomcat 5.5.15 , meanwhile my application works fine on tomcat

problem on url rewriting and cookies ,

uced after we moved our web application to new host) they said : It looks like a bug in tomcat. Please force your application not to do url rewriting and use cookies instead. This should solve your problem. When i ask them about tomcat version they said : its tomcat 5.5.15 , meanwhile my applica

Re: Forcing URL Rewriting over Cookies in an existing application.

e detected to be on, they stop using url rewriting. Or do those first two communications scare you? ;) Besides, a packet sniffer could see the cookie being transmitted every time anyway so does it really matter if the cookie is in the browser URL line or being transmitted before the URL in the co

RE: Forcing URL Rewriting over Cookies in an existing application.

Bernhard, Does it really matter? In most Java application servers, don't they do both for the first request but after the second request, where cookies are detected to be on, they stop using url rewriting. Or do those first two communications scare you? ;) Besides, a packet sniffer coul

AW: Forcing URL Rewriting over Cookies in an existing application .

> -Ursprüngliche Nachricht- > Von: David G. Friedman [mailto:[EMAIL PROTECTED] > Gesendet: Montag, 23. Januar 2006 18:10 > > What do you mean by "do it the other way around" ? > Well I mean that you ONLY use cookies for the session management and not URL Rew

RE: Forcing URL Rewriting over Cookies in an existing application.

What do you mean by "do it the other way around" ? URL Rewriting is in the servlet spec 2.2 and beyond, hence the ability in Java to determine if the JSessionId was in a Cookie, URL, or both, but I don't know if there is a standard web.xml syntax. I have read that context.xml f

AW: Forcing URL Rewriting over Cookies in an existing application .

CTED] > Gesendet: Montag, 23. Januar 2006 17:28 > An: Struts Users Mailing List > Betreff: RE: Forcing URL Rewriting over Cookies in an existing > application. > > > The same thing (disable cookies but enable url rewriting) > should work on Tomcat 4.X and 5.X. See the

RE: Forcing URL Rewriting over Cookies in an existing application.

The same thing (disable cookies but enable url rewriting) should work on Tomcat 4.X and 5.X. See the "cookies" attribute in the below url(s): http://tomcat.apache.org/tomcat-4.0-doc/config/context.html http://tomcat.apache.org/tomcat-5.0-doc/config/context.html http://tomcat.apache.

AW: Forcing URL Rewriting over Cookies in an existing application .

OT, but I'm interested, is this available im Tomcat too? Thanks Bernhard > -Ursprüngliche Nachricht- > Von: David G. Friedman [mailto:[EMAIL PROTECTED] > Gesendet: Montag, 23. Januar 2006 17:08 > An: Struts Users Mailing List > Betreff: RE: Forcing URL Rewritin

RE: Forcing URL Rewriting over Cookies in an existing application.

http://access1.sun.com/techarticles/sessions.iws.html Regards, David -Original Message- From: Jay [mailto:[EMAIL PROTECTED] Sent: Monday, January 23, 2006 10:53 AM To: user@struts.apache.org Subject: Forcing URL Rewriting over Cookies in an existing application. Hi all, I have an

Re: Forcing URL Rewriting over Cookies in an existing application.

Jay wrote: Hi all, I have an application (Sun ONE 6.1 sp2, Struts 1.02 (I guess)) that uses Cookies for session handling and has been so for around 3/4 years. I have a requirement where I want to force URL Rewriting even if the browser supports cookies. Please help! Jay This is a

Forcing URL Rewriting over Cookies in an existing application.

Hi all, I have an application (Sun ONE 6.1 sp2, Struts 1.02 (I guess)) that uses Cookies for session handling and has been so for around 3/4 years. I have a requirement where I want to force URL Rewriting even if the browser supports cookies. Please help! Jay Broadband interface (RIA) + mail

Re: How to disable URL rewriting for session id?

ut it under WEB-INF/classes/org/apache/struts/taglibs so Struts calls YOUR class, not the original. David, Nice plan! I basically did as you suggested, and automatic URL rewriting no longer takes place. (Removed calls to HttpServletResponse.encodeURL within org.apache.struts.tagl

RE: How to disable URL rewriting for session id?

David -Original Message- From: Julian Kerr [mailto:[EMAIL PROTECTED] Sent: Monday, July 04, 2005 1:25 AM To: Struts Users Mailing List Subject: Re: How to disable URL rewriting for session id? Ahh, the problem spreadeth... also need to use plain old forms, which means no struts help there e

Re: How to disable URL rewriting for session id?

struts-html.html#link says " URL rewriting will be applied automatically, to maintain session state in the absence of cookies. " Can you do URL-rewriting-in-reverse on the front end, and strip off the ;jsessionid on the way in, before it causes a problem? Otherwise a

Re: How to disable URL rewriting for session id?

http://struts.apache.org/userGuide/struts-html.html#link says " URL rewriting will be applied automatically, to maintain session state in the absence of cookies. " Can you do URL-rewriting-in-reverse on the front end, and strip off the ;jsessionid on the way in, before it causes a prob

Re: How to disable URL rewriting for session id?

Michael Jouravlev wrote: On 6/30/05, Julian Kerr <[EMAIL PROTECTED]> wrote: The html:link tag automatically applies URL rewriting to maintain session state in the absence of cookies. Is it possible to disable this feature? Have you tried <%@ page session="false&qu

Re: How to disable URL rewriting for session id?

On 6/30/05, Julian Kerr <[EMAIL PROTECTED]> wrote: > The html:link tag automatically applies URL rewriting to maintain > session state in the absence of cookies. Is it possible to disable this > feature? Have you tried <%@ page session="

How to disable URL rewriting for session id?

Dear All, The html:link tag automatically applies URL rewriting to maintain session state in the absence of cookies. Is it possible to disable this feature? [I'm using Resin in a shared environment. Resin considers the sessionid as part of the URL address, and hence I get 404 e

Re: Using Apache URL Rewriting with Struts?

Jonathan Corbin wrote: Is there a better way to accomplish this? Or am I stuck with Struts hacks for the time being? You could try rewriting the url in your appserver instead. Haven't got time to try it myself yet though :(. http://tuckey.org/urlrewrite/ -- Robin Ericsson http://robin.vill.ha.k

Using Apache URL Rewriting with Struts?

a little, and disabling session cookies (instead using session tracking through URL rewriting, putting jsessionid=blah on the end of every url). I'd like to avoid using a modified version of struts, however, so I'm wondering if there is a better way to accomplish URL rewriting. The

url rewriting fails with multipart/form-data

ither - Have tomcat be able to extract jsessionid from url when it is a multipart POST - Have tomcat use exclusively cookies (no url rewriting) This is a big problem here as it prevent us to send emails with links to fileupload struts form where authentification is required. Thanks for help i

url rewriting problem

(i don't think this made it through the first time i sent it, so i'm trying again. apologies if you get this twice.) i'm getting some weird problems with url rewriting in a struts 1.2.4 webapp. specifically, the urls generated by the form, link, and rewrite tags have an extra &

Re: url rewriting

On Tue, 20 Jul 2004 09:08:39 -0700, Jim Barrows <[EMAIL PROTECTED]> wrote: > > > > > I think you can use url rewriting, and that won't put the > > jsessionid on it. > > > > It's sort of the other way around :-). The "jsessionid" paramete

RE: url rewriting

> -Original Message- > From: Craig McClanahan [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 20, 2004 8:57 AM > To: Struts Users Mailing List > Subject: Re: url rewriting > > > > I think you can use url rewriting, and that won't put the > jsessionid

Re: url rewriting

> I think you can use url rewriting, and that won't put the jsessionid on it. It's sort of the other way around :-). The "jsessionid" parameter is the *result* of performing URL rewriting. If your browser client is using cookies, this will only show on the first requ

RE: url rewriting

> -Original Message- > From: news [mailto:[EMAIL PROTECTED] Behalf Of j h > Sent: Tuesday, July 20, 2004 7:41 AM > To: [EMAIL PROTECTED] > Subject: url rewriting > > > Is there a way to disable the jsessionid from being appended > to the url when a > f

url rewriting

Is there a way to disable the jsessionid from being appended to the url when a form is submitted? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

url rewriting

Hi, I'm using the following code : logout The html code I get is the following : logout When I read the explanation about how the tag works, I understood the content of href attribute should be something more like : "http://www.myserver.com/lec/logoutAction.do"; I do have an

Re: URL Rewriting

Why don't you rewrite UrlRedirect to UrlForward? At 10:34 PM 5/23/2004, Morten wrote: Hi! We are using Struts 1.1 and Tomcat 4.1.x at our company. We are considering to separate our urls from our struts configuration. Instead of /news.do?articleid=43 we would like the url to look like this: /news/a

URL Rewriting

Hi! We are using Struts 1.1 and Tomcat 4.1.x at our company. We are considering to separate our urls from our struts configuration. Instead of /news.do?articleid=43 we would like the url to look like this: /news/article/43. Furthermore the generated html should contain urls of the form /news/artic