From dev-return-28112-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Thu Nov 27 00:10:12 2008
Return-Path:
Delivered-To: apmail-directory-dev-archive@www.apache.org
Received: (qmail 54119 invoked from network); 27 Nov 2008 00:10:12 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
by minotaur.apache.org with SMTP; 27 Nov 2008 00:10:12 -0000
Received: (qmail 81100 invoked by uid 500); 27 Nov 2008 00:10:22 -0000
Delivered-To: apmail-directory-dev-archive@directory.apache.org
Received: (qmail 81053 invoked by uid 500); 27 Nov 2008 00:10:22 -0000
Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: "Apache Directory Developers List"
Delivered-To: mailing list dev@directory.apache.org
Received: (qmail 81042 invoked by uid 99); 27 Nov 2008 00:10:22 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Nov 2008 16:10:22 -0800
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: local policy)
Received: from [98.136.44.63] (HELO smtp108.prem.mail.sp1.yahoo.com) (98.136.44.63)
by apache.org (qpsmtpd/0.29) with SMTP; Thu, 27 Nov 2008 00:08:53 +0000
Received: (qmail 22107 invoked from network); 27 Nov 2008 00:08:39 -0000
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=T/CS5vFMDYwz4GDsmrkQKG8vutvZkhejVW7P9WPD2xw5ohEr5SRE7hlNCKiXFE5vxLnDIdCSnA2LdZ+n/uN+UywaQQMhRurOP1woRHDJumTikenS7ncG3r7D0bU0AHzniBpxKKDZu8KH4jwnNyvcjoECSaVhkjCzLvy18czhMCI= ;
Received: from unknown (HELO ?10.11.55.45?) (david_jencks@63.105.20.225 with plain)
by smtp108.prem.mail.sp1.yahoo.com with SMTP; 27 Nov 2008 00:08:38 -0000
X-YMail-OSG: rnMrv6QVM1lzmKYj904diUv_sI4u.lxv9QW1XQXcDyzXWNswQ0khtIRTL9kUTW4ipHhtxOWcr0L2DZ28VZOe_tJ6PM.Nc4nHpAQwXPlfzDvHOXm2fIxgsJu51WD4O82enRafc4FP9P3QUoSF79mAmTEA55pEB3BmantAE0jU_4gjbTT0wKNRExVdUo4-
X-Yahoo-Newman-Property: ymail-3
Message-Id: <01C057B7-116C-4457-91A3-0C41B3286658@yahoo.com>
From: David Jencks
To: "Apache Directory Developers List"
In-Reply-To: <492DBED5.1080902@nextury.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: XBean questions
Date: Wed, 26 Nov 2008 16:08:37 -0800
References: <49248A0D.3050901@nextury.com> <18CEF8CD-029B-4499-B3EE-E9BA618AEB75@yahoo.com> <492DBED5.1080902@nextury.com>
X-Mailer: Apple Mail (2.929.2)
X-Virus-Checked: Checked by ClamAV on apache.org
On Nov 26, 2008, at 1:25 PM, Emmanuel Lecharny wrote:
> David Jencks wrote:
>> Sorry this slipped by the first time...
> np, I was also pretty busy myself :)
>>
>> I don't know of any way to do this. Are these methods really not =20
>> setters? Why are the called setXXX if they aren't setting =20
>> configuration parameters?
> They are setters, but not some I want to set dynamically with a =20
> config file. Usually, the config file is there to help the user to =20
> configure the system, and should not expose useless parameters. But =20=
> as this file is generated from the code, obviously, there is a =20
> problem.
>
> An annotation (something like @xbeans.hidden) could be used to mask =20=
> such a parameter.
>
>>
>> I'll try to find time to look further but have a lot of projects =20
>> piling up.
> Np. It's not urgent anyway.
>
> Thanks !
I looked a little more... it looks to me as if there might be a design =20=
problem masquerading as an xbean problem. Here's your list of =20
problems that I've annotated:
- DatagramAcceptor
- SocketAcceptor
I don't see how NTP can function without these being set... how do =20
requests get in?
- DirectoryService (we don't use it for the NtpServer)
So, it should be protected getter/setter in AbstractDirectoryService =20
or better just not there at all
- ServiceID (This is a technical info which will never change)
- ServiceName (This is a technical info which will never change)
I think these should be final in AbstractDirectoryService and set in =20
the constructor. At least don't have public setters for them even if =20=
they aren't final
- started (it's a protected boolean set by the server itself, no need =20=
to configure it)
setStarted doesn't make much sense to me. start() and stop() methods =20=
do.
- TransportProtocols
Either these actually can be meaningfully set, or they should be set =20
in the AbstractDirectoryService constructor, or they shouldn't be in =20
AbstractDirectoryService at all.
Another possibility is that AbstractDirectoryService is not a suitable =20=
superclass for NTPServer
---
A comment on philosophy...
In geronimo we started out making you explicitly describe which =20
attributes were exposed for configuration and which operations could =20
be called through the kernel. Everyone without exception hated us and =20=
complained bitterly both about the difficulty of writing components =20
and about not having everything exposed through the kernel. We =20
basically gave up on this attempt to separate stuff into "manageable" =20=
and "public but not manageable". I supported the separation for a =20
long time but it really doesn't buy you anything and definitely makes =20=
understanding the code more difficult. So, I really encourage you to =20=
make the classes so that everything that looks like a settable =20
configuration property really is a settable configuration property.
thanks
david jencks
>
>
> --=20
> --
> cordialement, regards,
> Emmanuel L=E9charny
> www.iktek.com
> directory.apache.org
>
>