Reinstate the Creation of Domain for GlassFish V3

Introduction

The way V3 (TP2) works is, a basic domain is created as part of distribution. The "formal" create-domain process is not available. Some snapshot of domain.xml and other files is taken and the domain's directory structure is created. The file-layout of the domain remains intact. It is as if some domain was created with config, config/domain.xml, config/server.policy, etc. at some point in time and it was zipped up as a base glassfish-10.0 distribution.
We need to reinstate the create-domain command that creates this basic configuration with some flexibility. For TP-2, since we are having web-bundle, we can use the developer profile domain.xml template and apply certain token replacement to it to get the desired configuration. More configuration options are welcome.

Tasks to be done

Introducing Templates (Done? - No)

Currently, if you see the distributions, <ws>/v3/distributions/target/glassfish/lib does not contain templates. We need to introduce at least something like following structure (Note: This should evolve):

|---- lib
      |---- templates
               |---- common
                        |---- domain.xml.template (a template for TP-2. We will discuss that should stay and how should it be, for now copy V2/dev profile).
                        |---- default-web.xml (default web-tier configuration)
                        |---- cacerts.jks (server's default trusted ca's -- these are standard, just copy from V2)
                        |---- logging.properties (this is new).
                        |---- docroot
                                      |---- en (locale, en being default)
                                             |---- index.html (much improved as compared to V2, talk to docs people and work with them).
                                             |---- about.html (tells more about the product, lots of room for creativity here).
                                      |---- ja ...

Finalize the Syntax (Done? - No)

As far as possible, the syntax should be kept the same. There is again, lot of room for introducing something that was missing in earlier command. One thing I'd definitely keep is --profile as it gives us some flexibility to choose a particular template. The current syntax is:

Usage: create-domain [--user admin] [--adminport port_number] [--terse=false] [--echo=false] [--interactive=true] 
[--domaindir domain_directory] [--profile profile_name] [--template domain_template]  [--passwordfile filename ] 
[--instanceport port_number] [--savemasterpassword=false] [--domainproperties (name=value)[:name=value]*] 
[--portbase portbase] [--savelogin=false] [--checkports=true] domain_name

I think we can retain most of these and introduce more.

Finalize the Tokens used in domain.xml.template (Done? - No)

Massage the domain.xml.template to decide on some of the tokens used, e.g. %

Change the FileLayout to match the above (Done? - No)

Reach a situation where existing (V2) PEFileLayout (rename it to DomainFileLayout or something more appropriate) can be retrofitted to the above structure. You can get rid of most of the unwanted things.

Coordinate with Paul Davies/Doc team about index.html and about.html (Done? - No)

These go to the docroot of the created domain. We can consider some token replacement in these files. Look at how we can make these files really useful and very informative.

Finalize the domain's directory structure/layout (Done? - No)

---- domain-folder
           | ---- config
                    | ---- domain.xml
                    | ---- default-web.xml
                    | ---- keyfile
                    | ---- admin-keyfile
                    | ---- server.policy
                    | ---- logging.properties
           | ---- bin
           | ---- logs
           | ---- docroot
           | ---- applications (don't create the V2-like structure underneath)
           | ---- autodeploy

Actual Tasks (Done? - No)

1. Create the directory structure for the domain.
2. Pick the right templates, token-replace if required and copy them across to domain. The template chosen should be profile aware. You can reinstate XSLT-support if desired, but it is not required at the moment.
3. Talk to Security Team about keyfile. The admin-keyfile should contain the secure one-way hash of the admin user and admin password. Refactor that logic to depend on security code. We depend on FileRealm class in security code. This would give rise to appropriate dependencies.
4. Bonus: Create a new server certificate. This requires quite some refactoring. Basically, we copy cacerts.jks as-is and generate the server certificate that goes to keystore.jks anew every time. I can help you with this one.
5. Make sure that domain starts.
6. Add unit tests to the build itself.

Consider Interactivity (Done? - No)

This is mostly for later, but this calls for asking the user in case we want some input, when --interactive is on. Do it after TP-2.

Other tidbits (Done? - No)

Here is an example of where the pluggability would come into picture. Take the example of simple "index.html" that is served at http://host:port when the server starts up. See this thread where the user was confused in V2, as different distributions of GlassFish did not identify themselves by default. All of the servers served "Sun Java System Application Server 9.1 bxx" as the content of their default index.html. Is it possible to distinguish the servers based on their distributions? This might be a pluggable aspect of create-domain functionality.