How-To Tutorials

The choice of validation method depends on the additional functionality required in the validation application. SAXParser is recommended if SAX parsing event notification is required in addition to validation with a schema. DOMParser is recommended if the DOM tree structure of an XML document is required for random access and modification of the XML document. Schema validation with a SAX parser In this section we shall validate the example XML document catalog.xml with XML schema document catalog.xsd, with the SAXParser class. Import the oracle.xml.parser.schema and oracle.xml.parser.v2 packages. Creating a SAX parser Create a SAXParser object and set the validation mode of the SAXParser object to SCHEMA_VALIDATION, as shown in the following listing: SAXParser saxParser=new SAXParser();saxParser.setValidationMode(XMLParser.SCHEMA_VALIDATION); The different validation modes that may be set on a SAXParser are discussed in the following table; but we only need the SCHEMA-based validation modes: Validation Mode Description NONVALIDATING The parser does not validate the XML document. PARTIAL_VALIDATION The parser validates the complete or a partial XML document with a DTD or an XML schema if specified. DTD_VALIDATION The parser validates the XML document with a DTD if any. SCHEMA_VALIDATION The parser validates the XML document with an XML schema if any specified. SCHEMA_LAX_VALIDATION Validates the complete or partial XML document with an XML schema if the parser is able to locate a schema. The parser does not raise an error if a schema is not found. SCHEMA_STRICT_VALIDATION Validates the complete XML document with an XML schema if the parser is able to find a schema. If the parser is not able find a schema or if the XML document does not conform to the schema, an error is raised. Next, create an XMLSchema object from the schema document with which an XML document is to be validated. An XMLSchema object represents the DOM structure of an XML schema document and is created with an XSDBuilder class object. Create an XSDBuilder object and invoke the build(InputSource) method of the XSDBuilder object to obtain an XMLSchema object. The InputSource object is created with an InputStream object created from the example XML schema document, catalog.xsd. As discussed before, we have used an InputSource object because most SAX implementations are InputSource based. The procedure to obtain an XMLSchema object is shown in the following listing: XSDBuilder builder = new XSDBuilder();InputStream inputStream=new FileInputStream(new File("catalog.xsd"));InputSource inputSource=new InputSource(inputStream);XMLSchema schema = builder.build(inputSource); Set the XMLSchema object on the SAXParser object with setXMLSchema(XMLSchema) method: saxParser.setXMLSchema(schema); Setting the error handler As in the previous section, define an error handling class, CustomErrorHandler that extends DefaultHandler class. Create an object of type CustomErrorHandler, and register the ErrorHandler object with the SAXParser as shown here: CustomErrorHandler errorHandler = new CustomErrorHandler();saxParser.setErrorHandler(errorHandler); Validating the XML document The SAXParser class extends the XMLParser class, which provides the overloaded parse methods discussed in the following table to parse an XML document: Method Description parse(InputSource in) Parses an XML document from an org.xml.sax.InputSouce object. The InputSource-based parse method is the preferred method because SAX parsers convert the input to InputSource no matter what the input type is. parse(java.io.InputStream in) Parses an XML document from an InputStream. parse(java.io.Reader r) Parses an XML document from a Reader. parse(java.lang.String in) Parses an XML document from a String URL for the XML document. parse(java.net.URL url) Parses an XML document from the specified URL object for the XML document. Create an InputSource object from the XML document to be validated, and parse the XML document with the parse(InputSource) object: InputStream inputStream=new FileInputStream(newFile("catalog.xml"));InputSource inputSource=new InputSource(inputStream);saxParser.parse(inputSource); Running the Java application The validation application SAXValidator.java is listed in the following listing with additional explanations: First we declare the import statements for the classes that we need. import java.io.File;import java.io.FileInputStream;import java.io.FileNotFoundException;import oracle.xml.parser.schema.*;import oracle.xml.parser.v2.*;import java.io.IOException;import java.io.InputStream;import org.xml.sax.SAXException;import org.xml.sax.SAXParseException;import org.xml.sax.helpers.DefaultHandler;import org.xml.sax.InputSource; We define the Java class SAXValidator for SAX validation. public class SAXValidator { In the Java class we define a method validateXMLDocument. public void validateXMLDocument(InputSource input) {try { In the method we create a SAXParser and set the XML schema on the SAXParser. SAXParser saxParser = new SAXParser();saxParser.setValidationMode(XMLParser.SCHEMA_VALIDATION);XMLSchema schema=getXMLSchema();saxParser.setXMLSchema(schema); To handle errors we create a custom error handler. We set the error handler on the SAXParser object and parse the XML document to be validated and also output validation errors if any. CustomErrorHandler errorHandler = new CustomErrorHandler();saxParser.setErrorHandler(errorHandler);saxParser.parse(input);if (errorHandler.hasValidationError == true) {System.err.println("XML Document hasValidation Error:" + errorHandler.saxParseException.getMessage());} else {System.out.println("XML Document validateswith XML schema");}} catch (IOException e) {System.err.println("IOException " + e.getMessage());} catch (SAXException e) {System.err.println("SAXException " + e.getMessage());}} We add the Java method getXMLSchema to create an XMLSchema object. try {XSDBuilder builder = new XSDBuilder();InputStream inputStream =new FileInputStream(new File("catalog.xsd"));InputSource inputSource = newInputSource(inputStream);XMLSchema schema = builder.build(inputSource);return schema;} catch (XSDException e) {System.err.println("XSDException " + e.getMessage());} catch (FileNotFoundException e) {System.err.println("FileNotFoundException " +e.getMessage());}return null;} We define the main method in which we create an instance of the SAXValidator class and invoke the validateXMLDocument method. public static void main(String[] argv) {try { InputStream inputStream = new FileInputStream(new File("catalog.xml")); InputSource inputSource=new InputSource(inputStream); SAXValidator validator = new SAXValidator(); validator.validateXMLDocument(inputSource); } catch (FileNotFoundException e) { System.err.println("FileNotFoundException " + e.getMessage()); }} Finally, we define the custom error handler class as an inner class CustomErrorHandler to handle validation errors. private class CustomErrorHandler extends DefaultHandler {protected boolean hasValidationError = false;protected SAXParseException saxParseException = null;public void error(SAXParseException exception){hasValidationError = true;saxParseException = exception;}public void fatalError(SAXParseException exception){hasValidationError = true;saxParseException = exception;}public void warning(SAXParseException exception){}}} Copy the SAXValidator.java application to SAXValidator.java in the SchemaValidation project. To demonstrate error handling, add a title element to the journal element. To run the SAXValidator.java application, right-click on SAXValidator.java in Application Navigator, and select Run. A validation error gets outputted. The validation error indicates that the title element is not expected.

