Nuxeo Developers Blog

Nuxeo Runtime adds support for scripting languages

Bogdan had added preliminary, yet powerful, support for scripting in Nuxeo Runtime, before leaving for well deserved vacations. This makes scripting available from all Nuxeo’s platform. Thanks to this new feature, you can easily uses scripts from your custom components. This can be very useful for a lot of use cases, like, dynamic rules (scripting language as DSLs), easily modifiable behaviours, light and powerful configuration / customization, etc. Scripts have access to the whole API thanks to Java scripting integration (JSR-223).

Moreover, scripts can also be run remotely thanks to the Nuxeo Runtime command line. This allow you to create a script on your administration machine, launch it on the remote platform and get the result back. It makes scripting a killer-feature for administration scripts (ex: expire content, bulk content modification, bulk refactoring of the content repository layout, etc.).

Last, but not least, we are working on a interactive shell (using Python or Groovy) to interact with Nuxeo’s platform.

Here is a quote a Bogdan’s mail to get more details:

Hi all,

I’ve just integrated scripting support through JSR 223 in nuxeo. This was integrated as a new project nuxeo-runtime-scripting which is in svn but it is was not yet added in the nuxeo.ear build (neither in runtime svn module)

For now only these scripting engine were integrated:

1. jexl

2. jruby

3. groovy

4. jython

5. groovy

6. js (rynho)

If needed I will add more later (like php for example). You can run scripts in nuxeo in 3 different ways:

1. Put the script inside the nuxeo.ear/script directory (you should define this directory through a runtime var.) Then from the java code you can do:

    Framework.getService(ScriptingService.class).eval("my_script.js");
   

   where my_script.js is the script path relative to the script directory

   Or you can use the JSR 322 API:

    ScriptEngineManager factory = new ScriptEngineManager();
    ScriptEngine engine = factory.getEngineByName("js");
    engine.eval("absolute/path/to/my_script.js");
   

2. Let the script inside your .jar and registered it under using name as a script component. The you can run the script as follow:

    Framework.getService(ScriptingService.class).getScript("myScript").eval();
   

   This method is caching the compiled script so it is only supported for languages that support compilation. (actually all the engines that comes in nuxeo)

3. Run a script from remote :)

   This can be used for debug, testing or administration. You write a script locally then you run it against a remote Nuxeo EP server. The script will be send to the server and executed on the server then the server will return the result (including STDOUT and STDERR) to the client.

   For security reason this feature can be disabled using a runtime property on the server.

   Here is an example on how you can run a remote script:

      ScriptingClient client = new ScriptingClient("localhost", 62474);
      URL src = RemoteTest.class.getClassLoader().getResource("test.js");
      RemoteScript script = client.loadScript(src);
      script.eval();
   

   For the following js script:

      importPackage(java.lang);
      importPackage(org.nuxeo.runtime);
      importPackage(org.nuxeo.runtime.api);
      importPackage(org.nuxeo.runtime.model);
   
   
      runtime = Framework.getRuntime();
      name = runtime.getName();
      version = runtime.getVersion();
      desc = runtime.getDescription();
      println("Remote runtime: "+name+" v."+version);
      println(desc);
      println("---------------------------------------");
      println("Registered components:");
      println("---------------------------------------");
      regs = runtime.getComponentManager().getRegistrations();
      for (var i=0, size=regs.size(); i<size; i++){
          println(regs.get(i).getName());
      }
   

   The following will be printed on the STDOUT of the client:

     Remote runtime: OSGi NXRuntime v.1.4.0
     OSGi NXRuntime version 1.4.0
     ---------------------------------------
     Registered components:
     ---------------------------------------
     service:org.nuxeo.ecm.core.api.DocumentAdapterService
     service:org.nuxeo.ecm.core.repository.RepositoryService
     service:org.nuxeo.runtime.remoting.RemotingService
     service:org.nuxeo.runtime.EventService
     service:org.nuxeo.ecm.platform.login.LoginConfig
     ...
   

So, this new feature can be used to write pure script based Nuxeo components. Also in future I will try to configure tomcat to be able to run scripts inside servlets. This means to be able to write we pages in php or other supported language for Nuxeo EP ;-)

Bogdan

