Blogger finally gets the 'Read More' link as in Wordpress

It is good news for all Blogger fans out there. Your favourite blogging platform finally gets the "Read more" link.

It had been a sticking point that a blogging platform as versatile as Blogger didn't have such a basic functionality as "Read more" which most other blogging software considered passe. But not any longer. Now you can stop using code hacks to get what you want.
Read more »

Ellison's statement to Sun customers

Yes, this is marketing. But it sheds light (and hope) upon us, concerned Solaris users, who were wondering about what will happen to our favorite OS. Here's what Oracle CEO, Larry Ellison, is saying about the merger.

Bad news for HP, Dell and IBM, indeed. "We're in it to win it." Let's give Larry a chance.

JSR 303 - Overview, part 2

Table of contents:

Introduction

Part 1

Part 2

Part 3

In the previous post, I began introducing the concepts defined in the JSR 303 (Bean validation) specification. The first concept we dealt with was the concept of constraint. The constraint represent the validation rule you want to apply to the target of your validation process, be it a field, a method or an entire class. This post is an overview of the validation API and a brief description of the validation process you can trigger on a JavaBean of your own. The understanding of the validation routine is necessary to avoid common pitfalls when defining and applying constraint to a class or a class' fields.

A word of warning: JSR 303 API is not yet committed and might change in a future revision of the specification. At the moment, the JSR 303 is in the public draft review state.

The validation process (in a nutshell)

The validation process is always started on a bean instance and may be instructed to recursively validate the objects in the object graph starting from such bean. Although the validator API also provides methods to validate only a given field or property of the target bean (for fine grained validation process, such as it might be the case for a partially populated bean) the validation routine described here will be partially honored for such methods, too.

The validation routine performs the following tasks, for the applying groups to be validated:

• perform all field-level constraints' validations
• perform all method-level constraints' validations
• perform class-level constraints' validations
• perform cascade validations

The validation routine is a deterministic routine which also checks the following:

• the validation routine will avoid infinite loops, keeping track of the validated object instances in the current validation process
• the validation routine won't execute the same validation more than once for the same validation constraint, keeping track if it matched on a previous group match.

The constraint validations matching the current groups being validated are run with no deterministic order.

Constraints semantics and constraint validator visibility

The algorithm implemented by the validation routine is pretty intuitive: it starts from inside the bean and goes to the outside. First, fields are validated, then properties, then the entire bean. The first thing to grasp is what a constraint really represent, that is something you must be aware of when designing your constraints and your validation strategy.

The constraint may be thought of as a validation rule applied to an object. The context in which the constraint is applied (the root object's type) is part of the validation rules' semantics:

• If you apply a constraint to an object's field or property, you're applying a validation rule to that field (as part of a type), but the validation routine visibility is limited to only that object. You cannot access values of other fields of your object during the validation of the fields' constraints.
• If you apply a constraint to a type, the validation routine visibility will be able to apply class' invariants (if you've got any) and any other validation rule whose parameters may be whichever part (be it field or property) that make up your type.

Basically, you'll use field-level (resp: property-level) constraints when you want to apply the validation rule to that field (resp.: property) as part of a type. For example, a String id field may be length-bounded when part of a type, such as a Passport (A String isn't length-bounded by definition).

You'll use class-level constraints when you want to apply a validation rule to the state of a type as a whole. For example, if you define a Passport type you would apply a class level constraint to check that the id-field is coherent with the Country field.

That's why the validation routine starts from inside the bean and proceeds outwards: you would not apply validation rules to an entire class instance state if some of the class' fields were invalid.

Constraint design principles and a constraint domain

The validation routine definition and the constraints semantics outlined in the previous section have got an effect, which is visible in the way these concepts have been defined. As we saw, whether to apply a constraint to a class or to a field depends on the semantics of the constraint you defined. But a class' fields are class' instances themselves. Let's suppose we're validation a bean of class X which defines a field of type Y.

public class X {

  private Y y;

  [...]

}

