deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <gerhard.petra...@gmail.com>
Subject Re: XML Config
Date Tue, 18 Sep 2012 08:38:11 GMT
@ shane: +1

regards,
gerhard



2012/9/18 Shane Bryzak <sbryzak@redhat.com>

> Oh, and just to be clear I think we should by all means discuss the
> required features on the mailing list first, we just need to ensure that
> any features we agree upon are collated on the wiki.
>
>
> On 18/09/12 18:07, Shane Bryzak wrote:
>
>> I think that a more formal list like we had on the wiki for security,
>> exceptions or messages [1] might be the way to go.  That way everyone can
>> contribute to it so that we have an authorative declaration of requirements
>> before proceeding with any development work.
>>
>> [1] https://cwiki.apache.org/**confluence/display/DeltaSpike/**Drafts<https://cwiki.apache.org/confluence/display/DeltaSpike/Drafts>
>>
>> On 18/09/12 09:06, Jason Porter wrote:
>>
>>> That works for me, shall we start a new thread or continue with this one?
>>>
>>> On Mon, Sep 17, 2012 at 4:40 PM, Shane Bryzak <sbryzak@redhat.com<mailto:
>>> sbryzak@redhat.com>> wrote:
>>>
>>>     I think we need to take a step back and define some requirements.
>>>      One that I'm aware of is the ability to wire up beans, something
>>>     that Drools (in particular, though this is a generally useful
>>>     feature) needs to be able to provide proper CDI support.
>>>
>>>
>>>     On 18/09/12 07:17, Jason Porter wrote:
>>>
>>>         Though it doesn't seem like everyone is in agreement as to
>>>         what this
>>>         feature should include, it certainly sounds like we can move
>>>         forward with
>>>         what was in Seam 3 and add / remove features as needed. Does
>>>         that sound
>>>         about right?
>>>
>>>         On Tue, Sep 11, 2012 at 4:24 AM, Romain Manni-Bucau
>>>         <rmannibucau@gmail.com <mailto:rmannibucau@gmail.com>**>wrote:
>>>
>>>             yes but code will become harder if you are not a
>>>             weld/candi or owb dev
>>>             since you'll not know where you beans comes from.
>>>
>>>             you'll not be able to grep java files as expected
>>>
>>>             Another point is the format is not logical since inject
>>>             doesnt decorate the
>>>             bean but is nested into it
>>>
>>>             *Romain Manni-Bucau*
>>>             *Twitter: @rmannibucau*
>>>             *Blog: http://rmannibucau.wordpress.**com<http://rmannibucau.wordpress.com>
>>> *
>>>
>>>
>>>
>>>
>>>             2012/9/11 Bernard Łabno <s4237@pjwstk.edu.pl
>>>             <mailto:s4237@pjwstk.edu.pl>>
>>>
>>>                 Ok, let's consider
>>>
>>>
>>> http://it-crowd.com.pl/svn/**seam3-persistence-framework/**
>>> trunk/framework/src/main/java/**pl/com/it_crowd/seam/**
>>> framework/converter/**EntityConverter.java<http://it-crowd.com.pl/svn/seam3-persistence-framework/trunk/framework/src/main/java/pl/com/it_crowd/seam/framework/converter/EntityConverter.java>
>>>
>>>                 It's part of seam3-persistence-framework (itcrowd's
>>>                 port of seam2
>>>                 persistence framework).
>>>                 Entity converter needs EntityManager to load entity
>>>                 from DB by id.
>>>                 Currently all I need to do is to attach
>>>                 seam3-persistence-framewor.jar to
>>>                 my application and
>>>                 add following lines to seam-beans.xml:
>>>
>>>                      <pf-converter:EntityConverter>
>>>                          <pf-converter:entityManager>
>>>                              <s:Inject/>
>>>                          </pf-converter:entityManager>
>>>                          <s:modifies/>
>>>                      </pf-converter:**EntityConverter>
>>>
>>>
>>>                 I know that I could write @Produces method, but I like
>>>                 this way. It's
>>>
>>>             also
>>>
>>>                 cool to turn some bean from non CDI library into CDI
>>>                 bean simply with 1
>>>                 line of XML config.
>>>
>>>                 Other sample:
>>>
>>>                      <app-config:PBESpecImpl
>>> algorithmJNDI="java:/appName/**encryption/algorithm"
>>> iterationCountJNDI="java:/**appName/encryption/**iterationCount"
>>>
>>>                 passwordJNDI="java:/appName/**encryption/password"
>>>                 saltJNDI="java:/appName/**encryption/salt">
>>>                          <s:modifies/>
>>>                      </app-config:PBESpecImpl>
>>>
>>>                 Do all servers have same JNDI patterns so I could
>>>                 hardcode it? Even if so
>>>                 PBESpecImpl is part of library that is being attached
>>>                 to many projects
>>>                 where each project wants different JNDI locations for
>>>                 particular config.
>>>
>>>                 2012/9/11 Mehdi Heidarzadeh <heidarzadeh2@gmail.com
>>>                 <mailto:heidarzadeh2@gmail.com**>>
>>>
>>>                     We have some developers who like xml and some who
>>>                     hate xml and that
>>>
>>>             might
>>>
>>>                     be because of different tastes or background when
>>>                     working with XML in
>>>
>>>             the
>>>
>>>                     past or what ever.
>>>                     I think configuration with both xml and property
>>>                     files are ok, because
>>>
>>>                 some
>>>
>>>                     developers like property files and some like
>>>                     annotations and some xml
>>>
>>>             and
>>>
>>>                     some of them like combination of them like me ;)
>>>                     I hate *writing* *code* using  XML (like mapping
>>>                     entities, it's kind of
>>>                     writing code using xml) but I like configuring
>>>                     *application
>>>                     configuration*with xml or property files, because
>>>                     I can change them in
>>>                     deploy time
>>>                     depending on deployment environment without any
>>>                     compilation.
>>>                     when you ask someone about XML vs annotation vs
>>>                     ...? I think the answer
>>>                     will depend on the taste and background of that
>>>                     developer.
>>>
>>>                     Since seam3 has xml configuration and DS can
>>>                     reuse it, why not
>>>
>>>             providing
>>>
>>>                     xml configuration feature too, and letting the
>>>                     developer to choose
>>>
>>>             which
>>>
>>>                     one to use? producer methods vs xml vs property file?
>>>
>>>
>>>                     On Tue, Sep 11, 2012 at 6:40 AM, Marius Bogoevici <
>>>                     marius.bogoevici@gmail.com
>>> <mailto:marius.bogoevici@**gmail.com <marius.bogoevici@gmail.com>>>
>>> wrote:
>>>
>>>                         On 2012-09-10 8:25 AM, Pete Muir wrote:
>>>
>>>                             This is what I would use non-compiled
>>>                             resources for as well.
>>>
>>>                             If I needed to CDI-enable some code
>>>                             without using annotations, I
>>>
>>>             would
>>>
>>>                             use the portable extension API directly.
>>>
>>>                         Yes and no. In my opinion this is generic
>>>                         enough to warrant a
>>>
>>>                     configurable
>>>
>>>                         implementation, rather than producing a code
>>>                         template that would be
>>>
>>>                     copied
>>>
>>>                         and pasted around. I understand that all of us
>>>                         can master the fine
>>>
>>>                 points
>>>
>>>                         of writing an extension, but a configurable
>>>                         solution may be easier
>>>
>>>             for
>>>
>>>                     the
>>>
>>>                         average developer.
>>>
>>>
>>>                             On 7 Sep 2012, at 22:31, Romain
>>>                             Manni-Bucau wrote:
>>>
>>>                               Why i would like to use files (i find
>>>                             xml too verbose) is for
>>>
>>>                 constants
>>>
>>>                                 (uri for instance) or
>>>                                 alternative/interceptor (as mentionned)
>>>
>>>                                 Today i find other use case the
>>>                                 translation of bad design
>>>
>>>                                 ...just my opinion maybe
>>>                                 Le 7 sept. 2012 23:01, "Jason Porter"
>>>                                 <lightguard.jp@gmail.com
>>> <mailto:lightguard.jp@gmail.**com <lightguard.jp@gmail.com>>>
a
>>>
>>>                     écrit
>>>
>>>                                 :
>>>
>>>                                   Mark, Pete and I discussed a little
>>>                                 bit about the XML config (from
>>>
>>>                                     Solder)
>>>                                     on IRC today. We quickly decided
>>>                                     that we needed to move over to
>>>
>>>             the
>>>
>>>                                     mailing
>>>                                     list for more input, and to make
>>>                                     things official.
>>>
>>>                                     As things currently exist in the
>>>                                     Solder XML Config, it's probably
>>>
>>>                 not
>>>
>>>                                     portable and would really need
>>>                                     some of the changes in CDI 1.1 to
>>>
>>>                 work
>>>
>>>                                     properly. We also discussed
>>>                                     throwing out the idea of completely
>>>                                     configuring
>>>                                     beans via XML and using the XML
>>>                                     config for other tasks such as
>>>
>>>                     applying
>>>
>>>                                     interceptors and the like via
>>>                                     regex or similar ideas, in other
>>>
>>>             words
>>>
>>>                                     having
>>>                                     it being a subset of what
>>>                                     currently exists today. What is in
>>>
>>>             Solder
>>>
>>>                 is
>>>
>>>                                     very
>>>                                     similar to configuring beans via
>>>                                     XML in Spring, and we feel that
>>>                                     paradigm
>>>                                     has sailed.
>>>
>>>                                     I'm starting this thread to get
>>>                                     some other ideas about what we
>>>
>>>                 should
>>>
>>>                     do
>>>
>>>                                     for XML config and also see what
>>>                                     people think.
>>>
>>>                                     --
>>>                                     Jason Porter
>>> http://lightguard-jp.blogspot.****com <
>>>
>>>                     http://lightguard-jp.blogspot.**com<http://lightguard-jp.blogspot.com>
>>> >
>>>
>>> http://twitter.com/****lightguardjp <http://twitter.com/**lightguardjp><
>>>
>>>             http://twitter.com/**lightguardjp<http://twitter.com/lightguardjp>
>>> >
>>>
>>>                                     Software Engineer
>>>                                     Open Source Advocate
>>>                                     Author of Seam Catch - Next
>>>                                     Generation Java Exception Handling
>>>
>>>                                     PGP key id: 926CCFF5
>>>                                     PGP key available at:
>>>                                     keyserver.net
>>> <http://keyserver.net>,
>>>                                     pgp.mit.edu <http://pgp.mit.edu>
>>>
>>>
>>>
>>>                     --
>>>                     Mehdi Heidarzadeh Ardalani
>>>                     Independent JEE Consultant, Architect and Developer.
>>>                     http://www.TheBigJavaBlog.com
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Jason Porter
>>> http://lightguard-jp.blogspot.**com <http://lightguard-jp.blogspot.com>
>>> http://twitter.com/**lightguardjp <http://twitter.com/lightguardjp>
>>>
>>> Software Engineer
>>> Open Source Advocate
>>> Author of Seam Catch - Next Generation Java Exception Handling
>>>
>>> PGP key id: 926CCFF5
>>> PGP key available at: keyserver.net <http://keyserver.net>, pgp.mit.edu<
>>> http://pgp.mit.edu>
>>>
>>
>>
>>
>>
>
>

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