deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: XML Config
Date Mon, 10 Sep 2012 23:36:34 GMT
I hate xml simply because it is too verbose.

Imo config on top of cdi is not the right place. It will often be over
engineered.

Properties will often be enough IMO (class name. Attribute = value for
instance)
Le 11 sept. 2012 01:31, "Stuart Douglas" <sdouglas@redhat.com> a écrit :

>
>
>   Mark Struberg <struberg@yahoo.de>
>  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 <s4237@pjwstk.edu.pl>
>  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.bogoevici@gmail.com><marius.bogoevici@gmail.com>
>
>
>   Marius Bogoevici <marius.bogoevici@gmail.com>
>  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 <struberg@yahoo.de>
>  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 <marius.bogoevici@gmail.com>
>  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.
>
>
>
>
>

Mime
  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message