first I'd like to say thanks for your work, it's really nice to see how Virgo is growing in maturity and functionality each time a new milestone/major release is released.

For the latest milestone release I have some questions and notes:

1. Now that there is telnet and SSH support there are four configuration files to configure host and port for these two services. I personally don't like that and think that one configuration file should be enough to configure telnet and SSH both for kernel and user region. What do you guys think about that? Are there any technical reasons that don't allow one config file?

Moreover there are two files now for the user credentials (org.eclipse.virgo.kernel.users.properties and the generated store file). Again multiple configuration files for a similar purpose (and one has clear text passwords in it while the other one is storing some kind of hash (SHA-1?) for the password). Same question as before - is it possible to merge these into one config file?

Let me even go one step further. I personally like the idea of having just one (or at least only a few) files where all the config stuff is done. Would that be possible? I thought of maybe one big XML configuration (and an XSD file for code completion and validation). What are your thoughts on this?

2. In this blog article there is this note that the Jetty version of Virgo is not to be considered a prototype anymore. Now I'm wondering if there are any reasons why I should choose one servlet container version over the other. I know that some of the Spring guys work on Tomcat so my guess is that there is more experience available when it comes to the question on how to integrate Tomcat into Virgo the best way possible than with Jetty. Is this assumption correct?

2. In this blog article there is this note that the Jetty version of Virgo is not to be considered a prototype anymore. Now I'm wondering if there are any reasons why I should choose one servlet container version over the other. I know that some of the Spring guys work on Tomcat so my guess is that there is more experience available when it comes to the question on how to integrate Tomcat into Virgo the best way possible than with Jetty. Is this assumption correct?

Correct. Virgo Jetty Server is provided so that Jetty users who want to use Virgo are not forced to migrate to Tomcat, e.g. for configuration. It has some known limitations, like it doesn't yet support WAR files. But we felt the package, such as it is, was ready for exposure.

1. Now that there is telnet and SSH support there are four configuration files to configure host and port for these two services. I personally don't like that and think that one configuration file should be enough to configure telnet and SSH both for kernel and user region. What do you guys think about that? Are there any technical reasons that don't allow one config file?

Moreover there are two files now for the user credentials (org.eclipse.virgo.kernel.users.properties and the generated store file). Again multiple configuration files for a similar purpose (and one has clear text passwords in it while the other one is storing some kind of hash (SHA-1?) for the password). Same question as before - is it possible to merge these into one config file?

Let me even go one step further. I personally like the idea of having just one (or at least only a few) files where all the config stuff is done. Would that be possible? I thought of maybe one big XML configuration (and an XSD file for code completion and validation). What are your thoughts on this?

While I agree having a single configuration file is much more convenient we are a bit limited here from technical perspective.

As you probably know we consume the new shell from the Equinox project.

The shell itself is configured from a Configuration object in ConfigAdmin. The properties in this configuration cannot be bound with Virgo specifics, as this shell can run in pure Equinox, in single or multiple region environment so it needs to be flexible and with no knowledge of the surrounding environment.
That's why it currently searches for its predefined configurations and knows nothing about regions, therefore the multiple configuration files for each region.

Also the SSH support is optional and most likely when Equinox gets the new shell it won't support SSH, only telnet. And because the new shell isn't bound with anything Virgo specific it also runs its own user store which is encrypted and optional as is the SSH support. Also I think this is why the configuration was split in two.
I don't know if its possible but maybe we can check if reusing the shell's store is an option.

With that in mind in do believe its possible to merge the SSH and telnet configuration in one file and in some cases the shell will have to ignore the SSH properties. I'll contact a shell committer to discuss that enhancement.

As for having a single configuration file for all shell configurations in Virgo - the current situation is a Virgo implementation detail and I think it can be done in a single file even though this will require more than just minor changes in Virgo, but also some post processing before uploading to the correspoding ConfigAdmins.

I think I'm not too fond of the single master configuration file as I've seen what abominations these tend to become as a project evolves and grows. Personally I like how the configuration responsibility is split in Virgo into areas.
But discussions are a good thing and maybe there are arguments I haven't thought of so if we get convincing opinions in favour of this one we may choose to go there.

Thank you for the confirmation. I think we'll continue using the Tomcat version then.

@Borislav

Thank you for the information as well as raising the bugs. I see the point regarding your concerns towards one big config file. I agree that such config files tend to grow over time and might become overly complex. But I think the same concerns are valid if there are lots of different small config files as that can be as confusing and complex as one big config file.

Thank you for the information as well as raising the bugs. I see the point regarding your concerns towards one big config file. I agree that such config files tend to grow over time and might become overly complex. But I think the same concerns are valid if there are lots of different small config files as that can be as confusing and complex as one big config file.

I'm curious what others have to say about this

I think we should avoid conflating kernel and user region configuration in the same properties file. Eventually, I would expect both kernel and user region shells to be disabled by default. Most users would be interested in enabling just the user region shell and they would be able to ignore the kernel shell configuration.

However, there is a duplication issue in having separate telnet and ssh properties files, especially when a host other than the default needs to be specified.