Corporate     Forums     Blogs     Twitter

Log in

Setting the 'Remember my name' option will set a cookie with your user name, so that when you next log in, your user name will already be filled in for you.

Don't forget to logout or exit your browser when you're done.

Having trouble logging in? Make sure to enable cookies in your web browser.

I have forgotten my password!


08/06/2009
CMIS Meeting, Day Two
(The first part of this series described the first day of the meeting.)

On the second day of the CMIS face-to-face meeting we again spent some quality time reading the spec nearly line by line, making sure everything is coherent, and discussing a few important points that people felt were important for their use cases.

Below I'll outline some important changes made to the spec on the first and second day of this meeting. There's more of course, you may want to follow everything in the CMIS JIRA.

The XML and XHTML property types are gone. No vendor was in support of them, and it was actually quite hard to standardize on exactly what kind of XML would be stored in such a property (well-formed? fragment? etc.). We kept the HTML property type, as many repositories still want to distinguish between "basic text" and "rich text", especially for presentation purposes. If a repository has XML or XHTML properties, it can easily expose them as Strings.

The ability to use paths to get to folders was extended to documents as well (getFolderByPath turns into getObjectByPath). For folders (were paths are well-defined), paths are retrieved through an explicit property "cmis:path", but for documents (which may be multi-filed) we have to be more careful. Whenever a document is retrieved in the context of a folder (getChildren, getDescendants, getObjectParents), its last path segment inside that folder will be available, so that clients can determine a full path for the document — but this segment is not a real property of the document, as it may change depending on context. Finally, the "cmis:name" property will be only a hint for the repository to choose a path segment for new objects, but the only way to be sure of an object's path is through folder's cmis:path and the aforementioned document path segment.

ACLs have been available since 0.62, but the exact set of basic permissions that they can expose is hard to pin down. We had cmis:read, cmis:write, cmis:delete and cmis:all, however some vendors have a hard time mapping their native permissions (or pseudo-roles) to such a basic model, and especially to cmis:delete which in itself is ambiguous considering that in a given repository deleting an object may require some permission on the parent and some other permission on the child. To further simplify the model, it's been decided that cmis:delete would go. But fear not, the ACL model is such that each vendor has the possibility of exposing its native permissions, and exposing which of them are required for each of the CMIS operations, so clients will still be able to make good use of ACLs even if not everything about them is standardized.

With ACLs come principals, and some special principals are sufficiently common that it's worthwhile for a client to know their ids. Therefore we added a way for a repository to tell a client what's the principal id for "anonymous", what's the one for "everybody", and we added a way to specify "me" when setting ACLs.

The need for Policies has been discussed as well, as there are no actual uses of them in the spec; they're an abstract placeholder for vendor extensions. Should they go? We now have ACLs after all... But there are already vendors making use of them to expose features of their repositories, so keeping them is good for them, and costs little to others (they're optional after all).

We now have a way to do copies! For the longest of time, this wasn't the case. There was strong opposition to adding a copy method, as copy semantics is very varied among repositories (do you copy document relations? acls? versions? renditions? streams? folder children? what about multi-filing? etc.). Nevertheless myself and others persistently asked for a way to do copies. The deciding argument this time was that even though in most cases the clients can do the copy themselves, by just creating a new object with the same properties as the one to copy, there is a problem with content streams as they may be multi-gigabyte objects — at a minimum we need a way to copy content streams. After lots of discussions, we decided to introduce a createDocumentFromSource method, which works just like a normal creation except that a source document is also provided. The repository will then use whatever it feels is best from this source document to fill in the created document. Note that we don't specify a way to do folder copies, as these very too much between implementations.

In AtomPub, if you want to create a document with a content stream, you have several standard ways available. However the only way to do creation in just one call is to embed the content stream in the message, and AtomPub has strong constraints on how you can do that: for XML- or text-related content types, AtomPub mandates that the stream be inlined in clear text (presumably for the benefit of AtomPub readers). But this is problematic as soon as you want to transfer content that is slightly invalid (but nevertheless stored in your repository!), or whose text content encoding is unknown, or is XML where you want to keep exact formatting, comments, prefixes, namespaces and all. Therefore, we added an extension to AtomPub (cmisra:content) that allows base64 transfer of content in all cases.

