Docstoc
EXCLUSIVE OFFER FOR DOCSTOC USERS
Try the all-new QuickBooks Online for FREE.  No credit card required.

Developer Guide Chicago Real Estate

Document Sample
Developer Guide Chicago Real Estate Powered By Docstoc
					   National Association of Realtors




   National Association of Realtors
RETS 1.5 Reference Implementation
                Developer's Guide

                         Version 1.5.1
NAR RETS 1.0 Reference Implementation                                      Version:        1.5.1
Developer's Guide                                                          Date:          9/8/2011
be278102-6387-4e2e-8531-20a126ded030.doc


                                    Revision History
         Date             Version                   Description                            Author
2002/01/07              1.0           Initial Document                          Jeff Brush - Avantia, Inc
2002/10/25              1.5           RETS 1.5 updates                          Tom Weber - Avantia, Inc
2003/10/20              1.5.1         Added Update transaction and              Paula O’Brien – Avantia, Inc.
                                      Validation Engine; using HttpClient for
                                      connection management




Public Documentation                National Association of Realtors,                                 Page 2
                                                 2011
NAR RETS 1.0 Reference Implementation                                       Version:        1.5.1
Developer's Guide                                                           Date:          9/8/2011
be278102-6387-4e2e-8531-20a126ded030.doc


                                     Table of Contents
1.   Introduction                                                                                            5
     1.1    RETS Functionality - What’s New                                                                  5
     1.2    Other Changes                                                                                    5

2.   RETS Reference Implementation Architecture                                                              7
     Figure 1 show the basic architecture of the RETS Reference Implementation. The RETS Client is
     implemented as a web application, an HTML interface passes user requests to the RETS Client API,
     the Client API builds and sends RETS Transactions to the RETS Server. The RETS Server is
     implemented as a Servlet. The Data Access Interface provides access to the MySQL datastore.             7
     2.1    The Login Transaction Client Side – high level overview                                          7
     2.2    The Login Transaction Server Side                                                                8

3.   RETS Server Implementation                                                                              9
     3.1    RETSServer                                                                                       9
     3.2    RETSResponse                                                                                     9
     3.3    RETSServerResponse                                                                               9
     3.4    RETSResonseFactory                                                                               9
     3.5    RETSLoginResponse                                                                                9
     3.6    RETSLogoutResponse                                                                              10
     3.7    RETSGetObjectResponse                                                                           10
     3.8    RETSActionResponse                                                                              10
     3.9    RETSSearchResponse                                                                              10
     3.10     RETSPropertySearchResponse                                                                    10
     3.11     RETSAgentSearchResponse                                                                       10
     3.12     RETSOfficeSearchResponse                                                                      10
     3.13     RETSGetMetadataResponse                                                                       10
     3.14     RETSUpdateResponse                                                                            10

4.   RETS Client Implementation                                                                             11
     4.1    RETSConnection                                                                                  11
     4.2    RETSTransaction                                                                                 11
     4.3    RETSLoginTransaction                                                                            11
     4.4    RETSLogoutTransaction                                                                           11
     4.5    RETSGetObjectTransaction                                                                        11
     4.6    RETSActionTransaction                                                                           11
     4.7    RETSGetMetadataTransaction                                                                      12
     4.8    RETSSearchTransaction                                                                           12
     4.9    RETSSearchAgentTransaction                                                                      12
     4.10     RETSSearchOfficeTransaction                                                                   12
     4.11     RETSSearchPropertyTransaction                                                                 12
     4.12     RETSLogoutTransaction                                                                         12
     4.13     RETSUpdateTransaction                                                                         12

5.   DMQL                                                                                                   12

6.   Persistence                                                                                            13

7.   OJB Persistence for Update                                                                             14
Public Documentation                  National Association of Realtors,                                Page 3
                                                   2011
