You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2008/11/19 22:50:05 UTC
XBean questions
Hi,
as I have added some properies into the AbstractProtocolService class,
I'm now trying to get them listed on the web site (documentation effort
...).
The problem I have is that all the setXXX() methods are immediately seen
as configuration parameters, even if it's not the case.
We are using a generic XBean annotation :
* @org.apache.xbean.XBean
*/
public class NtpServer extends AbstractProtocolService
...
which use reflection to construct the XSD file from the javaclass. What
I would like to do is to remove the useless parameters from this XSD
file when the maven-xbean-plugin is run. For instance, I don't want :
- DatagramAcceptor
- SocketAcceptor
- DirectoryService (we don't use it for the NtpServer)
- ServiceID (This is a technical info which will never change)
- ServiceName (This is a technical info which will never change)
- started (it's a protected boolean set by the server itself, no need to
configure it)
- TransportProtocols
Anyone knows how to get those elements not generated as part of the XSD
file ?
I have looked at the very sparse xbean doco, but didn't find anywhere
something helpful. What I would like to do is to add some annotation to
tell XBean not to use a setter as a configuration element. Or the
opposite : declare all the configurable element in the top level class,
telling xbean not to dig into the class and its parents for a new
configurable element.
Is it possible ?
Thanks !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: XBean questions
Posted by Emmanuel Lecharny <el...@gmail.com>.
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
Re: XBean questions
Posted by David Jencks <da...@yahoo.com>.
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
>
>
Re: XBean questions
Posted by Emmanuel Lecharny <el...@gmail.com>.
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 !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: XBean questions
Posted by David Jencks <da...@yahoo.com>.
Sorry this slipped by the first time...
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?
I'll try to find time to look further but have a lot of projects
piling up.
thanks
david jencks
On Nov 26, 2008, at 11:46 AM, Alex Karasulu wrote:
> Did you get an answer for this problem? (being 7 days old and all)
>
> You might want to post this to the geronimo mailing list for XBean.
> It's really hard to get any answers from anyone except David Jencks
> and Dain Sundstrom. You can also try the IRC channel.
>
> Alex
>
> On Wed, Nov 19, 2008 at 4:50 PM, Emmanuel Lecharny <elecharny@gmail.com
> > wrote:
> Hi,
>
> as I have added some properies into the AbstractProtocolService
> class, I'm now trying to get them listed on the web site
> (documentation effort ...).
>
> The problem I have is that all the setXXX() methods are immediately
> seen as configuration parameters, even if it's not the case.
>
> We are using a generic XBean annotation :
>
> * @org.apache.xbean.XBean
> */
> public class NtpServer extends AbstractProtocolService
> ...
>
> which use reflection to construct the XSD file from the javaclass.
> What I would like to do is to remove the useless parameters from
> this XSD file when the maven-xbean-plugin is run. For instance, I
> don't want :
> - DatagramAcceptor
> - SocketAcceptor
> - DirectoryService (we don't use it for the NtpServer)
> - ServiceID (This is a technical info which will never change)
> - ServiceName (This is a technical info which will never change)
> - started (it's a protected boolean set by the server itself, no
> need to configure it)
> - TransportProtocols
>
> Anyone knows how to get those elements not generated as part of the
> XSD file ?
>
> I have looked at the very sparse xbean doco, but didn't find
> anywhere something helpful. What I would like to do is to add some
> annotation to tell XBean not to use a setter as a configuration
> element. Or the opposite : declare all the configurable element in
> the top level class, telling xbean not to dig into the class and its
> parents for a new configurable element.
>
> Is it possible ?
>
> Thanks !
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Re: XBean questions
Posted by Alex Karasulu <ak...@apache.org>.
Did you get an answer for this problem? (being 7 days old and all)
You might want to post this to the geronimo mailing list for XBean. It's
really hard to get any answers from anyone except David Jencks and Dain
Sundstrom. You can also try the IRC channel.
Alex
On Wed, Nov 19, 2008 at 4:50 PM, Emmanuel Lecharny <el...@gmail.com>wrote:
> Hi,
>
> as I have added some properies into the AbstractProtocolService class, I'm
> now trying to get them listed on the web site (documentation effort ...).
>
> The problem I have is that all the setXXX() methods are immediately seen as
> configuration parameters, even if it's not the case.
>
> We are using a generic XBean annotation :
>
> * @org.apache.xbean.XBean
> */
> public class NtpServer extends AbstractProtocolService
> ...
>
> which use reflection to construct the XSD file from the javaclass. What I
> would like to do is to remove the useless parameters from this XSD file when
> the maven-xbean-plugin is run. For instance, I don't want :
> - DatagramAcceptor
> - SocketAcceptor
> - DirectoryService (we don't use it for the NtpServer)
> - ServiceID (This is a technical info which will never change)
> - ServiceName (This is a technical info which will never change)
> - started (it's a protected boolean set by the server itself, no need to
> configure it)
> - TransportProtocols
>
> Anyone knows how to get those elements not generated as part of the XSD
> file ?
>
> I have looked at the very sparse xbean doco, but didn't find anywhere
> something helpful. What I would like to do is to add some annotation to tell
> XBean not to use a setter as a configuration element. Or the opposite :
> declare all the configurable element in the top level class, telling xbean
> not to dig into the class and its parents for a new configurable element.
>
> Is it possible ?
>
> Thanks !
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Re: XBean questions
Posted by Guillaume Nodet <gn...@gmail.com>.
On a given setter, you should be able to use the following:
@org.apache.xbean.Property hidden="true"
AFAIK, there is no way to tell xbean to ignore the parent class.
On Wed, Nov 19, 2008 at 10:50 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
> Hi,
>
> as I have added some properies into the AbstractProtocolService class, I'm
> now trying to get them listed on the web site (documentation effort ...).
>
> The problem I have is that all the setXXX() methods are immediately seen as
> configuration parameters, even if it's not the case.
>
> We are using a generic XBean annotation :
>
> * @org.apache.xbean.XBean
> */
> public class NtpServer extends AbstractProtocolService
> ...
>
> which use reflection to construct the XSD file from the javaclass. What I
> would like to do is to remove the useless parameters from this XSD file when
> the maven-xbean-plugin is run. For instance, I don't want :
> - DatagramAcceptor
> - SocketAcceptor
> - DirectoryService (we don't use it for the NtpServer)
> - ServiceID (This is a technical info which will never change)
> - ServiceName (This is a technical info which will never change)
> - started (it's a protected boolean set by the server itself, no need to
> configure it)
> - TransportProtocols
>
> Anyone knows how to get those elements not generated as part of the XSD file
> ?
>
> I have looked at the very sparse xbean doco, but didn't find anywhere
> something helpful. What I would like to do is to add some annotation to tell
> XBean not to use a setter as a configuration element. Or the opposite :
> declare all the configurable element in the top level class, telling xbean
> not to dig into the class and its parents for a new configurable element.
>
> Is it possible ?
>
> Thanks !
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com