URI templates had been added to the AtomPub bindings in order to have a non-REST but very fast way for a client to access a document by ID, by path, or to make a query without a POST. URI templates, however, are still a draft, and it's problematic to include them in a standard. Furthermore the URI templates draft specifies many different ways along which variable replacement can be done, including tests, defaults, list delimiters, escaping, etc. We thus decided that a simplified subset would be used: just simple {variable} replacement, with percent-escaping. This solves most of the problems, and is still better than nothing.

Today is the third and last day of the meeting, mostly filled with interoperability tests and still more discussions about the spec. Stay tuned for more!
Posted by Florent Guillaume @ 08/06/2009 06:25 PM. - Categories: ecm, java, nuxeo, web -  0 comments
08/05/2009
CMIS Meeting, Day One
Yesterday was the first day of the CMIS Technical Committee face-to-face meeting. This time we're grateful to Oracle for hosting us in their offices in Boulder, Colorado.

Here are a few highlights of what transpired during this first day.

First, CMIS is really taking hold inside the big companies in this TC. Most of them plan to make available, privately to other TC members, some test versions of the CMIS servers they are working on, to ensure interoperability as early as possible. Of course these face-to-face meetings are also designed as "plugfests", where we set up test servers and let other's clients connect to them, but it's important to have it continue beyond these three days of meetings. It's unfortunate that these servers can't be public, but it's a fact of life inside big companies that you can't publicly speak about or show what you're working on.

Of course in the open source world we have much more latitude, and Nuxeo will be putting up soon a page with instructions for downloading and using Apache Chemistry and the Nuxeo CMIS bindings, as well as a public server that people can use for testing. And with all the code available! :)

Another thing that became clear today is that everybody is pretty happy with the spec as it is, and that we're nearly ready to start the OASIS review process that will first make it go through formal public review, and then open the OASIS vote for CMIS to become a standard. This process takes time (a minimum of four month), so we should start it as early as possible. But this means that, baring problems, CMIS should be a 1.0 standard by the end of the year, which is great news!

Much of the afternoon of this first day was taken up by a paragraph-by-paragraph review of the spec, where we criticized, clarified, reworded, or otherwise discussed every aspect of the spec. This process is long but invaluable, and we all agree that it makes the spec better. It will continue tomorrow and the day after, both for the first part that describes the domain model, and for the AtomPub and SOAP bindings.

Stay tuned for more news...

(The second part of this series describes the second day of the meeting.)
Posted by Florent Guillaume @ 08/05/2009 04:39 PM. - Categories: ecm, java, nuxeo, web -  0 comments
06/25/2009
The Promises of Modern Chemistry

By now, most of you should have heard about CMIS, the upcoming specification that promises interoperability between many systems for common content management tasks. The CMIS specification is being driven by an OASIS Technical Committee and is currently still a draft; it is expected to be finalized late 2009 or early 2010.

I won't detail here all that CMIS will bring, this has been covered extensively already and will be even more in the future... No, the purpose of this article is to present Chemistry.

Chemistry

Chemistry is a new Apache project for CMIS that started incubating recently ("incubation" is the term used in the Apache Software Foundation for young projects that still have to prove themselves). Chemistry's goal is to provide general purposes libraries for interaction using CMIS between a server and a client. These libraries are mainly written in Java, but some JavaScript code has been added as well, and we're open to more.

Chemistry provides a high level API so that a developer can manipulate objects like documents or folders and can call simple methods on them without having to deal with details of a specific low-level communication transport. In addition to that, Chemistry also provides a SPI (Service Provider Interface) for backend developers, making it quite easy to use Chemistry to store documents in a project-specific manner.

Underlying this, Chemistry has implementations for the CMIS transports. CMIS specifies two mandatory transport protocol bindings (one extending AtomPub, for a lightweight RESTful HTTP interface, and another using SOAP for a WebService-based interface), and Chemistry will support both — and probably more in the future.

The current Chemistry code base has an initial version of the API/SPI together with some actual implementations around the AtomPub protocol. Already Chemistry can talk to itself (AtomPub client talking to AtomPub server) and store data in-memory (which is very handy for unit tests). Outside of the Apache code base, Nuxeo has also coded a backend to provide access to Nuxeo 5.2 repositories using Chemistry. Generic CMIS AtomPub clients like CMIS Explorer are able to see a Nuxeo repository through Chemistry for instance.

Chemistry Modules