NAR RETS 1.0 Reference Implementation                                         Version:    1.5.1
Developer's Guide                                                             Date:      9/8/2011
be278102-6387-4e2e-8531-20a126ded030.doc

8.    Compression                                                                                       15

9.    Validation Engine                                                                                 15

10.          Monitoring and logging                                                                     16
      10.1      Logging - Apache Log4J                                                                  16
      10.2      RETSMonitor                                                                             16




Public Documentation                     National Association of Realtors,                         Page 4
                                                      2011
NAR RETS 1.0 Reference Implementation                                             Version:        1.5.1
Developer's Guide                                                                 Date:          9/8/2011
be278102-6387-4e2e-8531-20a126ded030.doc


                                       Developer's Guide
1.       Introduction
The National Association of Realtors has defined a set of standards for the exchange of Real Estate data. The Real
Estate Transaction Standard (RETS) consists of a transaction specification and an XML DTD. See http://www.rets-
wg.org for details of the RETS specification. The RETS 1.5 Reference Implementation extends the earlier
RETS1.0 Reference Implementation and is intended to be used as a testing platform for those who wish to develop
servers and clients that conform to the RETS 1.5 specification. Both a client and server are provided by the
reference implementation as well as a limited set of test data.

The RETS Reference Implementation is written in Java, the server is a Java servlet and the client consists of API
classes and JSP pages. This software was developed for Apache Tomcat 4.1.27 as the Servlet/JSP engine and
MySQL 4.0.15 as the database engine. The RETS Reference Implementation should work with any Servlet engine
that supports the 2.2 or 2.3 Servlet Specification and the 1.1 or 1.2 JSP specification. More information for each of
the classes can be found in the API documentation (JAVADOC) provided with the reference implementation.


1.1      RETS Functionality - What’s New

This version of the RETS Reference Implementation adds support for the Update transaction on both the client and
server side. This includes a Validation Rules Engine used to process Validation Expressions contained within the
Server’s metadata. The Validation Rules Engine is a utility that can be used by either the client or the server. For
demonstration purposes in this release, we have chosen to implement the Validation Rules Engine from within the
client application.

When implementing Update (as found in the RETS 1.5 d2 specification, Section 10) and Validation Expressions (as
found in the RETS 1.5 d2 specification, Section 11.4.9), we encountered ambiguities in the specification and the
Validation Expression language. In order to implement validation expressions, we made the following assumptions
to address those issues:
     1) The Sequence Element found the UpdateField element in the Metadata refers to the order in which
         validation is processed. I.e., a sequence of “1” means that the validation for this field is performed first.
     2) The transaction-id tag in the Update Response body is represented as <TRANSACTION-ID> and it is a
         unique value assigned by the RETS Server. For the reference implementation, we are using a timestamp in
         milliseconds.
     3) The <COLUMNS> and <DATA> returned in the Update Response body are the <COLUMNS> and
         <DATA> that represent the values for all updateable fields for that Resource/Class/Update Type in the
         Metadata.
     4) For Validation Expressions, the correct literal data format requires dashes, i.e., 2003-10-21.
     5) Time and Datetime formats are not handled by the Validation Expression language, only Date.
     6) String literals are quoted in the Validation Expression language.
     7) Interval literals may or may not be quoted in the Validation Expression language. If the literal is formatted
         like an interval, it is assumed to be an interval. I.e., P20Y and “P20Y” are assumed to be intervals.
     8) String concatenation is not allowed by the Validation Expression language.
     9) .TODAY. is a datetime at 00:00 hours in the Validation Expression language.
     10) .NOW. is the current date and time in the Validation Expression language.
     11) In arithmetic operations involving .TODAY. and .NOW. are expressed as days. I.e., “.TODAY.-3” today
         minus three days and “.NOW.+9” is now plus nine days.


1.2      Other Changes
The following additional changes were made to the Reference Implementation client and/or server to increase
performance and stability and to more completely support the standard:
Public Documentation                    National Association of Realtors,                                    Page 5
                                                     2011
