JBossDeveloper

Brian Stansberry wrote:

 

The same basic question applies to any system property passed in to ServerManager via run.sh; whether they propagate through to the individual servers or whether they stop at the ServerManager and anything that goes to the Server needs to be expressed in domain.xml or host.xml.

I'd say properties passed in to ServerManager via run.sh should affect only the ServerManager process.

The schema already allows to specify system properties on different levels to cover domain, server-group and individual servers. Except the ServerManager, actually.

AFAIU, if we allow system properties passed in through run.sh propagate to the servers then there will be no way to specify a system property that would affect the ServerManager process only?

Brian Stansberry wrote:

 

One thing we support in AS 4/5/6 (and probably earlier) is the -P or --properties command line switch where users can pass in system properties in bulk via a URL to a properties file.

 

I've been working on ProcessManager/ServerManager and have added support for reading such a command line switch in that code. But it's unclear how such a command line switch should be applied to the servers; should it be passed through to the servers, or just be used by the ServerManager?  When you execute run.sh, you're fundamentally starting a ServerManager process.

 

So, two possibilities:

 

1) The SM passes through to any Server process any URL that was passed in to it via --properties.

 

2) We add an child element to jvm where the user can provide the URL. The SM when it prepares the command to launch the Server sees that child element and passes that value through to the Server process.

 

The latter allows different servers to use different properties files. The main advantage to the former is if the ServerManager and all the Servers should use the same properties file, it skips some XML. But IMHO that advantage isn't worth the confusion, so I vote for #2.

I like the 2nd as well.

Actually, external property file may complicate things in a way that, I guess, it's not managed? I.e. will the same management tools be able to access and write to it? If not then the admin won't get the whole picture by just looking at the admin interface.

Another thing, the same property could be present in the properties file and in domain/host.xml. Then we need to agree which overrides which.

Brian Stansberry wrote:

 

Also, the schema defines a <system-properties> element as a child of <jvm> and also allows such an element as a child of domain, host, server.

 

I think this is fine, although needs good documentation. My handling of this is:

 

1) Any system-properties that are children of jvm are passed as arguments to java when the Server process is created. These are analogous to properties an AS 5/6 user would append to $JAVA_OPTS in run.conf. The purpose of such properties is to set things that the JVM needs to know right away.

 

2) Properties that come from via the direct child elements of domain/host/server are passed as args to the Server's main class. These are analogous to properties an AS 5/6 user would pass as args to run.sh.

 

An alternative to 2) is to not pass them as args to the Server main class but instead wait until the ServerManager sends the full configuration object to the new Server; let the new Server read them from the configuration object. That would be cleaner for an embedded use case, where there is no call to a main() involved. Only issue is if anything that goes on in the primordial bootstrap of the Server can be configured via a system property, said property would need to be specially handled and sent as an arg to the Server's main class.

 

(The "primordial bootstrap" is the portion of the Server boot that takes it to the point where it has established communication with the ServerManager and is therefore ready to be given it's configuration.)

This makes perfect sense to me.