-
Notifications
You must be signed in to change notification settings - Fork 0
GuideAdministration
There are several different ways to administrator and configure jUDDI. This section will outline and/or link to relevant information to assist you. There are two ways to configure and reconfigure jUDDI, via the XML file and through your web browser.
The jUDDI web services are typically first configured via manually editing the juddiv3.xml file, located at the following location:
<servletContainer>/juddiv3/WEB-INF/classes/juddiv3.xml
Note: version prior to 3.2 used a properties (key=value) file. Version 3.2 and up use an XML configuration file. Many of key names have changed to help cluster settings logically.
Once jUDDI is deployed, it can be reconfigured via the web browser by accessing:
http://<server>:<port>/juddiv3/admin
Then click on "Configure".
jUDDI includes a number of Cryptographic providers that are provided with most Java Runtime environments. Not all of the functions will operate in all countries due to various legal restrictions.
-
Triple Data Encryption Standard
-
Advanced Encryption Standard 128 and 256 bit
-
Password Based Encryption With MD5 and DES
For convenience, administrators can use a command line utility to encrypt passwords that are stored within the jUDDI server and client configuration files.
If you want to change the port Tomcat listens on to something non-standard (something other than 8080), use the following guidance.
jUDDI Server (Tomcat) - This assumes you are using the jUDDI server bundled with Apache Tomcat. For other application servers, consult their documentation, however the juddiv3.xml must still be altered.
-
Edit conf/server.xml and change the port within the <Connector> element.
-
Edit webapps/juddiv3/WEB-INF/classes/juddiv3.xml and change the port number jUDDI Server Baseurl.
-
Edit webapps/juddiv3/WEB-INF/config.properties and change the port numbers for "securityurl" and "juddipapi".
-
Edit webapps/juddi-gui/META-INF/config.properties and change the port numbers for all of the URLs listed.
There are a few options for deploying jUDDI to another application server and/or web service stack. . Grab the default prebuilt war file and modify it to work in your environment . Download the source code for jUDDI and run the maven integration script. Use the following steps
-
Target platform Tomcat and Derby using OpenJPA and CXF. Both OpenJPA and CXF are packaged up in the juddiv3.war. <pre> mvn clean package -P openjpa </pre>
-
Target platform Tomcat and Derby using Hibernate and CXF. Both Hibernate and CXF are packaged up in the juddiv3.war. <pre> mvn clean package -P hibernate </pre>
-
Target platform Tomcat and Derby using OpenJPA and Apache Axis2. Both Hibernate and Axis2 are packaged up in the juddiv3.war. <pre> mvn clean package -P axis2 </pre>
-
Target platform JBoss-6.x and HSQL using Hibernate and JBossWS-native. The juddiv3.war relies on Hibernate and JBossWS-native in the appserver. <pre> mvn clean package -P hibernate-jbossws-native </pre>
-
Target platform JBoss-6.x and HSQL using Hibernate and JBossWS-cxf. The juddiv3.war relies on Hibernate and JBossWS-cxf in the appserver. <pre> mvn clean package -P hibernate-jbossws-cxf </pre>
KNOWN ISSUES
-
15:14:37,275 SEVERE [RegistryServlet] jUDDI registry could not be started. org.apache.commons.configuration.ConfigurationException: java.util.zip.ZipException: error in opening zip file: org.apache.commons.configuration.ConfigurationException: org.apache.commons.configuration.ConfigurationException: java.util.zip.ZipException: error in opening zip file
Workaround: deploy juddiv3.war as a directory (not a zip file).
II. JBoss-5.x Note that configuration 3 and 4 will also run on JBoss-5.x, but you may run into the following: ERROR [org.jboss.ws.metadata.wsdl.xmlschema.JBossXSErrorHandler] (main) [domain:http://www.w3.org/TR/xml-schema-1]::[key=src-resolve]::Message=src-resolve: Cannot resolve the name ns1:Signature to a element declaration component. for which there is the following workaround:
-
Unzip the deployers/jbossws.deployer/jbossws-native-core.jar and add the xmldsig-core-schema.xsd in the schema directory,
10293 Fri May 27 14:40:40 EDT 2011 schema/xmldsig-core-schema.xsd
-
Edit the file META-INF/jbossws-entities.properties by adding a line at the bottom saying:
http\://www.w3.org/2000/09/xmldsig#=schema/xmldsig-core-schema.xsd
If you are using Hibernate as a persistence layer for jUDDI, then Oracle will generate a default sequence for you ("HIBERNATE_SEQUENCE"). If you are using hibernate elsewhere, you may wish to change the sequence name so that you do not share this sequence with any other applications. If other applications try to manually create the default hibernate sequence, you may even run into situations where you find conflicts or a race condition.
The easiest way to handle this is to create an orm.xml file and place it within the classpath in a META-INF directory, which will override the jUDDI persistence annotations and will allow you to specify a specific sequence name for use with jUDDI. The following orm.xml specifies a "juddi_sequence" sequence to be used with jUDDI.
<entity-mappings
xmlns="http://java.sun.com/xml/ns/persistence/orm"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm http://java.sun.com/xml/ns/persistence/orm_1_0.xsd"
version="1.0">
<sequence-generator name="juddi_sequence" sequence-name="juddi_sequence"/>
<entity class="org.apache.juddi.model.Address">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.AddressLine">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.BindingDescr">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.BusinessDescr">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.BusinessIdentifier">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.BusinessName">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.CategoryBag">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.Contact">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.ContactDescr">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.DiscoveryUrl">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.Email">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.InstanceDetailsDescr">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.InstanceDetailsDocDescr">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.KeyedReference">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.KeyedReferenceGroup">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.OverviewDoc">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.OverviewDocDescr">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.PersonName">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.Phone">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.ServiceDescr">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.ServiceName">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.SubscriptionMatch">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.TmodelDescr">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.TmodelIdentifier">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.TmodelInstanceInfo">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.TmodelInstanceInfoDescr">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.TransferTokenKey">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.BindingTemplate">
<attributes>
<basic name="accessPointUrl">
<column name="access_point_url" length="4000"/>
</basic>
</attributes>
</entity>
</entity-mappings>
jUDDI supports both OpenJPA and Hibernate as persistence providers. If you are embedding jUDDI, it is important to note that there are two JARs provided through maven. If you will be using Hibernate, please use the juddi-core JAR, if you are using OpenJPA, use juddi-core-openjpa.
The difference between these JARs is that the persistence classes within juddi-core-openjpa have been enhanced (http://people.apache.org/~mprudhom/openjpa/site/openjpa-project/manual/ref_guide_pc_enhance.html). Unfortunately, the Hibernate classloader does not deal well with these enhanced classes, so it it important to note not to use the juddi-core-openjpa JAR with Hibernate.
The jUDDI codebase uses the commons-logging-api, and log4j as the default logging implementation. The juddiv3/WEB-INF/classes/commons-logging.properties sets the logging to log4j. The default log4j configuration logs to a juddi.log file in the tomcat/logs directory. The log4j configuration lives in the juddiv3/WEB-INF/classes/log4j.properties file, which is referenced in the web.xml
<context-param>
<param-name>log4jConfigLocation</param-name>
<param-value>/WEB-INF/classes/log4j.properties</param-value>
</context-param>
The commons-logging and log4j jars are shipped in the juddiv3/WEB-INF/lib directory.
If you are using CXF for the webservice stack you can log the request/response xml by adding
log4j.category.org.apache.cxf=INFO
to your log4j.properties and the cxf.xml file should contains this:
<cxf:bus>
<cxf:features>
<cxf:logging/>
</cxf:features>
</cxf:bus>
The jUDDI beans.xml specifies the location of this file at _META-INF/cxf/cxf.xml_.
= Administering the GUI (juddi-gui.war)
There are a few things worth mentioning for administering the jUDDI Graphical User Interface. The first is user authentication, which is covered in the authentication chapter. The other the the Digital Signature Applet. This applet enables users to digitally signed UDDI entities via the GUI. There are a number of requirements in order for this to work.
. The applet must be digitally signed. It is recommended that this signed by the administrator using the SSL certificate of the jUDDI instance. If it is not signed, it may not be able to digital certificates.
. The Oracle Java browser plugin must be installed. For details on this, visit Oracle's website.
. The end user must have a digital certificate installed that is accessible to the browser. On Windows computers, this is supported by Internet Explorer, Opera and Chrome which use the Windows Certificate Store (Start > Run > MMC, Add Certificates). Firefox uses its own certificate store. On MacOS, Safari uses the Mac Keychain.
== Task: Signing the Digital Signature Applet jar file
----
jarsigner -keystore your.keystore -storepass yourpass -keypass keypass <pathto>/juddi-gui.war/applets/juddi-gui-dsig-all.jar
----
Note: Jarsigner comes with most JDKs and has many command line options.