I'm going to agree with Bob here. Reducing complexity is a top level goal IMO. Using a different app for different URLs seems somewhat familiar to the MVC anti-pattern.
The domain name used to access a system ought to be considered part of the presentation layer (like an interface vs an implementation) and therefore should not inform how an application is assembled. John On Sat, Aug 1, 2015 at 11:01 PM, Bob Harner <bobhar...@gmail.com> wrote: > Stephen, > > An contrary viewpoint... > > There is really nothing wrong with having two web front ends for a single > web app if you handle authentication in a clean and reliable way. Sure, the > conventional wisdom is to split the app into 3 parts (clients, partners, > and a common JAR containing classes that both share) as Dimitri and Thiago > recommend. However, doing so does add significant infrastructure > complexity: > > 1) You have to maintain three projects (or a Maven multi-module project if > you're using Maven) instead of one. > 2) You'll have two different app servers to configure & maintain. > 3) You'll probably need to maintain database credentials in two different > places. > 4) You can't use Tapestry's Live Class Reloading on any class in the common > JAR (e.g. Tapestry IOC service implementation classes). > 5) If you use an automated build server like Jenkins then you'll have to > set up and maintain triple the number of jobs. > 6) Your build process will be slower and more error prone because you'll > often have to build the common JAR before building and deploying you'll > have different log files. > > On Thu, Jul 30, 2015 at 5:05 PM, Stephen Nutbrown <steves...@gmail.com> > wrote: > > > Thanks for the advice. I'll go with this. I will look into how to create > a > > module which I can use in both webapps, and I will need to find a > reliable > > way to connect both of the webapps to the same (amazon RDS) database > > without running out of connections etc (I believe this will just mean > > working with the hibernate config). > > > > In the long run, I do think this is the best approach, although as we > > currently have ~70 pages and around 10 services, i'm sure you can imagine > > why I was a little hesitant to start chopping things out of it, but I > > suppose this number of pages and services is all the more reason to split > > it into two webapps. > > > > One benefit of having a single webapp is hosting prices, as it's with > > Amazon on an EC2 instance - it means we will now have two EC2 instances > > unless I can figure out a way to get them both on one - I am sure this is > > possible but perhaps not particularly easy. > > > > Thanks again for all the help - I know what I have to do, it's just going > > to be quite an effort (no fault of T5 - it's a huge change to the > direction > > of the project). > > > > > > > > On 30 July 2015 at 21:45, Norman Franke <nor...@myasd.com> wrote: > > > > > Or have two instances of the same application with some configuration > > > parameter to tell it which version it should be. > > > > > > Norman Franke > > > Answering Service for Directors, Inc. > > > www.myasd.com <http://www.myasd.com/> > > > > > > > > > > > > > On Jul 30, 2015, at 4:12 PM, Thiago H de Paula Figueiredo < > > > thiag...@gmail.com> wrote: > > > > > > > > On Thu, 30 Jul 2015 16:19:50 -0300, Dimitris Zenios < > > > dimitris.zen...@gmail.com> wrote: > > > > > > > >> I would definitely split it into two web applications with a common > > > >> tapestry module.Any other way will result to a mess. > > > > > > > > Agreed, as that's basically two distinct web applications which just > > > happen to be in the same server, even if they have shared code. > > > > > > > > If it was the same web application but with different domains and > data, > > > you can use URL rewriting to make them work out of the same webapp > > > instance. My (incomplete, but working) Eloquentia blogging engine does > > > that: https://github.com/thiagohp/eloquentia. It can serve two or more > > > different blogs, each from its own different domain, in the same webapp > > > instance. It can also have subdomains for tags (domain.com for general > > > stuff and tapestry.domain.com for tapestry-specific posts, for > example). > > > > > > > > -- > > > > Thiago H. de Paula Figueiredo > > > > Tapestry, Java and Hibernate consultant and developer > > > > http://machina.com.br > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > > > > For additional commands, e-mail: users-h...@tapestry.apache.org > > > > > > > > > > > > >