Moreover, let's suppose you designed class Y as an helper class for X and that Y is seldom visible, or visible at all, in your API. When validating such type you might be tempted to apply validation rules to Y instances as field level validations in class X. The constraint validation would indeed be passed Y instance and you could get access to all of Y's fields and properties, if you needed them. Furthermore, you could argue that this way you could validate both X and Y instances in just one validation pass. Yes, but that could be a huge design flaw if the constraints you're applying in the "X context" were in reality validation rules of class Y whose scope is not restricted to the "Y as a field of X" use case.

The question you've got to answer, during the definition of every constraint you design, is the following:

What is this constraint's domain?

If you establish an analogy with a constraint validators and a set of mathematical operators, you should be asking yourself:

What is the domain of this operator?

The answer to this question will suggest you the correct way to define and apply your constraint. If the answer is "The domain of the constraint is the entire type Y" (and you own type Y), you would define constraints accordingly and apply them to type Y (and its fields, if necessary). If the answer is "The domain of the constraint is field y of type X" you would define the constraints accordingly and you'll apply them to X.id.

Obviously reality might be more complicated than this and you might, for example:

• discover that you need both a set of constraints for the Y domain and another set for X.id domain.
• need constraints for the Y type but it's not yours.

In the first case you would act accordingly to achieve the correct isolation of the two distinct domains while in the second case you could extend, if possible, type Y or wrap it in another type of yours.

This leads us directly to why the validation routine must execute cascading validations.

Cascading validations

Cascading validations are the means you need to cleanly implement constraints such as:

Type X is subject to the following validation rules [...] and its field Y y is valid in the Y domain.

To model such situation you would apply the @Valid annotation to the X.y field:

public class X {

  @Valid

  private Y y;

  [...]

}

When encountering such annotation during the validation of an X instance, the validation routine will also apply the constraint validators applied to Y in the Y domain. In other words, the validation routine would go down the object graph recursively reapplying itself to everyone of such fields (resp: properties).

What's next

In the next post I'll introduce the least (but not last) few missing concepts and then we'll start building some examples.

Firefox Mozilla Mockups for version 4

How would you like the next version of Mozilla Firefox UI to look ? Would you like it to have a spartan look and feel similar to Google Chrome ? Or should it be an amalgamation of all the good UI ideas found in different browsers like Opera, Internet Explorer 8.0, Safari and Google Chrome ?

Mozilla Firefox has initiated a discussion on how the UI of Firefox 4.0 should be designed. It has put together a couple of ideas as mockups.

Read more »

JSR 303 - Overview, part 1

Table of contents:

Introduction

Part 1

Part 2

Part 3

What was before the JSR 303?

Well, as you probably know, before the JCP promoted this specification, very little could be done and you probably ended up using non-standard validation frameworks and/or tier-specific validation frameworks (such as Spring Validator, just to make an example). Things could go even worse: you probably ended up writing your own implementation solution.

The only standard approach I can think of is the venerable (and neglected) JavaBeans specification. I won't dig into the specification details, but JavaBeans are not just classes with some getters and setters. That's just the beginning. The JavaBeans specification, although nowadays that solution might seem clumsy, would support validations in the form of event listeners processing property change events. The mechanism is powerful but won't really fit the simplest use cases, which probably are the great majority we're dealing with everyday. The JavaBeans specification was tailored to provide a object component framework, such as Microsoft's COM could be. That's why events and listeners find their place there. But in the case of your-everyday-class, I recognize there's too much boilerplate code in it. Moreover, JavaBeans' events and listeners aren't declaratively configurable and, once more, the pitfall would be building your own configuration mechanism: ending up with your own non-standard solution, once more.

The basic concept: the constraint

The JSR 303 specification introduces the concept of constraint. The beauty of a constraint is that it's a metadata which can be applied declaratively to types, methods and fields. The constraint is a simple and intuitive concept which defines:

• How you would apply an instance of the constraint to a target. In other words, its interface.
• Who's going to implement the validation algorithm associated to that constraint.

