[
https://issues.apache.org/jira/browse/DIRSERVER-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13846541#comment-13846541
]
Shevek commented on DIRSERVER-1930:
-----------------------------------
At this point, in 2013, I'm using Cassandra as a backend, which while it
basically acts as a hashtable, has a weaker consistency which needs dealing
with.
In the Java world, I think DNS is very well served by xbill/dnsjava and NTP is
a very hairy protocol to get right which I'm not keen to attack right now (and
it is in commons-net, quality unknown).
DHCP really needs the RockSaw (or JNA) treatment, because the pure Java
protocol stack can't actually send broadcast packets with much versatility: a
broadcast listening UDP socket in Java cannot identify the NetworkInterface
which received the packet, and hence cannot actually reply, so for all the work
constructing a DHCP protocol stack, it's still not actually possible to write
either a server or a client this way. Right now I'm using a fixed configuration
with the jdk1.6 NetworkInterface classes.
Are there currently any consumers of dhcp within apacheds?
> DhcpOptions not extensible
> --------------------------
>
> Key: DIRSERVER-1930
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1930
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: dhcp
> Reporter: Shevek
>
> It is impossible to add my own DhcpOption types, due to the fixed and private
> static encapsulation in DhcpOption. Also, the option set isn't even complete
> enough for practical use.
> This method:
> public static int getTagByClass( Class c )
> {
> return ( ( Integer ) CODE_BY_CLASS.get( c ) ).intValue();
> }
> will NPE given an option class which isn't privately registered.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
