geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Denes" <de...@ppgia.pucpr.br>
Subject RES: RES: "Virtual Hosting"
Date Fri, 08 Aug 2003 17:50:58 GMT

> -----Mensagem original-----
> De: Aaron Mulder [mailto:ammulder@alumni.princeton.edu]
> Enviada em: sexta-feira, 8 de agosto de 2003 15:37
> Para: geronimo-dev@incubator.apache.org
> 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:ammulder@alumni.princeton.edu]
> > > Enviada em: sexta-feira, 8 de agosto de 2003 13:08
> > > Para: geronimo-dev@incubator.apache.org
> > > 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
> >


Mime
View raw message