I'm going to make the most basic example: validating a String length. The constraint would use two configuration parameters representing the minimum and the maximum length of the string. If one of the parameters would be left unspecified it would take its default value, such as 0 for the lower bound and infinite for its upper bound. The metadata you would need to apply to a field subject to this validation rule would thus be:

• the constraint itself, let's call it Size
• the constraint configuration parameters: min and max.

How would your class end up? Something like:

public class YourClass {

  @Size(min=1,max=9)

  private String yourField;

...

}

Of course the specification gives us the means to inject this kind of metadata without applying annotations. Somewhere in the definition of the Size constraint there would be the link with the class which actually implements the (really basic) validation algorithm. This is one of the indirection levels formalized in the specification: the validation algorithm cleanly separates the general validation process and introduces hooks, in the same definition of a constraint, where the constraint specific algorithm would be invoked. The general validation process, for example, takes into account the objects' graph navigation and the API to discover and describe the constraints applied to a target (the constraint metadata request API).

The responsibility of the analyst programmer would then be:

• Define his own constraints.
• Implement his own constraints.
• Apply constraints to validation targets.
• Trigger the validation process when needed.

All of the validation API has been designed with simplicity and reusability in mind. As far as I've seen this API is JavaBeans-based and does not establish a dependence with any other API. Furthermore this API is not obtrusive: you can define, declare and use constraints in every tier of your Java EE application, from the EJB up, up to the JSF components and the managed beans. The validation metadata and the validation process are (finally) orthogonal to the logic of your application: the design and the implementation of a Java EE system-wide validation policy for your objects' is finally feasible and standardized.

What's next

In the next post we'll dig into the technical details of what a constraint is and how you can define and use your own.

Sun xVM: Cloning your domU

If you're using Sun xVM for server virtualization the capability of cloning a domU is a real time-saver: reduced downtime and reuse of a corporate-standard OS installation and configuration. Really cool. If you sum up the power of ZFS snapshots and clones to all this, the picture is impressing: you can configure you domU to use ZFS volumes that you can take snapshot of and clone at will.

Now that you have the big picture, assuming you already know how to administer you ZFS pools, how can you clone your domU? This way: the first thing you have to do is shutting down your domU:

# virsh shutdown your-domain

Now you can copy your domain disk files or snapshot the corresponding ZFS volumes with a command such as:

# zfs snapshot your-fs@snap-name

# zfs clone your-fs@snap-name your/clone/name

If your just using files, then:

# cp your-domain-disk-file your-new-domain-disk-file

The next thing you've got to do is dumping and editing your source domain configuration:

# virsh dumpxml your-domain > your-domain.xml

# cp your-domain.xml your-new-domain.xml

Now, before importing this file, you've got to apply some modifications. Since Sun xVM identifies domains by means of a name and an uuid: then, you've got to edit the domain definition file to change the name and remove the already-used uuid. A new uuid will be generated for you as soon as Sun xVM wil import the domain definition. So, open the file:

# vi your-new-domain.xml

First, change the name you'll find in the <name/> element and then remove the entire <uuid/> element. The last modification you must apply is having the new domain point to the new file or ZFS volume you copied or cloned earlier. An example of a disk definition is the following excerpt from a domain configuration:

<disk type='file' device='disk'>

  <driver name='file'/>

  <source file='/export/home/xvm/db-server/winsrv2003.img'/>

  <target dev='hda'/>

</disk>

Just change the file attribute of the <source/> element and the job is done.

Last thing you've got to do is importing the new domain definition:

# virsh define your-new-domain.xml

Done! Now you can boot your new domain.

A last word of warning: chances are your just-cloned system shouldn't be running aside the old one without proper configuration. Double check your virtualized OS configuration for parameters such as:

• network configuration (hostname, DNS, static IP addresses, etc.)
• network service which may clash

Enjoy your virtualized server environment.

Opera 10 - A first look at this fabulous web browser

Opera 10 has been released. This release of Opera sports a number of alluring, new features, many of them not seen in any of its contenders. The enhancements to look out for in Opera 10 are as follows.

Read more »