Re: XML Config

[Stuart Douglas]

Mark Struberg 11 September 2012 1:59 AM One of the credos is that you MUST NOT repackage for just moving to a new server. Either this is in JNDI (same location) or just use @Inject ProjectStage ps; to check on which server you are running. I see no benefit of moving config to XML if it's not picked up from a really changable location. I kinda agree with this, and in AS7 upstream you can now use deployment overlays to modify an individual descriptor without having to open up the archive (I am pretty sure some other servers also support this). I think we should also support reading the external config (wether XML or not) from an outside location somehow. Just using the ProjectStage is not really sufficient for all use cases IMHO, as you may have multiple production servers with different configurations.  To me this just means to replace hardcoding in java sources with hardcoding in some XML which gots scanned by java sources. Personally I think there are quite a few advantages of configuring via XML: - It is obvious to new developers where your configuration settings are (META-INF or WEB-INF) - You can inspect any pre-built archive and see what settings are in effect - You can also potentially modify those settings with just zip and a text editor (I know this is not ideal, but if your fighting fires and just need to get your app back online this is a lot better than having to do a full re-build). - Servers that support modification of descriptors at deployment time can modify the config - There are lots of editors with XML support - There are lots of developers that know XML I really don't think that hard coding configuration via annotations is a good idea. Configuration should be plain text, and I think a lot of the push back against XML is more because of the Spring/J2EE overuse of it in the past has made a lot of developers hate XML. Stuart LieGrue strub ----- Original Message ----- Bernard Łabno 11 September 2012 1:41 AM Ok, what If I have library with CDI beans that send emails and need to have JNDI of mail session configured? When I attach this library to project A that is deployed on JBoss AS7 it may have different jndi then in some other project or server. 2012/9/10 Marius Bogoevici <marius.bogoev...@gmail.com> Marius Bogoevici 11 September 2012 12:20 AM Spring supports it, but in practice you'd want to stay away from it. I thought more along the lines of a script that is interpreted at startup. Mark Struberg 11 September 2012 12:15 AM hmm 'scriptable' imo implies that it can be changed at runtime. But that's by design not possible with CDI. Spring supports this, we do not. Otoh this allows us to be much faster in all 'static' use cases. LieGrue, strub ----- Original Message ----- Marius Bogoevici 10 September 2012 11:20 PM Generally speaking, I think it would be good to have a mechanism for configuring beans that does not require re-compilation - may be of limited use in greenfield applications, but above all with brownfield/legacy code. In fairness, for the latter one could use producers and such, but it may still be a PITA in some cases. Now, the key here IMO would be to have a scriptable (no recompilation) and toolable DSL outside the annotation system. It so happens that of all the options, XML is IMO the most common and better understood by the average developer. If we manage to define a proper intermediate model for this mechanism, then there could be plenty of other options (yaml, or even Groovy or Ruby if one so wishes) to add on later.