Table of Contents
Objective: To learn about what triggers events to be fired in the Nuxeo system and how to take actions in Java code to handle these events. Learn how to test Java code that is part of a bundle inside Eclipse.
In historic events, the so-called great men are labels giving names to events, and like labels they have but the smallest connection with the event itself. -- L. Tolstoy, Russian novelist (1828-1910)
If you have any comments, questions, or general-purpose harassment you would like give us about this book, then please use the comment form at the bottom of each page! We promise that we will try to incorporate any feedback you give (minus the profanity, of course), will respond to your questions, and credit you appropriately.
In the lessons to this point, we have not required the reader to write Java code. The reasons for this "XML first" approach (with apologies to Winston Churchill) were two fold. First, it allowed us to show many features and functions of the platform that you can access without Java code. Second, it allowed the introduction of many key concepts with minimal "overhead" during the explanation. The reader should now be quite familiar with concepts like manifests, extension points, schemas, and document types so detailed explanations will not be necessary as we use these concepts in the Java code.
The editor is not convinced that the construction of sets of XML files that correctly "implement" desired functionality, such as we have done with the Upcoming document type, is not "coding." Many authors would argue that the ability to configure Nuxeo via XML files, such as the reader has done to this point, shows that Nuxeo's feature set (and power) can be used "without coding," but this phrase has been deliberately omitted in this book.
Up to this point, we have encouraged the reader to use Eclipse
only as a text editor-for the XML files-and to use Maven to build the
bundles. Again, this decision was made to simplify the explanations
needed. Now, the rubber meets the road in the battle for supremency of
the build tools. As before, please check out the project named
lesson-events from the SVN repository. Again, you
should use maven from the command line to construct the eclipse project
files with mvn eclipse:eclipse. This time, however,
you will also need to a script that is suppied with the lesson like
this:
/nuxeo/workspace/lesson-events$ mvn eclipse:clean [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'eclipse'. [INFO] ------------------------------------------------------------------------ [INFO] Building Events [INFO] task-segment: [eclipse:clean] [INFO] ------------------------------------------------------------------------ [INFO] [eclipse:clean] [INFO] Deleting file: .project [INFO] Deleting file: .classpath [INFO] Deleting file: .wtpmodules [INFO] Deleting file: .component [INFO] Deleting file: org.eclipse.wst.common.component [INFO] Deleting file: org.eclipse.wst.common.project.facet.core.xml [INFO] Deleting file: org.eclipse.jdt.core.prefs [INFO] Deleting directory: .settings [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESSFUL [INFO] ------------------------------------------------------------------------ [INFO] Total time: 1 second [INFO] Finished at: Fri Feb 27 12:26:40 CET 2009 [INFO] Final Memory: 14M/340M [INFO] ------------------------------------------------------------------------ /nuxeo/workspace/lesson-events$ $ mvn eclipse:eclipse [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'eclipse'. [INFO] ------------------------------------------------------------------------ [INFO] Building Events [INFO] task-segment: [eclipse:eclipse] [INFO] ------------------------------------------------------------------------ [INFO] Preparing eclipse:eclipse [INFO] [buildnumber:create {execution: default}] [INFO] Storing buildNumber: 20090227-122648 at timestamp: 1235734008892 [INFO] [apt:execute {execution: generate-bindings}] [INFO] [nuxeo:eclipse-version {execution: eclipsize-version}] [INFO] eclipseVersion:0.0.1.0 [INFO] [eclipse:eclipse] [INFO] Using source status cache: /nuxeo/workspace/lesson-events/target/mvn-eclipse-cache.properties [INFO] Wrote settings to /nuxeo/workspace/lesson-events/.settings/org.eclipse.jdt.core.prefs [INFO] Wrote Eclipse project for "lesson-events" to /nuxeo/workspace/lesson-events. [INFO] [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESSFUL [INFO] ------------------------------------------------------------------------ [INFO] Total time: 6 seconds [INFO] Finished at: Fri Feb 27 12:26:53 CET 2009 [INFO] Final Memory: 45M/410M [INFO] ------------------------------------------------------------------------ /nuxeo/workspace/lesson-events$ ./fixeclipse Fixing eclipse classpath to use bin output directory instead of target... ./.classpath Done. Replacing missing or badly generated files with .*.ok files... Done.
If you read the listing above, you will notice that it starts not
with mvn eclipse:eclipse, but with mvn
eclipse:clean. This invocation of maven insures that all
previous changes that you might have made to the eclipse configuration
for this project are deleted (cleaned). Then we use mvn
eclipse:eclipse to create the necessary files for Eclipse.
Finally, we use ./fixeclipse to "fix" some things
about the interaction between eclipse and maven. If you look at the
output of the fixeclipse script, you will it changes the Eclipse output
directory to bin, instead of the maven standard one
of target. If you were to not do this, you will
find that eclipse and maven will interact badly with one another.
In a previous lesson when we described how to set up your
development environment, we warned against using any of the "maven
plugins" within eclipse. We did this because a common one, m2eclipse,
attempts to "merge" all the output directories into
target and the merging does not work well with
Nuxeo + Eclipse. We know because some of the authors use it! Now that
you have run the fixeclipse script, you actually can use the m2eclipse
successfully. m2eclipse, however, may not have the result you
anticipated since building within Eclipse now sends its output to bin
and not to target, so you must explicitly invoke Maven from the
Eclipse interface to do a build or install. We will continue to assume
in the text that you are using maven from the command line.
We have also had some feedback that other Maven plugins for Eclipse, notably Maven4MyEclipse from Genuitec, does not have any of the problems we have experienced, so it is likely to function properly without the use of the fixeclipse script.
You should now open the project in Eclipse and select the project name then choose and then . You will see a dialog like this:
There are several critical things to note in this screen shot.
First, the default output folder (at the bottom) is shown to be
lesson-events/bin/main and this is the change that
was made by fixeclipse. Further, there are now five directories in the
source path, including
lesson-events/src/main/resources and
lesson-events/src/test/resources (not
pictured).
If you do not have these two directories in your source path in eclipse (the Source tab above), your bundle(s) will be unavailable inside Eclipse! The contents of these directories-with the exception of Java code-is copied directly into the output directory, including all directories. Java code is compiled first, then the resulting class files are copied into the output directory. Thus the name Source is actually a bit deceptive since Java source code is the only thing not copied wholesale into the resulting classpath of your application!
Besides the two directories we just mentioned, there are two
directories that will actually contain Java source code,
lesson-events/src/main/java and
lesson-events/src/test/java. These two directories
contain the java source code for your bundle, and the java source code
for testing your bundle, respectively. There is a final directory,
lesson-events/target/generated, that is at the
bottom of this list that you should remove from your source path by
clicking on the name of the directory in the dialog above then clicking
on Remove. This directory is, as you would expect, the output directory
of some tools used in Nuxeo generate source code. Since we are not using
these, you can remove this item for now; it is probably listed as
"missing" in your display anyway.
If you switch to the Libraries tab, you will get an eyefull! This shows you the real purpose of the mvn eclipse:eclipse command, to generate a list of libraries needed by the program and place them all into eclipse:
The error shown at the top of this dialog means that the snapshot
was taken before I followed the directions above to remove
target/generated subdirectory from the list of
directories in the tab!
This list is quite extensive and it is only those libraries need
for this fairly simple lesson! The variable M2_REPO
that you see above on each line evaluates to your current home
directory, say /home/ismith, and then to the
.m2/repository directory within that. To the
extreme right of the list, not shown above, Eclipse will display the
full path used for each item in this list.
Using the skeleton provided to you, open up the test directory for
java source code (src/test/java), the package
org.nuxeo.upcoming.test, and select the file
EventTest.java. The top of this When we warned you in
a previous lesson to not use any of ef is shown in the following
capture:
Depending on exactly how you have your editor preferences, you may see different colors, no line numbers, or no print margin line at the 80th column.
In Java code in this book, we use two distinct types of comments.
The "//" type indicate commentary about the code immediately following the
comment. In the screenshot above, you can see at line 29 a comment that
explains that we are searching for the EventProducer service; right
afterwards, we use JUnit's (www.junit.org) function
assertNotNull to test that the value
producer is not null. If the value turns out to be
null, the test will immediately halt with an error. The text "Found the
event producer ok?" will be displayed as part of the failure message. We
find that writing this explanatory text as a question-that explains what
the assertNull or other function is testing-to be a nice way understand
the errors produced. If you see your text in an error message, then you
can assume that some part of the question turned out to not have the
answer you expected. You should go back an examine your
assumptions!
We will discuss the particulars of Events, EventListeners in the next couple of sections. However, for now, you should try to run the tests and make sure that they pass! You can do this by making sure EventTest.java is selected in Eclipse's Package Explorer, then use the context menu (usually bound to the right mouse button) to choose from the menu. This creates, if you don't have it already, a JUnit tab behind the Package Explorer tab in Eclipse. Assuming everything went ok, you should see the fabled and much discussed "green bar" in the upper left region of your display:
For most Java programmers that use JUnit this is the sign that "the world is ok" because all the tests are passing!
For fun, try changing the source the
assertNotNull shown in the screenshot above (line 31)
to assertNull; you will probably see something more
like this:
The dreaded "red bar" is shown in this shot! This means that
something is broken. You can see from this snap a lot of information about
the failure: You can see that it happened in the test function
testEventIsHandled (because of the 'x' next to that
test, as opposed to the check mark by
testDocumentCreationHandled). In the lower section
you have a stacktrace of the place where the failure occurred: you can
click on items in this stack trace to zip to that location in the source
code! You can also see part of the text comment of the test that was being
attempted, "Found the even..." Be sure to put your test back to the way it
was, with assertNotNull, or you'll be seeing that red
bar forever!
You should probably read the two tests in
EventTest.java,
testEventIsHandled and
testDocumentCreationHandled, follow along with the
commentary, and look at the Nuxeo and JUnit APIs used. The text of the
book does not cover each line of the code in detail!
We will start with a high level description of the purpose of testEventIsHandled. The objective of this test is very simple: to prove that if we create an event, any event, and send it through the Nuxeo infrastructure, our code under test will get called. The code to be tested for correctness can be seen by opening up the src/main/java directory in Eclipse and
With the preliminaries now over, let us proceed with the point of
this lesson! Events in Nuxeo are notifications, or messages, that
something interesting has happened. In this respect, Nuxeo is identical to
many of the other Java-based systems, such as Java's Swing, that use
Events to indicate to some part of a program that, well, an event has
occurred. The code that receives the notification is referred to as an
EventListener. Nuxeo has dozens of different Events that a program may be
interested in: A common type are events that generated when there are
changes to the repository, such a documents being created, destroyed, or
changing versions. Let us look at a simple EventListener
(this is an interface in Nuxeo) that is contained in the skeleton for this
lesson. You should open up the privary Java source code folder
(src/main/java) and then look in the package
org.nuxeo.upcoming. There is only one file in there at this
point, DocumentCreationListener.java:
This code, when put in our bundle, is going to create a title on a document automatically whenever a document of type Upcoming is created. It listens for an event indicating that a document has been created to know when to do its job. This listener is careful to not do so when other documents get created or when other events (that are not document creation events) are sent to it. The title generated for Upcoming documents is "Event XXX" where XXX is the date of the Event, displayed in a locale-specific way. It would be good for the reader to read through the comments in this file that begin with "//" and see the Nuxeo APIs used. The other type of comment, starting with "/**" and terminating with "**/", is used to enclose parts of the code that display interesting information. You can uncomment these and watch the console output to get more insight into how Nuxeo-in this case a Nuxeo EventListener-works. For instance, one of these commented sections in DocumentCreationListener will walk through all the properties that are part of the event and many readers may find this informative.
A key resource for any technical issue with Nuxeo is the Nuxeo Book. Events are covered in Chapter 28; if you reading this book you most likely can ignore all the content in that chapter about "old style" events since this book only covers the "new style." In addition, now that you are using the Java API of Nuxeo 5, you will most likely want to access the JavaDoc to see all the methods and types that you have available in the API.
A key Nuxeo notion seen in DocumentCreationListener is reified in the Java type EventContext and it's descendent type DocumentEventContext. This is contextual information that is associated with an event and the specific type of the context depends on the particular event type. As you can see from the snapshot above (lines 32-34), this Listener ignores any Event that does not have a context that meets the interface DocumentEventContext. This should not be surprise, we are only interested in Documents being created!
Also, critical to most event handlers, including the one shown here is to determine the "source" of the event-in other words, what object logically "caused" the event. Here is the snippet from the DocumentCreationListener.
//this gets the document that is the "cause" of the event, critical!
DocumentModel model = context.getSourceDocument();
This returns a reference to the DocumentModel that has just been created. Most of the time, event listeners will need to ask for information from or operate on the source of the event that they are interested in.
Finally, readers familiar with the more strongly-typed event system of Java Swing or other, similar systems should notice that Nuxeo events do not have "subtypes" as the Swing events do (MouseEvent, KeyboardEvent). The way to differentiate between the various types of Nuxeo events is by examining the name field (event.getName) and, if necessary, the type of the EventContext object. The example code given in this lesson does both of these.
Since this is the first lesson with Java code, most readers are likely to be more interested in the APIs used by the test code since these are more varied than the actual code under test. We will discuss the test code in some detail, since it introduces many new concepts.
Here is a listing of the body of the first test function,
testEventIsHandled:
public void testEventIsHandled() throws Exception {
//check for this name, if you want, using the debugger on the event listener
String eventName = "my event: there are many like it but this one is mine";
//get the event production service, so we can send an event
EventProducer producer=Framework.getService(EventProducer.class);
assertNotNull("Found the event producer ok?",producer);
//create a fake event object with some bogus values
Map<String, Serializable> props = new HashMap<String, Serializable>();
props.put("test-name", "testEventBasic");
//the event context is a really an "EventGenerator" in some sense
EventContext context=new InlineEventContext(null,props);
Event syntheticEvent = context.newEvent(eventName);
//the event service is the center of all event processing...
EventService service=Framework.getService(EventService.class);
assertNotNull("Found event service ok?",service);
//EventListenerHelper is the wrapper around our DocumentCreationListener
service.addEventListener(new EventListenerHelper());
//send the event and make sure it got handled!
assertFalse("No events handled yet?",props.containsKey(DocumentCreationListener.HANDLED_EVENT));
producer.fireEvent(syntheticEvent);
assertTrue("handled our event?",props.containsKey(DocumentCreationListener.HANDLED_EVENT));
}
This test does one, seemingly simple, thing: It creates an event
from scratch (syntheticEvent) and transmits it to the
code under test that expects events (see previous section). To be sure
that the code under test actually ran, we create a map of properties
(props) that the EventListener modifies
in an particular way and we test that this modification is observed.
This has no functional value, it just allows us to test "did the code
under test run at all."
In two places, the Nuxeo framework is asked to look up and return
a "service." This done through Framework.getService
and the two services retrieved are the EventProducer and
the EventService. Almost all of Nuxeo's functionality is
organized into services that offer various functions to their clients.
It is required that one access these services via the
Framework.getService mechanism shown in this
example rather than declaring an instance of these types directly. The
reasons for this are many and varied, but the simplest one is that this
allows the services to not be created until they are first needed, if
they are created at all.
Each service is used once (we are doing a simple test!). The EventProducer is used to transmit the event and this is the "preferred" way for Events to be generated by code that wishes to send events; Nuxeo itself uses this same mechanism when it generates events internally. The EventService is used to "hook up" our event listener to the Event stream. We created a small helper class, EventListenerHelper, that is a thin wrapper around the true class DocumentCreationListener. This wrapper is normally generated by Nuxeo as it reads the XML file that contributes an EventListener to the proper extension point. To avoid the need for deploying our bundle-and to create the simplest possible test from a logical point of view-we created the small wrapper ourselves and added it to the EventService manually.
The code for the other test, that does use the normal Nuxeo bundling mechanisms:
public void testDocumentCreationHandled() throws Exception {
String path="mydoc";
//send our upcoming bundle to the infrastructure
deployBundle("org.nuxeo.book.upcoming");
//initialize the repository and session. these are implemented in base class
openRepository();
CoreSession session=getCoreSession();
//get a document type that represents our code, just to be sure we are ok
DocumentType upcoming = session.getDocumentType("Upcoming");
assertNotNull("Does our type exist?",upcoming);
//create the object that represents the new document
DocumentModel modelDesired=new DocumentModelImpl("/",path,"Upcoming");
//setup the properties that make it an upcoming event:
//one man show, today, by Bob Newhart (comedian) at a cost of 25.00
modelDesired.setProperty("upcoming", "occursOn", new Date());
modelDesired.setProperty("upcoming", "presenter", "bob newhart");
modelDesired.setProperty("upcoming", "admissionPrice", new Float(25.00f));
//create the document in the repository
DocumentModel modelResult = session.createDocument(modelDesired);
//make sure that the path is the parent path (/) plus our new path
assertEquals("path is same?","/"+path,modelResult.getPathAsString());
assertEquals("path is same? (sanity)", "/"+path, modelDesired.getPathAsString());
//document is created ok, let's see if event handler ran
assertNotSame("the result object is different than the desired object?",
modelDesired,modelResult);
String titleFromDublinCore = (String)modelDesired.getProperty("dublincore","title");
assertNull("document handler did not run on desired?",
titleFromDublinCore);
//make sure our handler computed everything correctly
titleFromDublinCore = (String)modelResult.getProperty("dublincore","title");
assertTrue("document handler ran ok on result?",
titleFromDublinCore.startsWith("Event"));
//don't bother saving any of these documents... normally you want to do
//coreSession.save() but since this is a test, let's not bother
coreSession.cancel();
}
Most test code that would be written for a new Nuxeo bundle will have this type of structure: deploy the bundle or bundles needed for the test, open the repository and get the core session, and then create the document or documents needed for the test. The CoreSession object is perhaps the most central object to the Nuxeo API; it is going to be used in one way or another by almost any Nuxeo application or bundle since it holds the means of accessing the repository, and thus documents.
The process of programmatically creating a document in Nuxeo can
also be seen in this test. The process is to create a new
DocumentModelImpl to implement the
DocumentModel that is desired, shown as
modelDesired. The DocumentModel
implementation needs to know who the parent is (like a directory in a
normal file system) and the document's type, "Upcoming" in our example
here. After the desired basics are set up, one uses the
CoreSession method createDocument to
create a "real" DocumentModel, called
modelResult. In the case we have here, we set the
properties of the upcoming schema on the desired document
model so that the result DocumentModel would also have
these properties. However, the creation of the
modelResult is an action that Nuxeo generates an
Event for and our EventListener should be called and should
generate a title for the document. This is verified at the end of the
test function by examining the
We have been a bit sloppy in this chapter and blurred the distinction between logical "documents" and the Nuxeo types used to manipulate Documents through the API. This has, unfortunately, been necessary because Nuxeo actually has several different Java types that can be used to manipulate "documents" depending on the situation. The most common for test code is DocumentModel which is lightweight representation of a document, including all the document's properties. A DocumentModel's properties and content are loaded only when accessed (it is lazy) and this optimization is extremely valuable for many applications. A true Nuxeo Document can be very expensive to manipulate, depending on exactly what state the document is in and what features of the system interact with it. For now, it is not terribly wrong for the reader to consider DocumentModel to be the basic "document type" in Nuxeo.
Because we wanted to focus this lesson on developing Java code and testing it in Eclipse, we did not mention earlier that there are other important files in the skeleton provided. We provided them in already working form, unlike previous lessons, because we wanted your tests to work "out of the box."
If you notice, we have added a new extension point contribution
src/main/resources/OSGI-INF/event-contrib.xml and
added to the MANIFEST.MF to reflect this new
contribution. The contribution looks like this:
<?xml version="1.0"?>
<component name="org.nuxeo.upcoming.event.documentCreationListener">
<extension target="org.nuxeo.ecm.core.event.EventServiceComponent"
point="listener">
<listener name="documentCreationListener" async="false" postCommit="false"
class="org.nuxeo.upcoming.DocumentCreationListener" priority="140">
</listener>
</extension>
</component>
This is the pattern for a simple event listener; the critical part
in the listener tag is to get the correct class name that
implements your listener. The attributes async,
postCommit, and priority are ways that you can
modify under what circumstances your event listener gets called. These
are, for now, unlikely to be of much interest other than possibly
priority. EventListeners are called in an order based on
their priority, with the lower values having precedence. We do not
recommend creating EventListeners that have an ordering dependency, but
sometimes it is unavoidable and if you have two listener contributions,
you can control which is called first with this attribute. Choosing a
priority that is high, such as the 140 above, is a good practice when
you don't really care about the order of the calls.
For the first time in these lessons, we have now created a test
resource. This test resource is located in the file
src/test/resources/log4j.properties. This file,
like the contents of src/main/resources, will be
copied into the bin subdirectory by Eclipse and the
target subdirectory by Maven. As a result of the
copying, log4j.properties is in the classpath of the running tests. This
file controls the amount of log data output when running the
tests. It has no effect on normal operation and is not
packaged into the resulting bundle by Maven, since it has no function
other than during the running of the tests. As you can see from the
listing below, we have set the logging level to ERROR
so we will only get output when a test fails. If you need to debug a
bundle that has failing tests, you probably want to change the log level
to INFO or DEBUG.
log4j.rootLogger=ERROR, CONSOLE
log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
log4j.appender.CONSOLE.layout.ConversionPattern=%d{HH:mm:ss,SSS} %-5p [%C{1}] %m%n
Eclipse, as we have seen so far in this lesson, is used when you want to run tests and get "quick feedback" about the passing or failing of tests (the green bar). As you can see from the screenshots in this lesson, it usually takes only a few seconds to get the feedback from your tests. When all the tests are passing (and not before!) you should use maven to build, test (again), and package up your bundle. Let's try that for the skeleton in this lesson:
/nuxeo/workspace/lesson-events$ mvn clean install [INFO] Scanning for projects... -- lines elided for clarity -- [INFO] [compiler:testCompile] [INFO] Compiling 1 source file to /nuxeo/workspace/lesson-events/target/test-classes [INFO] [surefire:test] [INFO] Surefire report directory: /nuxeo/workspace/lesson-events/target/surefire-reports ------------------------------------------------------- T E S T S ------------------------------------------------------- Running org.nuxeo.upcoming.test.EventTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.751 sec Results : Tests run: 2, Failures: 0, Errors: 0, Skipped: 0 -- lines elided for clarity -- [INFO] Building jar: /nuxeo/workspace/lesson-events/target/lesson-events-0.0.1-sources.jar [INFO] [install:install] [INFO] Installing /nuxeo/workspace/lesson-events/target/lesson-events-0.0.1.jar to /home/ismith/.m2/repository/org/nuxeo/community/book/lesson-events/0.0.1/lesson-events-0.0.1.jar [INFO] Installing /nuxeo/workspace/lesson-events/target/lesson-events-0.0.1-sources.jar to /home/ismith/.m2/repository/org/nuxeo/community/book/lesson-events/0.0.1/lesson-events-0.0.1-sources.jar [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESSFUL [INFO] ------------------------------------------------------------------------ [INFO] Total time: 13 seconds [INFO] Finished at: Sat Feb 28 12:12:12 CET 2009 [INFO] Final Memory: 55M/408M [INFO] ------------------------------------------------------------------------
We have shown two key things in this example. Now that we have some
test code in src/test/java, it is found by Maven
during the build process and the tests are executed. It is good practice
to check that maven runs all the tests successfully; there are cases where
the classpath of Eclipse can include extra libraries that are not in the
maven classpath and thus the maven tests will fail. This is a critical
indicator, because the maven classpath is the same as the "real" one that
will be used as your bundle is loaded into Nuxeo server. You can see a
summary of the tests in the line above that starts with "Tests run:"... if
there are failures, you can find the information about the failures in
files in the directory target/surefire-tests.
The other thing to note is that the
lesson-events-0.0.1.jar gets built and placed in
the directory target as well as some other places.
However, if you inspect that file carefully (using jar
or your filesystem browser) it does not contain the
test code or test libraries (such as JUnit). Maven is smart enough to not
package the parts you need only for running the tests! You can see that
there is only the EventListener class in our bundle like
this:
/nuxeo/workspace/lesson-events/target$ jar tf lesson-events-0.0.1.jar | grep .class
org/nuxeo/upcoming/DocumentCreationListener.class
As before, you should copy your bundle from the
target directory of your workspace to the
plugins directory of your Nuxeo 5 server. Then create
a new document of type Upcoming, as in shown in this screen snap:
After we hit the Create button, we get a list of the document's properties and "No Chance" indeed did not have a chance!
So, we have now seen the output of the EventListener in action!