XML File Deployments

[jason.greene]

In past discussions it seemed unlikely that we would support XML deployments. This was for the following reasons:

1. The file would have to specify module configuration inline for it to even work (there is no more flat classpath in AS7) [and be polluted with other various AS internal info]
2. Configuration is no longer a "deployable" notion. The domain config contains all admin focused configs and supports runtime updates. This includes which subsystems are available
3. Code must be associated with it to really be worth being a deployment, so why not just bundle the code with the deployment? Even some kind of templating/scripting would likely be better represented as multiple files.
4. Everything you can do with an XML file can be done with an archive containing the XML file

Is there a strong case for it that was missed?

[dmlloyd]

Sounds like you nailed all the important points to me  I think the domain management philosophy directly opposes MC-style deployable XML files.

[aloubyansky]

The reason why it is convenient is that when you have a common library which is stable (or mostly stable and if it needs an update then all the services based on it need the update) and want to configure multiple services (i.e. create multiple instances) with different configuration.

So if you bundle the library with each deployment then:

- to modify the config you need to repackage;

- to upgrade the common library you'll need to repackage all the deployments including it.

[starksm64]

So why not have a deployable configuration fragment that addresses the specification of the module and bean configuration in a DSL more approriate than the full mc syntax. Having multiple deployments of common beans seems like a rather common usecase.

[jason.greene]

OK so the use case that I was missing is that we ship some kind of simple varia/example/one-off services which are more like application utilities then subsystems (note that the domain model allows for adding custom subsystems). At which point we have full control over the xml, and its superfluous to wrap a single xml file in a jar.

[dmlloyd]

Alexey Loubyansky wrote:

The reason why it is convenient is that when you have a common library which is stable (or mostly stable and if it needs an update then all the services based on it need the update) and want to configure multiple services (i.e. create multiple instances) with different configuration.

So if you bundle the library with each deployment then:

- to modify the config you need to repackage;

- to upgrade the common library you'll need to repackage all the deployments including it.

Do you have some more specific examples?  I don't see how this justifies single-file deployments.  It seems that at most this implies the need for deployment descriptor types (inside an archive) to override settings.

[aloubyansky]

David Lloyd wrote:

Alexey Loubyansky wrote:

The reason why it is convenient is that when you have a common library which is stable (or mostly stable and if it needs an update then all the services based on it need the update) and want to configure multiple services (i.e. create multiple instances) with different configuration.

So if you bundle the library with each deployment then:

- to modify the config you need to repackage;

- to upgrade the common library you'll need to repackage all the deployments including it.

Do you have some more specific examples?  I don't see how this justifies single-file deployments.  It seems that at most this implies the need for deployment descriptor types (inside an archive) to override settings.

If you have a library of classes that can be used to create a set of services, JMX beans, other managed beans, EJBs, etc, this library can be put into the servers classpath and then by deploying just deployment descriptors you can create new services, managed beans, EJBs, etc.

This feature was added previously to avoid creating JARs that contain only service XML files. Plus, with hot deploy tracking the file modifications it's like WYSIWYG editor (after the save of course).

[brian.stansberry]

There's been a lot of discussion on this thread on why we would support this; i.e. what the use case is.

I think it would be educational to hear more about why we wouldn't; i.e. what are the problems it causes.

At this point we have on the pro side IMHO kinda abstract use cases (I'd love to hear an actual concrete example where declaring subsystems wouldn't suffice) while on the con side it's unclear.