NAR RETS 1.0 Reference Implementation                                          Version:        1.5.1
Developer's Guide                                                              Date:          9/8/2011
be278102-6387-4e2e-8531-20a126ded030.doc

       HttpClient – in leveraging this library, we abstracted the details of Http handling. Jakarta’s HttpClient
        component provides an efficient, up-to-date, and feature-rich package implementing the client side of the
        most recent HTTP standards and recommendations. For more details on HttpClient, please see:
        http://jakarta.apache.org/commons/httpclient/
       Update persistence layer uses Object Relational Bridge (OJB). OJB is an Object/Relational mapping tool
        that allows transparent persistence for Java Objects against relational databases. With advanced object
        relational features and the ability to support multiple persistence APIs, OJB is designed to maximize
        flexibility, scalability and functionality. For more details on using OJB, please see:
        http://db.apache.org/ojb/index.html
       Test Driven Development with JUnit: Test driven development , also known as test-first programming or
        test-first development, is an evolutionary approach to development where you must first write a test that
        fails before you write new functional code. Avantia applied the test driven development approach to create
        and apply the validation rules engine. The tests were created using JUnit, a simple Java framework to write
        repeatable tests. To learn more about JUnit or expand upon the tests included here, please see:
        http://junit.sourceforge.net/
       Upgraded database to MySQL 4.0.15: http://www.mysql.com/downloads/mysql-4.0.html




Public Documentation                   National Association of Realtors,                                  Page 6
                                                    2011
NAR RETS 1.0 Reference Implementation                                           Version:        1.5.1
Developer's Guide                                                               Date:          9/8/2011
be278102-6387-4e2e-8531-20a126ded030.doc



2.      RETS Reference Implementation Architecture

Figure 1 show the basic architecture of the RETS Reference Implementation. The RETS Client is
implemented as a web application, an HTML interface passes user requests to the RETS Client API, the
Client API builds and sends RETS Transactions to the RETS Server. The RETS Server is implemented
as a Servlet. The Data Access Interface provides access to the MySQL datastore.




                                          Figure 1 Architecture Diagram



2.1     The Login Transaction Client Side – high level overview


Figure 2 is a sequence diagram for a login transaction from the RETS client perspective. “loginAction.jsp” is parsed
when a user selects submit on the login page. “loginAction.jsp” creates an instance of RETSLoginTransaction and
an instance of RETSConnection. The “execute()” method of the RETSConnection object is called passing the
LoginTransaction as an argument. RETSConnection sends the request to the RETSServer identified by the
“serverURL” variable of the Transaction. The RETSServer response is parsed by the RETSConnection object and
the “set Response()” method is called on the Transaction object to complete the transaction. “loginAction.jsp” calls
the Transaction’s “getResponseMap()” method and formats the response for display to the browser.




Public Documentation                    National Association of Realtors,                                  Page 7
                                                     2011
NAR RETS 1.0 Reference Implementation                                                           Version:       1.5.1
Developer's Guide                                                                               Date:         9/8/2011
be278102-6387-4e2e-8531-20a126ded030.doc



                                                                                                                     : RETSServer



         la : loginAction.jsp

                                <<create>>    trans : RETSLoginTransaction

                                 <<create>>                                        conn : RETSConnection


                                             execute(trans)
                                                              getRequestVariable("serverURL")

                                                              getResponseVariable("username")

                                                              getRequestVariable("password")


                                                                    getRequestMap( )


                                                                                                     requestStream


                                                                                                     responseStream
                                                                setResponse(responseText)




                                getResponseMap()




                                               Figure 2 Login Transaction Client side


2.2      The Login Transaction Server Side

Figure 3 is a sequence diagram for the login transaction on the Server side. When the RETSServer receives a client
request, it creates an instance of a Response object appropriate to the request (transaction) received, in this case a
RETSLoginResponse instance is created. The RETSServer streams the response from the “RETSLoginResponse”
back to the client.




