Return-Path: X-Original-To: apmail-incubator-deltaspike-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-deltaspike-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 2D866D825 for ; Mon, 10 Sep 2012 13:20:56 +0000 (UTC) Received: (qmail 38180 invoked by uid 500); 10 Sep 2012 13:20:55 -0000 Delivered-To: apmail-incubator-deltaspike-dev-archive@incubator.apache.org Received: (qmail 38143 invoked by uid 500); 10 Sep 2012 13:20:55 -0000 Mailing-List: contact deltaspike-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: deltaspike-dev@incubator.apache.org Delivered-To: mailing list deltaspike-dev@incubator.apache.org Received: (qmail 38134 invoked by uid 99); 10 Sep 2012 13:20:55 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Sep 2012 13:20:55 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of marius.bogoevici@gmail.com designates 209.85.223.175 as permitted sender) Received: from [209.85.223.175] (HELO mail-ie0-f175.google.com) (209.85.223.175) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Sep 2012 13:20:48 +0000 Received: by iebc11 with SMTP id c11so3290635ieb.6 for ; Mon, 10 Sep 2012 06:20:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=0DXYguOZLuxJc1MGogKk1zbOysuWzDhr6QVLXN9UXZQ=; b=Pndss16bfERPnDinGyozGeIAKGM88LrdEyKoRxvKkGjDwDDl0h1e4A7bW3d96qeT9+ x0K5UJo5vuNZQx4SLqolgQEOnMaDQJyiko18Sy3qqtKP/iX7oveh72Nh2/ZkF5IvvNWM S4eSyrf3QQFQ9UQj1BTUgQaenYWOMlTv2FguSwPH/NIX767CxvZg3VBXUk2Vs3AonDFn +5jodz5tWYzsiv1em1bqp6HuaOiwKfbkh+/Jdia2cbyA9KAnPI95N9iap/C7+5mhlKMe lGf23ND7ZxqQqGExZWbndETc+x32A4/bkf6lhdvDepIxcmn5lBScJAj2E6WpyrCjciY1 JqAQ== Received: by 10.50.156.170 with SMTP id wf10mr10490850igb.27.1347283227887; Mon, 10 Sep 2012 06:20:27 -0700 (PDT) Received: from vetinari.local (CPE185933473ebf-CM185933473ebc.cpe.net.cable.rogers.com. [99.234.135.121]) by mx.google.com with ESMTPS id n5sm20664376igw.13.2012.09.10.06.20.25 (version=SSLv3 cipher=OTHER); Mon, 10 Sep 2012 06:20:27 -0700 (PDT) Message-ID: <504DE918.5040408@gmail.com> Date: Mon, 10 Sep 2012 09:20:24 -0400 From: Marius Bogoevici User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: deltaspike-dev@incubator.apache.org CC: Romain Manni-Bucau Subject: Re: XML Config References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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. On 2012-09-10 3:50 AM, Romain Manni-Bucau wrote: > what does bring xml? i think that's the point > > if it is only to get a format with hierarchy you can use yaml for instance > > *Romain Manni-Bucau* > *Twitter: @rmannibucau* > *Blog: http://rmannibucau.wordpress.com* > > > > > 2012/9/10 Bernard Łabno > >> If you find elegant way to do everything that can be currently done then >> it's cool not to use XML, but if we won't be able to i.e. configure bean >> properties between compilation and deployment then it will be great >> disappointment. >> >> 2012/9/10 Charles Moulliard >> >>> I would prefer that we avoid to use XML. Otherwise, end users will be >>> confused about what a CDI / CDI Extension should looks like and why we >> are >>> moving one step down to do what Spring / Xbean are doing. >>> >>> On Fri, Sep 7, 2012 at 11:31 PM, 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" 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://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 >>>>> >>> >>> >>> -- >>> Charles Moulliard >>> Apache Committer / Sr. Pr. Consultant at FuseSource.com >>> Twitter : @cmoulliard >>> Blog : http://cmoulliard.blogspot.com >>>