JBOSS adressed the issue with import-all and export-all attributes from the classloading element e.g.
classloading directive in AppName.ear\WEB-INF\jboss-classloading.xml
In this case, we put the ear's classloader in the "uber_domain" which
is shared (with all other applications that don't define their own
domain)
import-all attribute allows us to select from all other classes exported by other (web)
applications
export-all attribute will expose all our (WAR) classes to other classes.
<classloading xmlns="urn:jboss:classloading:1.0"
name="AppName.ear"
domain="uber_domain">
parent-domain="Ignored"
export-all="NON_EMPTY"
import-all="true">
</classloading>
the effect is to manipulate the classloader hierarchy
If i follow what you're saying you're thinking of a 'hierarchical chain' of configuration files so that
Configuration0.properties OR Configuration0.xml
takes precedence over
Configuration99.properties OR Configuration99.xml
Logical first step would be to allow the master configurator to accept Hierarchical URIs (or URLS which can be coerced to Hierarchical URIS) e.g.:
URL master_configurator_url = ...some universal master configurator..
File master_configurator = new File(master_configurator_url.toURI());
then we can use master_configurator (from uber_domain)
Thoughts?
Martin --
______________________________________________
Jogi és Bizalmassági kinyilatkoztatás/Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Ez az
üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy
jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának
készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és
semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek
könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet
ezen üzenet tartalma miatt.
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut ętre privilégié. Si vous n'ętes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert ŕ l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement ętre sujets ŕ la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
Date: Wed, 9 May 2012 19:59:56 -0400
Subject: Re: Best mailing list to start a Java EE configuration discussion?
From: ljnelson_at_gmail.com
To: users_at_glassfish.java.net
On Wed, May 9, 2012 at 6:36 PM, John Clingan <john.clingan_at_oracle.com> wrote:
Hi Laird. To better understand the use case, do you use any tooling to facilitate this or is this all via CLI? Is this during development, production, or moving an app from dev->test->pre-prod->production?
I'll try to speak for a great class of users that for whatever reason don't always seem to show up on this list but that are out there, trust me. :-)
In our case we ship an .ear file (currently; we may ship various .*ar files in the future). It is a product. Our customers take delivery of it and expect to customize it in various ways.
The first thing that always comes up is binding their LDAP/Active Directory setup to our roles. I am unaware of any tooling to assist with taking a black-box .ear or .war file and editing various deployment descriptors inside it. I would be very excited to know of such tooling if it exists. So then I get to tell them a story about how they take our product, open it up, find another product inside it, open it up, edit a file in there, re-zip up that product, then rezip up the containing product, and hopefully name it something different or otherwise manage it so they don't now confuse their customized product with our stock one. Then when they take delivery of a new version of our product, they need to unzip their customized one again and diff whatever they've changed against the contents of whatever we've newly supplied them. Yuck.
The next thing that comes up is various too-lightweight-for-a-database, set-once-and-forget-it property/environment settings. These are (per the spec) usually encased inside ejb-jar.xml files. Same thing.
The next thing is frequently our customers will take our .ear file and want to swap out some of our implementations of a given business interface and replace them with their own. Some of this is scripted up with build tools, but incurring a Build here is kind of heavyweight, it seems to me, for what is fundamentally a packaging operation.
Various people have pointed me towards the alt-dd element as some kind of magic catch-all that will solve various aspects of this problem, and perhaps it would, but for me it would only be useful if it could point "outside" of the .ear file. Of course it cannot, as the spec is currently written, because the .ear file is the whole world/environment.
Even that wouldn't fully help. One rough partially baked idea I had in this area was to allow in the spec (or in various vendor implementations) a way to "chase" an .ear file with another .ear-like archive containing its configuration. If the application server detected such a configuration and that configuration matched the current environment in some unspecified way, then THAT would be the configuration it would use. This way the stock product could be signed, versioned, etc. safe in the knowledge that it wouldn't be mauled by the customer, but a solution would exist for constantly changing configuration data. I'm sure there are all kinds of problems with this proposal, but my overall aim is to break out the stuff that people tweak and doctor all the time from the stuff that stays static. Deploy and manage configurations separately from the product they customize.
(Note that this is exactly the pattern that is followed by anyone who says "just put your properties in a database". In this case, a database is simply a place for your configuration to be managed and versioned and "redeployed" and whatnot apart from the app which it customizes. I'm just proposing making this general separation more platform/technology agnostic, and standardizing its location and how it is activated/deployed: it doesn't have to be a database, indeed it probably shouldn't, and could easily be a combination of file-based and Java-class-based customization options. For example, java.util.logging allows you to customize logging by using a properties file or by swapping out the customization class altogether. I think such a feature in Java EE land would be great.)
Thanks; happy to discuss this offline or on another list, and will make sure not to hijack this list further for this discussion. Thanks for listening.
Best,Laird
--
http://about.me/lairdnelson