deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: XML Config
Date Tue, 18 Sep 2012 12:44:30 GMT
agree. 


We shall also identify all features which are non-portable in CDI-1.0

LieGrue,
strub



----- Original Message -----
> From: Gerhard Petracek <gerhard.petracek@gmail.com>
> To: deltaspike-dev@incubator.apache.org
> Cc: 
> Sent: Tuesday, September 18, 2012 10:38 AM
> Subject: Re: XML Config
> 
> @ 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
View raw message