Packaging application server resources in an EAR

[raydecampo]

Is there a way with JBoss 7 to package application server resources within an EAR?  What I mean are things like data sources, JDBC drivers, mail sessions, etc.; instead of configuring them in standalone.xml, configure and package them within an EAR.

[jaikiran]

Ray DeCampo wrote:

Is there a way with JBoss 7 to package application server resources within an EAR?  What I mean are things like data sources, JDBC drivers,

You can deploy datasources (and JMS queues) from within the application packaging. Here's an example http://www.jaitechwriteups.blogspot.in/2012/02/jboss-as-710final-thunder-released-java.html. However note that such resources are not "managed" - which means that you can't run management operations on them (for example from the CLI) to update their configurations.

[raydecampo]

Thanks for the reference; however I didn't see anything about mail session configuration, security realms or the JMS resources.  Does anyone have any information on those?

[ctomc]

Hi Ray,

you can package any jar you want in your application for instance mail.jar for mail session configuration, hornetq for jms resources and so on and on.

but then your application is responsable for managing all that you do not benefit from application server at all.

Why would you need app server for then? for web server? and nothing more?

--

tomaz

[jbertram]

For JMS destinations see the "Deployment of -jms.xml files" section of https://docs.jboss.org/author/display/AS71/Messaging+configuration.

[raydecampo]

Tomaz, I think you misunderstand.  I do not want to package jar files implementing the functionality, I want to package configuration files.  So, for example, instead of configuring my data sources using standalone.xml (or the CLI or the web interface), they are configured by a *-ds.xml file in my EAR.  I still use the application server facilities for the data source.

I would like to move as much configuration from the application server level to the application as possible.  Then when I bring on a new developer or new environment I can simply deploy the JDBC driver and the EAR and not have to configure the application server first.

[jbertram]

Much of Tomaz's points still stand.  One of the reasons that JBoss AS has moved from a collection of configuration files with little to no real structure and lots of implementation details (e.g. class names in every MBean) to a single configuration file based on well-defined schemas focused on user-facing functionality is because ongoing server maintenance over the lifetime of an application is generally more of "expensive" in terms of resources than the occassional introduction of a new developer or environment.  Of course, one size doesn't fit all so this won't be true in every circumstance, but I personally feel the consolidation/centralization of configuration is a usability win not least because it facilitates a management model where configuration can be changed via one of many different interfaces (e.g. CLI, web console, thin HTTP client, mobile app, etc.) and those changes are reflected immediately in all the other interfaces. 

