> -----Mensagem original----- > De: Aaron Mulder [mailto:[EMAIL PROTECTED] > Enviada em: sexta-feira, 8 de agosto de 2003 15:37 > Para: [EMAIL PROTECTED] > Assunto: Re: RES: "Virtual Hosting" > > I agree that what you describe can be a handy feature, with two > caveats: > > - it needs to be easy to change all relevant ports so you can run 2 > configs without them conflicting by default
I think that this can be solved or by assuming that this is an administration issue or by creating some kind of proxy that will listen in the default port and redirect the request to the proper service implementation (can't tell if this can be done for all J2EE stack components). > > - it would be nicer if all the common code was shared across > configuration dirs, instead of (for example) having a full servlet engine > in each config dir. In other words, let's put all the config files in > there but leave the bulky code elsewhere. AFAIK this can be done by the classloader hierarchy (as in Tomcat). So, one could install the various J2EE components in a common place and configure each server to use the implementation that it wants to. > > However, I'm really suggesting we implement this within the VM, > whereas the above works by running multiple VMs. If you want to run > multiple VMs, you can always just install the product twice. I prefer to > also have the option to run apps sandboxed in the same VM. Granted you > wouldn't be able to run different apps with different server components > (EJB/Web container, etc.) this way, but I think that's OK. Don't agree with the idea of installing the product twice because of the common services configuration described above, and because this would be a really ugly solution :), but I think that the two approaches can live together with no problems. Besides, I�m not arguing to separate the servers by separating the VMs of each server, although this sound like a good solution to me, if the VM's footprint don't become a issue to worry about. I'm just saying that creating several server directories is better than assuming a each-ear-is-a-separate-application policy or creating a config file to say how the ears are grouped. Denes > > Aaron > > On Fri, 8 Aug 2003, Denes wrote: > > For this kind of feature, I think that an approach like JBOSS, where you > > can define several server configurations based on directories is better, > > because the sandbox will have to deal with several server issues like > > where is the CMP Database, what is the cluster configs and, as Geronimo > > will be fully plugable, what implementations of each J2EE stack > > component it will want to use. > > > > Besides, this approach has the interesting feature that I can put > > various J2EE applications in the same sandbox, if I want to. > > > > Not sure if JBoss has a different JNDI tree for each server > > configuration when you have several JBoss instances running in the same > > server; but this is a key issue for a feature like that. > > > > Denes > > > > > > > -----Mensagem original----- > > > De: Aaron Mulder [mailto:[EMAIL PROTECTED] > > > Enviada em: sexta-feira, 8 de agosto de 2003 13:08 > > > Para: [EMAIL PROTECTED] > > > Assunto: Re: "Virtual Hosting" > > > > > > On Fri, 8 Aug 2003, Justin Ju wrote: > > > > just like server cluster, but some environment context may be shared > > > among > > > > all these applications? > > > > > > Ideally, it would appear to each application that it was the > > only > > > application running in the server, despite the fact that there may > > > actually be 3 or 4 or a dozen apps running in the server. So if an > > > application crawls JNDI, it will see nothing but its own stuff. If > > three > > > applications each declare a DB pool called "Database", the bindings > > won't > > > fail or replace other bindings, but instead each app will see only its > > own > > > DB pool. If a user can log in to application A (and it's JNDI space), > > > that does not mean the user can log in to application B (or its JNDI > > > space). Like virtual hosting, in the sense that as far as each app is > > > concerned it's the only app, whereas under the covers there may be > > loads > > > of them. > > > > > > Aaron > >
