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
do.
- 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.
thanks
david jencks
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
