directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: XBean questions
Date Thu, 27 Nov 2008 00:56:25 GMT
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



Mime
View raw message