Sebastian Koske [
http://community.jboss.org/people/sebastian.koske] created the
discussion
"Re: Data sources in EAR on AS7?"
To view the discussion, visit:
http://community.jboss.org/message/601257#601257
--------------------------------------------------------------
Hi Jason,
I understand the need for a clear configuration layout and a centralized configuration
file is clearly an advantage, but I'm quite shocked about the rigidness of the
implementation. Why not give developers the alternative to choose what fits best for them?
Erasing any alternatives or options has a significant impact on the whole deployment
process.
While now (using JBoss 5) Datasources and JMS-Destinations *can* ship predefined by the
developers and packed within the application. There are no server alterations required. If
server alterations such as memory, pools sizes, messaging configuration etc. are
recommended, they can be done *once* and *in advance* of any deployment.
After the server ist installed, we distribute the application as an EAR and a script to
replace the minimal set of configuration placeholder (basically the datasource
connection). At the customer side the EAR is run through the script and deployed just by
copying it into the deploy directory. Some customers deploy this EAR even multiple times
(each with its own datasources, queues, caches etc). They don't need any knowledge of
the internals (Topics, Queues, Datasource Names etc.) and they do not need to modify the
server configuration again.
If we migrate to JBoss 7, the process will become much more complicated. We will have to
provide detailed instructions of all the internally required ressources and how to name
and configure them properly. Yet, these customers are not experts, they are only
interested in our software to run - some do not know much more than how to start a JBoss
with a deployed EAR! If they do anything wrong, maybe just a mispelled queue, then the
server wont start and they have to get back to us.
To prevent this, we would have to come up with additional scipts which have to start
editing all the same configuration file or provide completely new customized installation
tools. That's certainly a huge amount of work for a much more complicated and
error-prone workflow.
You said
Also another requirement was that anything you can configure you can
manage remotely via scripting languages, java clients, and a CLI. Deployment driven
resources contradict all of this.
Why? What is the difference between a java client managing resources and a deployer using
a configuration file? I don't see any. Why eliminate a perfectly convinient solution
instead of just providing an alternative? If the centralized configuration is better in
all cases, developers will migrate to this anyway, but in cases where it's not you
will cause your users serious headaches...
--------------------------------------------------------------
Reply to this message by going to Community
[
http://community.jboss.org/message/601257#601257]
Start a new discussion in JBoss AS7 Development at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=1&...]