I think this open a wide range of new possibilities and ease of use for the Nuxeo Platform to allow you create innovative and powerful ECM applications (and not only, actually, since Nuxeo Runtime can be use to create any extensible application on the Java Platform).

Stay Tuned!

EB.

(Post originally written by Eric Barroca on the old Nuxeo blogs.)

Steve Raby joins Nuxeo as UK and Nothern Europe Manager

As you already might have seen, Steve Raby has joined Nuxeo as Director for UK and Nothern Europe and head of our London-based UK branch. We have started to do some great work, already and I’m just blogging about this to add some personal touch on this. :-)

Steve, a Sun and JBoss veteran, is a strong asset for our company and, of course, brings some new blood to our vision and management structure. The work we are doing is already productive and we recently signed our first large UK customer (you are going to read about that soon).

It’s also a really interesting to experience a shared vision for the business and the same enjoyment for the Open Source model. Same customer service orientation. And same faith in the success. The beginning of a long story, I'm sure.

Welcome on board Steve! We are going to continue building a great and successful Open Source vendor… (okay, okay, you’ve already been there for two months :-) )

Stay Tuned!

EB.

PS: Read the full PR here

(Post originally written by Eric Barroca on the old Nuxeo blogs.)

How to invoke method expressions with parameters in JSF?

2009 update: you should be looking at jboss-el if you'd like to get an esay integration of parameters handling in your application.

The usual way to use EL expression in JSF could seem a little too restrictive for some of us who are used to scripting languages.

For instance, if you'd like to display a bean property, you will write a getter on it:

public class MyBean {

 String myProperty;

 public String getMyProperty() {
   return myProperty;
 }

}

Then you'll be able to write the following value expression in a template:

<h:outputText value="#{myBean.myProperty}" />

Now imagine that your bean has to perform a more complex task to retrieve the property, like calling a service, and pass parameters to it. Even if there is always the possibility to pass the parameter using a "f:parameter" tag, the bean API will look kind of awkward. The more natural way to do so is to write a method with this parameter, and find a way to call it from the template.

For instance, we could have:

public String getMyProperty(String param) {
  // execute any function to get the result
  return function(param);
}

<h:outputText value="#{myBean.getMyProperty('foo')}" />

Sadly, there is no way to do that using "pure" JSF implementations.

That's where facelets can be very handy. In a very nice blog post, Andrew Robinson explains how to pass method bindings to children components using the facelet user tag system. I will explain how Nuxeo uses the same tricks to invoke method expressions with parameters as regular value expressions.

First let's define the famous MethodValueExpression class, that will behave as a regular value expression but will invoke a method expression when trying to resolve the value:

public class MethodValueExpression extends ValueExpression implements
    Externalizable {

  public MethodValueExpression(MethodExpression methodExpression,
      Class[] paramTypesClasses) {
    this.methodExpression = methodExpression;
    this.paramTypesClasses = paramTypesClasses;
  }

  ...

  @Override
  public Object getValue(ELContext context) {
    // invoke method instead of resolving value
    Object res;
    try {
      return methodExpression.invoke(context, paramTypesClasses);
    }
    catch(Throwable t) {
      return null;
    }
  }

}

Nuxeo benefits from an extension to the EL provided by Seam: it makes it possible to use parameters on any method expression without having to configure parameter types. That's why parameter types classes are never actually set in the Nuxeo code.

When this is done, we can use facelets meta rules to use this class instead of the generic one. This is done via a component handler:

public class GenericHtmlComponentHandler extends HtmlComponentHandler {

  ...

  protected MetaRuleset createMetaRuleset(Class type) {
    MetaRuleset m = super.createMetaRuleset(type);
    if (ValueHolder.class.isAssignableFrom(type)) {
      m.addRule(GenericValueHolderRule.Instance);
    }
    return m;
  }

}

This configuration tells to use the GenericValueHolderRule class when setting a component attributes. This rule does not do much but use our MethodValueExpression when appropriate, e.g. when brackets are detected.

We can configure tags to use this handler in a facelet taglib:

<tag>
 <tag-name>outputText</tag-name>
 <component>
  <component-type>javax.faces.HtmlOutputText</component-type>
  <renderer-type>javax.faces.Text</renderer-type>
  <handler-class>org.nuxeo.ecm.platform.ui.web.tag.handler.GenericHtmlComponentHandler</handler-class>
 </component>
