juddi-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From acutri...@apache.org
Subject cvs commit: ws-juddi/site/src/documentation/content/xdocs install.xml participate.xml site.xml
Date Wed, 07 Apr 2004 17:25:40 GMT
acutright    2004/04/07 10:25:40

  Modified:    site/src/documentation/content/xdocs install.xml
                        participate.xml site.xml
  Log:
  changes to link wiki and associated documentation into website. also
  moved the 'Wiki' menu item from the FAQ page to the Participation page
  
  Revision  Changes    Path
  1.5       +74 -74    ws-juddi/site/src/documentation/content/xdocs/install.xml
  
  Index: install.xml
  ===================================================================
  RCS file: /home/cvs/ws-juddi/site/src/documentation/content/xdocs/install.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- install.xml	6 Apr 2004 00:34:31 -0000	1.4
  +++ install.xml	7 Apr 2004 17:25:40 -0000	1.5
  @@ -7,27 +7,27 @@
     <body>
       <section>
         <title>Requirements</title>
  -      <p>jUDDI is a pure Java web application and as such can be deployed to 
  -        any application server or servlet engine that supports version 2.1 or 
  -        later of the servlet API. If you need an application server, we 
  -        recommend <link href="http://jakarta.apache.org/tomcat/">Jakarta 
  -        Tomcat</link>.  Note also that jUDDI requires Java 1.3 or later. As 
  -        with any Java web application, deployment to your application server 
  -        or servlet engine will vary on a product-by-product basis. 
  -		 </p>
  -      <p>Instructions for deploying jUDDI to several application servers have 
  -        been donated and are available in the <link href="/howto">HOWTO</link>

  -        section of the jUDDI documentation.
  -			</p>			
  +      <p>jUDDI is a pure Java web application and as such can be deployed to
  +        any application server or servlet engine that supports version 2.1 or
  +        later of the servlet API. If you need an application server, we
  +        recommend <link href="http://jakarta.apache.org/tomcat/">Jakarta
  +        Tomcat</link>.  Note also that jUDDI requires Java 1.3 or later. As
  +        with any Java web application, deployment to your application server
  +        or servlet engine will vary on a product-by-product basis.
  +                 </p>
  +      <p>Instructions for deploying jUDDI to several application servers have
  +        been donated and are available in the <link href="http://wiki.apache.org/ws/jUDDI">HOWTO</link>
  +        section of the jUDDI wiki.
  +                        </p>
         <p>jUDDI also requires an external datastore in which to save and search
  -        for published web services data. Database schemas for several 
  -        different relational database are included with the jUDDI release. 
  +        for published web services data. Database schemas for several
  +        different relational database are included with the jUDDI release.
           Again, instructions describing how to create a jUDDI datastore using
  -        several different database servers are available in the 
  -        <link href="/howto">HOWTO</link> section of the jUDDI documentation.

  -			</p>			
  +        several different database servers are available in the
  +        <link href="http://wiki.apache.org/ws/jUDDI">HOWTO</link> section of
the jUDDI wiki.
  +                        </p>
       </section>
  -    
  +
       <section>
         <title>Configuration</title>
         <p>To properly configure and deploy jUDDI it will be helpful to understand
  @@ -36,67 +36,67 @@
           function and marshalling UDDI responses (marshalling and unmarshalling
           is the process of converting XML data to/from Java objects).
         </p>
  -      <p>To invoke a UDDI function jUDDI employs the services of three 
  -        configurable sub-components or modules that handle persistence (the 
  -        DataStore), authentication (the Authenticator) and the generation of 
  -        UUID's (the UUIDGen). jUDDI is bundled and pre-configured to use 
  -        default implementations of each of these modules to help you get 
  -        jUDDI up and running quickly. The module categories and a 
  +      <p>To invoke a UDDI function jUDDI employs the services of three
  +        configurable sub-components or modules that handle persistence (the
  +        DataStore), authentication (the Authenticator) and the generation of
  +        UUID's (the UUIDGen). jUDDI is bundled and pre-configured to use
  +        default implementations of each of these modules to help you get
  +        jUDDI up and running quickly. The module categories and a
           description of the default implementations are described below.
         </p>
  -      <p>Several public Java interfaces for creating your own DataStore, 
  -        Authenticator and UUIDGen module implementations are available. Please 
  -        see the <link href="/devguide.html">jUDDI Developer's Guide</link>
for 
  +      <p>Several public Java interfaces for creating your own DataStore,
  +        Authenticator and UUIDGen module implementations are available. Please
  +        see the <link href="/devguide.html">jUDDI Developer's Guide</link>