Public Documentation                            National Association of Realtors,                                             Page 8
                                                             2011
NAR RETS 1.0 Reference Implementation                                             Version:         1.5.1
Developer's Guide                                                                 Date:           9/8/2011
be278102-6387-4e2e-8531-20a126ded030.doc


            :                           srv : RETSServer
      RETSConnection
                      requestStream


                                                      create(user)       loginResponse : RETSLoginResponse


                                                               getResponse( )

                                                                getStatus( )

                       responseStream




                                       Figure 3 Server side of the Transaction



3.       RETS Server Implementation
Figure 4 is a class diagram of the RETS Server side classes. There are actually more classes involved than those
shown in this diagram. Because this reference implementation support both the 1.5 and 1.0 specification, there are
two sets of RETSxxxResponse classes, one set in the package “org.realtor.rets.server.v10”, and one set in
“org.realtor.rets.server.v15”. Only one set of classes is shown in the diagram to make it less cluttered and easier to
understand.
3.1      RETSServer
Extends HTTPServlet, all client requests are received by RETSServer. RETSServer deals with the RETS header
information and creates an instance of the appropriate RETSResponse object to handle the client request transaction.
User session attributes are maintained by this class.
3.2     RETSResponse
An abstract class for handling client transaction requests. Classes extending RETSResponse must implement the
buildResponse() method.
3.3      RETSServerResponse
This class handles requests not recognized or supported by the server. Sends error response back to the client
application.
3.4     RETSResonseFactory
The response factory object builds a RETSResponse object based on the request from the client and level of support
claimed by the client. If a client claims to support version 1.5 of the RETS Specification, the factory create a 1.5
response object. 1.0 response objects are created if the client supports 1.0 of the specification.
3.5      RETSLoginResponse
Builds the response to a login transaction request. The bulk of the work for a login transaction request is currently
done in the RETSServer, the server looks up the user in the database and stores the user object as a session attribute.
The RETSLoginResponse simply builds the to the login transaction request.


Public Documentation                     National Association of Realtors,                                    Page 9
                                                      2011
NAR RETS 1.0 Reference Implementation                                            Version:        1.5.1
Developer's Guide                                                                Date:          9/8/2011
be278102-6387-4e2e-8531-20a126ded030.doc

3.6      RETSLogoutResponse
Builds the response to a logout transaction request.
3.7      RETSGetObjectResponse
Builds the a list of response objects in response to a GetObject transaction request. RETSServer uses the list
response objects to create a multipart response.

RETSActionResponse           RETSLoginResponse           RETSLogoutResponse             RETSServerResponse




                                                                              <<abstract>>
            RETSServer                 RETSResponseFactory
                                                                            RETSResponse




   RETSGetObjectResponse                   RETSSearchResponse               RETSGetMetadataResponse




 RETSOfficeSearchResponse              RETSAgentSearchResponse              RETSPropertySearchResponse




                                             Figure 4 Server Side Classes
3.8      RETSActionResponse
Builds a reply to a RETS Action request.
3.9      RETSSearchResponse
This class is extended to provide search response support for “Property”, “Agent” and “Office” searches.
3.10    RETSPropertySearchResponse
Extends RETSSearchResponse to support Property search requests.
3.11    RETSAgentSearchResponse
Extends RETSSearchResponse to support Agent search requests.
3.12    RETSOfficeSearchResponse
Extends RETSSearchResponse to support Office search requests.
3.13     RETSGetMetadataResponse
Builds response to get Metadata transaction request. The XML file “RETSMetadata.xml” contains the metadata for
the RETS Reference Implementation. RETSGetMetatDataResponse searches “RETSMetadata.xml” for the
requested metadata object to build the reply.
3.14      RETSUpdateResponse
Builds response Update transaction request. Uses the DataFactory and updates the databases for changes/additions
to agent, office and property data.

