directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: XBean questions
Date Thu, 27 Nov 2008 00:08:37 GMT

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  
>> setters?  Why are the called setXXX if they aren't setting  
>> configuration parameters?
> They are setters, but not some I want to set dynamically with a  
> config file. Usually, the config file is there to help the user to  
> configure the system, and should not expose useless parameters. But  
> as this file is generated from the code, obviously, there is a  
> problem.
> An annotation (something like @xbeans.hidden) could be used to mask  
> such a parameter.
>> I'll try to find time to look further but have a lot of projects  
>> 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  
problem masquerading as an xbean problem.  Here's your list of  
problems that I've annotated:

- DatagramAcceptor
- SocketAcceptor
I don't see how NTP can function without these being set... how do  
requests get in?

- DirectoryService (we don't use it for the NtpServer)
So, it should be protected getter/setter in AbstractDirectoryService  
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  
the constructor.  At least don't have public setters for them even if  
they aren't final

- started (it's a protected boolean set by the server itself, no need  
to configure it)
setStarted doesn't make much sense to me.  start() and stop() methods  

- TransportProtocols
Either these actually can be meaningfully set, or they should be set  
in the AbstractDirectoryService constructor, or they shouldn't be in  
AbstractDirectoryService at all.

Another possibility is that AbstractDirectoryService is not a suitable  
superclass for NTPServer

A comment on philosophy...
In geronimo we started out making you explicitly describe which  
attributes were exposed for configuration and which operations could  
be called through the kernel.  Everyone without exception hated us and  
complained bitterly both about the difficulty of writing components  
and about not having everything exposed through the kernel.  We  
basically gave up on this attempt to separate stuff into "manageable"  
and "public but not manageable".   I supported the separation for a  
long time but it really doesn't buy you anything and definitely makes  
understanding the code more difficult.  So, I really encourage you to  
make the classes so that everything that looks like a settable  
configuration property really is a settable configuration property.

david jencks

> -- 
> --
> cordialement, regards,
> Emmanuel L├ęcharny

View raw message