By tgardner on Oct 05, 2009
- Sun Netra x4250
- 13 millions of entries
- Sun Directory Server 5.2 patch 6
- Solaris 10 update 7
- 17,000 searches per second
SLAMD3 uses a model-view-controller paradigm to separate the view from the internal database action and action processing. The diagram above depicts the flow of browser requests and the SLAMD response, with emphasis on the Struts2 interceptor framework. The operator issues a request via the SLAMD administrative interface which passes through the interceptor stack (from left to right) until it reaches the Action. The Action is selected by the Struts framework based on the URL from the browser request. For example, the URL http://host:port/slamd/ScheduleJob.action results in Struts2 selecting the Action named "ScheduleJob". Actions are comprised of Java code which executes to satisfy the browser request. When the Action completes, it returns a result (in Struts2 the result is a string such as "success" or "failure") which passes back through the interceptor stack, this time from right to left. The result code string determines which JSP is used to generate the HTML that is displayed in the browser.
Interceptors are used to examine the request in a specific order of interception. Interceptors can be grouped together into a "stack", e.g., the "slamdStack". An arbitrary number of interceptors and interceptor stack groupings can be defined in the configuration file struts.xml, which like other configuration files, must be in the CLASSPATH. SLAMD stores the struts.xml file, the slamd.conf file, and the logging configuration file at the root of the CLASSPATH slamd/WEB-INF/classes.
The interceptors in request order are:
An Action executes Java code to fulfill the request from the SLAMD administrative interface. Action objects, for example, com.slamd.struts2.actions.JobActions, are created for each request before the interceptor stack executes, therefore, Action initialization cannot rely on any data that would be manipulated by the interceptor stack. Since Actions are created before the interceptor stack executes, interceptors can query actions for data and objects that might be needed for execution of the interceptor. The order of execution of interceptors is vital in determining what data is available to an Action.
Actions not only contain methods that are invoked to perform the task associated with the request, they also interact with JSPs via the ValueStack. Any getter or setter in an Action is accessed via the ValueStack and the results of a get() or set() is available to the JSP that generates HTML. This maintains separation between the Model (Action) and the View (HTML generated by JSPs) and allows changes to either to be made in isolation.
JavaServer Pages are used to generate HTML for display in the browser. JSPs make heavy use of the ValueStack (for access to data in the Action), beans (certain features that do not require SLAMD or the request to be in a certain state), and Struts tags. JSPs are a powerful programming resource that allow the use of dynamic HTML generation by supporting all basic programming constructs (loops, if-then-else) and page generation encapsulation (XML, HTML, character set encoding). Struts tags allow for the automatic conversion of data types such as Maps, Collections, and basic primitive data types to relieve the developer of the burden of the tedious tasks of doing the conversion by hand with special code. The price to pay for this functionality is a somewhat arcane syntax, and that is indeed a small price to pay to ensure isolation and separation of data and views.
Dynamic page generation is used to great effect in SLAMD. Every aspect of page generation is dynamic, for example, page titles, internationalization, CSS inclusion, meta keyword generation, and debugging. Actions can and do influence the title, keywords, CSS media type, and all other aspects of HTML generation.
Release 0.0.3.3 has more fixes for DSEE63 access log parsing, plus support is added for FDs taken and returned, and unindexed searches.
Download the WAR file and deploy into GlassFish or Tomcat under contextroot "dsla".
Parser defects caused application failures when parsing certain elements of access logs created by Directory Server Enterprise Edition 6.3. The defects that were noted have been corrected.
The command line above uploads a file named "access", provides a hostname, description, and the name of the instance where the access file was generated. Hostname, description and instance name could be omitted, in which case suitable defaults are provided. Use the correct application server hostname and port, obviously. The field named "uploadFile" is required, and must be named "uploadFile". Download the application WAR file from the download area at http://kenai.com and deploy into GlassFish or Tomcat under contextroot "dsla".
curl -F 'uploadedFile=@access' \\ --form-string hostname=example.com \\ --form-string description="a description of the file" --form-string instance="the name of the instance" \\ http://www.example.com:8080/dsla/FileUploaded.action > /dev/null
The report page had become very spaced-out and hard to read: too much white space, not enough data. Here is a mockup of my proposed changes:
Directory Server Log Analyzer 0.0.2.6 has been released. Download the WAR file and deploy it under ContextRoot "dsla" into Glassfish or Tomcat 5/6. This version corrects an oversight in building the software, and the code is now supported by Java 1.5 and Java 1.6.
Sun, LDAP, SLAMD, DSLA, java, Struts, networking, chess, books, cooking, wine, and many other things.