The following modules will be available in Chemistry:

  • The APIs: a low-level SPI between a client and a server that mirrors the CMIS specification closely (it is expected that the SPI will be used when either the client or the server implements one of the HTTP protocols defined in CMIS), and a high-level API that wraps the SPI to provide more object-oriented notions of connections, folders and documents, and that hides the nitty-gritty details of the protocols.
  • A set of common Java utilities around CMIS, for instance a parser to turn CMIS SQL into an AST (Abstract Syntax Tree) that can be reused by different backends, or a generic in-memory implementation of the SPI and API for unit testing.
  • Four implementations of the SPI for the protocols defined by CMIS: an AtomPub server and client, and a SOAP server and client.
  • A generic implementation of the API-to-SPI wrapping, so that a third-party implementation of just the SPI can be plugged into the rest of the Chemistry framework. (Some of the four basic protocol implementations may also provide the full API when this is more efficient than using the generic wrapping.)
  • An implementation of the APIs as a JCR backend.
  • A set of generic tests for CMIS servers and client, providing an unofficial TCK for CMIS.

In the future, it is expected that more implementations of the APIs will be available, for example we envision new transports:

  • A WebDAV-based transport.
  • An HTTP-based transport less RESTish and more friendly to browsers and JavaScript.

And new backends:

  • A backend storing documents on the filesystem, with or without metadata.
  • A backend storing documents in the Google AppEngine Datastore.
  • A backend storing documents using Microsoft Windows SharePoint Services.

The Pieces of the Puzzle

As you can see, these modules will allow for wide interoperability between systems. Here's a graphical representation of the building blocks:

The User Application speaks the API:

The API can be implemented in many ways. First, it could be a direct backend:

Or, more commonly, the API will be implemented as a client binding for a specific protocol, SOAP of AtomPub:

Each protocol speaks in its own way on the wire:

And this is connected to a server that speaks the protocol as well:

Finally, behind the server, a backend has to store the actual information somewhere:

Anyone is welcome to create new pieces, for instance new protocol bindings:

Or new storage backends:

Now let's see how the main pieces can be plugged together.

The simplest connection is between an application and a direct backend:

If the backend only wants to deal with the SPI, its implementation can reuse the API-to-SPI to provide a full API experience:

When talking through a wire protocol, we plug together a client and a server:

The end result is an application talking to a backend through a wire protocol:

Of course we can get creative and plug many more together:

Development

All of this is still a work in progress (even the spec!), but you should expect rapid changes in the available features in the coming months as the spec settles down, more code is written, more test cases are written, and more testing against third-party implementations is done.

If you're interested in helping, please join the list chemistry-dev@incubator.apache.org by sending an empty email to chemistry-dev-subscribe@incubator.apache.org.

Posted by Florent Guillaume @ 06/25/2009 03:26 PM. - Categories: ecm, java, nuxeo, nuxeo5 -  0 comments
06/23/2009
NKM et le libre - retour sur la convention System@tic

Hier avait lieu la convention annuelle du Pôle System@tic, la deuxième depuis la création du Groupe Thématique dédié au logiciel libre.

Nathalie Kosciusko-Morizet, Secrétaire d'Etat à l'Economie numérique, nous a fait l’honneur d’une longue visite de l’espace exposition, où étaient présentés les 9 projets financés labellisés par le GT et les démos de deux des projets les plus avancés: Scribo et Squale, dans deux des axes technologiques stratégiques du GT: les composants et services pour l’entreprise “3.0” (technologies sémantiques appliquées aux besoins de l’entreprise) et les outils de développement collaboratifs (en l’occurrence, la qualimétrie).

Lors de son discours (qui m’a touché par sa spontanéité), j’ai noté les observations suivantes:

  • Le logiciel libre est omniprésent y compris dans les projets qui ne dépendent pas de notre GT (plusieurs des projets mis en avant par les autres GT comprenaient aussi une composante logicielle libre) .

  • Elle estime de ce fait qu’on ne peut plus innover dans le secteur des TIC sans intégrer une part de logiciel libre.

  • Enfin, concernant les mesures de son plan de relance, elle a observé que “les mesure les plus simple à mettre en oeuvre sont celles qui ne nécessitent pas d’arbitrage budgétaire”, autrement dit, priorité aux propositions qui n'entraînent pas de besoin de financement nouveau.

