P, Sorry, I'm not sure why GMail included you as well. It should only have gone to the tomcat users listing.
I didn't realize that it was a servlet spec item and a non-tomcat item. I have downloaded SS 2.4 final. That has info on it. I've done a ton of mappings in the web.xml file already for the servlets that already exist for this. If it's more mappings that I need, it shouldn't be an issue. I'll need to read closely then on how filters work. Thanks again for everything again. On Mon, Jun 22, 2009 at 4:40 PM, Pid <p...@pidster.com> wrote: > Josh Gooding wrote: > > This is where my inexperience in tomcat will shine through. > > > > Scrapped all xxx.test.com sub-d's and went with > > test.com/[company<http://test.com/%5Bcompany>id] as the > > way to go. It prevented me from having to edit the server.xml file and > > restart tomcat each and everytime that a company is added / subtracted. > You > > are correct, the app [except database access (each co. get's it's own > > schema, and it's own file storage directory) and a few files (context.xml > > and web.xml)] is the exact same for everyone. > > > > All front ends (that the user views) can be the exact same for right now. > > Servlet filters though aren't they defined in the server.xml file? If > they > > are that defeats the purpose of everything being created without a > restart. > > Am I off base myself here? I'm looking in the docs for filters but not > > coming up with much. > > > Any advice? > > 1. Just reply to the list, I'm on it, I don't need a separate copy too. > > 2. It's Servlet Spec stuff, not Tomcat. Implement javax.servlet.Filter > and add mappings* in each web.xml. Make sure it's the first one in the > web.xml if other Filters or Servlets rely on anything it does. > > Filters are extremely useful, if used carefully. Do extra reading about > how they work. > > E.g. use getServerName() as a key for an object, set it as a request > attribute and then retrieve it in the HTML. > > @Override > public void doFilter(ServletRequest req, ServletResponse res, > FilterChain chain) throws IOException, ServletException { > > HttpServletRequest hreq = (HttpServletRequest) req; > HttpServletResponse hres = (HttpServletResponse) res; > > // do stuff > > ClientConfig config = yourFuncToGetConfig(hreq); > hreq.setAttribute("clientconfig", config); > > // do other stuff > > chain.doFilter(hreq, hres); > > } > > ... and in your html, assuming your ClientConfig object has a > getCssUrl()... > > > <link href="${requestScope.clientconfig.cssUrl}" rel="stylesheet" > type="text/css" /> > > etc. > > p > > > > * Filter mappings are an exercise for the reader. GIYF. > > > > > - Josh > > > > On Mon, Jun 22, 2009 at 3:54 PM, Pid <p...@pidster.com> wrote: > > > >> (Late arrival, skimmed the thread, apologies if I'm off the mark). > >> > >> Given the assumption of different data per user/client/company, is the > >> app identical for each company, bar aesthetic changes like images? > >> > >> > >> If so, with minor tweaks to your HTML, a servlet Filter which processes > >> the HttpRequestServlet.getServerName() field (to get the subdomain) > >> could look up the URL of a CSS file in a client DB, which is then > >> included in the document head. > >> > >> CSS is plenty powerful enough to make all the visual changes you'd need, > >> if the underlying HTML is the same. All subdomains would need to run on > >> the default host, but that would save you the effort of hard coding > >> Hosts each time. > >> > >> You could also extend this to look up a more complex client object, > >> (still based on server host name), with config info, perhaps even a > >> unique DB name for use elsewhere. > >> > >> Or not. > >> > >> > >> p > >> > >> > >> > >> > >> Josh Gooding wrote: > >>> Once again (sigh) ..... > >>> > >>> I just got out of my management meeting, they want to know if it can be > >> done > >>> the "other" way, with all companies sharing the core code. I'm not > >> exactly > >>> sure on how I'd even begin to do this. While I made a good point that > A > >> - > >>> it's more secure, and B - it is the better way of doing things, they > did > >>> countered. If we wanted to upgrade the software, it's better to > upgrade > >> one > >>> single install, than to upgrade 50 - 100 clients which takes a large > >> amount > >>> of time. It then becomes a logistical issue. All that aside, would > you > >>> have any clue as to how would I go about starting something like that? > >> I'm > >>> going to check the docs more closely, however, I am not confident that > I > >>> will find anything like that in there. > >>> > >>> - Josh > >>> > >>> On Wed, Jun 17, 2009 at 10:10 PM, Caldarale, Charles R < > >>> chuck.caldar...@unisys.com> wrote: > >>> > >>>>> From: Josh Gooding [mailto:josh.good...@gmail.com] > >>>>> Subject: Re: Just a few questions on my Tomcat Configuration > >>>>> > >>>>> Maybe each company would have a customized few pages each with > >>>>> their own directories, tied to their own schema, etc, but point > >>>>> to the core application in another directory. Everyone would > >>>>> see their own front ends, but use a common "framework" in the > >>>>> backend maybe? > >>>> That's quite a bit more than I was referring to, and I find it > unlikely > >>>> that any company would want its processing to be shared with others in > >> the > >>>> same webapp. Better to have separate deployments for each, even if > the > >>>> underlying webapp is identical in each instance. > >>>> > >>>>> Are those API's part of teh standard Tomcat docs? > >>>> The ones I referred to for adding and removing <Host> elements > >> dynamically > >>>> are part of the Embedded class: > >>>> http://tomcat.apache.org/tomcat-6.0-doc/api/index.html > >>>> > >>>> The doc states that components can be added and removed on the fly, > even > >>>> after the start() method has been invoked. I've never tried it. > >>>> > >>>> - Chuck > >>>> > >>>> > >>>> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE > PROPRIETARY > >>>> MATERIAL and is thus for use only by the intended recipient. If you > >> received > >>>> this in error, please contact the sender and delete the e-mail and its > >>>> attachments from all computers. > >>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >>>> For additional commands, e-mail: users-h...@tomcat.apache.org > >>>> > >>>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
