Not quite that I know of - other folks may know more. Containers are
a lightweight approach to virtualization. Containers are really about
application isolation on the same Solaris instance and not about
running multiple instances of an OS. With many other virtualization
technologies, you run a new instance of an OS. In some cases that is
necessary and appropriate, in some cases it is not.
Zones leveraged knowledge gained from from FreeBSD Jails.
On May 25, 2007, at 9:35 AM, Daniel Cavalcanti wrote:
> Is there an equivalent of these Containers on the Linux world?
>
> On 5/25/07, John Clingan <John.Clingan_at_sun.com > wrote:
> I've got a good chunk of experience doing this. Solaris Containers
> are your friend.
> http://www.sun.com/bigadmin/content/zones/index.html
>
> Each customer can have a dedicated container, therefore you can run
> many customers on the same physical server. Each customer is isolated
> from the other and has their own dedicated instance of SJSAS server.
> You can also enforce QoS on each container (network & CPU).
>
> On May 25, 2007, at 8:28 AM, Edson Carlos Ericksson Richter wrote:
>
> > Hi!
> >
> > I'm starting a pilot project offering to small companies the
> > hosting service of JSP/Servlet/JPA based applications on dedicated
> > Solaris + SJAS server.
> > Anyone knows issues on deploying dozens apps on one server?
> > I already seen problems with persistence-units (first app run,
> > second = error), and I expect to solve with latest night build.
> > But other questions that arise: how could I map resources on
> > web.xml/persistence.xml during deployment, so I can direct to
> > correct JNDI names?
> > Example: some developer decide his app will use "jdbc/MyDB" to his
> > JDBC data source. On development server, it's ok. But when it comes
> > to deployment server, I need to change it to "jdbc/App1CompanyA".
> > How could I map this?
> > (same problem apply to mail resources and so on). I don't have
> > access to application source, so I can't edit/recompile.
> >
> > I'll appreciate any help.
> >
> > Regards,
> >
> > Edson Richter
> >
> > <edson.richter.vcf>
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> > For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>