Sur ce dernier point, cela m’a fait penser que la majeure partie des propositions que nous mettons en avant en faveur de la “relance par le libre”, par exemple dans le cadre de PLOSS ou dans le cadre de la prochaine édition de la FLOSS Roadmap, rentrent dans ce cadre (ex: non-discrimination dans les appels d’offres, recommandations claires et actionables sur l’usage des logiciels libres dans l’administration, meilleur alignement des formations sur les besoins de recrutement en spécialistes du logiciel libre, des choix clairs en faveur de l’intéropérabilité et des standard ouverts, etc.).

Posted by adminsf @ 06/23/2009 05:57 PM. -  0 comments
Florent Guillaume on CMIS and Apache Chemistry

A few weeks ago I gave an interview to Irina Guseva of CMSWire. We touched the subjects of strategic value of CMIS, Apache Chemistry project history, partnerships, open source, future plans around CMIS, and more.

Chemistry has extremely ambitious plans. We believe that it can become the de facto bridge between most of the Java-based content-oriented products, allowing a very wide variety of back-ends and applications to be connected together. And actually Java is not the sole language that this project is targeting, as David Nuescheler is also working on a JavaScript library for CMIS. In the coming month you should see an exponential increase in the functionality that Chemistry provides...

You can read the full article at CMSWire.

Posted by Florent Guillaume @ 06/23/2009 03:30 PM. - Categories: ecm, java, nuxeo, nuxeo5 -  0 comments
Dicsussion about Enterprise 2.0

Tony Byrne has started a conversation (warning: website is down at present) about Enterprise 2.0 (aka Enterprise Social Software) on CMSWatch.

Here are my comments (waiting for moderation on the CMSWatch site).

  • Is “Enterprise 2.0” more meaningful than “Social Software”?

    “Enterprise 2.0” is more than just social software. I define them with the SLATES and FLATNESS paradigms.

    And “Enterprise 2.0” is already passé. Let’s add semantics in the mix and call it “Enterprise 3.0” ;)

  • Blogging is passé — vive micro-blogging?

    Blogging is passé for “hey look at this cool post on this guy’s blog” type of messages. But expressing complex ideas in less than 140 characters is not possible.

    So micro-blogging is just another tool of the trade, just as blogging hasn’t replaced mailing list or forums, or IM hasn’t replaced email.

    OTOH, I must admit that I’ve been blogging a lot less (and, more importantly, seeing much less blog posts by the people I follow on twitter) since I’ve started twittering.

  • Can social computing consistently bring real ROI?

    In any context where collaboration and knowledge sharing is important, yes.

    But “real” meetings and discussions are still relevant, though ;)

  • Should community managers have to worry about information lifecycle management?

    Yes. There is content that you need to control, specially in the face of trolling and other destabilisation attacks.

  • Are social content ratings really helpful ?

    With the right (for the given context) rating algorithm, yes.

  • Tools: suite or best of breed?

    Integration is of paramount importance. World-class open APIs help, a lot, but some features just need to be deeply integrated, at the repository level.

  • Should your website/intranet have a community or be a community?

    Be, of course.

  • Do you really need an enterprise micro-blogging tool when we have Twitter?

    Yes. Most people / corporations don’t want to merge personal and professional lives as the “A-list” twiterers do, and there are obviously confidentiality issues.

Posted by adminsf @ 06/23/2009 10:51 AM. -  0 comments
05/31/2009
Already 10000 views for the Nuxeo DM 5.2 teaser

My short musical screencast about Nuxeo DM 5.2, which I made two weeks ago to showcase the new features of Nuxeo DM 5.2, has already received 10000 views on nuxeo.tv, our TV channel dedicated to screencasts, presentations and interviews about the Nuxeo products, technology and community.

I you haven't seen it already, here it is:

Then download Nuxeo DM 5.2.

Posted by adminsf @ 05/31/2009 04:31 PM. - Categories: nuxeo5 -  0 comments
04/17/2009
Témoignage OEM en vidéo - Nel Taurisson (SkinSoft)

J’étais hier à une présentation de SkinMuseum, application de gestion de collections de musées dévelopées par la jeune entreprise innovante SkinSoft.

Nel Taurisson, responsable de la R&D chez SkinSoft, a accepté de répondre à mes question au cours d’une courte interview vidéo que vous trouverez ci-dessous.

Transcription de l’interview

Bonjour, je suis Nel Taurisson, je m’occupe de la R&D chez SkinSoft.

SkinSoft, c’est une société qui développe des applications sur la base de Nuxeo. Notre première application est une application de gestion de collections de musées. On va ensuite s’orienter vers des applications métiers: photothèque, médiathèque, bibliothèque.