for
           more information regarding jUDDI module development.
         </p>
       </section>
   
       <section>
         <title>Persistence (jUDDI DataStore)</title>
  -      <p>The default jUDDI DataStore is implemented using JDBC and the process 
  -        of setting this up is fairly straight forward. Start by creating a new 
  +      <p>The default jUDDI DataStore is implemented using JDBC and the process
  +        of setting this up is fairly straight forward. Start by creating a new
           jUDDI database using one of the following database schemas.
         </p>
         <p>
  -        <link href="dbscripts/juddi_mysql.ddl">MySQL</link> 
  +        <link href="dbscripts/juddi_mysql.ddl">MySQL</link>
           <link href="dbscripts/juddi_db2.ddl">DB2</link>
           <link href="dbscripts/juddi_hsql.ddl">HSQL</link>
  -        <link href="dbscripts/juddi_ase.ddl">Sybase</link> 
  +        <link href="dbscripts/juddi_ase.ddl">Sybase</link>
           <link href="dbscripts/juddi_postresql.ddl">PostreSQL</link>
           <link href="dbscripts/juddi_oracle.ddl">Oracle</link>
           <link href="dbscripts/juddi_totalxml.ddl">TotalXML</link>
           <link href="dbscripts/juddi_jds.ddl">JDataStore</link> (Borland)
         </p>
  -      <p>If a schema for your DBMS is not listed, one simply hasn't been 
  -        created yet. You can use the available schemas as a guide for 
  -        creating one (and if you're feeling generous please consider 
  +      <p>If a schema for your DBMS is not listed, one simply hasn't been
  +        created yet. You can use the available schemas as a guide for
  +        creating one (and if you're feeling generous please consider
           contributing it).
         </p>
  -      <p>To complete the DataStore set up you'll need to configure a JNDI 
  -        Datasource named 'jdbc/juddiDB' in the application server or servlet 
  -        engine that you're deploying to. Datasource setup varies on an 
  -        product-by-product basis so review documentation for your application 
  -        server. If you're deploying jUDDI to Jakarta Tomcat, take a look at 
  +      <p>To complete the DataStore set up you'll need to configure a JNDI
  +        Datasource named 'jdbc/juddiDB' in the application server or servlet
  +        engine that you're deploying to. Datasource setup varies on an
  +        product-by-product basis so review documentation for your application
  +        server. If you're deploying jUDDI to Jakarta Tomcat, take a look at
           the JNDI Datasource HOW-TO for assistance.
         </p>
       </section>
   
       <section>
         <title>Authentication (jUDDI Authenticator)</title>
  -      <p>Authenticating a jUDDI publisher is a two-step process. The first step 
  -        confirms that the ID/password combination provided by the user is valid. 
  -        It is expected that a typical jUDDI deployment will use an external 
  -        authentication mechanism. The default authentication module simply 
  -        approves any authentication attempt. It is our hope that additional 
  -        jUDDI authentication implementations will be developed by jUDDI users 
  -        as they determine how they would like authentication to take place in 
  -        their particular environment. See the jUDDI Developers Guide for more 
  +      <p>Authenticating a jUDDI publisher is a two-step process. The first step
  +        confirms that the ID/password combination provided by the user is valid.
  +        It is expected that a typical jUDDI deployment will use an external
  +        authentication mechanism. The default authentication module simply
  +        approves any authentication attempt. It is our hope that additional
  +        jUDDI authentication implementations will be developed by jUDDI users
  +        as they determine how they would like authentication to take place in
  +        their particular environment. See the jUDDI Developers Guide for more
           information on developing a custom jUDDI authentication module.
         </p>
  -      <p>The second step confirms that the publisher has been defined to 
  -        jUDDI. A publisher is said to be defined when a row identifying the 
  -        publisher exists in the PUBLISHER table of the jUDDI datastore. At the 
  -        moment the only way to do this is via SQL. An example of defining a 
  +      <p>The second step confirms that the publisher has been defined to
  +        jUDDI. A publisher is said to be defined when a row identifying the
  +        publisher exists in the PUBLISHER table of the jUDDI datastore. At the
  +        moment the only way to do this is via SQL. An example of defining a
           new publisher named John Doe would look like this:
         </p>
         <p>
  @@ -107,45 +107,45 @@
           are required and they are defined as follows:
         </p>
         <p>
  -         Column Name Description 
  -         PUBLISHER_ID The user ID the publisher uses when authenticating. IMPORTANT: This
should be the same value used to authenticate with the external authentication service.  
  -         PUBLISHER_NAME The publisher's name (or in UDDI speak the Authorized Name). 
  -         ADMIN Indicate if the publisher has administrative privileges. Valid values for
this column are 'true' or 'false'. The ADMIN value is currently not used. 
  -         ENABLED Indicate if the publishers account is enabled and eligible for use. 
  -      </p>
  -      <p>The jUDDI web application will (eventually) be extended to facilitate 
  -        the Publisher creation process. The value of the ADMIN column in the 
  -        PUBLISHER table above will be used to determine who has the privilege 
  +         Column Name Description
  +         PUBLISHER_ID The user ID the publisher uses when authenticating. IMPORTANT: This
should be the same value used to authenticate with the external authentication service.
  +         PUBLISHER_NAME The publisher's name (or in UDDI speak the Authorized Name).
  +         ADMIN Indicate if the publisher has administrative privileges. Valid values for
this column are 'true' or 'false'. The ADMIN value is currently not used.
  +         ENABLED Indicate if the publishers account is enabled and eligible for use.
  +      </p>
  +      <p>The jUDDI web application will (eventually) be extended to facilitate
  +        the Publisher creation process. The value of the ADMIN column in the
  +        PUBLISHER table above will be used to determine who has the privilege
           to create new jUDDI publishers.
         </p>
       </section>
   
       <section>
         <title>UUID Generation (jUDDI UUIDGen)</title>
  -      <p>There's nothing for you to do here but I thought I'd offer a little 
  +      <p>There's nothing for you to do here but I thought I'd offer a little
           information about how, why and where jUDDI makes use of UUID generation.
         </p>
  -      <p>The UDDI specification indicates that each Business, Service, Binding 
  -        and TModel (Technical Model) is to be uniquely identified by a 
  -        Universally Unique ID (UUID). Additionally, jUDDI also uses the UUID 
  +      <p>The UDDI specification indicates that each Business, Service, Binding
  +        and TModel (Technical Model) is to be uniquely identified by a
  +        Universally Unique ID (UUID). Additionally, jUDDI also uses the UUID
           generator to create AuthTokens.
         </p>
  -      <p>Generation of UUID's typically requires access to hardware level 
  -        information that (unfortunately) is not accessible from Java. 
  -        Fortunately, the UUID specification offers an alternative method for 
  -        generating these ID's when this hardware information is not present. 
  +      <p>Generation of UUID's typically requires access to hardware level
  +        information that (unfortunately) is not accessible from Java.
  +        Fortunately, the UUID specification offers an alternative method for
  +        generating these ID's when this hardware information is not present.
           By default the jUDDI implements this alternative method.
         </p>
       </section>
   
       <section>
         <title>Logging</title>
  -      <p>When deploying jUDDI you may wish to make changes to the 
  -       juddi.properties and log4j.properties files. These files are located in 
  -       the juddi webapp's WEB-INF/classes directory. They're here because 
  -       they need to be in the classpath for jUDDI to locate and load them at 
  -       runtime. One Log4j property value that you'll most likely want to set 
  -       is log4j.appender.LOGFILE.File which specifies the name and location of 
  +      <p>When deploying jUDDI you may wish to make changes to the
  +       juddi.properties and log4j.properties files. These files are located in
  +       the juddi webapp's WEB-INF/classes directory. They're here because
  +       they need to be in the classpath for jUDDI to locate and load them at
  +       runtime. One Log4j property value that you'll most likely want to set
  +       is log4j.appender.LOGFILE.File which specifies the name and location of
          the jUDDI log file.
         </p>
       </section>
  
  
  
  1.4       +11 -0     ws-juddi/site/src/documentation/content/xdocs/participate.xml
  
  Index: participate.xml
  ===================================================================
  RCS file: /home/cvs/ws-juddi/site/src/documentation/content/xdocs/participate.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- participate.xml	23 Mar 2004 20:18:24 -0000	1.3
  +++ participate.xml	7 Apr 2004 17:25:40 -0000	1.4
  @@ -67,6 +67,17 @@
             <link href="http://www.catb.org/~esr/faqs/smart-questions.html">"How to
Ask Questions The Smart Way</link>.
             </p>
         </section>
  +      <section>
  +        <title>jUDDI Wiki</title>
  +        <p>Like other Apache projects, jUDDI maintains a wiki, a sort of virtual
  +          meeting place for the jUDDI community. This is a resource available
  +          to everyone, and you are encouraged to contribute. This is a good resource
  +          for 'HowTos' for common configuration issues.
  +          <ul>
  +            <li> <link href="http://wiki.apache.org/ws/jUDDI">http://wiki.apache.org/ws/jUDDI</link></li>
  +          </ul>
  +          </p>
  +      </section>
   
     </body>
   </document>
  
  
  
  1.10      +2 -2      ws-juddi/site/src/documentation/content/xdocs/site.xml
  
  Index: site.xml
  ===================================================================
  RCS file: /home/cvs/ws-juddi/site/src/documentation/content/xdocs/site.xml,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- site.xml	22 Mar 2004 19:00:51 -0000	1.9
  +++ site.xml	7 Apr 2004 17:25:40 -0000	1.10
  @@ -19,10 +19,10 @@
     <juddi label="jUDDI">
       <welcome label="Introduction" href="index.html" description="Introduction"/>
       <news label="News" href="news.html" description="News"/>
  -    <faq label="FAQ/Wiki" href="faq.html" description="FAQ"/>
  +    <faq label="FAQ" href="faq.html" description="FAQ"/>
       <cvs label="CVS Repository" href="cvs.html" description="CVS Repository"/>
       <lists label="Mailing Lists" href="lists.html" description="Mailing Lists"/>
  -    <participate label="Participation" href="participate.html" description="Participation"/>
  +    <participate label="Participation/Wiki" href="participate.html" description="Participation"/>
       <reference label="Reference Library" href="library.html" description="Reference
Library"/>
       <bugs label="Bugs" href="bugs.html" description="Bug Tracking"/>
     </juddi>
  
  
  

Mime
View raw message