Thanks!
On 5/25/07, Jamey Wood <Jamey.Wood_at_sun.com> wrote:
>
> Daniel Cavalcanti wrote:
> > Got it.
> >
> > Question. I'm considering open source solution and I haven't followed
> > Solaris in full. I think Solaris is now open source, right?
>
> Absolutely. Go to http://www.opensolaris.org/ to see its open source
> project.
>
> > Are these features shipped with the OS, or do they come separately? If
> > separately, are they open source?
>
> They come with the OS (and thus are open source).
>
> > Also, I can run Solaris on a x86 ISA, right?
>
> Yes. You can run it in 32-bit mode on any x86 machine or 64-bit more on
> x86-64 machines (aka x64).
>
> --Jamey
>
> >
> > On 5/25/07, *Edson Carlos Ericksson Richter* <
> > edson.richter_at_mgrinformatica.com.br
> > <mailto:edson.richter_at_mgrinformatica.com.br>> wrote:
> >
> > Ok, liked Solaris containers idea (zones right?).
> > So, when I create a new Zone, I need a new SJAS running on it?
> > Memory is shared between SJAS instances on different zones?
> > Because I can have apps that need as much as 512Mb of RAM - but
> > not dedicated...
> > For example, what happen if I need to host 100 applications, using
> > 64Mb each. I'll need 100 zones (+one global zone), each with 128Mb
> > allocated to it (about 13 GB of RAM)?
> > (I'm not criticizing, just asking to know what expect me on
> future...)
> >
> > Thanks for directions until now.
> >
> > Regards,
> >
> > Edson Richter
> >
> >
> >
> >
> > John Clingan escreveu:
> >> 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
> >>> <mailto: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 <http://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
> >>> <mailto:users-unsubscribe_at_glassfish.dev.java.net>
> >>> > For additional commands, e-mail:
> >>> users-help_at_glassfish.dev.java.net
> >>> <mailto:users-help_at_glassfish.dev.java.net>
> >>>
> >>>
> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail:
> >>> users-unsubscribe_at_glassfish.dev.java.net
> >>> <mailto:users-unsubscribe_at_glassfish.dev.java.net>
> >>> For additional commands, e-mail:
> >>> users-help_at_glassfish.dev.java.net
> >>> <mailto:users-help_at_glassfish.dev.java.net>
> >>>
> >>>
> >>
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> > <mailto:users-unsubscribe_at_glassfish.dev.java.net>
> > For additional commands, e-mail: users-help_at_glassfish.dev.java.net
> > <mailto: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
>
>