Ca fait plus d’un an maintenant qu’on travaille en recherche et développement sur ce sujet. On est parti sur la base de Nuxeo, après avoir regardé de tous les côtés ce qu’on pouvait utiliser comme moteur. On est parti sur Nuxeo pour l’architecture de composants, pour l’architecture globale du produit, parce que c’est une plateforme sur laquelle on arrive très bien à développer, et parce qu’il y a une vraie communauté, qui marche bien, qui répond bien.

Voilà, c’est un beau produit et on essaye de faire de beaux produits avec.

Posted by adminsf @ 04/17/2009 08:33 AM. - Categories: java, nuxeo, nuxeo5 -  0 comments
04/03/2009
Impact du logiciel libre en France sur la formation et les métiers de l'informatique - Publication d'une étude de l'OPIIEC

Syntec Informatique vient de publier un communiqué de presse synthétisant les principales conclusions et recommandations de l’étude “Impact du logiciel libre en France” réalisée par Pierre Audoin Conseil (PAC) pour le compte de l’OPIIEC, organisme paritaire chargé d’orienter la politique de formation professionnelle en France dans le secteur de l’informatique.

Cette étude montre un impact très fort dès aujourd’hui du logiciel libre sur le secteur de l’informatique, aussi bien dans les sociétés de service que chez les éditeurs.

Par exemple:

  • 78% des développeurs interrogés utilisent du logiciel libre dans leur entreprise

  • 87% des développeurs interrogés pensent que le logiciel libre est une opportunité.

  • Plus de la moitié des sociétés interrogées (directeurs ou responsables des systèmes d’information) utilisent aujourd’hui des composants libres dans leur système d’information (54% de oui).

  • Le logiciel libre est vu comme une opportunité pour l’industrie IT française. En effet, 88% des personnes interrogées pensent que le logiciel libre peut protéger le développement de logiciel des délocalisations.

Des recommandations fortes en termes de formations (profils et compétences à mettre en avant) pour conserver le leadership de la France dans ce domaines ont été proposées, et validées par le Syntec comme par les syndicats.

De plus, les conclusions de cette étude vont servir à orienter le plan “Editeur SL12” élaboré par le Syntec pour valoriser le métier d’éditeur (open source ou non) en France à l’horizon 2012 et qui sera prochaînement présenté formellement par le Syntec. Elles devraient, à mon sens, aider les éditeurs à comprendre comment tirer au mieux parti du virage majeur que représente pour leur métier l’utilisation quasi-généralisée de technologies et “briques” open sources dans leurs applications métiers.

Cette information a été reprise dans la presse:

Posted by Stéfane Fermigier @ 04/03/2009 04:26 PM. -  0 comments
03/25/2009
Nuxeo on Glasshfish TV

Glassfish TV tomorrow!

I'll be playing Ed McMahon to Stefan Fermigier's Johnny Carson tomorrow on Sun's Glassfish TV. Well, perhaps one could apologize to Paul Simon and say "you can call me Al" ... of "Stefane Fermigier et al."

We will discussing a number of key areas of interest that are of interest to Nuxeo users/developers, Glassfish users/developers/crustaceans, and general Web ne'er-do-wells:

  • Our analysis of the (approximately) two dozen Java web technologies and how they perform under the strain of a transport workers strike.
  • Our efforts to reduce the locking costs -and thus increase the number concurrent users served - of our large (>200,000 lines) JSF application, after we have had a few bottles of Beaujolais Nouveau at lunch.
  • Maximizing the heat dissapation of a large number of JVM in a small machine room : Reblochon is the answer.
  • Our proposal for a new JVM bytecode op that could dramatically increase bandwidth utilization in applications that have complex content negotiation needs: MILD_INTRANSIGENCE_AT_THE_UN.
  • Finally, we will give an overview our use of Glassfish and OSGi in the 5.2 RC Release of Nuxeoune nouvelle de dernière minute») as well as various and sundry ideas that we have that are Java-, Glassfish-, or paté-related for the future of Nuxeo 6, Nuxeo 7, or the heat death of the universe.
Posted by Ian Smith @ 03/25/2009 04:05 PM. - Categories: media -  0 comments
03/09/2009
Java Management Interface, coming in 5.2 RC1

Credit Where It's Due