Packaging server configuration details with the application breaks this model, which (as I understand it) was one of Tomaz's main points.  In other words, the management model doesn't encompass the configuration files you deploy in your EAR.  Such configuration fragmentation is typically fine in early development (which is why we've made it available with caveats), but can become problematic when the application moves to production and needs to be managed for months or years (often by a non-development oriented group). 

It should be possible to quickly set up a new server with most of the necessary environment-specific configuration details by using the CLI in non-interactive mode so that packaging configuration files with the application becomes largely unnecessary even for quick setup in a new environment or for a new developer.  It's not perfect, of course, so we need feedback to make it better.

[raydecampo]

Justin, thank you for your response.  Allow me to provide a rebuttal to some of your points.

In previous versions of JBoss we had many configuration files for the different pieces of functionality.  I recognize that the sheer number of files was probably intimidating to new users.  However my team made good use of this model by keeping the separate files under version control.  Changes made to, for example, the JMS structure were kept independent of the JDBC structure.  If a particular server was hosting multiple applications, there was little if any merging to be done as the files for the new application could simply be added.

You say packaging the configuration files with the application causes problems when moving to production and is managed by a non-development team.  My experience has been that the JEE role of deployer is non-existent in the real world.  The teams managing the servers are generally incapable of configuring the application servers and that falls on the developer. 

Furthermore, there are cases where the configured resources depend on classes in the deployed application (e.g. custom login modules for security domains).  It feels unnatural to place these references in the server-wide configuration file instead of an application-specific configuration file.

You tout the CLI.  For my experience the CLI is frustrating and esoteric.  The syntax used is unlike anything I have ever used.  If I were to write a CLI script to set up the resources for my application, I would lose the schema-based verification you touted in the first paragraph. (Also, there is no reason a multiple file based configuration cannot be schema-based as well.)

As you said, one size does not fit all and perhaps my experiences are not typical.  My experience moving from JBoss 5 to JBoss 7 has been frustrating in that I have not been able to leverage much of my knowledge of JBoss 5 (or 4 or 3).  Also, it seems there is significantly less documentation for JBoss 7 than for previous versions.  Also, little things like an easily-downloaded source bundle and downloadable documentation appear to be missing.

I hope this did not come off as a tirade against JBoss.  I recognize that reasonably people can disagree on these points.  I try to give developers the benefit of the doubt and extend the same courtesy to the JBoss developers.  I hope that others have found the transition to JBoss 7 to be smoother.

[ctomc]

Hi Ray,

Yes i have missunderstood your question in my previous post.

I acutaly now get what your main problem is and why it is important for you. As I was in exacly same position as you are some time ago (before joining Red Hat).

My solution to your problem was not to bundle as much of configurations inside of application deployment as IMO this is beyond bad practice and you end with development configurations on productions servers.

I addressed problem bit different, we had as7 in SCM and had many different standalone.xml configurations (one per project) this way developer all it had to was run AS7 with -c <project-code>.xml

For all our "custom" modules we have created our own jboss modules repository and then just told as7 to also use that one (-mp paramter or %JBOSS_MODULEPATH) this way we made sure that

• we could easaly upgrade version of AS7 with just modifying one config file
• have our own reposirory of modules that can be shared between projects as as7 loads just the one it needs not all of them as it used to be
• as7 configuration files could be part of your project
• and lots more

Furthermore, there are cases where the configured resources depend on classes in the deployed application (e.g. custom login modules for security domains).  It feels unnatural to place these references in the server-wide configuration file instead of an application-specific configuration file.

You know that since 7.1 you can have custom login modules in your application and no need to bundle it into global module?

As you said, one size does not fit all and perhaps my experiences are not typical.  My experience moving from JBoss 5 to JBoss 7 has been frustrating in that I have not been able to leverage much of my knowledge of JBoss 5 (or 4 or 3).  Also, it seems there is significantly less documentation for JBoss 7 than for previous versions.  Also, little things like an easily-downloaded source bundle and downloadable documentation appear to be missing.

This is true, as7 was a complete rewrite and is relativly "new" project, and becouse of that there are still lots of bugs and not as much documentations that there is for previous versions that had same basic configuration since version 3.x all the way till 6.1. Having said that I complety agree that we need and must improve in documentation front and provide easier migration paths for users.

As for source code download goes? what problems did you have with it? all source is avalibale on github and so are downlodable "bundles" check

https://github.com/jbossas/jboss-as/tags also we make sure there are all maven artifaces are published with source

--

tomaz

[raydecampo]

Tomaz, thanks for the information on how you organized your projects within your team.  It is always valuable to see how others are doing things.

You know that since 7.1 you can have custom login modules in your application and no need to bundle it into global module?

Yes actually I just figured out how to do it and that was what I was referring to.  I added the security-domain to my standalone.xml referring to a class in my EAR.  That's what felt unnatural to me; I don't think of things that are deployed as in the application server classpath and referenced from the application server configuration files.  But it is consistent with the handling of JDBC drivers (where you deploy the jar).  So it is just different and takes a little getting used to.

[raydecampo]

I forgot to address the source code downloads.  I did download the source from github a few weeks back.  In the past the source downloads have been on the download page, e.g. there was a link to download the source for 6.1.0.Final on http://www.jboss.org/jbossas/downloads when I checked.  I was also a little frustrated that the source download I did did not contain the PicketBox files as I was recently looking for the source to the various LoginModules.  I'm not sure how valid that complaint is, although I don't know how I am supposed to know that, e.g. org.jboss.security.auth.spi.DatabaseServerLoginModule is not in JBoss proper but in a sub-project.  In the end the source downloads are not a very high priority, they are only useful rarely so it is not a big deal.