CRaSh 1.0.0-beta9 minor feature and fix a few issues with GateIn 3.1:
We have just released CRaSH 1.0.0 Beta 8 on Google Code forge, in that release we have worked on two usability aspects of the shell:
Just released the 1.0.0-beta3 release of CRaSH, you can get it there.
The first and foremost new features in that release are contributed by Patrice Lamarque that gave us very important commands such as cp to copy a JCR node, mv to move a JCR node and xpath to perform an xpath query in a similar way you can perform a SQL query.
Beside that, the pwd command was bugged in beta2 and is fixed in beta3.
The embbeded type support for Chromattic brings much power to object modeling on top of Java Content Repository that allows to fully take advantage of how JCR models node types. JCR type model provides two features that don’t match the Java type mode.
The first feature is multiple inheritance that is supported natively by JCR which allows a type to extend several super types. The other feature is the mixin support which is pretty much similar to multiple inheritance except that it can be dynamic, meaning that a node can be assigned with a mixin type. Conversely a mixin type can be removed from a node.
Both features are difficult with classic Java inheritance and the most appropriate way for modeling those is to leverage object delegation. Actually often object delegation is preferable over inheritance as it decouples the object types and provides support for dynamicity.
The following example is taken from GateIn and it shows how several java type can support templatization with the embedded support.
The Templatized class is a delegate object that provides a relationship to a Template type.
@MixinType(name="templatized")
public abstract class Templatized {
@OneToMany(type=RelationshipType.PATH)
@MappedBy("template")
public abstract Template getTemplate();
public abstract void setTemplate(Template template);
}
The Page class has an embedded relationship with a Templatized type.
@PrimaryType(name="page")
public abstract class Page {
// Returns null if the mixin is not present
@OneToOne(type=RelationshipType.EMBEDDED)
public abstract Templatized getTemplatized();
// Controls the life cycle of the mixin
public abstract void setTemplatized(Templatized templatized);
}
At runtime this would likely be used in the following manner:
Page page = session.findByPath(Page.class, "page");
Templatized templatized = session.create(Templatized.class);
page.setTemplatized(templatized);
Template template = session.findByPath("template");
templatized.setTemplate(template);
Likewise Chromattic supports primary type, the only difference is that the dynamicity aspect does not occur therefore the relationship always exists between the types and it is obviously not possible to destroy it. This feature provides to my opinion a very good alternative for reusability.
The embedded type feature has been added for GateIn in order to allow the Model Object for Portal (MOP). Indeed the model itself does not care about certain aspects and the portal needs to be able to make the base model richer than it is. With the embedded type we have the opportunity to keep the base model simple and have GateIn add its own mixins such as security, templatization, etc… Likewise eXo WCM that is built on top of GateIn will be able to add its own mixins for the purpose of web content management.
The CRaSH 1.0.0 Beta 2 has been released, you can download it there and the documentation has been updated with the new features.
The most important feature brought by that release is the brand new support for SSH thanks to the Apache SSHD project. SSH access is more suitable for remote access on public networks and SCP can be used to import or export content from the repository.
Configuration is now possible via the web.xml file and the following can be configured:
At the beginning of the year I started to write management capabilities in eXo Portal. It already had some management features but it was not really in a usable shape, it was indeed exposing every service of the kernel on the JMX registry, which was very confusing because it was exposing too much information and not the right information, it was just not usable.
Usability is word that matter, even in management, so my idea was, let’s expose management in a usable way. So I went on designing a way to expose management information based on Java annotations (well it’s pretty obvious to do that isn’t it?).
An important point was also to not tie the management to JMX. Indeed even if JMX is the kind of standard for exposing management in Java, I wanted to be able to expose the same management interface using Rest. The idea is to leverage the gadget server of GateIn and provide management information to gadgets.
So I went on designing the management contract (Java 5 annotations) that are agnostic of the management layer. Of course this is not enough for exposing the management in JMX nor in Rest. So we do have custom JMX annotations that describe how a management interface should be exposed in the JMX registry.
Here is an example of a managed service:
@Managed
@NameTemplate({@Property(key = "service", value = "cache"),
@Property(key = "name", value = "{Name}")})
@ManagedDescription("The Cache")
public interface Cache
@Managed
@ManagedName("Name")
@ManagedDescription("The cache name")
public String getName();
@Managed
@ManagedDescription("Evict all entries of the cache")
public void clearCache();
...
}
The @Managed, @ManagedName and @ManagedDescription are the agnostic annotations. The @NameTemplate is an annotation that has only a sense for the JMX layer. The @Managed* annotations really focus on giving a clear and non programmatic description of the management interface.
There a few more features in the framework such an @ManagedBy annotation to specify a delegate for management interface to avoid to clutter the service with management, a ManagementAware interface for programmatically registering new managed object, a management context facility for correctly scoping managed resources (so several instances of the same service can be registered several times with different names in a transparent manner).
Recently I spent time to develop in the kernel layer the plugability for management provider. It is still in the trunk so nothing is really commited yet in GateIn. This plugability allowed my to write the Rest management provider in GateIn. It was also a good way for me to learn a bit more about JAX-RS (many thanks to Stephane that came a few weeks ago at the Mars JUG to talk about Rest and also for helping me a bit tonight 
). So I’m still not yet a Rest expert but I have a few bits of management stuff coming to Rest:
@Managed
@NameTemplate({@Property(key = "service", value = "cache"),
@Property(key = "name", value = "{Name}")})
@ManagedDescription("Exo Cache")
@Rest("cache")
public interface Cache
{
...
}
The @Rest (it’s not yet definitive) expose the management interface on the Rest connector. For now I’m only considering JSON in my experiment.
management returns a list of the managed services annotated with the @Rest annotation,
aka “resource list”
/management/{resource} returns the management interface description, for instance in our case
we have {name:”cache”,description:”The Cache”,properties:[{name:"Name", description:
"The cache name"}],methods:[{name:"clearCache",description:"Evict all entries of the
cache"}]}
The good news is that we have already plenty of useful management interface in GateIn that were developed a few months ago by our team and all those will be soon available via Rest!!!