This blog post would not have been possible without the diligent and thoughtful assistance of Stéphane Lacoin. Stephain gave me the big clues on how to configure the current Nuxeo 5.2 "head" to make all the JMX stuff "turn on" and also personally tracked down and squashed a number of bugs that made this article possible (including one in JBoss!). Somebody, please give that man a croissant!

Not Quite in 5.2.0.m4

This blog post is about a feature that did not quite make it into the 4th milestone release of Nuxeo 5.2. It is in the current source code build (or you can get it from the nightly snapshots) but I thought those that are waiting for the release candidate release might be interested to see what's "coming down the pike." As of the time of this writing, it is expected to be in the 5.2 RC1 release.

JMX: The Java Management Extensions

The Java Management Extensions or JMX debuted with Java 1.5. These extensions allow an client application to manage and monitor a collection of devices, computers, and services. A simple example might be a three-tiered web application, deployed on three separate servers. One would like to all the feedback for monitoring sent to a single place, often called the management client, where a human can look at the incoming data or the management client itself can process the data with some type of analysis procedure. The data from a three-tiered web application would include data from all the software layers such as database, application server, and application itself, but might also include reports from the network connecting the layers, and some type of hardware monitoring daemons as well. Once this has been analyzed, by a human, computer, or both, then one may want to take some time of actions to manage the objects being monitored; in the example of the three-tiered application one can easily a imagine a scenario where you would want to begin an orderly shutdown procedure. Coordinating all the layers of software, on different machines, to do this gracefully is clearly a management problem!

Configuring Nuxeo

You need to install one extra bundle into your build of Nuxeo 5.2 to get this to work, the bundle is nuxeo-runtime-management. You should put the bundle in <nuxeo-install-dir>/server/default/deploy/nuxeo.ear/plugins. Nuxeo is smart enough to "pick up" this additional modules and its features the next time you fire it up just because it is present. So, go ahead and restart (or start) your server with the script bin/run.sh (or run.cmd for windows).

Connecting JConsole to the running Nuxeo

With Nuxeo now running and exposing its management interfaces you need to hook up a JMX client to see what's going inside the Nuxeo system. You can do this with the program "jconsole" that is supplied with the Java development kit (at least if you got your JDK fairly recently). When you fire it up, you'll need to enter these three values:

???

The first one is the tricky one, obviously! The hostname of the machine running nuxeo in this example is "localhost" and the nuxeo server, at the time of this writing, exposes its java management interface on port 2009. Normally, the nuxeo server does not require a username and password, the second and third values, since the management service is "turned off" by default and you have to turn it on by installing bundles.

Getting information about the system state

Once you have connected, you will see the set of mbeans (management beans) that are exposed by Nuxeo:

???

When you drill down into a category you can get statistics about the objects in that category. In the previous screenshot, for example, if you click on the "metric" you will get information about the number of http sessions that have been created and destroyed while the nuxeo server is running. Also shown in the previous screen shot is the "probe" mbean. This mbean does a probe of the repository periodically (about every 30 seconds) and keeps track of the successes and failures. Here's what you would see if you drilled down into that item:

???

So, from this display you can see that the probe has been run 25 times without failures and the last probe took 111 milliseconds.

Running Methods

You can not only see data with the JMX interface to Nuxeo, but you can execute management functions as well. For example in the previous screen shot, if you click on the "Operations" button you will be presented with a list of methods that you can execute from the management interface. One of these is "disable" that you can use to turn off the probe behavior. When you run a method via the management interface, normally you get a message like this:

???

More fun, though, is to map the Nuxeo Runtime's inventory with the RuntimeInventory's factory object. You can click on that object (shown in the upper left) of the probe screenshots under category "nx" then category "Runtime" inventory. You will have your choice of a number of methods on that screen that give information about your system, but the most interesting one is "bindTree". The result of clicking this button to invoke that method is shown in this screenshot:

???

This takes all the bundles and components that the runtime knows about and makes them available via the JMX interface, so you can get some statistics about them, although in many cases this is quite minimal. You can, of course, unbind that tree of objects with "unbindTree" as shown in the screenshot above.

Getting audited isn't all bad...

Athough it's getting perilously close to tax day for our friends in the United States (tax days come in September in France), we are going to bring up the subject of auditing anyway. Many of the actions that users peform when using Nuxeo are audited (assuming you have deployed the auditing bundle) and some summary statistics can be seen via the JMX interface. The following screen shot gives you a feeling for what types of actions can be seen via the NXAuditService category:

???