</tag>

Note that there is no need to use another term than "value" as shown in this code (using "genericValue") as the last rule added to the MetaRuleSet will apply first and override the default behaviour.

The nxh taglib, using the namespace "http://nuxeo.org/nxweb/html" redefines all basic jsf html tags to use this handler.

We could add any number of attributes to be dealt in the same way than "value": for instance, being able to write <nxh:outputText rendered="#{myBean.getProperty('foo')}" /> can be handy too.

Now it can a little painful to define a new taglib with this handler when reusing custom tag libraries. The Nuxeo tag library defines a new tag "nxu:methodResult", that will make the result of the given expression available in the variable map:

<nxu:methodResult name="prop" value="#{myBean.getMyProperty('foo'}">
 <h:outputText value="foo" rendered="#{prop == 'bar'}" />
</nxu:methodResult>

The variable named "prop" is available inside the methodResult tag, as a row variable in a "h:dataTable" tag.

This behaviour is achieved using a specific tag handler that will use the MethodValueExpression presented above:

public class MethodResultTagHandler extends MetaTagHandler {

  private final TagAttribute name;

  private final TagAttribute value;

  public MethodResultTagHandler(TagConfig config) {
    super(config);
    name = getRequiredAttribute("name");
    value = getRequiredAttribute("value");
  }

  public void apply(FaceletContext ctx, UIComponent parent)
      throws IOException {
    String nameStr = name.getValue(ctx);
    // parameter types evaluation not needed using Seam
    MethodExpression meth = value.getMethodExpression(ctx, Object.class,
        new Class[0]);
    ValueExpression ve = new MethodValueExpression(meth, paramTypesClasses);
    ctx.getVariableMapper().setVariable(nameStr, ve);
    this.nextHandler.apply(ctx, parent);
  }

}

This tag handler is linked to the MethodResult tag in a taglib file:

<tag>
 <tag-name>methodResult</tag-name>
 <handler-class>org.nuxeo.ecm.platform.ui.web.tag.handler.MethodResultTagHandler</handler-class>
</tag>

Nice, huh?

Nuxeo Tag Library documentation: http://maven.nuxeo.org/nuxeo-platform-parent/nuxeo-platform-ui-web/tlddoc/.

Complete code mentioned above is available here:

• MethodValueExpression.java
• GenericHtmlComponentHandler.java
• GenericValueHolderRule.java
• MethodResultTagHandler.java

Nuxeo EP: the Service Oriented ECM Platform

If you’re one of those people that believe that SOA is more than a buzzword surrounded by hype, then this blog might be worth reading. As you might guess, I’m one of those. And for real-world solutions. :-)

Nuxeo EP is built around two simple yet powerful concepts:

• Services: a service is a component of the Nuxeo platform offering some feature to others (ok, so you do know what a service is! :-). From a technical point of view, in Nuxeo’s case a service is an OSGi bundle.

• Extension points: a service might provide one or more extension points so that other services can contribute extensions to this point (to configure the service or extend it). Think Eclipse Equinox extension system ported to the server-side.

Basically, Nuxeo EP is a set of services that mutually extend themselves (plus a bunch of business specific configuration files and UI) to offer a complete set of high-level ECM Services, ready to be integrated into the Service Oriented Architecture of your Information System (IS).

This is the future of ECM Platform providers and here is why… ;-)

One company, different needs

As you might know, or guess, a company’s departments can have very different needs related to content management.

Let’s take a few examples:

• marketing people want an application to manage their pictures and videos so that they can quickly find and get the right picture to illustrate their new “fact sheet”.

• the legal dept want a collaboration system to share and collaborate on legal documents. They also want a document management system to store all kinds of legal documentation.

• engineers want a full-blown ECM system to handle collaboration, document management for industrial documents (blueprints, specifications, operation manuals, etc.)

• the accountants want a system to manage invoicing and payment processes which can track physical items (e.g. incoming paper invoices, acceptance papers, delivery proof, etc.) and interact with SAP where all numbers are stored

• the QA people want to manage their organizational diagrams and processes to be under version control and workflow. They also want the engineers to use a document management system to enforce audit and compliance on produced documents (specs, op. manuals, etc.).

Of course, I could add dozens of examples, and I’m sure you could too.

