-
1. Re: XML File Deployments
dmlloyd Sep 2, 2010 3:04 PM (in response to jason.greene)Sounds like you nailed all the important points to me I think the domain management philosophy directly opposes MC-style deployable XML files.
-
2. Re: XML File Deployments
aloubyansky Sep 2, 2010 3:54 PM (in response to jason.greene)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.
-
3. Re: XML File Deployments
starksm64 Sep 3, 2010 12:20 AM (in response to jason.greene)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.
-
4. Re: XML File Deployments
jason.greene Sep 3, 2010 10:12 AM (in response to 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.
-
5. Re: XML File Deployments
dmlloyd Sep 3, 2010 10:31 AM (in response to aloubyansky)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.
-
6. Re: XML File Deployments
aloubyansky Sep 3, 2010 5:24 PM (in response to dmlloyd)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).
-
7. Re: XML File Deployments
brian.stansberry Sep 7, 2010 2:35 PM (in response to aloubyansky)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.