The JMX interfaces are a nice way to interact with enterprise software systems like Nuxeo and not only keep an eye on how they are running but also perform many basic management functions. This is going to be a standard feature of Nuxeo starting with the 5.2 GA release and you can expect that we will gradually be exposing more functionality through JMX is we go forward.

If you have questions or comments about Nuxeo and JMX, or this article, drop me a note at ismith [at] nuxeo [point] com. We would especially love to hear from folks who have specific needs for functions to be exposed by Nuxeo through the management interface.

Posted by Ian Smith @ 03/09/2009 06:01 PM. - Categories: ecm, nuxeo5 -  0 comments
03/05/2009
Two more soldiers down

Double your pleasure, Double your fun

This has been a busy week on the book front and general purpose Nuxeo chicanery. I've got a number of things cooking right now so that I can show off features of the platform. Both of these features are of the "should be available to the public soon" type, so I've had to actually garner time from the developers to get them to give me demos and let me capture screenshots. I hope both of those posts are available tomorrow. I have the text of one written and the other should not be a major hurdle.

I've completed two more chapters, one fairly short one about XMap and Apache Commons Logging. I think it's only fair to admit that I really dislike Apache Commons Logging beacuse it gives people the distinct idea that writing more logging frameworks is ok. I can't believe the Apache Foundation green-lighted a meta-framework for logging when they already had log4j. Oh well. The other part of the short chapter is about the XML un-pickling code we use, which is packaged up into the library XMap. We use this all over the place in nuxeo to read in snippets of XML and turn it into Java objects.

The more meaty chapter is about Users and Groups. I got a lot of help, particularly on understanding directories and the test infrastructure needed for UserManager, from Anahide T. Big props to her! In this lesson, we construct a new class that interacts with the UserManager to create a new Group. Although it doesn't do that much, there is quite a bit to working with the UserManager service because of the wide variety of situations in which Nuxeo can be deployed. We have to work with flat text files, databases of user records of all sorts, and LDAP to be good enterprise citizens. I think that folks that read this chapter will come away realizing, more than anything, that messing around with users and groups in a big organization is serious business!

As always, the whole text can be found at http://www.nuxeo.com/static/book-draft.

Posted by Ian Smith @ 03/05/2009 09:30 PM. - Categories: ecm, nuxeo5 -  0 comments
03/04/2009
Selenium and Ajax Requests

Following Lance Ivy's excellent post (http://codelevy.com/articles/2007/11/05/selenium-and-ajax-requests), here's an easy way to write Selenium tests for Ajax requests when you're not using Prototype directly, but using Ajax4JSF or RichFaces.

Add this to your user-extensions.js:

/**
 * Registers with the a4j library to record when an Ajax request
 * finishes.
 *
 * Call this after the most recent page load but before any Ajax requests.
 *
 * Once you've called this for a page, you should call waitForA4jRequest at
 * every opportunity, to make sure the A4jRequestFinished flag is consumed.
 */
Selenium.prototype.doWatchA4jRequests = function() {
  var testWindow = selenium.browserbot.getCurrentWindow();
  // workaround for Selenium IDE 1b2 bug, see
  // http://clearspace.openqa.org/message/46135
  if (testWindow.wrappedJSObject) {
      testWindow = testWindow.wrappedJSObject;
  }
  testWindow.A4J.AJAX.AddListener({
    onafterajax: function() {Selenium.A4jRequestFinished = true}
  });
}

/**
 * If you've set up with watchA4jRequests, this routine will wait until
 * an Ajax request has finished and then return.
 */
Selenium.prototype.doWaitForA4jRequest = function(timeout) {
  return Selenium.decorateFunctionWithTimeout(function() {
    if (Selenium.A4jRequestFinished) {
      Selenium.A4jRequestFinished = false;
      return true;
    }
    return false;
  }, timeout);
}

Selenium.A4jRequestFinished = false;

Instead of using pauses or waitForCondition (writing some esoteric javascript test to detect that the Ajax call ended), you can then write something as simple as:

<tr>
  <td>watchA4jRequests</td>
  <td></td>
  <td></td>
</tr>

... (command triggering the ajax call) ...

<tr>
  <td>waitForA4jRequest</td>
  <td>10000</td>
  <td></td>
</tr>
</pre>

