Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer;
  b=YT/XWK6Ai1Dckpd2OejfItaDGLKqliyyhpZ5lyDnhHJCva4YiV6NPXhM2sdt3QHJC27ZD85Bx+FFlqiJjWcqvLVK+Y+X4CZF/Wc0EM8FeFxBzHzMgeHONUxY8aV8i/O7FBmPecXmPKeZeNTmANcrwOAiLe79haJepe5EB3HscXg=
  ;
Message-Id: <D3BE83D9-630B-446E-AA5E-9AAE308297AC@yahoo.com>
From: David Jencks <david_jencks@yahoo.com>
To: "Apache Directory Developers List" <dev@directory.apache.org>
In-Reply-To: <48B52502.1060809@sharp.fm>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v926)
Subject: Re: [ApacheDS] [XBeans] [Spring] Any issue with moving to spring 2.5?
Date: Wed, 27 Aug 2008 08:50:46 -0700
References: <a32f6b020808261128u3848035co9a3dc9e38ae8b268@mail.gmail.com>
 <48B46741.3040008@labeo.de> <48B4722E.8040403@gmail.com>
 <48B52502.1060809@sharp.fm>


On Aug 27, 2008, at 2:57 AM, Graham Leggett wrote:

> Emmanuel Lecharny wrote:
>
>> not only is this complex from the user POV, but from the developper  
>> POV, this is a nightmare. I frankly don't like those annotations  
>> stuff, plus the fact that the objects are instanciated during the  
>> xml file processing is a real burden (and makes the configuration  
>> file way too complex).
>> I will talk my mind : I think that going for Spring was a big  
>> mistake.
>
> I have to agree at this point.
>
> My key experience with Spring is with debugging issues with it. On  
> the last major project, virtually all issues that managed to slip  
> past continuous integration were caused by mistakes in Spring files,  
> which march straight past the compiler and in many cases past the  
> unit tests and are found by the end user instead.
>
> The worst problem was a stray 'singleton="true"' that someone had  
> put on a bean by accident through some careless cut and paste. It  
> caused some financial reports to return subtly different data when  
> the reports were repeated, and took over a month to find and fix.  
> The end result was a whole host of assertions in the code entitled  
> "dodgy stuff that Spring might do", and it aged us by years.
>
>> Now, what can we do ? I think that the way to go is to have the  
>> configuration in the DIT, with LDIF based configuration files (like  
>> OpenLdap has).
>
> What I have been doing with config files is defining the structure  
> of the config files with an XSD, and then reading in the config file  
> at the outset using xmlbeans autogenerated from the XSD.
>
> Like Spring, your config files are in an XML format, and like  
> Spring, you end up with a set of Java beans that you can query to  
> read your config, but unlike Spring, the format of the config file  
> has a fixed structure validated against an XSD, and your code is  
> validated by your compiler before it hits the end user.
>
> What this gives you is a (reasonably) sensible error message if the  
> user makes a mistake in the config file, as you ask xmlbeans to  
> validate the file when you read it in.
>
> In addition, making changes is a breeze: Change the XSD, regenerate  
> the xmlbeans, wherever you have a compile error, that's where you  
> need to change your code to support your new structure.

Offhand I don't see why this is better than spring + xbean-spring,  
where you get an xsd generated from your classes that your server.xml  
plan can be validated against.  Furthermore you don't have to write  
the code that translates from the xmlbeans objects to the runtime  
components, as spring does that part for you.  Could you explain?

However if anyone decides to go in this direction I think that using  
jaxb instead of xmlbeans, and more particularly sxc, is definitely the  
way to go.  I think there's a good chance that it would be easy to  
make the runtime components actually be the jaxb objects.

thanks
david jencks
>
>
> Regards,
> Graham
> --