David Jencks wrote:
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?
I don't use anymore those two classes. They have been designed once upon
a time to allow xbean to feed the real Acceptors (which are MINA data
structure). I would rather prefer to feed the direct MINA objects
instead, but I have no idea how this is possible.
So currently, I have added some parameters to the servers.
- 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
But if they are protected, there is no way we can access them from a
Java class which is not extending the NtpServer class. Bad, IMHO.
- 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
To be double checked. We may have more than one Directory service, hence
more than one name, so we may have access to these members.
- 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.
True.
- 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
:) Strange... It was Geronimo, not Maven you were working on !
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.
I will think about that a couple of days. Maybe the way I did was not
the best.
One important point though : I would really like to access to MINA
objects which are already Xbeanized (ie, XXXAcceptor). How can I do that ?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
