Also ass public_ipv6_address for ipv6 address management.
Extend nics and vlans for ipv6 address.
Add dependency to com.googlecode.ipv6(java-ipv6).
Modify dhcpcommand for ipv6.
- Fixed new join dao impls as spring components
- Fixed component context xml to load api rate limit checker
- Fixed root pom.xml for duplicate plugin
- Fixed list data centers method
- Fixed following conflicts:
api/src/org/apache/cloudstack/api/command/admin/network/CreateNetworkOfferingCmd.java
api/src/org/apache/cloudstack/api/command/user/offering/ListServiceOfferingsCmd.java
api/src/org/apache/cloudstack/api/command/user/template/DeleteTemplateCmd.java
api/src/org/apache/cloudstack/api/command/user/template/ExtractTemplateCmd.java
plugins/api/discovery/src/org/apache/cloudstack/discovery/ApiDiscoveryServiceImpl.java
server/src/com/cloud/api/ApiDBUtils.java
server/src/com/cloud/api/ApiServer.java
server/src/com/cloud/api/query/QueryManagerImpl.java
server/src/com/cloud/configuration/DefaultComponentLibrary.java
server/src/com/cloud/server/ManagementServerImpl.java
server/src/com/cloud/storage/swift/SwiftManagerImpl.java
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
Fix usage in ApiDispatcher. Add two kinds of helpers:
- One that gets list of exclude cmd whose fields are not be included
- One that loops till a base class is asssignable from superclass
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
The default data source assumption is that db server is on localhost, port 3306
and has user cloud and password cloud. The static variables rely on hardcoded
db.properties file only. We need to fix it
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
and CloudException in one place, and Introduced ApiErrorCode to handle CloudStack API error
code to standard Http code mapping.
Signed-off-by: Min Chen <min.chen@citrix.com>
Enhanced baremetal servers support on Cisco UCS
introduce an python etree like xml helper.
Ok, this is not a new wheel. Frankly speaking, all Java XML API just suc**.
there are two popular types of XML API in java, one class is for data binding, JAXB,
XStream fall into this category. Another class is tree based, like JDOM, XOM ...
for XML api call, data binding library is painful as you have to specify the schema
that how xml stream converts to java object, which means you have to pre-define all
schemas(xsd file for JAXB, java object for XStream ...). This is not productive, because you
must add new schema when XML document grows.
Tree based library shines in this case, for it's able to dynamically create an object tree
from xml stream without any knowledge of its structure. However, all tree based
XML API library fall into below convention:
Element e = root.getChildElement("child1").getChildElement("child2").getChildElement("child3")...getChildElement("childN")
anything wrong with it???
the sadness is if there is no "child2", you will get a NPE with above code, which means you have to judge
before getting.
And, why so verbose?? why not:
Element e = root.child1.child2.child3...childN ???
Ok I am joking, it's impossible in Java the world knows Java is a static language.
but you can actually do:
Element e = root.get("child1.child2.child3");
or
List<Element> e = root.getAsList("child1.child2.child3")
this is known as XPath style(though XPATH use '/'), python etree has supported it.
so I did this toy for my UCS xml api call, it's quite like etree which is easy to use, for example:
<components.xml>
<system-integrity-checker class="com.cloud.upgrade.DatabaseUpgradeChecker">
<checker name="ManagementServerNode" class="com.cloud.cluster.ManagementServerNode"/>
<checker name="EncryptionSecretKeyChecker" class="com.cloud.utils.crypt.EncryptionSecretKeyChecker"/>
<checker name="DatabaseIntegrityChecker" class="com.cloud.upgrade.DatabaseIntegrityChecker"/>
<checker name="DatabaseUpgradeChecker" class="com.cloud.upgrade.PremiumDatabaseUpgradeChecker"/>
</system-integrity-checker>
</components.xml>
XmlObject xo = XmlObjectParser.parseFromFile("~/components.xml.in");
List<XmlObject> checkers = xo.getAsList("system-integrity-checker.checker");
then you get a list of XmlObject which represent each 'checker' element:
XmlObject firstChecker = checkers.get(0);
// firstChecker.get("name") == "ManagementServerNode"
// firstChecker.get("class") == "com.cloud.cluster.ManagementServerNode"
// firstChecker.getTag() == "checker"
// firstChecker.getText() == "" if it's <checker/>xxx</checker>, then getText() == "xxx"
example 2:
<checker name="ManagementServerNode" class="com.cloud.cluster.ManagementServerNode"/>
<system-integrity-checker class="com.cloud.upgrade.DatabaseUpgradeChecker">
<checker name="ManagementServerNode" class="com.cloud.cluster.ManagementServerNode"/>
</system-integrity-checker>
</components.xml>
yout can do:
XmlObject xo = XmlObjectParser.parseFromFile("~/components.xml.in");
XmlObject checker = xo.get("system-integrity-checker.checker");
then it returns a single object as we only have one "checker" in xml stream,
or you still do
List<XmlObject> checkers = xo.getAsList("system-integrity-checker.checker");
it returns a list which only contains one element of "checker"
if you do:
XmlObject checker = xo.get("system-integrity-checker.checker.this_middle_element_doesnt_exist.some_element");
it returns a null without any exception, so you don't have to worry if a parent element is missing when getting a leaf element
again it's not a new wheel, I just hate JAVA xml api