Public Documentation                     National Association of Realtors,                                  Page 10
                                                      2011
NAR RETS 1.0 Reference Implementation                                            Version:        1.5.1
Developer's Guide                                                                Date:          9/8/2011
be278102-6387-4e2e-8531-20a126ded030.doc

4.       RETS Client Implementation
The client is implemented as a series of JSP pages that use the Client API to connect to the server and send
transactions. Figure 5 is a class diagram of the RETS Client API.
4.1      RETSConnection
Used to establish a connection to a RETS Server. RETSConnection also handles building the required header fields
for the RETS Specification (see Section 3) as well as filtering the header information in responses returned from the
server. All transactions are sent to RETS servers through using the “execute()” method of the RETSConnection
object.
RETSGetObjectTransaction RETSLoginTransaction RETSLogoutTransaction RETSActionTransaction




                                                RETSTransaction                    RETSConnection




      RETSGetMetadataTransaction             RETSSearchTransaction RETSChangePasswordTransaction




     RETSSearchPropertyTransaction        RETSSearchAgentTransaction          RETSSearchOfficeTransaction




                                         Figure 5 RETS Client API Classes




4.2      RETSTransaction
Generic RETS Transaction. Extends “RETSRequestResponse” to deal with transaction responses from the server.
The classes listed below extend RETSTransaction.
4.3      RETSLoginTransaction
Builds the login transaction. The methods “setUsername()” and “setPassword()” are used to set the required
parameters for the login transaction.
4.4      RETSLogoutTransaction
Builds the logout transaction request.
4.5      RETSGetObjectTransaction
Builds the get object transaction request.
4.6      RETSActionTransaction
Builds an Action transaction request to sent a RETS server.



Public Documentation                     National Association of Realtors,                                    Page 11
                                                      2011
NAR RETS 1.0 Reference Implementation                                              Version:     1.5.1
Developer's Guide                                                                  Date:       9/8/2011
be278102-6387-4e2e-8531-20a126ded030.doc

4.7      RETSGetMetadataTransaction
Builds the get metadata transaction request.
4.8      RETSSearchTransaction
Builds the search transaction. This class is extended for each type of search transaction.
4.9      RETSSearchAgentTransaction
Builds search transactions requests for agents. Sets the search type to “Agent”.
4.10     RETSSearchOfficeTransaction
Builds search transaction requests for offices.
4.11     RETSSearchPropertyTransaction
Builds search transaction requests for property.
4.12     RETSLogoutTransaction
Builds the Logout transaction request.
4.13     RETSUpdateTransaction
Builds the Update transaction request for agent, office and property.



5.       DMQL
Bruce Toback’s DMQLtoSQL was modified to support DMQL and DMQL2 For more information on Bruce
Toback’s DMQLtoSQL, see the following URL:http://www.optc.com/~btoback/DMQLtoSQLTest/doc/index.html
Figure 6 shows the classes used to implement DMQL support. DMQLtoSQLImpl and DMQLtoSQLImpl are
modeled after Bruce’s DMQLtoSQLTest class. DMQLtoSQLImpl and DMQLtoSQLImpl use SQLTableDescrition
objects to map RETS objects to the SQL tables used for the reference implementation. In DMQLtoSQL and
DMQL2toSQL, the “translate()” method is used to translate DMQL/DMQL2 query strings into SQL where clauses.

The StaticTableDescriptions class stores static table descriptions for Property, Agent and Office searches. These
objects are kept in memory because one or more of these objects are used for every RETS Search transaction,. so it
is much more efficient to keep these objects in memory than loading them for each search transaction.




Public Documentation                     National Association of Realtors,                                Page 12
                                                      2011
