tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pid...@pidster.com>
Subject Re: Just a few questions on my Tomcat Configuration
Date Mon, 22 Jun 2009 20:40:21 GMT
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 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.Caldarale@unisys.com> wrote:
>>>
>>>>> From: Josh Gooding [mailto:josh.gooding@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-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message