For Selenium beginners, the Javascript code has to be placed in a file named user-extensions.js and passed as an attribute to the Selenium Server command line option "-user-extensions <file>". When using Selenium IDE, it can be set in the options menu (don't forget to close the IDE and restart it for this to be taken into account).

Posted by Anahide Tchertchian @ 03/04/2009 07:12 PM. - Categories: java, web -  0 comments
Cross validation with jsf

I'm happy to have found an elegant (and easy) way to handle cross-validation of JSF components. The idea is to add an hidden input and bind it to a validator, passing component ids to validate as attributes:

<h:inputHidden value="needed" validator="#{myBean.validatePassword}">
   <f:attribute name="firstPasswordInputId"
     value="#{layout.widgetMap['firstPassword'].id}" />
   <f:attribute name="secondPasswordInputId"
     value="#{layout.widgetMap['secondPassword'].id}" />
</h:inputHidden>

Note that here, component ids are retrieved from the layout widget ids, but any id bindings will do (taking example on what's done when adding a "for" attribute to a h:message tag for instance).
Note also that the hidden input has to be placed after the referenced components in the page, so that they have been validated, and had their local values set.
The "needed" value is just here because the tag requires its "value" attribute to be set on my box, even if it's useless for us.

The validation method can then retrieve the components values:

public Object retrieveInputComponentValue(UIComponent anchor, String componentId) {
    Map attributes = anchor.getAttributes();
    String inputId = (String) attributes.get(componentId);
    UIInput component = (UIInput) anchor.findComponent(inputId);
    return component.getLocalValue();
}

public void validatePassword(FacesContext context, UIComponent component, Object value) {
    Object firstPassword = retrieveInputComponentValue(component, "firstPasswordInputId");
    Object secondPassword = retrieveInputComponentValue(component, "secondPasswordInputId");
    if (!firstPassword.equals(secondPassword)) {
        FacesMessage message = new FacesMessage(FacesMessage.SEVERITY_ERROR, "Password mismatch", null);
        throw new ValidatorException(message);
    }
}

Note that all components have to be in the same container for this to work properly as is (UIComponent#findComponent method restricts its search to the nearest container). Of course, this retrieval method can be adapted to handle more tricky situations, or to handle other kinds of component types.

What's the improvement compared to what i've seen so far? Well I've seen recommendations to use an hidden input too, but it's retrieving the referenced components values binding the components to some fields in the backing bean. So in this case, you had to add getters and setters for each component, and you had to do it for every set of components following the same validation criterion on a given page. Other recommendations involved writing a custom component handling several other ones, assuming dependent components will be rendered in the same part of the page... overkill, right?

In other words, here you can perform the same validation several times in the same page... with less code.

And it's prettier ;-)

Posted by Anahide Tchertchian @ 03/04/2009 05:58 PM. - Categories: java, web -  0 comments
03/01/2009
Events, both real and imagined

Another week, another chapter?

Yeah, I know I said I'd be releasing these chapters every day or so, but sometimes things go astray. I had a rough week with a lot of immigration into France problems (for my dog! my wife didn't have any) as well as having to install my "world" on yet another machine. I've got through an old mac, a big server in the amazon cloud, and I'm now using my desktop remotely (via the old mac) on some huge 8 way server in a Nuxeo machine room. Sigh. Anyway, that setup is performing pretty well so I should be out of the woods now until my new macbook comes. (Air! Will somebody give me an Air, puh-leeze?)

This installation is nominally about Events and Event Handling--but secretly there is a agenda! I wanted to introduce readers to all of the tricks involved in getting eclipse to work well for testing but I did't want to do it in a chapter where the content itself was super-tricky. So, I figured most Java developers know about Events and Event Handling (since this used everywhere else) and it would be a good place to introduce the "Eclipse for testing, Maven for deploying" mantra that I'm using in the book.

So, here it is in all it's glory, chapter 8, Events and Event Handling.

The whole book can be found here.

It's only fair to admit that Alexandre Russel helped me a ton on this chapter--he re-introduced me to the idea of Eclipse's source path. I, foolishly, thought that a source path should contain, you know, "java source code." Oh, no, no! The "source path" in Eclipse can be better named "Places where the content will be copied into eclipse's designated output folder, unless it is Java source code, in which case we will compile it and then put the compiler OUTPUT in the designated output folder." I guess that was hard for them to fit on the menu item.

Posted by Ian Smith @ 03/01/2009 12:13 PM. -  0 comments
Nuxeo Bloggers: Log in!
© 2002-2009 Nuxeo
All content is copyrighted by their author.