All those needs might require very different UI, processes and business logic. But they still have some crucial common parts…

On to a Central Content Platform

Looking at those needs, besides their specifics, we can quickly define some common requirements:

• Content storage: scalable and secure content storage for short term (e.g. press release) to long term storage (e.g. documents of specifications).

• Flexible content model: to address all those needs, a flexible content model is required. Hence the content storage needs to be flexible to store any kind of content model.

• Security and access control: all the managed content needs to be secure and access controls have to be carefully applied. Hence the need of global security and access.

• Search: you need to search all this content. Hence the need for a flexible (to be adaptable to different content model) indexing and search engine. If you can search all the managed content using one UI it would be even better.

• Process management / workflow: to support everything from simple approval processes (specification draft) through to complex business processes (invoicing) or complex hierarchical approval processes (legal docs, specifications) you need an enterprise process engine, deeply integrated with your content repository.

• Relation management: wouldn’t it be great to be able to track dependencies between specifications documents, or between legal documentation and contracts? Or track links between pictures? Or maybe just track impacts between the specification and the operations manual? It might even be in the requirements! Well, to do this you need a powerful relation engine.

• User Notification: People want to be able to subscribe to changes so that they are notified (via email or RSS feed) when documents change. Let’s set up a notification system with email and RSS support (and maybe IM or SMS).

• Content Rendition: pictures need to be resized or cropped, word documents have to be converted as PDF after approval (e.g. for distribution or long term archiving), etc. You need an extensible content rendition system that allows you to define your renditions and maybe write your own rendition plugins.

• Directories / Vocabularies: You need to manage lists of terms to populate lists of choices in metadata forms, workflow screens, etc. You might also want to lists to come from your ERP system (e.g. project codes, imputation codes, customer list), some other applications or LDAP servers (customer lists, user lists, etc.). You need a flexible service to centrally manage lists (flat or hierarchical), stored into SQL or LDAP, and bind them to forms in your application.

• Audit: last but not least, you want all actions performed in the applications by users or other applications to be logged. You also might want to create reports from that data. Hence the need of a central audit trail.

This is what we define by Central Content Platform: a unique place offering content related services consumed by applications for end-users. End-users might see/use very different applications/UIs, services and storage are centralized to dramatically reduce maintenance cost and improve maintainability. And it’s much easier to secure (high-availability, physical protection, security audit, etc.) one central platform than each aspect of several different applications (with their own storage, language, platform, etc.).

One platform, many applications…

With Nuxeo Service Platform this pattern can become a reality. You can set up a scalable and reliable platform for ECM and make your business applications consume those services. Each application for end-users might be written in different languages, implement different paradigms, serve different users with different business needs.

Moreover, Nuxeo EP leverages standards and patterns to offer a wide range of communication systems. Java applications can use the java remoting system (EJB3 Remoting / POJO Remoting) and get access to the native API.

You prefer .NET, Ruby or PHP? Go on! Nuxeo EP also offer a wide range of Web Services (SOAP or REST) which enable integration with with virtually any software language / platform.

Need a workflow engine for your existing Spring based application? Just embed Nuxeo Runtime in your contract management app, connect to our Nuxeo EP instance and integrate your app with Nuxeo Workflow Service. Need advanced document storage with versioning and security? Just contribute your content type and store your documents into your Nuxeo EP’s Content Repository and access through the API or directly from HTTP links. We will take care of all complex document storage details such as access control, versioning, file streaming, transactions, etc. Need to add search? Plug your app to your Nuxeo EP’s Indexing and Search Service!

No more “one size fits all” ECM application

This is really what we think as the future of ECM. One application cannot fit all needs of content and information management in an organization straight out of the box. End-users ask for more and more adapted applications to improve their daily work flow. They require more security, ease of use, accountability, business focus… Why not avoid those “$10M, 3 years” burdens that made ERPs famous and deliver more to your users? More dynamic, more usable, more often, more complete…

ECM platforms should not be huge monolithic applications. The SOA pattern gives a golden opportunity to deliver great applications to your end users while keeping all the advantages of reusable and centralized software.

This is our real business. This means a lot to us. It’s available today. Try Nuxeo EP.

Still thinking Open Source cannot innovate?

Stay Tuned! ;-)

EB.

(Post originally written by Eric Barroca on the old Nuxeo blogs.)