NAR RETS 1.0 Reference Implementation                                          Version:       1.5.1
Developer's Guide                                                              Date:         9/8/2011
be278102-6387-4e2e-8531-20a126ded030.doc

     DMQL1Tokenizer                                                                DMQL2Tokenizer


                                            <<interface>>
                                          DMQLTokenizer
      DMQLtoSQL                                                                      DMQ2LtoSQL



     DMQLtoSQLImpl                                                                DMQL2toSQLImpl
+translate(dmql:String)                                                        +translate(dmql:String)

              getTableDescription                                   getTableDescription
                                      StaticTableDescriptions



                                        SQLTableDescription


                                                                            SQLFieldDescription

                                             <<interface>>
                                           TableDescription

                                                                               <<interface>>
                                                                             FieldDescription




                                             Figure 6 DMQL Classes
6.      Persistence
The reference implementation is delivered with three MySQL tables; AGENTS, OFFICES and PROPERTIES. Data
Access Objects (DAO) are mapped to these tables to provide data for the application. All database access is
provided by the class GenericJDBCDAO, this class basically allows other objects to build a SQL query one piece at
a time. The “FROM” clause in the SQL statement is defined by the class using GenericJDBCDAO, this defines
tables and join conditions. For example the “FROM” statement for RetsListingDAO is an outer join between the
property, agent and office tables providing listing information as well as list office and list agent. The “where”
clause is built by translating the DMQL or DMQL2 query submitted with the request.

Figure 7 shows the classes of the persistence package. The AttributeList interface provides two methods,
getAttribute(name:String) and getAttributeType(name:String). This just provides a very generic method of accessing
objects that are basically a collection of attributes. SimpleJDBCConnectionPool provides JDBC connection
pooling for the Reference Implementation.

RetsListingDAO, RetsOfficeDAO and RETSAgentDAO provide access to the associated content in the database.
RetsProperySearch, RetsAgentSearch and RetsOfficeSearch provide convent methods for doing searches using the
associated DAO objects.




Public Documentation                   National Association of Realtors,                                Page 13
                                                    2011
NAR RETS 1.0 Reference Implementation                                            Version:        1.5.1
Developer's Guide                                                                Date:          9/8/2011
be278102-6387-4e2e-8531-20a126ded030.doc

                                       <<interface>>
                                       AttributeList
                      +getAttribute(name:String): String
                      +getAttributeType(name:String): String

                                                                 SimpleJDBCConnectionPool
                                                          -connections: static Collection
                                                          +<<static>> getConnection(): Connection
                                                          +<<static>> release(conn:Connection)

                                        <<abstract>>
                                   GenericJDBCDAO




     RetsListingDAO                   RetsOfficeDAO                    RetsAgentDAO




RetsPropertySearch                  RetsOfficeSearch                 RetsAgentSearch




                                            Figure 7 Persistence classes
7.       OJB Persistence for Update
The update functionality in the reference implementation utilizes Jakarta's Object Java Bridge (OJB). OJB provides
a simple, seamless and database-neutral way to map Objects into a relational database structure. The objects used for
this purpose are in the org.realtor.rets.dataobjects package. The mappings for each object are defined in separate
files in the /etc directory. These files are:
        repository_agent.xml Maps the table AGENTS to the object org.realtor.rets.dataobjects.Agent

        repository_office.xml Maps the table OFFICES to the object org.realtor.rets.dataobjects.Office

        repository_listing.xml Maps the table PROPERTIES to the object org.realtor.rets.dataobjects.Listing (The
         name Property was avoided since Java has a fairly well known Property object)

        repository_database.xml Contains database configuration parameters including database URL and login
         information

        repository.xml Imports all the above files using XML entity references. If additional mapping files are
         required, you can add them to this file and OJB will recognize the new file in its repository.
