Sharing look/feel across webapps
hi all.. We're creating several web applications which must share a common look/feel. We have thought of combining them into a single webapp - this will work, but requires a convoluted install/upgrade/uninstall strategy. I suspect that objects kept in the session context will persist across apps on the same server, and the CLASSPATH could hold any required classes for tags et al, but i'm not sure if tag library declarations or includes of JSP pages/CSS style sheets across app boundaries would work. Does anyone have a useful strategy to solve this problem? thanks! david aiken
RE: MVC problem
That sounds workable.. i looked for an archive of this newsgroup but didn't have any luck - do you know where the relevant section in the JSP/servlet spec is? thanks! david -Original Message- From: Mike La Budde [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 30, 2000 10:54 AM To: [EMAIL PROTECTED] Subject: Re: MVC problem I believe one solution offerred previously on this list (thank you Craig!) was to place all of your .jsp pages underneath /WEB-INF (e.g. /WEB-INF/jsp/...) Since these can never be served up (goes against the jsp/servlet spec) HTH, Mike At 11/30/2000 10:20 AM -0600, you wrote: hi all.. We're hitting a problem with the MVC approach in tomcat. Our controller is designed to intercept all requests for URLs within our web application so that it can handle internationalization and security checks centrally. The problem is as follows: - the controller servlet registers interest in URLs of the form '*.jsp' - a request for 'a.jsp' arrives and the controller checks security and negotiates the locale settings - the controller includes the contents of 'a.jsp' in the response At this point it seems that tomcat takes over. Unfortunately, it doesn't retrieve the contents of the page - it just resubmits the request to the controller again, resulting in an endless loop. This also occurs for a 'forward'. Not good. One of the workarounds is to use URLs of the form '.do' to request page content. This allows the controller to forward to a .jsp URL without getting into a loop. The problem is that someone who knows the structure of the www site can submit requests for '.jsp' directly and bypass any security checks. The obvious workaround for this is to put tags into the .jsp pages and java calls into any servlets to perform the security check - but this negates any advantage to the MVC approach (and forces page/servlet developers to remember to place checks into all of their content). We're probably missing something - it seems difficult to believe that the MVC approach has such a fundamental flaw. thanks! David Aiken BMC Software
MVC problem
hi all.. We're hitting a problem with the MVC approach in tomcat. Our controller is designed to intercept all requests for URLs within our web application so that it can handle internationalization and security checks centrally. The problem is as follows: - the controller servlet registers interest in URLs of the form '*.jsp' - a request for 'a.jsp' arrives and the controller checks security and negotiates the locale settings - the controller includes the contents of 'a.jsp' in the response At this point it seems that tomcat takes over. Unfortunately, it doesn't retrieve the contents of the page - it just resubmits the request to the controller again, resulting in an endless loop. This also occurs for a 'forward'. Not good. One of the workarounds is to use URLs of the form '.do' to request page content. This allows the controller to forward to a .jsp URL without getting into a loop. The problem is that someone who knows the structure of the www site can submit requests for '.jsp' directly and bypass any security checks. The obvious workaround for this is to put tags into the .jsp pages and java calls into any servlets to perform the security check - but this negates any advantage to the MVC approach (and forces page/servlet developers to remember to place checks into all of their content). We're probably missing something - it seems difficult to believe that the MVC approach has such a fundamental flaw. thanks! David Aiken BMC Software