There's lots what Nagios can do, and how it can make your life easier. Imagine that you set up Nagios to send a text message to your mobile during day time. It can also send you a message on Jabber or MSN. Imagine that you also make Nagios stop notifying you when your workstation is not online. Even though the above examples above seem complicated, they are actually quite simple to implement. It's a matter of combining event handlers with custom variables, and a little ingenuity. A service that will check if a user's workstation is present can have an event handler to automatically enable and disable host and/or service notifications for a contact or contact group. It's also possible to set up your monitoring to notify managers if the issue has not been fixed within a certain period of time. Based on the importance of a host or service, these can be different managers that are notified and different time periods after which the notification is sent. Nagios can also be used to notify emergency response teams, so that if a problem is not fixed in a short period of time, they will assist in recovering from the potential after effects of this problem. There are cases when you want Nagios to perform one or more actions if a service starts or stops malfunctioning. For instance, you might have a web server set up to retry five times before a failure becomes a hard state for Nagios. In such a case, you can also configure Nagios to try restarting itself after the third soft failure —if it fails, it will move to a hard state after the next two failures. In case the restart succeeds, a hard state will not even get recorded and only a soft failure will get logged. Nagios is able to integrate itself with other applications that can send commands to Nagios directly and can report the status of host or service checks. Sending commands can be used by Nagios web interface, but you might as well use it inside your application or event handlers for various objects. Effective Notifications This section covers notifications in depth and describes the details of how Nagios can tell other people about what is happening. We will discuss a simple approach, as well as a more complex approach on how notifications can make your life easier. Probably, most people already know that a plain email notification about a problem may not always be the right thing to do. As people's inboxes get cluttered with emails, the usual approach is to create rules to move certain messages that they don't even look at to separate folders. There's a pretty good chance that if people start getting a lot of notifications that they won't need to react to, they'll simply ask their favorite mailing program to move these messages into a 'do not look in here unless you have plenty of time' folder. Moreover, in such cases, if there is an issue they should be handling, they will most probably not even see the notification email. This section talks about the things that can be implemented in your company to make notifications more convenient to the IT staff. Limiting the amount of irrelevant information sent to various people tends to increase their response time, as they will have much less information to filter out. At this point, it's worth mentioning that there's another easy solution. Again, most people do not use it even though it offers a very flexible set up in an easy way. The approach is to create multiple contacts for a single person. For example, you can set up different contacts when you're at work, when you're offline, and define a profile to not to disturb you too much during the night. The first issue that many Nagios administrators overlook is the ability to create more than one notification command. In this way, Nagios can try to notify you on both instant messaging (such as Jabber, Gtalk, MSN, or Yahoo) and email. It can also send you an SMS. A disadvantage is that at some point, you might end up receiving SMSes at 2 AM about an outage of a machine that may well be down for the next 3days and is not critical. For example you can set up the following contacts to handle various times of the day in a different fashion: jdoe-workhours would be a contact that will only receive notifications during working hours; notifications will be carried out using both the corporate IM system and an email jdoe-daytime would be a contact that will only receive notifications between 7 AM and 10 PM, excluding working hours; notifications will be sent as a text or a pager message, and an email jdoe-night would be a contact that will only receive notifications between 10 PM and 7 AM; notifications will only be sent out as an email All entries would also contain contactgroups pointing to the same groups that the single jdoe contact entry used to contain. This way, the other objects such as hosts, services, or contact groups related to this user would not be affected. All entries would also reside in the same file; for example, contacts/jdoe.cfg. The main drawback of this approach is that logging on to the web interface would require using one of the users above or keeping the jdoe contact without any notifications, just to be able to log on to the interface. The example above combined both the creation of multiple contacts and use of multiple notification commands to achieve a convenient way of getting notified about a problem. Using only multiple contacts also works fine. Another approach to the problem is to define different contacts for different ways of being notified—for example, jdoe-email, jdoe-sms, and jdoe-jabber. This way, you can define different contact methods for various time periods—instant messages during working hours, SMSes while on duty, and an email when not at work. Another important issue is to make sure that as few people as possible are notified of the problem. Imagine there is a host without an explicit administrator assigned to it. A notification about a problem gets sent out to 20 different people. In such a case, either each of them will assume that someone else will resolve the problem, or people will run into a communication problem over discussing who will actually handle it. Teams that cooperate tightly with each other usually solve these issues naturally—knowledgeable people start discussing a solution and a natural person to solve the issue comes out of the discussion. However, the teams that are distributed across various locations or that have poor communication skills will run into problems in such cases. This is why, it is a good idea to either nominate a coordinator who will assign tasks as they arise, or try to maintain a short list of people responsible for each machine. If you need to make sure that other people will investigate the problem if the original owner of the machine cannot do it immediately, then it is a good idea to use escalations for this purpose. These are described later in this article. Previously, we mentioned that notifications only via email may not always be the best thing to do. For example, they don't work well for situations that require fast response times. There are various reasons behind this. Firstly, emails are slow—even though the email lands on your mail server in a few seconds, people usually only poll their emails every few minutes. Secondly, people tend to filter emails and skip those that they are not interested in. Another good reason why emails should not always be used is that they stay on your email account until you actually fetch and read them. If you have been on a 2-week vacation and a problem has occurred, should you still be worried when you read it after you get back? Has the issue been resolved already? If your team needs to react to problems promptly, using email as the basic notification method is definitely not the best choice. Let's consider what other possibilities exist to notify users of a problem effectively. As already mentioned, a very good choice is to use instant messaging or SMS (Simple Messaging Service) messages as the basic means of notification, and only use email as a last resort. Some companies might also use the client-server approach to notify the users of the problems, perhaps integrated with showing Nagios' status only for particular hosts and services. NagiosExchange has plenty of available solutions you can use for handling notifications effectively. The first and the most powerful option is to use Jabber for notifications. There is an existing script for this that is available in the contributions repository on the Nagios project website. This is a small Perl script that sends messages over Jabber. You may need to install additional system packages to handle Jabber connectivity from Perl. On Ubuntu, this requires running the following command: root@ubuntu1:~# apt-get install libnet-jabber-perl If you are using CPAN to install Perl packages, then simply run the following command: root@ubuntu1:~# cpan install Net::Jabber In order to use the notification plugin, you will need to customize the script—change the SERVER, PORT, USER, and PASSWORD parameters to an existing account. Our recommendation is to create a separate account to use only for Nagios notifications—you will need to set up authorization for each user that you want to send notifications to. As you plan to monitor servers and potentially even outgoing Internet connectivity, it would not be wise to use public Jabber servers for reporting errors. Therefore, it would be a good idea to set up a private Jabber server, probably on the same host on which the Nagios monitoring system is running. If you plan to have a more comfortable setup, you can also use Tkabber as a Jabber client, and write a plugin that reads object's cache and the current status from the Nagios host and shows an up-to-date report for hosts that you are the owner of. Information on reading Nagios output can be found on my Tclmentor blog Another possibility is to send messages over SMB/CIFS protocol. This way, you can send messages directly to the computers, assuming people are running the Microsoft Windows operating system. There is also the possibility of receiving messages using Samba package on UNIX machines. This requires having the smbclient command installed. On Ubuntu, this requires running the following command: root@ubuntu1:~# apt-get install smbclient A simple command definition example that uses smbclient directly to send messages to the specified host name is as follows: define command{command_name notify_host_via_smbclientcommand_line printf "Host notification: $NOTIFICATIONTYPE$nnHost: $HOSTNAME$nState: $HOSTSTATE$Address: $HOSTADDRESS$nInfo: $HOSTOUTPUT$" |smbclient -M $_CONTACTSMBHOSTNAME$} The preceding example uses the $_CONTACTSMBHOSTNAME$ macro definition. It maps to the _SMBHOSTNAME custom variable defined for a specified contact. In order for Windows XP and 2003 to show the messages from other users correctly, you will need to enable the Messenger service. This can be done by running the following command as the system administrator, or as a user with administrator privileges: C> net start Messenger Another way to communicate problems to the users is to use text messages, also known as SMS. This is a very sensitive issue because if your system is not properly configured, it can send a message in the middle of a night about a noncritical thing that can be fixed within the next 5 working days. There is a very useful package for handling of SMS sending called SMSServerTools. It allows the configuration of email and web gateways, as well as sending text messages over dedicated GSM (Global System for Mobile Communication) terminals. The tool offers the ability to queue text messages so that it handles a higher number of messages to be sent by the appropriate means. GSM terminals work in a manner similar to a typical mobile phone. They use a standard SIM card and have a normal GSM phone module that is used to send SMS messages. Terminals are usually connected via a serial port or USB connection. Your server can then send messages by sending commands to the terminal. GSM terminals use the same command convention as phone modems, although each model uses a different set of commands. For information on how you can send SMS messages over it, please refer the terminal's user manual. Current mobile phones also offer cheap Internet connectivity, and smart devices offer the possibility to write custom applications in Java, .NET, and many other languages including Python and Tcl. Therefore, you can also make a client-server application that queries the server for the status of selected hosts and services. It can even be unified with a notification command that pushes the changes down to the application immediately. These are only a few of the possibilities that you can use to communicate problems more effectively. Other possibilities include a ready-to-use client-server application (visit http://www.nagiosexchange.org/Notifications.35.0.html?tx_netnagext_pi1[p_view]=182) that allows the sending of notifications to people directly to their desktop machines. One interesting notification command allows you to choose other commands to use based on user availability on Jabber—this sends messages over Jabber if the user is are available and uses SMSes or emails otherwise. (Visit http://www.nagiosexchange.org/Notifications.35.0.html?&tx_netnagext_pi1[p_view]=1036). There are also tools to send messages to ICQ users and ones that use VoIP technology to provide you with predefined wave messages or output from a speech synthesis system. Escalations A common problem with resolving problems is that a host or a service may have blurred ownership. Often, there is no single person responsible for a host or service, which makes things harder. It is also typical to have a service with subtle dependencies on other things, which by themselves are small enough not to be monitored by Nagios. In such a case, it is good to include lower management in the escalations so that they are able to focus on problems that haven't been resolved in a timely manner. Here is a good example: a database server might fail because a small Perl script that is run prior to actual start and clean things up has entered an infinite loop. The owner of this machine gets notified. But the question is who should be fixing it? Should it be the script owner? Or perhaps, should it be the database administrator? In IT reality, this often ends up in a series of throwing ball into each other's yards without solving anything. In such cases, escalations are a great way to solve such complex problems. In the previous example, if the problem is not been resolved after two hours, the IT team coordinator or manager would be notified. Another hour later, he would get another email. At that point, he would schedule an urgent meeting with the developer who owns the script, and the database admin, to discuss how this could be solved. Of course, in real-world scenarios, escalating to management alone would not solve all problems. However, often, situations need a coordinator that will take care of communicating issues between teams and trying to find a company-wide solution. Business-critical services also require much higher attention. In such cases, it is a real benefit for the company if it has an escalation ladder that can be followed for all major problems. Nagios offers many ways to set up escalations, depending on your needs. Escalations do not need to be sent out just after a problem occurs—that would create confusion and prevent smaller problems from being solved. Usually, escalations are set up so that additional people are informed only if a problem has not been resolved after a certain amount of time. From a configuration point of view, all escalations are defined as separate objects. There are two types of objects—hostescalation and serviceescalation. Escalations are configured so that they start and stop being active along with the normal host or service notifications. This way, if you change the notification_ interval directive in host or service definition, the times at which escalations start and stop will also change. A sample escalation for company's main router is as follows: define hostescalation{host_name mainroutercontactgroups it-managementfirst_notification 2last_notification 0notification_interval 60escalation_options d,u,r} The following table describes all available directives for defining a host escalation. Items in bold are required when specifying an escalation. Option Description host_name Defines host names that escalation should be defined for; separated by comma hostgroup_name Defines host group names for all members of which groups escalation should be defined for; separated by comma contacts List of all contacts that should receive notifications related to this escalation; separated by comma; at least one contact or contact group needs to be specified for each escalation contactgroups List of all contacts groups that should receive notifications related to this escalation, separated by comma; at least one contact or contact group needs to be specified for each escalation first_notification Number of notifications after which this escalation becomes active; setting this to 0 causes notifications to be sent until host recovers from problem; see description below last_notification Number of notifications after which this escalation stop being active; see description below notification_interval Specifies number of minutes between sending notifications related to this escalation escalation_period Specifies time period during which escalation should be valid; if not specified defaults to 24 hours a day 7 days a week escalation_options Specifies which notification types for host states should be sent, separated by comma; should be one or more of the following: d - host DOWN state u - host UNREACHABLE state r - host recovery (UP state) Service escalations are defined in a very similar way to host escalations. You can specify one or more hosts or host groups, as well as a single service description. Service escalation will be associated with this service on all hosts mentioned in the host_name and hostgroup_name attributes. The following is an example of a service escalation for an OpenVPN check on the company's main router: define serviceescalation{host_name mainrouterservice_description OpenVPNcontactgroups it-managementfirst_notification 2last_notification 0notification_interval 60escalation_options w,c,r} The following table describes all available directives for defining a service escalation. Items in bold are required when specifying an escalation.

Unix—all releases Something that has not been made very clear in the Oracle Scheduler documentation is that redirection cannot be used in jobs (<, >, >>, |, &&, ||). Therefore, many developers have tried to use it. So, let's keep in mind that we cannot use redirection, not in 11g as well as older releases of the database. The scripts must be executable, so don't forget to set the execution bits. This might seem like knocking down an open door, but it's easily forgotten. The user (who is the process owner of the external job and is nobody:nobody by default) should be able to execute the $ORACLE_HOME/bin/extjob file. In Unix, this means that the user should have execution permissions on all the parent directories of this file. This is not something specific to Oracle; it's just the way a Unix file system works. Really! Check it out. Since 10gR1, Oracle does not give execution privileges to others. A simple test for this is to try starting SQL*Plus as a user who is neither the Oracle installation user, nor a member of the DBA group—but a regular user. If you get all kinds of errors, then it implies that the permissions are not correct, assuming that the environment variables (ORACLE_HOME and PATH) are set up correctly. The $ORACLE_HOME/install/changePerm.sh script can fix the permissions within ORACLE_HOME (for 10g). In Oracle 11g, this again changed and is no longer needed. The Scheduler interprets the return code of external jobs and records it in the *_scheduler_job_run_details view. This interpretation can be very misleading, especially when using your own exit codes. For example, when you code your script to check the number of arguments, and code an exit 1 when you find the incorrect number of arguments, the error number is translated to ORA-27301: OS failure message:No such file or directory by Oracle using the code in errno.h. In 11g, the Scheduler also records the return code in the error# column. This lets us recognize the error code better and find where it is raised in the script that ran, when the error codes are unique within the script. When Oracle started with Scheduler, there were some quick changes. Here are the most important changes listed that could cause us problems when the definitions of the mentioned files are not exactly as listed: 10.2.0.1: $ORACLE_HOME/bin/extjob should be owned by the user who runs the jobs (process owner) and have 6550 permissions (setuid process owner). In a regular notation, that is what ls –l shows, and the privileges should be -r-sr-s---. 10.2.0.2: $ORACLE_HOME/rdbms/admin/externaljob.ora should be owned by root. This file is owned by the Oracle user (the user who installed Oracle) and the Oracle install group with 644 permissions or -rw-r—-r--, as shown by ls –l. This file controls which operating system user is going to be the process owner, or which user is going to run the job. The default contents of this file are as shown in the following screenshot: $ORACLE_HOME/bin/extjob must be the setuid root (permissions 4750 or -rwsr-x---) and executable for the Oracle install group, where the setuid root means that the root should be the owner of the file. This also means that while executing this binary, we temporarily get root privileges on the system. $ ORACLE_HOME/bin/extjobo should have normal 755 or -rwxr-xr-x permissions,and be owned by the normal Oracle software owner and group. If this file is missing, just copy it from $ORACLE_HOME/bin/extjob. On AIX, this is the first release that has external job support. 11g release: I n 11g, the same files as in 10.2.0.2 exist with the same permissions. But $ORACLE_HOME/bin/jssu is owned by root and the Oracle install group with the setuid root (permissions 4750 or -rwsr-x---). It is undoubtedly best to stop using the old 10g external jobs and migrate to the 11g external jobs with credentials as soon as possible. The security of the remote external jobs is better because of the use of credentials instead of falling back to the contents of a single file in $ORACLE_HOME/, and the flexibility is much better. In 11g, the process owner of the remote external jobs is controlled by the credential and not by a file. Windows usage On Windows, this is a little easier with regard to file system security. The OracleJobscheduler service must exist in a running state, and the user who runs this service should have the Logon as batch job privilege. A .batfile cannot be run directly, but should be called as an argument of cmd.exe, for example: --/BEGINDBMS_SCHEDULER.create_job(job_name => 'env_windows',job_type => 'EXECUTABLE',number_of_arguments => 2,job_action => 'C:windowssystem32cmd.exe',auto_drop => FALSE,enabled => FALSE);DBMS_SCHEDULER.set_job_argument_value('env_windows',1,'/c');DBMS_SCHEDULER.set_job_argument_value('env_windows',2,'d:temptest.bat');end;/ This job named env_windows calls cmd.exe, which eventually runs the script named test.bat that we created in d:temp. When the script we want to call needs arguments, they should be listed from argument number 3 onwards.

(For more resources on Plone, see here.) Introducing versioning Now that you have learned how to add various types of content, from pages to events to news items, we're ready to introduce a feature of Plone called versioning, which is an important part of content management. The content items you work with in your Plone site may go through many changes over time. Plone provides versioning information to help you manage your content from the time it was initially created through to the current version. By default, Plone provides versioning for the following content types: Pages News Items Events Links Other content types can be configured to provide versioning through the Plone Control Panel under Types. Although you may enable the File type to use versioning, the only changes that are tracked are those items actually describing the File (for example, Title, Description, and so on). The changes to the contents of the File are not tracked. Creating a new version Versions are created each time you save your content. Note that there is a Change note field at the bottom of the Edit page for content items with versioning enabled: The information entered in the Change note field will be stored along with other versioning information, which you are able to view through the History tab. Viewing the version history You can view the list of all of the versions of a content item by clicking on the History tab for that content item. In the History view that you can see in the following screenshot, the most recent version is listed fi rst. Clicking on any of the column headers will re-sort the listing based on that column heading. The most current version is always labeled Working Copy in the History view. Previewing previous versions To preview a specific version, simply click the preview link of the desired revision. In the following example, revision 3 has been identified, and will be displayed if this link is clicked: On the subsequent page, you may either click on the jump down link to the point of the content preview: or you may scroll down the page in order to see the actual preview:

