henk de boer [http://community.jboss.org/people/henk53
] created the discussion
"Re: Data sources in EAR on AS7?"
To view the discussion, visit: http://community.jboss.org/message/617373#617373
Will Tatam wrote:
We deploy many different self contained versions or our application to the same
application server. This is required as it would be a waste of resources to use a single
instance of jboss for each application.
Although I sympathize with your situation and see it as 'proof' that there are
many different use-cases in the wild for having such configuration inside an EAR, I would
like to mention that typically a single instance of JBoss AS for each application version
(production, qa, dev) is actually highly recommended.
Unless you're a startup with extreme budgetary problems, I would not deploy a QA or
DEV version on the same JBoss AS instance that runs the production version. I'm not
sure how long you have running in this setup, but it's mostly a recipe for disaster.
Even in the startups with the least amount of resources that I've seen, people were
able to cobble together a €500 workstation and bless it as the 'server' to be used
More typically, I've seen companies running one application per single JBoss AS
instance per single (Linux) virtualized server. The overhead of this in relation to the
current sizes of disks and memory isn't that much anymore.
Our application's EAR contains the configuration for the JMS
resources needed for each app (multiple topics and queues per instance of the app)
Do note that even if the EAR contains the configuration for these resources, they are
still deployed globally. You probably must know this already and I guess every version of
the application uses (slightly) different names?
I vaguely remember that there once was talk on the JBoss dev forum about having an option
for resources like JMS destinations and datasources to be EAR scoped (so one EAR cannot
see the resources of another EAR). I wonder what ever happened to this idea?
The "global" configuration introduced in AS7 works fine in
the case where you only have a single application in any given jboss instance as it can be
pre-configured by the system admins and then the app deployed.
In this case I would +almost+ say that the deployable unit is not the EAR anymore, but
JBoss AS itself with the EAR embedded inside it. The 'server' is then the plain
JVM. Of course, Jesper's proposed CLI archive will change this for the better, but it
doesn't yet exists.
It also currently requires that system admins know more about the
"internals" of the application as they now need to build the JMS resources,
rather than let the developers deal with these. So this now requires that system
administrators need to re-config the application server for a specific version of our app
for example if the latest version adds a new JMS queue
Yes, that has been my argument for a long time.
There is some school of thought that preaches EAR based applications should be deployed
with unresolved dependencies, and that teams of system administrators having both intimate
knowledge about the application server and about resources like JMS and Datasources are
dedicated to wiring applications to the production environment.
This school of thought is not wrong per se, but it's mostly applicable to *very* large
enterprises. There's a huge section in between, where system administrators mostly
have knowledge about Linux, firewalls, XEN installations, apt-get, DNS, routing etc etc,
but where their knowledge about Java and JBoss typically does not extend much beyond using
+'/etc/init.d/jboss restart'+ to restart the server. In these cases, developers or
devops people know about JMS destinations and are the ones who can judge whether a new JMS
queue is allowed or not in the application etc.
About that last thing, the "unresolved dependency"-approach typically seems to
work the other way around. An application can not just add a new JMS queue. In this setup
developers are often considered to be irresponsible cowboys who constantly endanger the
stability of the production system, while the system administrator is the wise and
knowledgeable 'defender' of said system. It's thus the system administrator
who dictates what data sources are JMS queues are available and the developers just have
to build the application around that.
What I've seen in practice is that in such restricted environments developers then
simply resort to shipping a different application server *inside* the EAR. In the majority
of the cases this different application server is Spring.
You probably do now want to know how many organizations run on Websphere (which strongly
advocates the unresolved dependency approach) and decree that developers go to system
administrators for resource definitions and upgrades of the server, but then base their
EAR completely on Spring so that all Websphere functionality and 99% of the role of the
system administrator is completely by-passed. It's scary and to be honest fairly
Reply to this message by going to Community
Start a new discussion in JBoss AS7 Development at Community