deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Porter <lightguard...@gmail.com>
Subject Re: XML Config
Date Mon, 17 Sep 2012 23:06:41 GMT
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> 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>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>
>>>
>>>  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>
>>>>
>>>>  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> 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>
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, pgp.mit.edu
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>> --
>>>>> Mehdi Heidarzadeh Ardalani
>>>>> Independent JEE Consultant, Architect and Developer.
>>>>> http://www.TheBigJavaBlog.com
>>>>>
>>>>>
>>
>>
>
>


-- 
Jason Porter
http://lightguard-jp.blogspot.com
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, pgp.mit.edu

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