Each of the data objects has a store() method. When invoked, this method uses the PersistenceFactory object to store
the values into the database.
The PersistenceFactory object has methods for storing objects to and retrieving objects from the database. These
methods utilize ODMG [http://www.odmg.org] Object Query Language (OQL) to specify certain constraints on the
query. Details about OQL can be found on the ODMG site. Currently, only the UID/OID fields are queried upon,
but additional methods can be added that query on other parameters of an object. For instance, It would be trivial to
generate a list of all Listings that had a list date that fell within a certain range.



Public Documentation                    National Association of Realtors,                                  Page 14
                                                     2011
NAR RETS 1.0 Reference Implementation                                            Version:        1.5.1
Developer's Guide                                                                Date:          9/8/2011
be278102-6387-4e2e-8531-20a126ded030.doc

8.       Compression
Compression support for the Reference Implementation is handled by a Servlet Filter. The reference
Implementation supports both GZip and BZip compression The compression filter processes every response before
a reply is sent back to the RETS Client. If the client claims that is support GZip or BZip compression, the
compression filter will compress the reply sent back to the client. The XML below sets up the compression filter
for the rets web application, this piece of XML is taken from the web.xml file for the RETS web application.
…
   <filter>
     <filter-name>Compression Filter</filter-name>
     <filter-class>org.realtor.rets.server.filter.CompressionFilter</filter-class>
     <init-param>
       <param-name>compressionThreshold</param-name>
       <param-value>0</param-value>
     </init-param>
   </filter>
   <filter-mapping>
    <filter-name>Compression Filter</filter-name>
    <servlet-name>RETSServer</servlet-name>
   </filter-mapping>
…

Figure 8 shows the classes involved in supporting compression in the RETS Reference Implementation. This
compression implementation is modeled the intercepting filter design pattern described here :
http://java.sun.com/blueprints/corej2eepatterns/Patterns/InterceptingFilter.html


                                        CompressionFilter




BZipServletResponseWrapper                                   GZipServletResponseWrapper




       BZipRepsonseStream                                           GZipRepsonseStream



                                           Figure 8 Compression Filter


9.       Validation Engine
The validation engine is made up of all packages and objects in org.realtor.rets.validation.
The first step in validation is to obtain the validation expression from the metadata. Once that has been done, the
expression is tokenized into Terms and Operators. A Term is a variable or constant. An Operator is either a
mathematical or logical operation.
The tokens are then loaded into a stack, and the stack is executed using a recursive execution evaluator
(ValidationExpressionEvaluator.java). The result of the validation expression is then returned and processed.
Public Documentation                        National Association of Realtors,                                Page 15
                                                           2011
NAR RETS 1.0 Reference Implementation                                                Version:        1.5.1
Developer's Guide                                                                    Date:          9/8/2011
be278102-6387-4e2e-8531-20a126ded030.doc

The validation evaluator and tokenizer have extensive unit tests associated with them. These tests reside in the
org.realtor.rets.validation.tests package. These tests adhere to the JUnit API, and should be run if any changes are
made to the evaluator. All tests must pass in order to consider the change compliant. Due to the limited scope of the
specification certain assumptions were made about how the validation language should be implemented, these
assumptions are discussed elsewhere in this document.


10.      Monitoring and logging
10.1       Logging - Apache Log4J
Apache Log4J is used for logging by all classes in the reference implementation. By default server side classes write
to the file “/tmp/retsServer.log” and client side classes write to the file “/tmp/retsClientAPI.log”. This is
configurable by modifying the “log4j.properties” files. For more information on Log4J see the following web site:
http://jakarta.apache.org/log4j
10.2      RETSMonitor
The RETSMonitor class is a servlet that streams the contents of a file to an http client. The reference
implementation uses the RETSMonitor servlet to stream the log4j files to web pages. By modifying the
“log4j.properties” determines the contents of the log files. If the debug level is set to “info”, only the transaction
text is written to the log files. If the debug level is set to “debug” more detailed debug information is written to a log
file.




Public Documentation                      National Association of Realtors,                                     Page 16
                                                       2011

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:8
posted:9/9/2011
language:English
pages:16