dev@glassfish.java.net

Re: Where should GlassFish Installation create the "default" domain?

From: Markus KARG <markus.karg_at_gmx.net>
Date: Sun, 21 Jan 2007 10:27:22 +0100

I'm a Windows user, so what you will get now is a Windows view of
things. ;-)

The home folder on Windows is user specific. GF is a server product,
that hosts applications that are most often NOT user specific. So that
should not go into the home folder, but it should stay in a machine
specific folder. Most software on Windows is allowing to specify folders
at installation. If nothing specific is told, a subfolder of its
installation folder is used. This is what GlassFish currently does. So
there is no need for a change. If you want to change something, then you
should support defaulting the installation into the
ProgramFiles/Java/GlassFish folder instead of c:\sun*, and use the File
System ACLs to control read and write access to that folder.

Have Fun
Markus



kedar schrieb:
> Folks,
>
> Need a user perspective in this case.
>
> When GlassFish is installed and set up using the setup.xml's,
> the domain (server) where your applications get deployed is
> created in install-dir/domains. This domain is named "domain1".
>
> Domain is what you own. Your applications, your configurations,
> customizations are all stored there. Does it then make more sense
> to store it in your home folder, rather than the folder where
> you install the bits?
>
> One benefit I see with storing your data in your home folder
> is protection against accidental deletion. When you upgrade
> GlassFish from build to build or from release to release, you of
> course don't want to recreate domain, redeploy apps etc. Every
> subsequent build should be able to smoothly run the applications
> that were deployed/run with previous builds.
>
> This is kinda similar to other softwares where your configuration
> (user data, if you will) is stored at one place and the bits
> are stored in some system folders (e.g. "Program Files" in case
> of Windows).
>
> Are there other benefits? Would this be something that we should
> attempt? This should help smoother upgrade experience, because every
> new build/release just "runs" your applications without any hassle.
>
> Are there any cons?
>
> Please discuss.
>
> Thanks,
> Kedar
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>