Code usage for sliders with options We are now done with the most important part of the slider: the implementation of the slider in our applications. But wait, we need the slider to suit our applications, right? So let's customize our slider with options. We have mentioned earlier that track is the range of values. So let's first define the range for our slider. window.onload = function() { new Control.Slider('handle1' , 'track1', { axis:'vertical', range:$R(1,100)} The range option uses the Prototypes' objectRange instance. Hence, we declare it using $R (minimum, Maximum). Everything looks neat until here. Let's add some more options to our constructor, onSlide(). Using the onSlide() callback every time, we drag the slider and the callback is invoked. The default parameter passed to onSlide() is the current slider value. window.onload = function() { new Control.Slider('handle1' , 'track1', { axis:'vertical', range:$R(1,100), onSlide: function(v) { $('value1').innerHTML = "New Slide Value="+v;} }} We have added a div called value1 in our HTML code. On dragging the slider, we will update the value1 with the current slider value. OK, so let's see what happened to our slider to this point. Check out the following screenshot: Impressed? And, we are not done yet. Let's add more options to the slider now. You may ask me, what if the slider in the application needs to be at a particular value by default? And I will say use the sliderValue option. Let's make our slider value 10 by default. Here is the snippet for the same: window.onload = function() {      new Control.Slider('handle1' , 'track1',     {   axis:'vertical',   range:$R(1,100),   sliderValue: 10,   onSlide: function(v) { $('value1').innerHTML = "New Slide                                                 Value="+v;}} And, you should see the slider value at 10 when you run the code. Now your dear friend will ask, what if we don't want to give the range, but we need to pass the fixed set of values? And you proudly say, use the values option. Check out the usage of the values options in the constructor. window.onload = function() { new Control.Slider('handle1' , 'track1', { range:$R(1,25), values:[1, 5,10,15,20,25], onSlide:function(v){ $('value1').innerHTML = "New Slide Value="+v;} } );} We have added a set of values in the array form and passed it to our constructor. Let's see what it looks like. Tips and tricks with the slider After covering all the aspects of the slider feature, here is a list of simple tips and tricks which we can make use of in our applications with ease. Reading the current value of the slider script.aculo.us "genie" provides us with two callbacks for the slider to read the current value of the slider. They are: onSlide onChange Both these callbacks are used as a part of options in the slider. onSlide contains the current sliding value while the drag is on. The callback syntax is shown as follows: onSlide: function(value) {// do something with the value while sliding. Write or Edit thevalue //of current slider value while sliding} onChange callback will contain the value of the slider while the sliding or the drag event ends. After the drag is completed and if the value of the slider has changed then the onChange function will be called. For example, if the slider's current value is set to 10 and after sliding we change it to 15, then the onChange callback will be fired. The callback syntax is shown as follows: onChange: function(value){// do anything with the "changed" and current value} Multiple handles in the slider Now, a thought comes to our mind at this point: Is it possible for us to have two handles in one track? And, the mighty script.aculo.us library says yes! Check out the following code snippet and screenshot for a quick glance of having two handles in one track: HTML code<div id="track1"><div id="handle1"></div><div id="handle2"></div></div> JavaScript code for the same: window.onload = function() { new Control.Slider(['handle1','handle2'] , 'track1');} Now, check out the resulting screenshot having two handles and one track: The same can also be applied for the vertical slider too.

Overview Around a decade ago, it was possible for a single, precocious developer to build an entire SOA-like platform single-handedly. Granted, it was not an easy task to construct a service container and surround it with robust connection management, application security, transaction management, and reliable messaging, but it was at least an attainable goal. It was a proud achievement to build a toy application server or MOM platform in one’s basement. Those were simpler times. Today’s SOA suite is far too vast for one person to build, and uses computer science that is more advanced than a basement hacker can contend with. In the first place, today’s services—as I argue in my new book SOA Cookbook (Packt, 2008)—are designed as processes rather than simple method calls. Building an SOA process engine means brushing up on, or learning from scratch, Finite State Automata, Petri Nets, and, perhaps, the Pi Calculus. Additionally, these processes use business rules to decide on next actions. Building the required rules engine presupposes proficiency in forward-chaining rule definitions, the RETE algorithm, and, possibly, genetic algorithms. Toy SOA is a relic of the past; today’s SOA requires a large team of very smart people. Still, for all its might, today’s SOA is merely reactive. An SOA process provides a business function that reacts to requests. If the function is requested ten thousand times, the process is run ten thousand times. It is not in SOA’s mandate to make sense of trends, or to find suspicious happenings, across those ten thousand invocations. SOA’s job is to be a workhorse, serving the requests. It is not an anomaly watchdog or a slice-and-dice business analysis tool. Still, many enterprises seek just such a capability. Not surprisingly, SOA vendors are starting to add Complex Event Processing (CEP) to their solution. CEP listens on the bus for the same events that pass in and out of SOA processes, but—unlike SOA—is concerned mainly with the detection of patterns that emerge across events. It does this, as we’ll discuss, by applying event-pattern matching rules to the events. CEP thus relies on both SOA’s event bus and its rules engine. Not only does CEP fit in the SOA architecture, but also provides the watchdog capability that business stakeholders find so valuable. CEP and SOA CEP isn’t a new technology but is only now gaining traction in the marketplace. David Luckham wrote the definitive book on CEP (The Power of Events, Addison Wesley), which was published in 2002. Over the years several academic implementations have been developed, notably Stanford’s Rapide and Cornell’s Cayuga. Numerous CEP startups failed in the early days of CEP, during the rise and fall of dotcom in the late 1990s. It was to help market one of these companies, ePatterns, that Luckham started work on his book. The company didn’t pan out, as Luckham reminisces in his article “A Short History of Complex Event Processing Part 3: The Formative Years.” (http://complexevents.com/?p=553), but the book lived on, becoming the bible of events. Until recent years, the most established commercial implementations came from small vendors, such as Coral8 and Streambase. But within the past few years the major SOA vendors—who had previously kept arms-length from CEP, doubtful of its market potential— have started to incorporate CEP into their stacks. IBM, for instance, recently acquired Coral8. TIBCO aggressively sells its CEP tool, BusinessEvents, in its SOA and BPM deals. Oracle, thanks to its BEA acquisition, offers a product called “Oracle” CEP. The combined SOA/CEP offering is encouraging, because CEP’s value comes not from its intrinsic value but from its contribution to an overall solution. SOA vendors, in a sense, have been in the “overall solution” business for years. They promote the idea that business architecture should be built on services, and they provide a platform on which to build those services. But what’s always been missing was a tool to watch the services, to make sense of what’s happening operationally. What CEP and SOA have in common is events. Both technologies use events, but for different purposes. SOA processes use events to drive control flow. An SOA process is started by an event, and during the course of its execution waits for further events to propel it forward. Events in SOA, in effect, force process transitions. Most SOA processes not only receive events but also send events. When a process sends an event, another process receives it. Elaborate choreographies arise when the processes of multiple organizations engage in conversations of events. CEP, by contrast, is a rules engine that uses events to trigger rule evaluations. CEP is constantly listening on the SOA bus for events. As we explore in more detail below, by using event pattern matching rules, CEP is able to infer causal connections between seemingly disparate events. CEP can also aggregate a set of inconsequential low-level events into a single, business-meaningful complex event. In stock trading, for example, a customer’s purchase of shares is the combination of four events (keeping it simple): The customer’s request to the broker to buy the shares The broker’s placement of the order The result of the order, including the price at which the shares were bought The broker’s response back to the customer. When CEP detects these four events, it publishes a complex event—BuyOrderCompleted, let’s call it—back to the bus, where interested listeners may pick it up. The following figure illustrates the sequence of steps; this design is discussed in more detail below. CEP can also detect breakdowns in the buy order. For example, if the broker fails to respond back to the customer in a timely fashion, CEP can easily spot this and publish a BuyOrderBrokerResponseLate event. CEP can also spot anomalies that span multiple orders. For example, it can detect suspicious broker activities like a buy-ahead, in which the broker, when directed by a customer to buy shares, buys his own lot of shares first, and sells them after placing the customer’s order. (The broker makes a nice profit from this furtive trade; the customer’s order, when large enough, drives the price up, so when the broker sells, he comes out ahead.) It would be fiendishly difficult to build a detection mechanism for buy-aheads into SOA processes; CEP, as a watchdog off to the side, is much better equipped. This trade monitoring example is one of many CEP use cases. CEP use cases arise naturally from SOA use cases. If events move through the bus to drive services and processes, there is bound to be some important business reason to infer complex events from them. Indeed, many CEP use cases require SOA. Fraud detection, for example, which checks for anomalies in transactions on an account, must reside on an SOA platform with processes in place to perform transactions on accounts. The fraud detection rules must understand the structure of the account events and the protocol governing how they are exchanged. CEP in the SOA Stack The following figure shows where CEP fits in the stack offered by major SOA vendors. The three layers of the operational stack, shown on the right side of the diagram, are the Enterprise Service Bus (ESB), the Orchestration/Service Engine, and the BPM engine. The Orchestration Engine runs SOA processes, and it uses the ESB, which acts as a full-featured message broker, to send and receive events to its partner systems. Processes that involve both system and human work are split between the Orchestration Engine and the BPM Engine. A workflow process running on the BPM Engine invokes SOA processes in the Orchestration Engine to perform system actions; an SOA process running on the Orchestration Engine uses processes in the BPM Engine to delegate human work. You can refer SOA Cookbook (Packt, 2008) for an expanded discussion of the stack. CEP and its cousin Business Activity Monitoring (BAM) are shown as pieces off to the side. They are the not part of the core operational SOA platform, but rather provide an important business monitoring capability. BAM, in most implementations, is a summary view of business processes in the system. Like CEP, it observes the progress of operational processes, though it handles this data somewhat differently. BAM’s purpose is to create a rolled-up, read-only data view. CEP, in contrast, tries to infer complex events that can trigger follow-on actions. Both CEP and BAM funnel (as the figure shows) have large volume of events from the operational stack, reducing all that chatter to a smaller set. The following table maps this stack to vendors. We consider the four major SOA vendors: IBM, Oracle, BEA, and TIBCO. BAM is omitted from the table; CEP is our focus. Vendor BPM Orchestration ESB CEP TIBCO iProcess BusinessWorks ActiveMatrix Service Grid/Bus BusinessEvents BEA AquaLogic BPM Weblogic Integration AquaLogic Service Bus Oracle CEP Oracle "Fusion" BPA Suite "Fusion" BPEL Process Manager "Fusion" Enterprise Service Bus Oracle CEP (acquired from BEA) IBM Websphere Process Server, FileNet Websphere Process Server, Websphere Interchange Server Websphere Enterprise Service Bus, Websphere Message Broker Coral8 (recent acquisition) The operational stack supports a distributed architecture in which the activities of client applications and partner services, both internal and external to the organization, are coordinated by orchestration processes. Clients and partners communicate with these processes through the ESB. Internal connections typically use MOM queues to access the bus; external connections use SOAP over HTTP. The orchestration processes, besides coordinating partner activities, also interface with backend systems (databases, mainframes, and so on) and use BPM to delegate manual work to human actors. The following figure illustrates this architecture. CEP consists of a set of rules that listen for events from the bus. (A publish-subscribe messaging infrastructure allows CEP to get these events without disrupting the operational processes.) CEP rules, as we discussed above, infer complex events from these operational events. They send complex events back on the bus on orchestration queues, where, as we discuss further below, they are picked up and handled by CEP-aware orchestration processes. CEP must be sufficiently scalable to handle the high volume of events on the bus. There is more to this than sheer processing speed. CEP, like most rule-based systems, is stateful. It keeps its state (i.e., its current set of asserted facts) in a datastore called Working Memory. For performance reasons, Working Memory should be kept in physical memory, and paged out to disk when necessary. Using an RDBMS instead of memory would prove to be simply too slow and only a few commercial databases can handle updates at the volumes of events on a bus anyway. This memory should be fault-tolerant, given the business criticality of CEP. Such an implementation is full of the sort of thorny performance design issues in which SOA vendors have the greatest expertise. BAM works somewhat differently from CEP. Orchestration and BPM processes have state, and BAM uses this state, combined with business data from backend systems, to present a consolidated view of the state of the processes. For example, rather than tracking just order processes, BAM might also track the orders themselves, as they appear in the backend order system. In the previous figure, we labeled this piece as BAM/BI (for business intelligence), because most BAM implementations by themselves lack the ability to incorporate application data. Combining process state with application data often requires the combination of BAM and some sort of BI or analytics tool. Whereas BAM merely presents a view of the system, CEP, by creating events that it has inferred from its observations, serves as an active participant. SOA platforms with CEP are self-healing; CEP watches what’s happening operationally and sounds up when it detects a significant occurrence. The dotted line in the previous figure from CEP to BAM suggests that complex events created by CEP could be incorporated into the BAM dashboard. Thus, the BAM dashboard for the trading application could show statistics on completed orders or buy-aheads per broker. The mechanism by which CEP notifies BAM of complex events is implementation-specific.

External Commands Nagios offers a very powerful mechanism for receiving events and commands from external applications—the external commands pipe. This is a pipe file created on a file system that Nagios uses to receive incoming messages. The name of the file is rw/nagios.cmd and it is located in the directory passed as the localstatedir option during compilation. Following the compilation and installation instructions and the given guidelines, the file name will be /var/nagios/rw/ nagios.cmd. The communication does not use any authentication or authorization—the only requirement is to have write access to the pipe file. An external command file is usually writable by the owner and the group; the usual group used is nagioscmd. If you want a user to be able to send commands to the Nagios daemon, simply add that user to this group. A small limitation of the command pipe is that there is no way to get any results back and so it is not possible to send any query commands to Nagios. Therefore, by just using the command pipe, you have no verification that the command you have just passed to Nagios has actually been processed, or will be processed soon. It is, however, possible to read the Nagios log file and check if it indicates that the command has been parsed correctly, if necessary. An external command pipe is used by the web interface to control how Nagios works. The web interface does not use any other means to send commands or apply changes to Nagios. This gives a good understanding of what can be done with the external command pipe interface. From the Nagios daemon perspective, there is no clear distinction as to who can perform what operations. Therefore, if you plan to use the external command pipe to allow users to submit commands remotely, you need to make sure that the authorization is in place as well so that it is not possible for unauthorized users to send potentially dangerous commands to Nagios. The syntax for formatting commands is easy. Each command must be placed on a single line and end with a newline character. The syntax is as follows: [TIMESTAMP] COMMAND_NAME;argument1;argument2;...;argumentN TIMESTAMP is written as UNIX time—that is the number of seconds since 1970-01-01 00:00:00. This can be created by using the date +%s system command. Most programming languages also offer the means to get the current UNIX time. Commands are written in upper case. This can be one of the commands that Nagios should execute, and the arguments depend on the actual command. For example, to add a comment to a host stating that it has passed a security audit, one can use the following shell command: echo "['date +%s'] ADD_HOST_COMMENT;somehost;1;Security Audit;This host has passed security audit on 'date +%Y-%m-%d'">/var/nagios/rw/nagios.cmd This will send an ADD_HOST_COMMENT command (visit http://www.nagios.org/developerinfo/externalcommands/commandinfo.php? command_id=1) to Nagios over the external command pipe. Nagios will then add a comment to the host, somehost, stating that the comment originated from Security Audit. The first argument specifies the host name to add the comment to; the second tells Nagios if this comment should be persistent. The next argument describes the author of the comment, and the last argument specifies the actual comment text. Similarly, adding a comment to a service requires the use of the ADD_SVC_COMMENT command (visit http://www.nagios.org/developerinfo/externalcommands/ commandinfo.php? command_id=1) . The command's syntax is very similar to the ADD_HOST_COMMENT command except that the command requires the specification of the host name and service name. For example, to add a comment to a service stating that it has been restarted, you should use the following echo "['date +%s'] ADD_SVC_COMMENT;router;OpenVPN;1;nagiosadmin;Restarting the OpenVPN service" >/var/nagios/rw/nagios.cmd The first argument specifies the host name to add the comment to; the second is the description of the service to which Nagios should add the comment. The next argument tells Nagios if this comment should be persistent. The fourth argument describes the author of the comment, and the last argument specifies actual comment text. You can also delete a single comment or all comments using the DEL_HOST_ COMMENT (visit http://www.nagios.org/developerinfo/externalcommands/ commandinfo.php? command_id=3), DEL_ALL_HOST_COMMENTS (visit http://www. nagios.org/developerinfo/externalcommands/commandinfo.php? command_ id=13), and DEL_SVC_COMMENT (visit http://www.nagios.org/developerinfo/externalcommands/commandinfo.php? command_id=4) or DEL_ALL_SVC_COMMENTS commands (visit http://www.nagios.org/developerinfo/externalcommands/ commandinfo.php? command_id=14). Other commands worth mentioning are related to scheduling checks on demand. Very often, it is necessary to request that a check be carried out as soon as possible; for example, when testing a solution. This time, let's create a script that schedules a check of a host, all services on that host, and a service on a different host, as follows: #!/bin/shNOW='date +%s'echo "[$NOW] SCHEDULE_HOST_CHECK;somehost;$NOW" >/var/nagios/rw/nagios.cmdecho "[$NOW] SCHEDULE_HOST_SVC_CHECKS;somehost;$NOW" >/var/nagios/rw/nagios.cmdecho "[$NOW] SCHEDULE_SVC_CHECK;otherhost;Service Name;$NOW" >/var/nagios/rw/nagios.cmdexit 0 The commands SCHEDULE_HOST_CHECK (visit http://www.nagios.org/ developerinfo/externalcommands/commandinfo.php? command_id=127) and SCHEDULE_HOST_SVC_CHECKS (http://www.nagios.org/developerinfo/externalcommands/commandinfo.php?command_id=30) accept a host name and the time at which the check should be scheduled. The SCHEDULE_SVC_CHECK command (visit http://www.nagios.org/developerinfo/externalcommands/ commandinfo.php? command_id=29) requires the specification of a service description as well as the name of the host to schedule the check on. Normal scheduled checks, such as the ones scheduled above, might not actually take place at the time that you scheduled them. Nagios also needs to take allowed time periods into account as well as checking whether checks were disabled for a particular object or globally for the entire Nagios. There are cases when you'll need to force Nagios to do a check—in such cases, you should use SCHEDULE_FORCED_HOST_CHECK (visit http://www.nagios. org/developerinfo/externalcommands/commandinfo.php? command_id=128), SCHEDULE_FORCED_HOST_SVC_CHECKS (visit http://www.nagios.org/developerinfo/externalcommands/commandinfo.php? command_id=130) and SCHEDULE_FORCED_SVC_CHECK (visit http://www.nagios.org/developerinfo/ externalcommands/commandinfo.php? command_id=129) commands. They work in exactly the same way as described above, but make Nagios skip the checking of time periods, and ensure that the checks are disabled for this particular object. This way, a check will always be performed, regardless of other Nagios parameters Other commands worth using are related to custom variables, introduced in Nagios 3. When you define a custom variable for a host, service, or contact, you can change its value on the fly with the external command pipe. As these variables can then be directly used by check or notification commands and event handlers, it is possible to make other applications or event handlers change these attributes directly without modifications to the configuration files. A good example would be that the IT staff registers its presence via an application without any GUI. This application periodically sends information about the latest known IP address, and that information is then passed to Nagios assuming that the person is in the office. This would later be sent to a notification command to use that specific IP address while sending a message to the user. Assuming that the user name is jdoe and the custom variable name is DESKTOPIP, the message that would be sent to the Nagios external command pipe would be as follows: [1206096000] CHANGE_CUSTOM_CONTACT_VAR;jdoe;DESKTOPIP;12.34.56.78 This would cause a later use of $_CONTACTDESKTOPIP$ to return a value of 12.34.56.78. Nagios offers the CHANGE_CUSTOM_CONTACT_VAR (visit http://www.nagios.org/developerinfo/externalcommands/commandinfo.php? command_id=141), CHANGE_CUSTOM_HOST_VAR (visit http://www.nagios.org/developerinfo/ externalcommands/commandinfo.php?command_id=139), and CHANGE_CUSTOM_ SVC_VAR (visit http://www.nagios.org/developerinfo/externalcommands/commandinfo.php?command_id=140) commands for modifying custom variables in contacts, hosts and, services accordingly. The commands explained above are just a very small subset of the full capabilities of the Nagios external command pipe. For a complete list of commands, visit http:// www.nagios.org/developerinfo/externalcommands/commandlist.php, where the External Command List can be seen. External commands are usually sent from event handlers or from the Nagios web interface. You will find external commands most useful when writing event handlers for your system, or when writing an external application that interacts with Nagios. Event Handlers Event handlers are commands that are triggered whenever the state of a host or  service changes. They offer functionality similar to notifications. The main difference is that the event handlers are called for each type of change and even for each soft state change. This provides the ability to react to a problem before Nagios notifies it as a hard state and sends out notifications about it. Another difference is what the event handlers should do. Instead of notifying users that there is a problem, event handlers are meant to carry out actions automatically. For example, if a service defined with max_check_attempts set to 4, the retry_ interval set to 1, and the check_interval is set to 5, then the following example illustrates when event handlers would be triggered, and with what values, for $SERVICESTATE$, $SERVICESTATETYPE$, and $SERVICEATTEMP$ macro definitions: Event handlers are triggered for each state change—for example, in minutes, 10, 23, 28, and 29. When writing an event handler, it is necessary to check whether an event handler should perform an action at that particular time or not. See the following example for more details. A typical example might be that your web server process tends to crash once a month. Because this is rare enough, it is very difficult to debug and resolve it. Therefore, the best way to proceed is to restart the server automatically until a solution to the problem is found. If your configuration has max_check_attempts set to 4, as in the example above, then a good place to try to restart the web server is after the third soft failure check—in the previous example, this would be minute 12. Assuming that the restart has been successful, the diagram shown above would look like this: Please note that no hard critical state has occurred since the event handler resolved the problem. If a restart cannot resolve the issue, Nagios will only try it once, as the attempt is done only in the third soft check. Event handlers are defined as commands, similar to check commands. The main difference is that the event handlers only use macro definitions to pass information to the actual event handling script. This implies that the $ARGn$ macro definitions cannot be used and arguments cannot be passed in the host or service definition by using the ! separator. In the previous example, we would define the following command: define command{command_name restart-apache2command_line $USER1$/events/restart_apache2$SERVICESTATE$ $SERVICESTATETYPE$ $SERVICEATTEMPT$} The command would need to be added to the service. For both hosts and services, this requires adding an event_handler directive that specifies the command to be run for each event that is fired. In addition, it is good to set event_handler_enabled set to 1 to make sure that event handlers are enabled for this object. The following is an example of a service definition: define service{host_name localhostservice_description Webserveruse apacheevent_handler restart-apache2event_handler_enabled 1} Finally, a short version of the script is as follows: #!/bin/sh# use variables for argumentsSERVICESTATE=$1SERVICESTATETYPE=$2SERVICEATTEMPT=$3# we don't want to restart if current status is OKif [ "$SERVICESTATE" != "OK" ] ; then# proceed only if we're in soft transition stateif [ "$SERVICESTATETYPE" == "SOFT" ] ; then# proceed only if this is 3rd attempt, restartif [ "$SERVICESTATEATTEMPT" == "3" ] ; then# restarts Apache as system administratorsudo /etc/init.d/apache2 restartfififiexit 0 As we're using sudo here, obviously the script needs an entry in the sudoers file to allow the nagios user to run the command without a password prompt. An example entry for the sudoers file would be as follows: nagios ALL=NOPASSWD: /etc/init.d/apache2 This will tell sudo that the command /etc/init.d/apache2 can be run by the user nagios and that asking for passwords before running the command will not be done. According to our script, the restart is only done after the third check fails. Assuming that the restart went correctly, the next Nagios check will notify that Apache is running again. As this is considered a soft state, Nagios has not yet sent out any notifications about the problem If the service would not restart correctly, the next check will cause Nagios to set this failure as a hard state. At this point, notifications will be sent out to the object owners. You can also try performing a restart in the second check. If that did not help, then during the third attempt, the script can forcefully terminate all Apache2 processes using the killall or pkill command. After this has been done, it can try to start the service again. For example: # proceed only ifthis is 3rd attempt, restartif [ "$SERVICESTATEATTEMPT" == "2" ] ; then# restart Apache as system administratorsudo /etc/init.d/apache2 restartfi# proceed only ifthis is 3rd attempt, restartif [ "$SERVICESTATEATTEMPT" == "3" ] ; then# try to terminate apache2 process as system administratorsudo pkill apache2# starts Apache as system administratorsudo /etc/init.d/apache2 startfi Another common scenario is to restart one service if another one has just recovered—for example, you might want to restart email servers that use a database for authentication if the database has just recovered from a failure state. The reason for doing this is that some applications may not handle disconnected database handles correctly—this can lead to the service working correctly from the Nagios perspective, but not allowing some of the users in due to internal problems. If you have set this up for hosts or services, it is recommended that you keep flapping enabled for these services. It often happens that due to incorrectly planned scripts and the relations between them, some services might end up being stopped and started again. In such cases, Nagios will detect these problems and stop running event handlers for these services, which will cause fewer malfunctions to occur. It is also recommended that you keep notifications set up so that people also get information on when flapping starts and stops. Modifying Notifications An interesting new feature in Nagios 3 is the ability to change various parameters related to notifications. These parameters are modified via an external command pipe, similar to a few of the commands shown in the previous section. A good example would be when Nagios contact persons have their workstations connected to the local network only when they are actually at work (which is usually the case if they are using notebooks), and turn their computers off when they leave work. In such a case, a ping check for a person's computer could trigger an event handler to toggle that person's attributes. Let's assume that our user jdoe has two actual contacts—jdoe-email and jdoejabber, each for different types of notifications. We can set up a host corresponding to the jdoe workstation. We will also set it up to be monitored every five minutes and create an event handler. The handler will change the jdoe-jabber's host and service notification time period to none on a hard host down state. On a host up state change, the time period for jdoe-jabber will be set to 24x7. This way, the user will only get Jabber notifications if he or she is at work. Nagios offers commands to change the time periods during which a user wants to receive notifications. The commands for this purpose are: CHANGE_CONTACT_HOST_ NOTIFICATION_TIMEPERIOD ( http://www.nagios.org/developerinfo/ externalcommands/commandinfo.php? command_id=153 ) and CHANGE_CONTACT_ SVC_NOTIFICATION_TIMEPERIOD ( http://www.nagios.org/developerinfo/externalcommands/commandinfo.php?command_id=152 ). Both commands take the contact and the time period name as their arguments. An event handler script that modifies the user's contact time period based on state is as follows #!/bin/shNOW='date +%s'CONTACTNAME=$1-jabberif [ "$2,$3" = "DOWN,HARD" ] ; thenTP=noneelseTP=24x7fiecho "[$NOW] CHANGE_CONTACT_HOST_NOTIFICATION_TIMEPERIOD;$CONTACT;$TP" >/var/nagios/rw/nagios.cmdecho "[$NOW] CHANGE_CONTACT_SVC_NOTIFICATION_TIMEPERIOD;$CONTACT;$TP" >/var/nagios/rw/nagios.cmdexit 0 The command should pass $CONTACTNAME$, $SERVICESTATE$, and $SERVICESTATETYPE$ as parameters to the script. In case you need a notification about a problem sent again, you should use the SEND_CUSTOM_HOST_NOTIFICATION or SEND_CUSTOM_SVC_NOTIFICATION command. These commands take host or host and service names, additional options, author name, and comments that should be put in the notification. Options allow specifying if the notification should also include all escalation levels (a value of 1), if Nagios should skip time periods for specific users (a value of 2) as well as if Nagios should increment notifications counters (a value of 4). Options are stored bitwise so a value of 7 (1+2+4) would enable all of these options. The notification would be sent to all people including escalations; it will be forced, and the escalation counters will be increased. Option value 3 means it should be broadcast to all escalations as well, and the time periods should be skipped. To send a custom notification about the main router to all users including escalations, you should send the following command to Nagios [1206096000] SEND_CUSTOM_HOST_NOTIFICATION;router1;3;jdoe;RESPOND ASAP

The following screenshot shows a dialog widget and the different elements that it is made of: A basic dialog A dialog has a lot of default behavior built-in, but few methods are needed to control it programmatically, making this a very easy widget to use that is also highly configurable. Generating it on the page is very simple and requires a minimal underlying mark-up structure. The following page contains the minimum mark-up that's required to implement the dialog widget: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"><html lang="en"> <head> <link rel="stylesheet" type="text/css" href="jqueryui1.6rc2/themes/flora/flora.dialog.css"> <link rel="stylesheet" type="text/css" href="jqueryui1.6rc2/themes/flora/flora.resizable.css"> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <title>jQuery UI Dialog Example 1</title> </head> <body> <div id="myDialog" class="flora" title="This is the title">Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean sollicitudin. Sed interdum pulvinar justo. Nam iaculis volutpat ligula. Integer vitae felis quis diam laoreet ullamcorper. Etiam tincidunt est vitae est. Ut posuere, mauris at sodales rutrum, turpis tellus fermentum metus, ut bibendum velit enim eu lectus. Suspendisse potenti. Donec at dolor ac metus pharetra aliquam. Suspendisse purus. Fusce tempor ultrices libero. Sed quis nunc. Pellentesque tincidunt viverra felis. Integer elit mauris, egestas ultricies, gravida vitae, feugiat a, tellus.</div> <script type="text/javascript" src="jqueryui1.6rc2/jquery-1.2.6.js"></script> <script type="text/javascript" src="jqueryui1.6rc2/ui/ui.core.js"></script> <script type="text/javascript" src="jqueryui1.6rc2/ui/ui.dialog.js"></script> <script type="text/javascript" src="jqueryui1.6rc2/ui/ui.resizable.js"></script> <script type="text/javascript" src="jqueryui1.6rc2/ui/ui.draggable.js"></script> <script type="text/javascript"> //define function to be executed on document ready $(function(){ //create the dialog $("#myDialog").dialog(); }); </script> </body></html> Dialog properties An options object can be used in a dialog's constructor method to configure various dialog properties. Let's look at the available properties: Save this as dialog1.html in the jqueryui folder. A few more source files are required, specifically the ui.resizable.js and ui.draggable.js files and the flora.resizable.css stylesheet. The JavaScript files are low-level interaction helpers and are only required if the dialog is going to be resizable and draggable. The widget will still function without them. The dialog flora theme file is a mandatory requirement for this component, although the resizable one isn't. Other than that, the widget is initialized in the same way as other widgets. When you run this page in your browser, you should see the default dialog widget shown in the previous screenshot, complete with draggable and resizable behaviors. One more feature that I think deserves mentioning here is modality. The dialog comes with modality built-in, although it is disabled by default. When modality is enabled, a modal overlay element, which covers the underlying page, will be applied. The dialog will sit above the overlay while the rest of the page will be below it. The benefit of this feature is that it ensures the dialog is closed before the underlying page becomes interactive again, and gives a clear visual indicator that the dialog must be closed before the visitor can proceed. Custom dialog skins The dialog's appearance is easy to change from the flora theme used in the first example. Like some of the other widgets, certain aspects of the default or flora themes are required to make the widget function correctly. Therefore, when overriding styles, we need to be careful to just override the rules related to the dialog's display. When creating a new skin for the default implementation, including resizable behavior, we have a lot of new files that will need to be created. Apart from new images for the different components of the dialog, we also have to create new images for the resizing handles. The following files need to be replaced when skinning a dialog: dialog-e.gif dialog-n.gif dialog-ne.gif dialog-nw.gif dialog-s.gif dialog-se.gif dialog-sw.gif dialog-title.gif dialog-titlebar-close.png dialog-titlebar-close.png To make it easier to remember which image corresponds to which part of the dialog, these images are named after the compass points at which they appear. The following image illustrates this: Note that these are file names as opposed to class names. The class names given to each of the different elements that make up the dialog, including resizable elements, are similar, but are prefixed with ui- as we'll see in the next example code. Let's replace these images with some of our own. In a new file in your text editor, create the following stylesheet: .flora .ui-dialog, .flora.ui-dialog { background-color:#99ccff;}.flora .ui-dialog .ui-dialog-titlebar, .flora.ui-dialog.ui-dialog-titlebar { background:url(../img/dialog/my-title.gif) repeat-x; background-color:#003399;}.flora .ui-dialog .ui-dialog-titlebar-close, .flora.ui-dialog.ui-dialog-titlebar-close { background:url(../img/dialog/my-title-close.gif) no-repeat; }.flora .ui-dialog .ui-dialog-titlebar-close-hover, .flora.ui-dialog.ui-dialog-titlebar-close-hover { background:url(../img/dialog/my-title-close-hover.gif) norepeat;}.flora .ui-dialog .ui-resizable-n, .flora.ui-dialog .ui-resizable-n { background:url(../img/dialog/my-n.gif) repeat center top;}.flora .ui-dialog .ui-resizable-s, .flora.ui-dialog .ui-resizable-s { background:url(../img/dialog/my-s.gif) repeat center top;}.flora .ui-dialog .ui-resizable-e, .flora.ui-dialog .ui-resizable-e { background:url(../img/dialog/my-e.gif) repeat right center; }.flora .ui-dialog .ui-resizable-w, .flora.ui-dialog .ui-resizable-w { background:url(../img/dialog/my-w.gif) repeat left center;}.flora .ui-dialog .ui-resizable-ne, .flora.ui-dialog .ui-resizable-ne{ background:url(../img/dialog/my-ne.gif) repeat;}.flora .ui-dialog .ui-resizable-se, .flora.ui-dialog .ui-resizable-se{ background:url(../img/dialog/my-se.gif) repeat;}.flora .ui-dialog .ui-resizable-sw, .flora.ui-dialog .ui-resizable-sw{ background:url(../img/dialog/my-sw.gif) repeat;}.flora .ui-dialog .ui-resizable-nw, .flora.ui-dialog .ui-resizable-nw{ background:url(../img/dialog/my-nw.gif) repeat;} Save this as dialogTheme.css in the styles folder. We should also create a new folder within our img folder called dialog. This folder will be used to store all of our dialog-specific images. All we need to do is specify new images to replace the existing ones used by flora. All other rules can stay the same. In dialog1.html, link to the new file with the following code, which should appear directly after the link to the resizable stylesheet: <link rel="stylesheet" type="text/css" href="styles/dialogTheme.css"> Save the change as dialog2.html. These changes will result in a dialog that should appear similar to the following screenshot: So you can see that skinning the dialog to make it fit in with your existing content is very easy. The existing image files used by the default theme give you something to start with, and it's really just a case of playing around with colors in an image editor until you get the desired effect. Dialog properties An options object can be used in a dialog's constructor method to configure various dialog properties. Let's look at the available properties: Property Default Value Usage autoOpen true Shows the dialog as soon as the dialog method is called bgiframe true Creates an <iframe> shim to prevent <select> elements showing through the dialog in IE6 - at present, the bgiframe plugin is required, although this may not be the case in future versions of this widget buttons   {} Supplies an object containing buttons to be used with the dialog dialogClass ui-dialog Sets additional class names on the dialog for theming purposes draggable true Makes the dialog draggable (use ui.draggable.js) height 200(px) Sets the starting height of the dialog hide none Sets an effect to be used when the dialog is closed maxHeight none Sets a maximum height for the dialog maxWidth none Sets a maximum width for the dialog minHeight 100(px) Sets a minimum height for the dialog minWidth 150(px) Sets a minimum width for the dialog modal false Enables modality while the dialog is open overlay {} Object with CSS properties for the modal overlay position center Sets the starting position of the dialog in the viewport resizable true Makes the dialog resizable (also requires ui.resizable.js) show none Sets an effect to be used when the dialog is opened stack true Causes the focused dialog to move to the front when several dialogs are open title none Alternative to specifying title on source element width 300(px) Sets the original width of the dialog

Installing Zenoss Our first step is to choose one of the three installation methods: virtual appliance, binary installer, or source. The virtual appliance makes a good choice, if we want to evaluate or demonstrate Zenoss. The virtual appliance runs a functional Zenoss system using VMware Player or VMware Server out-of-the-box and needs no Linux knowledge. When run from VMware, the Zenoss virtual appliance may be used to monitor networks with relatively few devices. The binary installer makes a good choice if we want to avoid building Zenoss from source, and we run a supported distribution. The Supported Operating Systems section in this tutorial includes a list of distributions that have binary installation support. We can build from source on a variety of Unix-based environments, like Ubuntu and Mac OS X. A source installation gives us the ability to install Zenoss in the environment of our choice but requires more work. Of the three installation methods, a source install requires the most familiarity with your operating system and presents more points of failure. As we move beyond installing Zenoss to set up, we focus on firewall policies and Simple Network Management Protocol (SNMP) for Linux and Windows systems. Even though Zenoss can use other methods to monitor devices, SNMP is the default monitoring protocol. We are free to change how we monitor and collect information at any time. During the installation and the set up, we work from the command line because it's fast and it's consistent from one distribution to the next. If an error does occur, we can see the error immediately printed to the terminal window. When working from the command line, we assume knowledge of two basic tasks: opening the terminal window and navigating the file structure. For all other tasks, the book provides the exact command to type. After installation and set up, we spend most of our time working with Zenoss through the web interface. Let's get this installation out of the way so we can discover Zenoss. Server Specifications Actual server specifications may vary depending on the amount and frequency of the data you collect. Zenoss Inc. recommends the following hardware specifications as a starting point based on feedback from the community: Network with up to 250 devices: 4 GB RAM Core 2 Duo E6300 1.86/1066 RTL 75 GB disk storage Network with more than 250 devices : 8 GB RAM XEON 5120 DC 1.86/1066/4MB Four 75 GB drives in two RAID-1 pairs Supported Operating Systems Zenoss requires a Unix-based platform and installs on systems capable of running a GNU build environment. However, Zenoss supports only a few distributions with binary installers. The following table shows the available installation options. Installation Type   Platform   Virtual Appliance   Windows Linux   Binary Installer Red Hat Enterprise Linux 5 Fedora Core 6 SUSE   Source Ubuntu FreeBSD Solaris 10 Mac 0S X Other Linux environments   As more binary installers become available, Zenoss posts them to http://www.zenoss.com/download Zenoss Dependencies Virtual appliance users do not need to install any dependencies because they are included in the image. For all other installations, you need to install the following software packages prior to installing Zenoss: MySQL 5.0.22 or higher MySQL development environment Python 2.3.5 or 2.4 Python development environment If you plan to build a Zenoss installation from source code, you need to install the following: SWIG Autoconf GNU build environment Dependent software packages are available via your distribution's normal software package manager. However, the package names and installation commands vary based on distribution. Consult your distribution's documentation for more information. Quick Start with Virtual Appliance If we know how to download and install software in our host environment, we can get a working Zenoss system with the virtual appliance. The Zenoss virtual appliance packages a working Zenoss Core installation inside a Linux guest that can be booted from a host system, including Windows, using VMware's Player, Server, or Workstation programs. The virtual appliance is great for: Users with little or no Linux knowledge Demonstrations and Evaluations Monitoring small networks with a few devices Install Virtual Appliance We will finish the installation as fast as we can download files and install the VMware Player. Let's begin: Download the VMware Player from http://www.vmware.com/player/.Registration is required to complete the download. Install VMware Player according to VMware's installation instructions for your operating system. Download the Zenoss virtual appliance from http://www.zenoss.com/download/ Unzip the Zenoss virtual appliance download file to a working directory in your system. Open VMware Player: On Windows, select Start > Programs > VMware Player. On Linux, select VMplayer from the application menu, or type the command: vmware VMwarePlayer prompts us to load the virtual machine configuration file we previously unzipped, as shown in the following screenshot: Open the Zenoss virtual appliance we unzipped in step 4.   The Zenoss virtual appliance takes a few minutes to load depending on the performance of your system. When the appliance boots, a welcome window opens and displays the IP address of the Zenoss management console and the standard Linux login prompt, as shown in the following screenshot:                 When we connect to Zenoss through our web browser, we use the IP address of the Zenoss management console that displays on the welcome screen (e.g. http://192.168.1.125.8080/). We cannot access our virtualized Zenoss installation by navigating to localhost, which is the host name of the Zenoss virtual appliance. If the IP address of the Zenoss console does not display, we can obtain the IP address using the ifconfig command, as described in the next section: Working with The Virtual Appliance. Zenoss is ready to monitor. Our next step is to set up the servers on our network to be monitored. If you can't wait to see Zenoss in action, feel free to skip the server setup section for now and check out Tutorial 4 for an introduction to web interface. You can come back and set up your servers later.      If this is the first time you are working with VMware or Linux, take a few minutes to get acquainted with the environment.      Working with The Virtual Appliance The Zenoss virtual appliance is a streamlined but functional Linux system, which means we can log in and have access to the underlying Linux environment. Let's cover a few basic tasks.      In order to type inside the virtual appliance window, use the keyboard shortcut: Ctrl + G      To return the cursor to the host desktop, use the keyboard shortcut: Ctrl + Alt      By default, the root login does not have a password assigned. To log in to the virtual appliance, enter the following user name at the login prompt: root   To set a password for the root user, enter the command:      passwd The passwd command prompts us to enter a new password. Assigning a password to the root user makes the system more secure and allows us to connect to the virtual appliance as root via SSH.      The IP address of the Zenoss virtual appliance is displayed at the top of the terminal window when the appliance loads. The most confusing part about using the Zenoss virtual appliance may be picking the correct IP address and port number. We connect to Zenoss on port 8080. So if our virtual appliance has an IP address of 192.168.1.103, then we use http://192.168.1.103:8080/o open the Zenoss login screen. If we use port 8003, we access the rPath management console, which is the underlying system used to build the Zenoss virtual appliance. After login, we can find additional IP configuration as shown in the following screenshot, with the command: ifconfig     To shut down the virtual appliance, select Player > Exit from the VMware Player. We may also use the the command: shutdown -h now If we shut down the virtual appliance, Zenoss no longer monitors the network and the web interface is not accessible.We may now jump ahead to the Server Setup section of this tutorial for help in configuring the servers we wish to monitor. Binary Installation Zenoss provides a binary installer in RPM format for Red Hat Enterprise Linux, which covers CentOS and Fedora Core. Binaries for additional distributions are added by Zenoss as the market demands and as time allows. To install Zenoss and its dependencies on Red Hat: Download the latest RPM for Red Hat Enterprise Linux from http://www.zenoss.com/download/ Open a terminal window and become the root user: su - If you have not yet installed the Zenoss dependencies, run: yum -y install mysql mysql-server net-snmp net-snmp-utils / python python-dev Install the Zenoss RPM by running the following command from the download directory where x.x-x equals the latest version number: rpm -ivh zenoss-2.x.x-x.el5.i386.rpm Start SNMP: service snmp start Start MySQL: service mysqld start Start Zenoss: /etc/init.d/zenoss start Let's test our installation. Open a browser and enter the URL of the Zenoss server, which listens on port 8080 (for example http://192.168.115:8080/ ). A screen appears as shown in the following screenshot.  

Passing information in and out The main reason for the simplicity of our Hello World example was that it neither took in any information, nor passed any information out—the rule always fired, and said the same thing. In real life, we need to pass information between our rules and the rest of the system. You may remember that in our tour of the Guvnor, we came across models that solved this problem of 'How do we get information into and out of the rules?'. Here is the spreadsheet that we will use as an example in this article: If we want to duplicate this in our model/JavaBean, we would need places to hold four key bits of sales-related information. Customer Name: String (that is, a bit of text) Sales: Number Date of Sale: Date Chocolate Only Customer: Boolean (that is, a Y/N type field) We also need a description for this group of information that is useful when we have many spreadsheets/models in our system (similar to the way this spreadsheet tab is called Sales). Note that one JavaBean (model) is equal to one line in the spreadsheet. Because we can have multiple copies of JavaBeans in memory, we are able to represent the many lines of information that we have in a spreadsheet. Later, we'll loop and add 10, 100, or 1000 lines (that is, JavaBeans) of information into Drools (for as many lines as we need). As we loop, adding them one at a time, the various rules will fire as a match is made. Building the fact model We will now build this model in Java using the Eclipse editor. We're going to do it step-by-step. Open the Eclipse/JBoss IDE editor that you installed earlier. If prompted, use the default workspace. (Unless you've a good reason to put it somewhere else.) From the menu bar at the top the screen, select File | New Project. Then choose Java Project from the dialog box that appears. You can either select this by starting to type "Java Project" into the wizard, or by finding it by expanding the various menus. In the Create a new Java Project dialog that appears, give the project a name in the upper box. For our example, we'll call it SalesModel (one word, no spaces). Accept the other defaults (unless you have any other reason to change them). Our screen will now look something like this: When you've finished entering the details, click on Finish. You will be redirected to the main screen, with a new project (SalesModel) created. If you can't see the project, try opening either the Package or the Navigator tab. When you can see the project name, right-click on it. From the menu, choose New | Package. The New Java Package dialog will be displayed, as shown below. Enter the details as per the screenshot to create a new package called org.sample, and then click on Finish. If you are doing this via the navigator (or you can take a peek via Windows Explorer), you'll see that this creates a new folder org, and within it a subfolder called sample. Now that we've created a set of folders to organize our JavaBeans, let's create the JavaBean itself by creating a class. To create a new Java class, expand/select the org.sample package (folder) that we created in the previous step. Right-click on it and select New Class. Fill in the dialog as shown in the following screenshot, and then click on Finish: We will now be back in the main editor, with a newly created class called Sales.java (below). For the moment, there isn't much there—it's akin to two nested folders (a sample folder within one called org) and a new (but almost empty) file / spreadsheet called Sales. package org.sample;public class Sales {} By itself, this is not of much use. We need to tell Java about the information that we want our class (and hence the beans that it creates) to hold. This is similar to adding new columns to a spreadsheet. Edit the Java class until it looks something like the code that follows (and take a quick look of the notes information box further down the page if you want to save a bit of typing). If you do it correctly, you should have no red marks on the editor (the red marks look a little like the spell checking in Microsoft Word). package org.sample;import java.util.Date;public class Sales {private String name;private long sales;private Date dateOfSale;private boolean chocolateOnlyCustomer;public String getName() {return name;}public void setName(String name) {this.name = name;}public long getSales() {return sales;}public void setSales(long sales) {this.sales = sales;}public Date getDateOfSale() {return dateOfSale;}public void setDateOfSale(Date dateOfSale) {this.dateOfSale = dateOfSale;}public boolean isChocolateOnlyCustomer() {return chocolateOnlyCustomer;}public void setChocolateOnlyCustomer(boolean choclateOnlyCustomer) {this.chocolateOnlyCustomer = chocolateOnlyCustomer;}} Believe it or not, this piece of Java code is almost the same as the Excel Spreadsheet we saw at the beginning of the article. If you want the exact details, let's go through what it means line by line. The braces ({ and }) are a bit like tabs. We use them to organize our code. package—This data holder will live in the subdirectory sample within the directory org. import—List of any other data formats that we need (for example, dates). Text and number data formats are automatically imported. Public class Sales—This is the mould that we'll use to create a JavaBean. It's equivalent to a spreadsheet with a Sales tab. Private String name—create a text (string) field and give it a column heading of 'name'. The private bit means 'keep it hidden for the moment'. The next three lines do the same thing, but for sales (as a number/long), dateOfSale (as a date) and chocolateOnlyCustomer (a Boolean or Y/N field). The rest of the lines (for example, getName and setName) are how we control access to our private hidden fields. If you look closely, they follow a similar naming pattern. The get and set lines (in the previous code) are known as accessor methods. They control access to hidden or private fields. They're more complicated than may seem necessary for our simple example, as Java has a lot more power than we're using at the moment.Luckily, Eclipse can auto-generate these for us. (Right-click on the word Sales in the editor, then select Source | Generate Getters and Setters from the context menu. You should be prompted for the Accessor methods that you wish to create.) Once you have the text edited like the sample above, check again that there are no spelling mistakes. A quick way to do this is to check the Problems tab in Eclipse (which is normally at the bottom of the screen). Now that we've created our model in Java, we need to export it so that we can use in the Guvnor. In Eclipse, right-click on the project name (SalesModel) and select Export. From the pop-up menu, select jar (this may be under Java; you might need to type jar to bring it up). Click on Next. The screen shown above will be displayed. Fill out this screen. Accept the defaults, but give the JAR file a name (SalesModel.jar) and a location (in our case C:tempSalesModel.jar). Remember these settings as we'll need them shortly. All being well, you should get an 'export successful' message when you click on the Finish button, and you will be able to use Windows Explorer to find the JAR file that you just created.

Throughout this article, we will follow the "learning by example" technique, and we will develop a completely functional JSF application that will represent a JSF registration form as you can see in the following screenshot. These kinds of forms can be seen on many sites, so it will be very useful to know how to develop them with JSF Tools. The example consists of a simple JSP page, named register.jsp, containing a JSF form with four fields (these fields will be mapped into a managed bean), as follows: personName – this is a text field for the user's name personAge – this is a text field for the user's age personPhone – this is a text field for the user's phone number personBirthDate – this is a text field for the user's birth date The information provided by the user will be properly converted and validated using JSF capabilities. Afterwards, the information will be displayed on a second JSP page, named success.jsp. Overview of JSF Java Server Faces (JSF) is a popular framework used to develop User Interfaces (UI) for server-based applications (it is also known as JSR 127 and is a part of J2EE 1.5). It contains a set of UI components totally managed through JSF support, like handling events, validation, navigation rules, internationalization, accessibility, customizability, and so on. In addition, it contains a tag library for expressing UI components within a JSP page. Among JSF features, we mention the ones that JSF provides: A set of base UI components Extension of the base UI components to create additional UI component libraries Custom UI components Reusable UI components Read/write application date to and from UI components Managing UI state across server requests Wiring client-generated events to server-side application code Multiple rendering capabilities that enable JSF UI components to render themselves differently depending on the client type JSF is tool friendly JSF is implementation agnostic Abstract away from HTTP, HTML, and JSP Speaking of JSF life cycle, you should know that every JSF request that renders a JSP involves a JSF component tree, also called a view. Each request is made up of phases. By standard, we have the following phases (shown in the following figure): The restore view is built Request values are applied Validations are processed Model values are updated The applications is invoked A response is rendered During the above phases, the events are notified to event listeners We end this overview with a few bullets regarding JSF UI components: A UI component can be anything from a simple to a complex user interface (for example, from a simple text field to an entire page) A UI component can be associated to model data objects through value binding A UI component can use helper objects, like converters and validators A UI component can be rendered in different ways, based on invocation A UI component can be invoked directly or from JSP pages using JSF tag libraries Creating a JSF project stub In this section you will see how to create a JSF project stub with JSF Tools. This is a straightforward task that is based on the following steps: From the File menu, select New | Project option. In the New Project window, expand the JBoss Tools Web node and select the JSF Project option (as shown in the following screenshot). After that, click the Next button. In the next window, it is mandatory to specify a name for the new project (Project Name field), a location (Location field—only if you don't use the default path), a JSF implementation (JSF Environment field), and a template (Template field). As you can see, JSF Tools offers a set of predefined templates as follows: JSFBlankWithLibs—this is a blank JSF project with complete JSF support. JSFKickStartWithLibs—this is a demo JSF project with complete JSF support. JSFKickStartWithoutLibs—this is a demo JSF project without JSF support. In this case, the JSF libraries are missing for avoiding the potential conflicts with the servers that already offer JSF support. JSFBlankWithoutLibs—this is a blank JSF project without JSF support. In this case, the JSF libraries are missing for avoiding the potential conflicts with the servers that already offer JSF support (for example, JBoss AS includes JSF support). The next screenshot is an example of how to configure our JSF project at this step. At the end, just click the Next button: This step allows you to set the servlet version (Servlet Version field), the runtime (Runtime field) used for building and compiling the application, and the server where the application will be deployed (Target Server field). Note that this server is in direct relationship with the selected runtime. The following screenshot shows an example of how to complete this step (click on the Finish button): After a few seconds, the new JSF project stub is created and ready to take shape! You can see the new project in the Package Explorer view.

Uses of non-default themes Magento's flexibility in themes gives a lot of scope for possible uses of non-default themes. Along with the ability to have seasonal themes on our Magento store, non-default themes have a range of uses: A/B testing Easily rolled-back themes Changing the look and feel of specific pages, such as for a particular product within your store Creating brand-specific stores within your store, distinguishing your store's products further, if you sell a variety of the same products from different brands A/B testing A/B testing allows you to compare two different aspects of your store. You can test different designs on different weeks, and can then compare which design attracted more sales. Magento's support for non-default themes allows you to do this relatively easily. Bear in mind that the results of such a test may not represent what actually drives your customers to buy your store's products for a number of reasons. True A/B testing on websites is performed by presenting the different designs to your visitors at random. However, performing it this way may give you an insight in to what your customers prefer. Easily rolled-back themes If you want to make changes to your store's existing theme, then you can make use of a non-default theme to overwrite certain aspects of your store's look and feel, without editing your original theme. This means that if your customers don't like a change, or a change causes problems in a particular browser, then you can simply roll-back the changes, by changing your store's settings to display the original theme. Non-default themes A default theme is the default look and feel to your Magento store. That is, if no other styling or presentational logic is specified, then the default theme is the one that your store's visitors will see. Magento's default theme looks similar to the following screenshot: Non-default themes are very similar to the default themes in Magento. Like default themes, Magento's non-default themes can consist of one or more of the following elements: Skins—images and CSS Templates—the logic that inserts each block's content or feature (for example, the shopping cart) in to the page Layout—XML files that define where content is displayed Locale—translations of your store The major difference between a default and a non-default theme in Magento is that a default theme must have all of the layout and template files required for Magento to run. On the other hand, a non-default theme does not need all of these to function, as it relies on your store's default theme, to some extent. Locales in Magento: Many themes are already partially or fully translated into a huge variety of languages. Locales can be downloaded from the Magento Commerce website at http://www.magentocommerce.com/langs. Magento theme hierarchy In its current releases, Magento supports two themes: a default theme, and a non-default theme. The non-default theme takes priority when Magento is deciding what it needs to display. Any elements not found in the non-default theme are then found in the default theme specified. Future versions of Magento should allow more than one default theme to be used at a time, as well as allow more detailed control over the hierarchy of themes in your store. Magento theme directory structure Every theme in Magento must maintain the same directory structure for its files. The skin, templates, and layout are stored in their own directories. Templates Templates are located in the app/design/frontend/interface/theme/template directory of your Magento store's installation, where interface is your store's interface (or package) name (usually default), and theme is the name of your theme (for example, cheese). Templates are further organized in subdirectories by module. So, templates related to the catalog module are stored in app/design/frontend/interface/theme/template/catalog directory, whereas templates for the checkout module are stored in app/design/frontend/interface/theme/template/checkout directory. Layout Layout files are stored in app/design/frontend/interface/theme/layout. The name of each layout file refers to a particular module. For example, catalog.xml contains layout information for the catalog module, whereas checkout.xml contains layout information for the checkout module.

As you work on and develop your own WordPress themes, you will no doubt discover that life will go much smoother if you debug and validate at each step of your theme development process. The full process will pretty much go like this: Add some code, check to see the page looks good in Firefox, validate, then check it in IE and any other browsers you and your site's audience use, validate again if necessary, add the next bit of code... repeat as necessary until your theme is complete. Don't Forget About Those Other Browsers and Platforms I'll mostly be talking about working in Firefox and then 'fixing' for IE. This is perhaps, unfairly, assuming you're working on Windows or a Mac and that the source of all your design woes will (of course) be Microsoft IE's fault. You must check your theme in all browsers and if possible, other platforms, especially the ones you know your audience uses the most. I surf with Opera a lot and find that sometimes JavaScripts can 'hang' or slow that browser down, so I debug and double-check scripts for that browser. I'm a freelance designer and find a lot of people who are also in the design field use a Mac (like me), and visit my sites using Safari, so I occasionally take advantage of this and write CSS that caters to the Safari browser. (Safari will interpret some neat CSS 3 properties that other browsers don't yet.) Generally, if you write valid markup and code that looks good in Firefox, it will look good in all the other browsers (including IE). Markup and code that goes awry in IE is usually easy to fix with a work-around. Firefox is a tool, nothing more! Firefox contains features and plug-ins that we'll be taking advantage of to help us streamline the theme development process and aid in the validation and debugging of our theme. Use it just like you use your HTML/code editor or your image editor. When you're not developing, you can use whatever browser you prefer. Introduction to Debugging Have a look at our initial work-flow chart. I was insistent that your work-flow pretty much be as edit -> check it -> then go back and edit some more. The main purpose of visually checking your theme in Firefox after adding each piece of code is so that you can see if it looks OK, and if not, immediately debug that piece of code. Running a validation check as you work just doubly ensures you're on the right track. So, your work-flow really ends up looking something more like this: You want to work with nice, small pieces or 'chunks' of code. I tend to define a chunk in XHTML markup as no more than one div section, the internal markup, and any WordPress template tags it contains. When working with CSS, I try to only work with one id or class rule at a time. Sometimes, while working with CSS, I'll break this down even further and test after every property I add to a rule, until the rule looks as I intend and validates. As soon as you see something that doesn't look right in your browser, you can check for validation and then fix it. The advantage of this work-flow is you know exactly what needs to be fixed and what XHTML markup or PHP code is to blame. All the code that was looking fine and validating before, you can ignore. The recently added markup and code is also the freshest in your mind, so you're more likely to realize the solution needed to fix the problem. If you add too many chunks of XHTML markup or several CSS rules before checking it in your browser, then discover something has gone awry, you'll have twice as much sleuthing to do in order to discover which (bit or bits) of markup and code are to blame. Again, your fail-safe is your backup. You should be regularly saving backups of your theme at good stable stopping points. If you do discover that you just can't figure out where the issue is, rolling back to your last stable stopping point and starting over might be your best bet to getting back on track. Here, you'll primarily design for Firefox and then apply any required fixes, hacks, and workarounds to IE. You can do that for each piece of code you add to your theme. As you can see in the preceding figure, first check your theme in Firefox and if there's a problem, fix it for Firefox first. Then, check it in IE and make any adjustments for that browser. At this point, you guessed it, more than half of the debugging process will depend directly on your own eyeballs and aesthetics. If it looks the way you intended it to look and works the way you intended it to work, check that the code validates and move on. When one of those three things doesn't happen (it doesn't look right, work right, or validate), you have to stop and figure out why. Troubleshooting Basics Suffice to say, it will usually be obvious when something is wrong with your WordPress theme. The most common reasons for things being 'off' are: Mis-named, mis-targeted, or inappropriately-sized images. Markup text or PHP code that affects or breaks the Document Object Model (DOM) due to being inappropriately placed or having syntax errors in it. WordPress PHP code copied over incorrectly, producing PHP error displays in your template, rather than content. CSS rules that use incorrect syntax or conflict with later CSS rules. The first point is pretty obvious when it happens. You see no images, or worse, you might get those little ugly 'x'd' boxes in IE if they're called directly from the WordPress posts or pages. Fortunately, the solution is also obvious: you have to go in and make sure your images are named correctly if you're overwriting standard icons or images from another theme. You also might need to go through your CSS file and make sure the relative paths to the images are correct. For images that are not appearing correctly because they were mis-sized, you can go back to your image editor, fix them, and then re-export them, or you might be able to make adjustments in your CSS file to display a height and/or width that is more appropriate to the image you designed. Don't forget about casing! If by some chance you happen to be developing your theme with an installation of WordPress on a local Windows machine, do be careful with the upper and lower casing in your links and image paths. Chances are, the WordPress installation that your theme is going to be installed into is more likely to be on a Unix or Linux web server. For some darn reason, Windows (even if you're running Apache, not IIS) will let you reference and call files with only the correct spelling required. Linux, in addition to spelling, requires the upper and lower casing to be correct. You must be careful to duplicate exact casing when naming images that are going to be replaced and/or when referencing your own image names via CSS. Otherwise, it will look fine in your local testing environment, but you'll end up with a pretty ugly theme when you upload it into your client's installation of WordPress for the first time (which is just plain embarrassing). For the latter two points, one of the best ways to debug syntax errors that cause visual 'wonks' is not to have syntax errors in the first place (don't roll your eyes just yet). This is why, in the last figure of our expanded work-flow chart, we advocate you to not only visually check your design as it progresses in Firefox and IE, but also test for validation. Why Validate? Hey, I understand it's easy to add some code, run a visual check in Firefox and IE, see everything looks OK, and then flip right back to your HTML editor to add more code. After-all, time is money and you'll just save that validation part until the very end. Besides, validation is just icing on the cake. Right? The problem with debugging purely based on visual output is, all browsers (some more grievously than others) will try their best to help you out and properly interpret less than ideal markup. One piece of invalid markup might very well look OK initially, until you add more markups and then the browser can't interpret your intentions between the two types of markup anymore. The browser will pick its own best option and display something guaranteed to be ugly. You'll then go back and futz around with the last bit of code you added (because everything was fine until you added that last bit, so that must be the offending code) which may or may not fix the problem. The next bits of code might create other problems and what's worse that you'll recognize a code chunk that you know should be valid! You're then frustrated, scratching your head as to why the last bit of code you added is making your theme 'wonky' when you know, without a doubt, it's perfectly fine code! The worst case scenario I tend to see of this type of visual-only debugging is that the theme developers get desperate and start randomly making all sorts of odd hacks and tweaks to their markup and CSS to get it to look right. Miraculously, they often do get it to look right, but in only one browser. Most likely, they've inadvertently discovered what the first invalid syntax was and unwittingly applied it across all the rest of their markup and CSS. Thus, that one browser started consistently interpreting the bad syntax! The theme designer then becomes convinced that the other browser is awful and designing these non-WYSIWYG, dynamic themes is a pain. Avoid all that frustration! Even if it looks great in both browsers, run the code through the W3C's XHTML and CSS validators. If something turns up invalid, no matter how small or pedantic the validator's suggestion might be (and they do seem pedantic at times), incorporate the suggested fix into your markup now, before you continue working. This will keep any small syntax errors from compounding future bits of markup and code into big visual 'uglies' that are hard to track down and troubleshoot. PHP Template Tags The next issue you'll most commonly run into is mistakes and typos that are created by 'copying and pasting' your WordPress template tags and other PHP code incorrectly. The most common result you'll get from invalid PHP syntax is a 'Fatal Error.' Fortunately, PHP does a decent job of trying to let you know what file name and line of code in the file the offending syntax lives (yet another reason why I highly recommend an HTML editor that lets you view the line number in the Code view). If you get a 'Fatal Error' in your template, your best bet is to open the file name that is listed and go to the line in your editor. Once there, search for missing < ?php ? > tags. Your template tags should also be followed with parenthesis followed by a semicolon like ( ) ; . If the template tag has parameters passed in it, make sure each parameter is surrounded by single quote marks, that is, template_tag_name('parameter name', 'next_parameter');. CSS Quick Fixes Last, your CSS file might get fairly big, fairly quickly. It's easy to forget you already made a rule and/or just accidentally create another rule of the same name. It's all about cascading, so whatever comes last, overwrites what came first. Double rules: It's an easy mistake to make, but validating using W3C's CSS validator will point this out right away. However, this is not the case for double properties within rules! W3C's CSS validator will not point out double properties if both properties use correct syntax. This is one of the reasons why the !important hack returns valid. (We'll discuss this hack just a little further down in this article under To Hack or Not to Hack.) Perhaps you found a site that has a nice CSS style or effect you like, and so you copied those CSS rules into your theme's style.css sheet. Just like with XHTML markup or PHP code, it's easy to introduce errors by miscopying the bits of CSS syntax in. A small syntax error in a property towards the bottom of a rule may seem OK at first, but cause problems with properties added to the rule later. This can also affect the entire rule or even the rule after it. Also, if you're copying CSS, be aware that older sites might be using depreciated CSS properties, which might be technically OK if they're using an older HTML DOCTYPE, but won't be OK for the XHTML DOCTYPE you're using. Again, validating your markup and CSS as you're developing will alert you to syntax errors, depreciated properties, and duplicate rules which could compound and cause issues in your stylesheet down the line. Advanced Troubleshooting Take some time to understand the XHTML hierarchy. You'll start running into validation errors and CSS styling issues if you wrap a 'normal' (also known as a 'block') element inside an 'in-line' only element, such as putting a header tag inside an anchor tag (<a href, <a name, etc.) or wrapping a div tag inside a span tag. Avoid triggering quirks mode in IE! This, if nothing else, is one of the most important reasons for using the W3C HTML validator. There's no real way to tell if IE is running in quirks mode. It doesn't seem to output that information anywhere (that I've found). However, if any part of your page or CSS isn't validating, it's a good way to trigger quirks mode in IE. The first way to avoid quirks mode is to make sure your DOCTTYPE is valid and correct. If IE doesn't recognize the DOCTYPE (or if you have huge conflicts, like an XHTML DOCTYPE, but then you use all-cap, HTML 4.0 tags in your markup), IE will default into quirks mode and from there on out, who knows what you'll get in IE. My theme stopped centering in IE! The most obvious thing that happens when IE goes into quirks mode is that IE will stop centering your layout in the window properly if your CSS is using the margin: 0 auto; technique. If this happens, immediately fix all the validation errors in your page. Another big obvious item to note is if your div layers with borders and padding are sized differently between browsers. If IE is running in quirks mode it will incorrectly render the box model, which is quite noticeable between Firefox and IE if you're using borders and padding in your divs. Another item to keep track of is to make sure you don't have anything that will generate any text or code above your DOCTYPE. Firefox will read your page until it hits a valid DOCTYPE and then proceed from there, but IE will just break and go into quirks mode. Fixing CSS Across Browsers If you've been following our debug -> validate method described in the article, then for all intents and purposes, your layout should look pretty spot-on between both the browsers. Box Model Issues In the event that there is a visual discrepancy between Firefox and IE, in most cases it's a box model issue arising because you're running in quirks mode in IE. Generally, box model hacks apply to pre IE 6 browsers (IE 5.x) and apply to IE6 if it's running in quirks mode. Again, running in quirks mode is to be preferably avoided, thus eliminating most of these issues. If your markup and CSS are validating (which means you shouldn't be triggering quirks mode in IE, but I've had people 'swear' to me their page validated yet quirks mode was being activated), you might rather 'live with it' than try to sleuth what's causing quirks mode to activate. Basically, IE 5.x and IE6 quirks mode don't properly interpret the box model standard and thus, 'squish' your borders and padding inside your box's width, instead of adding to the width as the W3C standard recommends. However, IE does properly add margins! This means that if you've got a div set to 50 pixels wide, with a 5 pixel border, 5 pixels of padding, and 10 pixels of margin in Firefox, your div is actually going to be 60 pixels wide with 10 pixels of margin around it, taking up a total space of 70 pixels.. In IE quirks mode, your box is kept at 50 pixels wide (meaning it's probably taller than your Firefox div because the text inside is having to wrap at 40 pixels), yet it does have 10 pixels of margin around it. You can quickly see how even a one pixel border, some padding, and a margin can start to make a big difference in layout between IE and Firefox!

Introduction It is assumed that you have a working copy of MySQL which you can use to work with this article. The MySQL version used in this article came with the XAMPP download. XAMPP is an easy to install (and use) Apache distribution containing MySQL, PHP, and Perl. The distribution used in this article is XAMPP for Windows. You can find documentation here. Here is a screen shot of the XAMPP control panel where you can turn the services on and off and carry out other administrative tasks. You need to follow the steps indicated here: Create a database in MySQL to which you will export a table from Microsoft Access 2003 Create a ODBC DSN that helps you connecting Microsoft Access to MySQL Export the table or tables Verify the exported items Creating a database in MySQL You can create a database in MySQL by using the command 'Create Database' in MySQL or using a suitable graphic user interface such as MySQL workbench. You will have to refer to documentation that works with your version of MySQL. Herein the following version was used. The next listing shows how a database named TestMove was created in MySQL starting from the bin folder of the MySQL program folder. Follow the commands and the response from the computer. The Listing 1 and the folders are appropriate for my computer and you may find it in your installation directory. The databases you will be seeing will be different from what you see here except for those created by the installation. Listing 1: Login and create a database Microsoft Windows XP [Version 5.1.2600](C) Copyright 1985-2001 Microsoft Corp.C:Documents and SettingsJayaram Krishnaswamy>cdC:>cd xamppmysqlbinC:xamppmysqlbin>mysql -h localhost -u root -pEnter password: *********Welcome to the MySQL monitor. Commands end with ; or g.Your MySQL connection id is 2Server version: 5.1.30-community MySQL Community Server (GPL)Type 'help;' or 'h' for help. Type 'c' to clear the buffer.mysql> show databases;+--------------------+| Database |+--------------------+| information_schema || cdcol || expacc || mengerie || mydb || mysql || phpmyadmin || test || testdemo || webauth |+--------------------+10 rows in set (0.23 sec)mysql> create database TestMove;Query OK, 1 row affected (0.00 sec)mysql> show databases;+--------------------+| Database |+--------------------+| information_schema || cdcol || expacc || mengerie || mydb || mysql || phpmyadmin || test || testdemo || testmove || webauth |+--------------------+11 rows in set (0.00 sec)mysql> The login detail that works error free is shown. The preference for host name is localhost v/s either the Machine Name (in this case Hodentek2) or the IP address. The first 'Show Databases' command does not display the TestMove we created which you can see in response to the 2nd Show Databases command. In windows the commands are not case sensitive. Creating an ODBC DSN to connect to MySQL When you install from XAMPP you will also be installing an ODBC driver for MySQL for the version of MySQL included in the bundle. In the MySQL version used for this article the version is MySQL ODBC5.1 and the file name is MyODBC5.dll. Click Start | Control Panel | Administrative Tools | Data Sources (ODBC) and open the ODBC Data Source Administrator window as shown. The default tab is User DSN. Change to System DSN as shown here. Click the Add... button to open the Create New Data Source window as shown. Scroll down and choose MySQL ODBC 5.1 Driver as the driver and click Finish. The MySQL Connector/ODBC Data Source Configuration window shows up. You will have to provide a Data Source Name (DSN) and a description. The server is the localhost. You must have your User Name/Password information to proceed further. The database is the name of the database you created earlier (TestMove) and this should show up in the drop-down list if the rest of the information is correct. Accept the default port. If all information is correct the Test button gets enabled. Click and test the connection using the Test button. You should get a response as shown. Click the OK button on the Test Result window. Click OK on the MySQL Connector/ODBC Data Source Configuration window. There are a number of other flags that you can set up using the 'Details' button. The defaults are acceptable for this article. You have successfully created a System DSN 'AccMySQL' as shown in the next window. Click OK. Verify the contents of TestMove The TestMove is a new database created in MySQL and as such it is empty as you verify in the following listing. Listing 2: Database TestMove is empty mysql> use testmove;Database changedmysql> show tables;Empty set (0.00 sec)mysql>

{literal} Overview The following steps will be followed in authoring an Intranet report using Postgres Plus as the backend database. Creating an ODBC DSN to access the data on Postgres Plus Creating a report with Report Builder 2.0 Configuring the data source for the control Configuring the report layout to display data Deploying the report on the Report Server The categories table in the EnterpriseDB shown will be used to provide the data for the report. The categories table is on the PGNorthwind database on the EnterpriseDB Advanced Server 8.3 shown in the next figure. Creating an ODBC DSN to access the data on Postgres Plus Click on Start | Control Panel | Administrative Tools | Data Sources (ODBC) to bring up the ODBC Data Source Administrator window. Click on Add.... In the Create New Data Source window scroll down to choose EnterpriseDB 8.3 under the list heading Name as shown. Click Finish. The EnterpriseDB ODBC Driver page gets displayed as shown. Accept the default name for the Data Source(DSN) or, if you prefer, change the name. Here the default is accepted. The Database, Server, User Name, Port and the Password should all be available to you. If you click on the option button Datasource you display a window with two pages as shown. Make no changes to the pages and accept defaults but make sure you review the pages. Click OK and you will be back in the EnterpriseDB Driver window. If you click on the option button Global the Global Settings window gets displayed (not shown). These are logging options as the page describes. Click Cancel to the Global Settings window. Click on the Test button and verify that the connection was successful. Click on the Save button and save the DSN under the list heading User DSN. The DSN EnterpriseDB enters the list of DSN's created as shown here.      Creating a report with Report Builder 2.0 It is assumed that the Report Builder 2.0 is installed on the computer on which both EnterpriseDB's Advanced Server 8.3 as well as the Reporting Services / SQL Server 2008 are installed. To proceed further the SQL Server 2008 Database Engine and the Reporting Services must have started and running. Start | All programs | Microsoft SQL Server 2008 Report Builder 2.0 will bring up the following display. Click on Report Builder 2.0. The Report Builder 2.0 gets displayed as shown. Double click the Table or Matrix icon. This displays the New Table or Matrix window as shown. Configuring the data source for the control Click on the New... button. This brings up the Data Source Properties window as shown. Click on the drop-down handle for "Select connection type:" as shown, scroll down and click on ODBC Click on the Build... button. This brings up the Connection Properties window as shown. Click on the option "Use user or system data source name" and then click on the drop-down handle. In the list of ODBC DSN's on this machine which gets displayed in the list click on EnterpriseDB as shown. Enter credentials for the EnterpriseDB as shown. Test the connection with the Test Connection button. A Test Results message will be generated displaying success if the connection information provided is correct as shown Click OK to the two open windows. This will bring you back to the Data Source Properties window displaying the connection string in the window. Click on navigational link Credentials on the left which opens the "Change the credentials used to connect to the data source". Make note that the credentials you supplied earlier have arrived at this page. If you need to be prompted you may check this option. Herein no changes will be made. Click on the OK button. In the New Table or Matrix window DataSource1 (in this report) will be high lighted. Click on the Next button. This brings up the "Design a query" window as shown. In the top pane of the query window type in the SQL Statement as shown. You may also test the query by clicking on the (!) button and the query result will appear in the bottom pane as shown.