Since you are creating new pages for each OEM, I think I would prefer to embed the OEM value in the pages themselves. Then your 3 step process can be replaced with just the 3rd step, and you don't need to restart your container.
If you do go with your approach, you may want to determine if the container is smart enough to recognize the same servlet across multiple aliases. Otherwise you are going to have unnecessary servlet instances. Seems like Tiles may fit in well here so you could possibly reuse some of the pages across OEMs. /Ross -----Original Message----- From: Parimi Srinivas [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 06, 2002 9:40 PM To: 'Struts Users Mailing List' (E-mail) Subject: Design issue Hi all, I want to validate my design. One of our applications caters to 3 OEM's. Application has three business functionalities and each business functionality has 4 to 5 screens on an average. The only difference between OEM's is LOOK and FEEL of the application. To achieve different LOOK and FEEL for OEM's, OEM names are mapped to 3 different aliases ( OEM1, OEM2 and OEM3) of action servlet. Mappings of OEM name and action servlet alias are stored in an xml mappings file. When users belonging to a particular OEM access application for the first time, OEM name is retrieved depending up on the action servlet alias and stored in a new session. Appropriate JSP's are processed depending up on the OEM name stored in the session. There is no user authentication screen in the application. If a new OEM is added to the application, following steps are followed - 1. a new servlet alias is created 2. Create a mapping between OEM name and action servlet alias. 3. Create JSP pages for new OEM. Any suggestions, -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
