Atlassian JIRA Configuration Tutorial: JIRA Schemes (Part 3)

Part I - JIRA Schemes (Part 1)

Part II - Overview of JIRA Security

Part III - JIRA Schemes (Part 2)

Part IV - JIRA Schemes (Part 3)

In the first part of this tutorial we learnt the importance of JIRA schemes and how to configure some of them:

• Issue type scheme.
• Issue type screen scheme.
• Field configuration scheme.
• Screen scheme.

In the second part of this tutorial we'll discover other types of schemes that JIRA provides to fine tune our projects:

• Permission scheme.
• Issue security scheme.

In this part we'll discover what workflow schemes and notification schemes are and how to use them.

Workflow Scheme

A workflow scheme let an administrator establish a relation between an issue type and a workflow and it has got a special entry to assign a workflow to all unmapped issue types as well.

What A Workflow Is

The concept of workflow is central in JIRA and it's where most of JIRA power resides in. Let's start with an example: in your project you define a couple of custom issue type called risk and documentation. So far they're just a name: a moniker that helps you categorize your projects issues into named sets but with no additional value. The next thing you'd probably do is to define custom fields for the new issue types of your projects to store the additional data you might need (such as a document author, a document title and so forth.)

As soon as you start using the new issue types in your project you'll realize (or your users will do) that it's not very intuitive to open, resolve and close a document (or a risk). Moreover, users will start complain that some operations are missing: reviewing a documentation, escalating a risk, etc.

JIRA workflows solve this problem: they let you define the process which an issue (of a specific type) will go through. The process is modeled as a finite state machine with transitions between state where you can even hook security policies and business rules (conditions and validators). 

Additionally, JIRA will let you specify other information that will let you glue together the features that JIRA offers (such as screens) to fine tune your project and provide your users the interface they expect.

A Use Case

For the sake of simplicity we'll start with a very simple example. Let's suppose that you've got a dependency with a third party that, sometimes, takes charge of an issue for part of its lifetime: it might be, for example, the software quality assurance department of your organization to which your code changes are submitted for validation. Then, you might want to put issues in a waiting state to explicitly reflect this fact.

A goot starting point to implement this custom workflow is copying the default JIRA workflow and using it as a starting point. The modifications you'll need to apply to the default state machine are:

• Create a new state: Waiting for feedback.
• Create new transitions to the new state:
• Ask feedback transition from the In Progress state to the Waiting for feedback state.
• Create new transitions from the new state:
• Continue transition from the Waiting for feedback state to the In Progress state.
• Resolve Issue transition from the Waiting for feedback state to the Resolved state.
• Close Issue transition from the Waiting for feedback state to the Closed state.

Screens for Transition Views

When you toggle the state of an issue, you can assign the transition a screen that will be presented to the user. You can choose one of the bundled JIRA screens or create a screen of your own. If during a transition you want the user to input some additional data, a transition screen is the place where you can ask the user to do so.

For the new Resolve Issue transition, for example, I replicate the settings in the default JIRA workflow Resolve Issue transition, that is using the Resolve Issue Screen during the transition.

Conditions

Conditions are propositions that must hold for the transition to complete successfully. Conditions, for example, are often used to create a security policy for a workflow transition. Some of the conditions that JIRA offers are:

• Only assignee
• Only reporter
• Permission
• User is in group
• User is in project role
• User is in group custom field

In this use case, for example, we want the Ask feedback and Continue transitions to be initiated only by the current assignee of an issue.

In the case of the Close Issue and Resolve Issue transitions, we replicated the conditions on the corresponding default JIRA workflow transitions, that is, check if the user has got the Close Issue permission or the Resolve Issue permission.

How To Create a Workflow

To create a workflow you've got to:

• Define the state machine for you workflow.
• Create a new workflow or copy an existing workflow that could be used as a starting point.
• Implement the state machine adding all the states you defined and all the possible transitions between the states.
• Optionally define and assign the screens you need to display during the workflow transitions.
• Define the conditions that must hold for a each transition to complete: pay attention to take into account JIRA standard permissions (such as the Close Issue and Resolve Issue) in the conditions for your transitions.

How To Create a Workflow Scheme

Before creating a workflow scheme, all of the required workflows for the issue types you're going to manage in a specific project must have been prepared. To create a workflow scheme, you've got to:

• Create a new workflow scheme.
• Assign the default workflow to be used for unmapped issue types.
• Assign a workflow to every issue type whose state machine you want to modify in the current scheme.

Apply the workflow to a project and the modification will take effect.

Please note that changing the workflows that are used in a project with existing issues is a potentially disruptive task that must be performed with care. Changing the workflow for an issue type might require mapping existing issues that find themselves in states that are no longer valid to valid states of the new workflow. JIRA will detect such conflicts and will ask the administrator to establish these mappings when changing a workflow or a workflow scheme for a project.

Best Practices

Hopefully, JIRA won't even let you modify the default system workflow (unless you hack it). Different projects usually mean different users and, although the words we use might be the same, the meaning we give them might differ a lot so the recommendation is the same: always create a custom scheme for your project when in doubt. It's easier to consolidate multiple equivalent schemes into one than decoupling projects that share schemes that were supposed to never change. JIRA lets you copy many of the objects it manages including workflow and workflow schemes. 

Notification Schemes

JIRA can notify users when some event has happened. The notification scheme establishes a relation between the type of event and the users who will receive a notification.

Event Types

Some of the types of event that JIRA offers are:

• Issue Created.
• Issue Resolved.
• Issue Closed.
• Work Logged On Issue.

The complete list can be checked in the official JIRA documentation. JIRA also offers a Generic Event that can be fired, for example, from a workflow transition, that can be used to extend the set of JIRA events should you need a new one.

Users Who Can Receive Notifications

The identities whom JIRA lets you send notification to are:

• Current Assignee.
• Reporter.
• Current User.
• Project Lead.
• Component Lead.
• Single User (chosen from a list).
• Group (chosen from a list).
• Project role (chosen from a list).
• Single email address (input by the user).
• All Watchers.
• User from a custom field.
• Group from a custom field.

A Use Case

Let's suppose that you're a project or a component leader and you want to receive a notification every time an issue is resolved or closed: it will be sufficient to create a custom scheme, for example by copying JIRA default notification scheme, and adding a notification for the desired event to the appropriate receiving identity.

How To Create a Notification Scheme

To create a notification scheme it's necessary to perform the following operations:

• Create a new notification scheme or copy an existing one to use it as a starting point.
• For every event you wish to handle, add a notification and assign the set of receiving identities.

A notification scheme can be associated to a project and it will take effect immediately.

Atlassian JIRA Configuration Tutorial: JIRA Schemes (Part 2)

Part I - JIRA Schemes (Part 1)

Part II - Overview of JIRA Security

Part III - JIRA Schemes (Part 2)

Part IV - JIRA Schemes (Part 3)

In the first part of this tutorial we learnt the importance of JIRA schemes and how to configure some of them:

• Issue type scheme.
• Issue type screen scheme.
• Field configuration scheme.
• Screen scheme.

In the second part of this tutorial we'll discover other types of schemes that JIRA provides to fine tune our projects:

• Permission scheme.
• Issue security scheme.

These schemes are used to tune the security policies you may want to establish over your JIRA instance, your projects and the issues they manage.

Before You Start

If you haven't done it yet, please read: Atlassian JIRA Configuration Tutorial: Overview of JIRA Security.

Permission Scheme

An introductory discussion about JIRA security and JIRA permissions is the subject of another blog post.

A permission scheme defines a the set of permissions to apply to a project.

A Use Case

The default JIRA permission scheme distinguishes between the following project roles:

• Administrators
• Users
• Developers

Users are granted the right of submitting issues into project (Create issues, Create comments, etc.) while developers are granted the right of working on issues and take them into completion (Edit issues, Close issues, etc.).

This is a starting point for refining your security policies adding actors (a project role) in your process and assigning them permissions. A first refinement might be requiring a project manager to check the developers' work on an issue before transitioning into the Closed state and letting developers transition an issue only up to the Resolved state.

How To Setup a Permission Scheme for Your Project

To setup a permission scheme for your project:

• Define the project roles your project needs: this is an optional step, since you can assign permissions to users and groups, but it's desirable to clearly organize JIRA users in sets (project roles) according to their status in each project.
• Assign users and groups to your project roles.
• Create a permission scheme for your project (possibly copying an existing permission scheme).
• Assign permissions to users, groups and project roles in the permission scheme.
• Assign the permission scheme to your project.

Issue Security Scheme

As we've seen in another post of this series, issue security scheme let administrators establish security policies to protect issues in a project. An issue security scheme defines a set of security levels and grants permissions to a set of identities to access issues in a given security level.

A Use Case

Issues in your projects could be organized in security level so that the visibility of certain issues is reduced to a subset of the users that can access a project.

In another scenario you could be sharing a project with some of your clients and would not like a client of yours having visibility of all of the issues managed in that project for confidentiality reasons.

An issue may be changing security level according to the workflow transitions it performed: just after creation, an issue could be transitioned to another security level so that a subset of users (such as a group of developers) might asses the issue and decide what to do with it. In a later time, the issue can be transitioned to another security level to be available to a wider audience.

How to Setup an Issue Security Level for Your Project

To setup an issue security scheme for a project of yours you have to:

• Create a new issue security scheme.
• Define the number of security level your project needs and create them in the issue security scheme.
• Grant permissions to a set of users for every security level in your scheme
• Assign the issue security scheme to your project.

Next Steps

In the following part of this series we'll explore the last two kinds of schemes that JIRA provides: the workflow scheme and the notification scheme.

Upgrading OpenSolaris to Oracle Solaris 11 Express

Today Oracle released Solaris 11 Express and, as described in the Getting Started Guide, there's plenty of installation options:

• An interactive GUI installer in a LiveCD.
• A text installer.
• An automated installer.
• An upgrade path from OpenSolaris.

Yes. If you're running some OpenSolaris machines while waiting for the release that never came, here's the option for you. The upgrade instructions are detailed in the Solaris 11 Express Release Notes:

• If your preferred publisher is not opensolaris.org (release), set it:

# pkg set-publisher -P -O http://pkg.opensolaris.org/release/ opensolaris.org

• Perform an image-update:

# pkg image-update

• Reboot into the new boot environment.
• Set the new publishers:

# pkg set-publisher --non-sticky opensolaris.org

# pkg set-publisher --non-sticky extra

# pkg set-publisher -P -g http://pkg.oracle.com/solaris/release/ solaris

• Read the license:

# pkg image-update 2>&1 | less

• If you accept the license, perform the last image-update:

# pkg image-update --accept

• Reboot into your brand new Oracle Solaris 11 Express boot environment

Oracle Releases Oracle Solaris 11 Express (2010.11)

More than one year after the latest and last OpenSolaris build (2009.06) was released Oracle has finally released a new snapshot of the next generation Solaris 11 Operating System: Solaris 11 Express (snv_151a).

Solaris Express is now available as:

• A text installer: this installer does not install any window manager but it can be easily installed using the Solaris package manager (pkg).
• A LiveCD with a GUI installer (does install the GNOME Desktop Environment).
• An automated installer for network deployments.
• USB install images.

If you want to discover what's new in this release, have a look at this presentation. The most important features I was waiting for are:

• Boot Environments.
• Fast Reboot.
• IPS packaging system.
• Boot Environments for Zones.
• ZFS as the default file system.
• ZFS deduplication.
• ZFS diff.
• ZFS dataset encryption.
• Network virtualization (Project Crossbow).

Atlassian JIRA Configuration Tutorial: Overview of JIRA Security

Part I - JIRA Schemes (Part 1)

Part II - Overview of JIRA Security

Part III - JIRA Schemes (Part 2)

Part IV - JIRA Schemes (Part 3)

JIRA flexibility is notorious and its security features are no exception. This blog post is an overview of JIRA security features and how to configure permissions to secure JIRA, your projects and all of your issues.

Users, Groups and Project Roles

At the global level, JIRA organizes users into groups and project roles. Groups are named sets of users and project roles are named sets of users and groups:

The administrator can create, edit an delete any number of users, groups and project roles.

Although, at first, the existence of both groups and project roles might seem redundant, project roles are important since they provide an additional level of indirection to decouple permissions from user accounts in a project. JIRA permissions at the global level (Global Permissions) can only be granted to groups. JIRA permissions at the project level can be granted at any combination of users, groups and project roles. An effective organization of your users (and groups) into project roles will help you create and maintain clean security policies in your project by:

• Defining the project roles you need.
• Assigning permissions to your project roles in a permission scheme.
• Assign a permission scheme to a project.

At the global level, to ease administration of a great number of projects, JIRA lets you define a project role's default members.

Global JIRA Permissions

Global JIRA permissions are (as of JIRA 4.2):

• JIRA System Administrators.
• JIRA Administrators.
• JIRA Users.
• Browse Users.
• Create Shared Objects.
• Manage Group Filter Subscriptions.
• Bulk Change.

Most of them are self-explanatory and further information about each of them can be found in the official JIRA documentation.

JIRA Users

This permission is required for users to be able to log in into JIRA. By default, groups that are granted this permissions will be assigned to any newly created user.

Disabling a User

Revoking this permission to a user, that is removing the users from every group that is granted the JIRA Users permission, will effectively disable the user and it won't count against your JIRA license limit.

Project Permissions

Project permissions are defined by JIRA and can be granted to an identity in a permission scheme. Assigning a permission scheme to a project will make those permissions effective in that project context.

Examples of most commonly used permissions are:

• Administer project
• Browse project
• Create issue
• Edit issue
• Resolve issue
• Close issue
• Add comment
• Delete comment
• Work on issues

For the complete list of permissions for a given JIRA version please check JIRA documentation or navigate to the Edit Permissions window of your JIRA installation accessible at the following URL:

http://your.jira/secure/admin/EditPermissions!default.jspa?schemeId=0

Further information about assigning project permissions to users, please check out this blog post.

Securing Workflow Transitions

The permissions seen so far make no mention of workflows and workflow transitions. Obviously, workflows are a fundamental part of JIRA functionality and it's essential for an administrator to be able to establish security policies at the workflow transition level.

Permission requirements can be associated to workflow transition using Conditions.

Conditions

Conditions essentially are validation rules that must be satisfied for a workflow transition to be executed. JIRA ships many built in conditions and many of them can be used to establish fine tuned security policies at a workflow transition level. The available security-related workflow transition conditions are (as of JIRA 4.2):

• Only assignee.
• Only reporter.
• Permission.
• User in group.
• User in group custom field.
• User in project role.

These conditions can be used to build security policies using any kind of identity seen so far: group and project role. Moreover, other identities related to a specific issue are available such as assignee and reporter.

Conditions are basic JIRA-provided parametrizable propositions that can be used to build more complex statements using the JIRA administration console.

Validators

Validators are similar to conditions with the difference that validators are executed against input parameters. As far as it concerns security policies, conditions is the way to go. Anyway, a Permission validator is available to check if the current user has a specific permission.

Securing Issues in a Project

We've seen many ways an administrator can secure its JIRA installation so far: at the global level, at the project level and at the workflow transaction level. There's case we haven't considered yet, though: applying distinct security policies to issues inside a project.

To achieve this goal in a flexible way, JIRA provides the ability to categorize a project's issues in the so-called security levels. A security level is an attribute of an issue that can be set in the usual ways:

• By using a screen that configured to edit such a field.
• By a workflow transaction.

An issue in a security level can be accessed only by identities (users, groups or project roles) that are granted permissions. The link between a security level and the identities that are granted access is established by means of an issue security scheme.

As usual, as soon as a project is associated to a security scheme, the scheme security policies are enforced. You can now create as many security level as your project needs and grant permissions to the corresponding users for every security level.

The available identities to grant permissions to in a security level are:

• Reporter.
• Group.
• Single User.
• Project Lead.
• Assignee.
• User custom field value.
• Project role.
• Group custom field value.

Next Steps

In this blog post we've introduced the facilities that JIRA provides to secure the operations it offers and the object it manages with flexible security policies.

In the next part of this series we'll examine what JIRA schemes are and how they can be used to decouple configurations from the context in which they are applied.

OpenSolaris (and OpenIndiana) Spends 50% of CPU Time in Kernel

A couple of days ago my client decided to prepare some new Java EE development environments and, when asked about which OS to choose, I suggested that he gave Solaris a try: since my client production servers run Solaris 10, he would benefit from a more homogeneous set of environments.

We installed a couple of test machines, one with Solaris 10 and another with OpenSolaris 2009.06, and we began installing the development environments and the required runtime components. The installation packages were SVR4: installation went straightforward on Solaris 10 while on OpenSolaris we had to resolve a couple of glitches. After a couple of day, test users were inclined towards OpenSolaris mostly because of its newer desktop environment: we started installing the remaining machines and started upgrading OpenSolaris to the latest dev release (b134).

Reduced Performance: CPU Time in Kernel When Idle 

The latest OpenSolaris dev release (b134) has got some known issues I wasn't concerned with since I already fought with in the past and can easily be resolved.

The surprise was discovering that all of the upgraded machines were affected by another problem: as soon as users rebooted into their b134 boot environment, the performance of the machine seemed to be pretty worse than when using the oldest (b111) boot environment.

prstat was showing no misbehaving process while vmstat indicated that the system was spending a constant 50% of the time in the kernel. With a quick search I easily pointed out this bug:

SNV_127 OpenSolaris spends 30-40% of CPU time in kernel

Repeating the steps outlined in the bug discussion confirmed me that we were hitting the same bug. We thus disabled cpupm in /etc/power.conf and the problem disappeared.

Upgrading to OpenIndiana

Although the bug is still listed as ACCEPTED, we decided to give OpenIndiana a try and upgrade a machine following the upgrade path from OpenSolaris b134. The upgrade went smooth and in no time we were rebooting into OpenIndiana b147.

The cpupm bug is still there, though. Nevertheless, it's a great opportunity for my client to test drive OpenIndiana and decide if it fits its needs. Nowadays, users will appreciate almost no differences between OpenSolaris and OpenIndiana (except for the branding.) As time goes by, we'll discover if and when Oracle will put back sources into OpenSolaris or if OpenIndiana is destined to diverge from its step-brother.

Atlassian JIRA Configuration Tutorial: JIRA Schemes (Part 1)

Part I - JIRA Schemes (Part 1)

Part II - Overview of JIRA Security

Part III - JIRA Schemes (Part 2)

Part IV - JIRA Schemes (Part 3)

Atlassian JIRA is an extremely flexible piece of software that can be easily customised by a casual administrator. Nonetheless, to take full advantage of all of its power, it's necessary to understand how it works and how are organised the concepts that it manages.

This series of blog posts is an overview of JIRA and a quick tutorial about configuring a JIRA project by taking advantage of JIRA configuration schemes.

If you're a Solaris user you may be interested to other posts I wrote about setting up and managing JIRA on a Solaris installation (some of them might be useful to users of other UNIX and UNIX-like operating as well):

• Installing JIRA on Solaris
• Registering JIRA as a Solaris SMF-Managed Service
• Backing Up JIRA and Confluence Taking Advantage of ZFS Snapshots
• JIRA: Creating Issues from TLS-Encrypted Email
• Adding Google Analytics Code To JIRA

Basic Concepts

Whenever you use JIRA, you're creating and updating issues in a project. Issues may be of specific types, may have custom fields and a security level. A user with appropriate permissions may act on an issue by applying a workflow transition.

Although it might seem otherwise, a project is not "just" an issue container with project roles and a set of security policies:

A project is a logical partition inside JIRA where a set of configuration rules are applied.

What a JIRA Scheme Is

This is when the JIRA scheme concept comes in. Inside JIRA almost everything can be configured:

• Workflows.
• Issue types.
• Custom fields.
• Field configurations.
• Screens.
• Notification.
• Permissions.

For each one of the above-mentioned concepts, user configurations and customisations are defined at the JIRA (global) level. The relation between a set of specific configuration rules for such concepts and one (or more) project is established by a set of schemes. In some conditions, a scheme might establish a relation between a scheme and another scheme.

This model is pretty flexible: the same issue type, for example, might be reused in different projects with different workflows, different field configurations and even different management screens. Conceptually, then, these concepts are organised as in the following picture:

The semantics and the behaviour of a concept can then be configured, customised and fine tuned at the project level by means of schemes.

The Importance of Schemes

Schemes probably are the biggest source of confusion for a novice JIRA administrator. At the beginning things may seem to work without the need of bothering with them. When the number of projects starts to grow, the possibility of configuration clashes grows too and that's when an administrator realises that the lack of a proper scheme partitioning is the source of all evil. Redesigning a JIRA configuration for a great number of projects is not easy and having projects polluted by configurations specific to other projects will make your users complain.

Schemes insulate projects from one another: a proper JIRA schemes' configuration guarantees that every manager can have its project configured with its own requirements without affecting other projects, even in the case in which they might be sharing some common concepts (such as an issue type defined at a corporate level.)

If in doubt, always create a scheme. If in the future apparently similar project configurations starts to diverge, schemes will enable you to independently manage different project.

JIRA Makes It Easy

Abstraction, decoupling and flexibility all come with a price: the administrator has to define configurations, schemes and associate them with a project. Fortunately, JIRA makes it easy since configuration and scheme can usually be copied: instead of starting from scratch, you can copy a scheme or a configuration and using it as a starting point for your new setups.

Types of Schemes

A JIRA scheme exists to map a project to almost any kind of concepts managed by JIRA:

• Workflow schemes.
• Issue type scheme.
• Issue type screen scheme.
• Issue security scheme.
• Field configuration scheme.
• Screen scheme.
• Notification scheme.
• Permission scheme.

In this series of posts we'll explore every kind of scheme, their relation between the project and the concepts they configure, and how they can be used.

In this part we'll explore the following types of JIRA schemes:

• Issue type scheme.
• Issue type screen scheme.
• Field configuration scheme.
• Screen scheme.

Issue Type Scheme

The first scheme you'll probably start with during the configuration of your JIRA project is the Issue type scheme. The issue type scheme establishes the relation between a project and the available issue types.

An Use Case

An issue type scheme is necessary when the default JIRA issue types are not sufficient for your project. Let's suppose your project will need additional issue types such as:

• Risk.
• Deliverable.
• Payment.

To safely add these new issue types with your project, you have to create the required issue types and associate them to the issue type scheme used by your project.

How to Setup Issues for Your Project

To setup the issue types you'd like to use in your project, you must perform the following operations:

• Define the issue types you need (if they do not exist yet).
• Create an issue type scheme for your project.
• Configure the issue type scheme to contain all the issue types to use in your project.
• Associate the issue type scheme with your project.

At this level, the selected issue types for your project are just names. During the configuration of the next schemes we'll give these names some meaningful behaviour.

What If I Use The Default Issue Type Scheme?

Since all issue types are implicitly associated to the default issue type scheme, if you modify it every project that is not associated with a custom scheme will see such modifications. If you're asked to setup a new JIRA project that will need a new issue type, that issue type will show up in every other project that is using the default scheme: that will probably make no sense to your users.

Field Configuration Scheme

The field configuration scheme establishes a relation between issue types and field configurations:

A field configuration scheme has a special default entry to map a field configuration to any unmapped issue type.

Field Configurations

A field configuration defines a field's behavior and is commonly used to tell JIRA:

• Whether a field is required.
• Whether a field is visible or hidden.
• How a field is rendered.

An Use Case

Field configurations and field configuration schemes are necessary whenever your issue fields behavior have to be customized. By default, every new field is visible and optional. If you need a field to be required or to be hidden for a given issue type, a field configuration scheme is required to map the affected issue types to the desired field configurations. A new Amount field, for example, might be required and visible only for the Payment issue type. Any screen for every other issue types should not require nor show the amount field.

How to Setup a Field Configuration Scheme for Your Project

With a field configuration scheme you can setup the behavior of every field, for every issue types it applies to:

• If applicable, define a field configuration that will apply to any unmapped issue types. A good starting point might be a copy of the default JIRA field configuration.
• Define a field configuration for every issue type that needs one. Many issue types can share the same field configuration.
• Create a field configuration scheme and associate the field configurations you created to the target issue types.
• Optionally, define the default field configuration for all of the unmapped issue types.
• Associate the field configuration scheme to your project.

What If I Use The Default Field Configuration Scheme?

Using the default JIRA field configuration scheme and the default field configuration may lead to configuration clashes such as the following:

• If a project requests a field to be hidden, every other project that might still require it will see the field disappear from its screens.
• If a project requests a field to be marked as required, every other project will be forced to set a value for such a field in its screens.

Screen Scheme

JIRA lets the user easily define new windows, called screens, that may be used during a workflow transaction or during an issue type operation such as create, edit and view.

A screen scheme establishes a relation between an issue operation and a screen. A screen scheme has a special default entry to map a screen to any unmapped issue operation.

Screens

A screen is just an ordered list of fields easily configurable with the JIRA administration console. The field rendering and behavior, such as its format or whether it's required or visible, is configured by a field configuration.

An Use Case

A custom screen it's necessary, for example, when you want to control which fields are visible or editable during an issue operation and when you need a brand new screen for a transition in a workflow of yours.

For a Payment issue type, for example, it might be desirable that some fields (such as Amount) should not be visible or editable during the edit operation. In this case, it's necessary to define a new screen that contains the editable fields and associate it with the edit operation in a new screen scheme. This screen scheme will then be associated with the target issue types by means of an issue type screen scheme that will be examined in the next section.

A Payment issue type might then be associated with a user-defined workflow. During a specific workflow transaction, such as Pay, it might be necessary to update another custom field: Payer. In this case, it's necessary to define a new screen that contains the Payer field and any other required field and associate it with the desired workflow transaction.

How to Setup a Screen Scheme for Your Project

To configure a screen scheme to use in your project you have to follow these steps:

• Define a screen for every customised issue operation screen that your project needs.
• Create a screen scheme.
• If applicable, define a screen for every unmapped issue operation.
• Associate the screens you created with the corresponding issue operation.
• Repeat this operation and create screens and screen schemes for every issue type whose operations need screen customisations in your project.

What If I Use the Default Screen Scheme?

Since the default JIRA screens are associated to all issue operations for every issue types, a modification in either the default screens or the default screen scheme will be visible in all the projects that don't use custom screen schemes. This situation may lead to complaints for missing or new and unknown fields in screens used by other projects.

Issue Type Screen Scheme

An issue type screen scheme establishes a relation between a screen scheme and an issue type. An issue type screen scheme has a special default entry to map a screen scheme to any unmapped issue types.

An Use Case

The issue type screen scheme is mostly a "technical" scheme to tell JIRA to use a screen scheme for a specific issue type in a project. Common use cases have been explored in the previous section.

How to

To setup an issue type screen scheme for your project you have to follow these steps:

• Create a new issue type screen scheme.
• If applicable, associate a default screen scheme for every unmapped issue types.
• Associate a screen scheme to every issue type whose screens you need to customise.
• Associate the issue type screen scheme to your project.

What If I Use The Default Issue Type Screen Scheme?

Since the default issue type screen scheme just maps the default screen scheme to any issue type, using this scheme in every project will have the same detrimental effects on project decoupling that we outlined in the previous section.

Conclusions

In the first part of this series, we've explored a basic component for the JIRA customisation: schemes. Schemes are a flexible mean to decouple configurations from their scope (projects). Although you might be tempted to ignore custom schemes and just modify JIRA default schemes, I suggest you think it twice, take a large breath, reread this post and convince yourself that it's really a bad idea.

JIRA helps the administrator build schemes quickly allowing him to generate copies of existing schemes on the fly. Create a test project and start configuring it copying JIRA default schemes and modifying them. You'll be surprised by discovering how powerful and easy it is.

Next Steps

In another post (coming soon) I'll explore other types of JIRA schemes with particular emphasis to workflows and their customisation.

Glassfish 3.0.x Admin Console Not Starting: Is It Behind a Proxy?

Today I was performing yet another Glassfish v. 3.0.1 installation, one of the easiest pieces of software to set up there, on a Solaris 10 system:

• Install the software (unzipping a zip or installing a native package).
  
• Optionally create a new domain.
• Start the domain.

To my surprise, when I tried to connect to the Admin Console, the browser got stuck just after inserting my user credentials. I tried to restart the domain over and over again but I had no luck.

The domain logs (that you can find in $YOUR_DOMAIN/logs/server.log) were telling nothing interesting: the domain was starting up correctly and the admin console application was logging no errors. The last line of the logs always was:

[#|[snip]|admin console: initSessionAttributes()|#]

After a while, it appeared a line such as this:

[#|[snip]|Cannot refresh Catalog: Connection timed out: Connect|#]

This was the clue! Glassfish is able to check for updates automatically from an IPS repository: do you remember that fancy update icon in the upper left corner of the Admin Console that shows up to suggest you the available updates? This server is behind a proxy: maybe I was experiencing a glitch related to this.

A quick search indeed revealed that other users were experiencing the same problem when Glassfish sat behind a proxy server. The workarounds I tested to work are the following:

• Have Glassfish use your proxy.
• Use Glassfish updatetool to disable automatic updates (which is something I would always suggest for a production environment).
• Remove the console-updatecenter-plugin.jar.

The third suggestion comes from a thread published in the java.net Forums. Unfortunately the link is broken now and I could only read it using Google's cache.

Have Glassfish Use Your Proxy

To setup Glassfish to use a proxy you can use the following Java system properties:

• http.proxyHost
• http.proxyPort
• http.proxyUser
• http.proxyPassword

You can either use the asadmin program or the admin console to do that. Using asadmin is as simple as:

$ asadmin
asadmin> create-jvm-options "-Dhttp.proxyXXX=value"
asadmin> create-jvm-options ...

If you prefer using the Admin Console, just navigate to Enterprise Server/System Properties and use the web interface to add the values.

The values you set will be reflected in the domain.xml domain configuration file:

[...snip...]
<java-config ...>
[...snip...]
  <jvm-options>-Dhttp.XXX=value</jvm-options>
</java-config>
[...snip...]

Use Glassfish updatetool To Disable Automatic Updates

You can use the updatetool program to update Glassfish and configure the autoupdate feature:

$ $GLASSFISH_INST/bin/updatetool

The first time you launch updatetool, it will ask you to install this feature. Since you're behind a proxy, you need to setup some environment variables. If you're using an HTTP proxy, you can just set the http_proxy variable:

$ export http_proxy=http://user:password@proxy.host:port

When updatetool finished installing the required packages, you can start it again and the updatetool windows will show up. In the Preferences window you can tune the update behaviour or disable it at all.

Remove the console-updatecenter-plugin.jar

The last thing you can do is removing the guilty plugin. The Glassfish plugins are deployed in the $GLASSFISH_INST/glassfish/modules directory. You can just move the console-updatecenter-plugin.jar to console-updatecenter-plugin.jar.old and Glassfish won't use it.

"No Network Access" for the Admin Console

As pointed out in a comment, Glassfish can be configured to have "no network access" by setting the

com.sun.enterprise.tools.admingui.NO_NETWORK

property to true. As usual, this can be done adding the

-Dcom.sun.enterprise.tools.admingui.NO_NETWORK=true

to the JVM parameters list or using the asadmin tool:

$ asadmin create-jvm-options \
  -Dcom.sun.enterprise.tools.admingui.NO_NETWORK=true

Conclusion

This is a bothering bug with an easy workaround. Looking forward to Glassfish v. 3.1.

VirtualBox 3.2.10 Has Been Released

On October, 11th Oracle has released VirtualBox v. 3.2.10, a maintenance release of its desktop virtualization solution. This is the complete changelog and here's the download location.

How To Connect The Magic Mouse Automatically (Sort Of...)

The last few days I've been using my brand new Apple Magic Mouse. I admit it's a pretty good piece of hardware although I doubt it's an adequate choice if you're a MacBook user as I am: the Magic Mouse, or at least its official gestures, fall (very) short when compared with the integrated MacBook trackpad. Anyway, I wanted a mouse and here it is.

Installing is really easy: depending on your OS X configuration you might even be automatically asked to configure your brand new mouse. If you're not, as in my case, just use the Bluetooth/Setup Bluetooth Device... and the pairing and the first configuration will be really quick.

Beware that if your Magic Mouse disconnects from your computer (because it goes into sleep mode or simply because you move your laptop and the mouse goes out of range) it will not reconnect again... unless you click it. Yes. This behaviour seemed really strange to me at first. I was expecting the mouse to automatically pair again, at least when moved. But it won't and you'll need to click.

Makes sense. If you're mouse is sleeping, it won't wake up when moved or when you slide your finger over it. Maybe Apple might improve this behaviour in the future: are we seeing accelerometers everywhere, aren't we? 

Some Reasons Why Solaris Is a Great Java Development Platform

Some days ago I posted "The Death of OpenSolaris: Choosing an OS for a Java Developer" in which I stated that Solaris is a great platform for a Java developer. The point of that post was simply wondering about which Solaris version I'd use since the demise of OpenSolaris. What the post did fail in clarifying, as Neil's comment made me realize, were the reasons why you should choose Solaris as your development platforms. I decided to write this follow up to that post to quickly summarize my favorite ones introducing some use cases where such technologies come in handy.

Software Availability

Although Solaris continues to be a niche OS (such as many other platforms are, anyway) in the last few years Sun and the community made an excellent job at promoting it as a desktop alternative for developers. There existed even a specific distribution for developers: Solaris Express Developer Edition. It was discontinued and there really is no need for it nowadays, anyway. Late Solaris distributions (such as SXCE, OpenSolaris, OpenIndiana), include (either bundled or in the official package repository):

• Data bases (MySQL, PostgreSQL).
• Web Servers (Apache, Java Enterprise System Web Server, etc.).
  
• Application servers (Glassfish).
• The SAMP stack (Solaris + Apache + MySQL + PHP).
• IDEs (NetBeans, Eclipse).
• Support for other popular languages (Ruby, Groovy, etc.).
• Identity management (LDAP, Java Enterprise System Identity Server).
  

Solaris also is a platform of choice in the enterprise hence common enterprise software packages are supported and you, as a Java developer or Java architect, won't miss the pieces you need to build your development environment. The very basic software packages I often need as a Java developers are:

• Oracle RDBMS.
• Oracle WebLogic Application Server.
• IBM WebSphere Application Server.
  
• JBoss Application Server.

Solaris' Technologies

Solaris has got some unique technologies that other UNIX (and UNIX-like) systems that might be used as development platforms are lacking (or ported from Solaris.) What's important here is not "technologies on their own" or technologies that are helpful only in big enterprise environments, but the fact that:

• They're pretty well integrated in Solaris and are built to take advantage of each other.
• There are common use cases in which these technologies are really helpful to a developer.

Each one of them would deserve several posts on their own, however, I'll try to make some concise examples.

Solaris Service Management Facility

Although this technology is probably most useful to a system administrator, as a developer I often took advantage of it. SMF is a framework that provides a unified model for services and services management. The basic recipe only needs an XML descriptor for a service. SMF lets you:

• Define a service: startup scripts location, parameters and semantics.
• Establish dependencies between services:
• Services and service instances may depend on other service instances.
• Service startup is preformed in parallel respecting service dependencies.
  
• Enhanced security and fine-grained role based access control:
• A service can be assigned only the minimum required set of privileges it needs to run.
• Service management can be delegated to non-root users using Solaris RBAC (Role-Based Access Control).
• Service health control:
• Service auto-restarts.
• Service health is enhanced by cooperation with Solaris Fault Manager which prevents service degradation when hardware failures occur.
• Automatic inetd Services Wrapper: SMF automatically wraps inetd services.
  

A Typical Use Case

Every software package I use has its own SMF descriptor (either provided with the package or defined by me) and it dramatically reduces the time I need to set up a development machine. In the case of WebSphere Application Server, for example, I have separate service instances for:

• WebSphere IHS.
• WebSphere Application Server.
• WebSphere Application Server DMGR.
• WebSphere Application Server cluster nodes.

Dependencies are defined between them and I can startup the required WebSphere services with just a line of code:

svcadm enable [websphere-service-name]

and SMF will take care of everything.

The usage pattern for SMF can be enhanced further. Let's suppose you're working in one or more projects and each one of them requires distinct set of running services. What usually happens is one of the following:

• You install them all and let them run.
• You install them all and start and stop them manually when you switch working project.

Resources are always few for a developers and some are paranoid about sparing them. With SMF you can:

• Define a SMF service for each of your projects.
• For every projects, define dependencies with the services you need.

This way, at a minimum, you can start and shutdown, with a single command, every service you need for a specific project. No more:

• Custom shell scripts for every service.
• Custom configuration entries for inetd services (such as Subversion, Apache, etc.)
  
• Specific OS customization.
• Running services when you don't need them and waste resources you could use otherwise.
  

Example of SMF service manifest customization can be found in the following posts:

• Registering a service with SMF.
• Credentials and Projects for a Solaris 10 SMF-Managed Service.
• Setting Up Subversion as an inetd Service.

ZFS

The ZFS filesystem is unique as far as it concerns flexibility and ease of use. With an incredibly lean set of commands, you can:

• Create file systems on the fly.
• Snapshot file systems on the fly.
• Clone file system on the fly with almost null space usage overhead.

There's a huge literature about ZFS and I'll limit to describe my favorite use cases.

Use case: Multiplexing Your Development Environment.

Software installations are just the beginning of your user experience. Often, we spend time:

• Configuring our environments.
• Fine-tuning them.
• Defining the set of additional libraries we need.
• Defining the set of server resources (JDBC, JMS, etc.) our applications use.

And so on. The list is endless.

Sometimes it's necessary to prepare different environments for different projects or different development stages of the same application. Instead of losing time and resource to build different environments I'll usually proceed as follows:

• Install and configure my environment.
• Make a ZFS snapshot of it.
  
• Make a ZFS clone of it for every additional setup I need.

Oracle JDeveloper is a good example of an application I often clone. JDeveloper is fundamentally a single user environment, despite adopting the common approach of using a per-user configuration directory in the user's home directory. Instead of fiddling with scripts to set per-user configuration parameters, I just install it once, snapshot it's installation directory and make a ZFS clone, one per environment. I use several clones of the JDeveloper environment myself, in my user home directory.

The power of ZFS clones can be used by the Zones infrastructure, as we'll see in the following section, thus enhancing further its power. Cloning a ZFS filesystem is also advantageous while dealing with big installations such as disk images of your favorite virtualization technologies.

Additional posts I wrote about ZFS that could clarify some of its use cases are:

• Sparing Disk Space With ZFS Clones While Setting Up a Developer Environment.
• Sun xVM: Cloning Your domU.
  

Containers and Other Virtualization Technologies

I consider Solaris a superior desktop virtualization platform. Once again, with a couple of commands. you can easily create a paravirtualized Solaris instance (a Zone). The zones infrastructure is ZFS-aware and can take advantage of it.

Zones can be configured with a command line interface to its XML configuration file. Creating a zone is straightforward and, since they're a lightweight technology, you can create as much zones as you need. If you're using ZFS, the process of cloning a zone is incredibly simple and fast.

Use Case: Clustering an Application Server

During the development of your Java EE application you will tipically need an instance of one (or more) of the following:

• An application server.
• A web server.
• A data base;
• An user registry.

It's also desirable to have them running on isolated environments so that you can mimic the expected production configuration. With zones it's easy: just create as many zones as you need and each one of them will behave as a separate Solaris instance: every zone will have, for example:

• Its own network card(s) and IP configuration.
• Its own users, groups, roles and security policies.
• Its own services.

Instead of installing and configuring an environment multiple times, you will prepare "master" zones with the services you need. I've got a "master" zone for every one of the following:

• WebSphere Application Server.
• WebLogic Application Server.
• Oracle DB.
• MySQL DB.
• LDAP directory.

and so forth. With one simple command (zoneadm clone [-m copy] [-s zfs_snapshot] source_zone) you'll end up with a brand new working environment in a question of minutes.

Use Case: VirtualBox and ZFS

Sometimes you'll rather work on a virtualized instance of some other OS, such as GNU/Linux, FreeBSD and Windows. Solaris is a great VirtualBox host and the power of ZFS will let you:

• Create "master" images for every OS or every "OS role" you need.
• Clone them on the fly to create a brand new virtual OS image.

In my case, I've got:

• A master Windows 7 client with Visual Studio for .NET development.
• A master Windows Server 2008.
• A master Windows Server 2008 (a clone of the previous one) with SQL Server 2008.
• A master Debian GNU/Linux.

Every time I need a new instance I just have to clone the disk image. In a matter of seconds I've got the environment I need. Not only I'm sparing precious time, I'm also sparing a vast amount of disk space. Should I store all of the images (and zones) I use without the ZFS technology and I'd need at least 4 times as much disks as I've got.

Use Case: A Virtualized Network Stack

Solaris provides you pretty powerful network virtualization capabilities. You can, for example, create as many virtual NICs as you need and use them independently either in Solaris Zones or as network cards for other virtualization technologies (such as VirtualBox.) Network cards can be interconnected with virtual switch (etherstubs) and enable you to create "networks in a box." Not only you can use virtualized instances to mimic your production environment: you'll be able to create a virtualized network to emulate the complex network policies your environment could need.

If you need to test an environment whose configuration would be impossible to replicate without additional physical machines, that's where virtualization technologies (such as Zones or VirtualBox) and the virtualized network stack come in handy. My developer environment for a project I'm working for is made up of:

• Two zones with two load balanced IBM IHS instances.
• A zone with an LDAP directory.
• Two zones with two clustered instances of IBM WebSphere Application Server.
• A Zone with an instance of IBM WebSphere DMGR.

With Solaris, I can replicate the production environment in my box and respect each and every network configuration we use. Without these technologies, it would have been much harder to accomplish this goal or I would end up with custom configurations (for example, to avoid port clashes). In all cases, I'd lose much more time on the administration and configuration of such environments if zones weren't so easy to use.

DTrace

DTrace power is extremely easy to explain to a developer. At the same time, it's difficult to grasp its usefulness without trying it yourself. DTrace on Solaris provides tens of thousand of probes out of the box and others can be created on the fly. This "probes" provide you an extremely powerful mean of troubleshoot problems in either your applications and the underlying operating systems. To use the probes you've got to use scripts written in the D language. Fortunately, this language is pretty easy by design and you can write powerful D scripts in a few lines of code.

DTrace is unobtrusive and let you troubleshoot problems immediately, without modifying your application, even in a production environment. Some IDEs, such as NetBeans, have powerful plugins that let you write D scripts and see the data collected by the probes in beautiful graphics.

As a developer, I valued DTrace usefulness more than once. Instead of troubleshooting problems having to dig into the source code and introduce additional code (even in the cases in which aspects come in handy), I could use a D script to observe the application from the outside and quickly collect data that could help me determine where the problem could be.

In some cases, moreover, you could find yourself dealing with situations in which there's no code available. I could quickly troubleshoot a problem I was having with WebSphere Application Server with a D script instead of relying on WebSphere tracing facilities and the task of interpreting log files.

Conclusion

So much for an introductory post. The possibility of building a development environment as close as possible as your target environment is a "must" for any development platform. Additionally, I consider that working on a environment as close as possible as the production environment not only gives you additional value and insights during an application development stage, but should also considered a mandatory requirement for every project we're involved into. Solaris provides all of the tools a developer need to accomplish this goal.

Solaris is a complex enterprise operating system with many features you won't probably ever use. Nevertheless, there's a use case for many others of them, as I tried to point out in this post. Since some of these technologies were developed with an open source license, they are also available on other operating systems: ZFS is available on FreeBSD and there exist a community effort to port it to OS X; DTrace is available on OS X, Linux and FreeBSD.

The "Solaris advantage" is that all of these technologies are highly integrated and take advantage of each other. The result is worth more than the sum of them. These technologies have got a very polished and easy to use administrative interfaces: when time is important, "How you do it" is fundamental.

I hope that these insights might help you understand if and when the Solaris operating system might be useful to you. Even if you consider that it's not, I suggest you give it a try anyway: it's always good to add new technologies to your tool box.

LibreOffice: How Communities Have Grown Tired of Oracle

It seems that Oracle attitude towards some communities is starting to have some unwanted consequences. After dumping the OpenSolaris community with an obstinate silence and continuing to leave the Java Community Process in an embarrassing limbo, the OpenOffice community has decided to take action and announced the creation of The Document Foundation to take control of the OpenOffice productivity suite.

Meanwhile, Oracle has been requested to join the "new" community by applying to the Foundation. Other companies worried by Oracle latest moves, such as Google and Novell and Red Hat, are  already supporting the Foundation.

I wonder what Oracle will do and hope that Larry, at least once, does something so that Oracle be not the bad guy. This news makes me miss the Good Old Sun Microsystems.

The Death of OpenSolaris: Choosing an OS for a Java Developer

A Bit of History: The Struggles of OpenSolaris

This is no news: you probably know all about it.

As a long time Solaris user, the recent years have been full of good news for me.

I remember starting with GNU/Linux at home to have "something similar" to the Solaris workstations I used at work. It was the time when software would most likely compile on Solaris rather than on Linux.

Years later I bought my first Sun Workstation: it was the time when trying to compile on Solaris packages that would supposedly compile on a POSIX system was a pain. Still, I continued to regard Solaris as a stable platform to keep on using it for my work duties, such as Java programming.

Then came Solaris 10 and all of its wonderful technologies such as ZFS, Zones and DTrace, just to cite a few. With it, there came the Solaris Express distributions which, at last, filled a long standing gap between Solaris and other operating systems, providing us a pretty modern desktop environment.

In late 2008 came the first OpenSolaris distribution. I installed it, played with it, but kept on using SXCE for my workstations. The main reason was compatibility with many Sun packages, such as the Java Enterprise System or the Sun Ray Server Software, that had more than one glitch on OpenSolaris.

When SXCE was discontinued, I waited for the 2010.xx OpenSolaris release to upgrade my systems. Unfortunately, that release will never see the light.

The Oracle Leaked Memo (the dignifying uppercase is a must given Oracle prolonged silence over the subject) shed a light over Oracle plans for Solaris proper and OpenSolaris. Part of the "good news" is that the Solaris Express program has been resurrected and the first binary distribution is expected later this year.

The bad news is that the code, at least the parts of it that will be released with an open source license, will be released after the releases of the full Solaris Operating Systems. Basically, our privileged observation point over the development of the operating system has been shut down.

Lots of ink has been been spilled since the Leaked Memo and plenty of information, discussions and wars are going on in the blogosphere. I'm not an authoritative source to speak about the subject and it's not even clear to me what I'm going to do, now.

Benefits of Solaris for a Java Developer

Solaris has been my operating system of choice since before I started working in the IT industry. As a student, I grew up with Solaris at the data center of my University and the Slackware I used at home seemed like a kid toy, compared to it. After graduating, I started working as a design engineer for a leading microprocessors producer. Needless to say, Solaris was the platform we ran our design software upon. Then, I moved to a consulting firm and started my career as a Java architect.

Solaris was and is the platform of choice for most of the clients I've been working for. Even today, the application servers, the cluster software, the database, and most of the infrastructure used by my clients run on Solaris. It always seemed a sound choice to me, then, developing software on the same platform that will run it in production.

IDEs, Tools and Runtimes

As a Java developer, I can run all of my tools I need on a supported platform. My favorite IDEs (NetBeans and JDeveloper), the application servers my clients use (WebLogic and WebSphere, mostly), the databases used by my applications (MySQL, Oracle RDBMS, PostgreSQL): all of them run and are supported on Solaris. Some of them are even bundled with it or readily available by Sun sponsored package repositories. The Eclipse platform, to cite a widely use IDE for Java, is available in the OpenSolaris IPS repository, too.

Solaris Technologies

Solaris 10 also integrates DTrace, a powerful, unobtrusive framework that allows you to observe and troubleshoot application and OS problem in real time, even in production systems with an almost null overhead. DTrace has allowed us to diagnose strange production quirks with no downtime: once you've tried DTrace and the D language, there's no going back to "just" a debugger, even in the development stages of your project.

Other kinds of problems does not show up in your debugger or are extremely hard to catch. It might be the case of network or file systems problems. That's where DTrace comes in handy: it lets you observe with an incredibly high detail what's going on in your application and in the kernel of the operating systems, if it's necessary to dig so deep.

Solaris Virtualization Technologies

Solaris is also an ideal host virtualization platform. Solaris can "virtualize itself" with Containers, Zones and Logical Domains: you can start a Zone in no time (and almost no space overhead), assign a resource cap to it and also build a virtualized network in a box to simulate a complex network environment.

One of the problems that I encountered during the development of big enterprise system is that the development environment, and sometimes even the integration environment, is very different than the production one. It surely is a methodology problem: nevertheless, developers have few weapons to counteract. For example, applications that appear to run fine on a single node may not run correctly on a server cluster, or scale badly.

The more you wait to catch a bug, the more impact will have a patch for it. That's why in my development team, for example, we use Solaris Zones to simulate a network cluster of IBM WebSphere Application Servers and a DB cluster. All of them run in completely isolated Zones in one physical machine and communicate on a virtual network with virtual etherstubs (sort of a network switch), VLANs and routing rules. This environment lets us simulate exactly how the software will behave in the production system. Without a flexible and lightweight virtualization technology it would have been much more difficult and expensive to prepare a similar environment.

And if you (still) need to run other platforms, you can use Xen or VirtualBox to run, for example, your favorite Linux distro, Windows, or *BSD.

Summarizing

Enumerating the advantages of Solaris is difficult in such a reduced space, however I'll try:

• It's a commercially supported operating system: that's an option, since Solaris is free for development purpose. Nonetheless, it's an important point to take into account.
• Is (very) well documented: there's plenty of official and unofficial documentation.
• It's easy to administer: Solaris is pretty easy to administer, even if you're not a seasoned system administrator.
• It's an UNIX system: with all of its bells and whistles.
• It is a great virtualization platform.
• It has some unique technologies that add much value to its offering, such as ZFS and DTrace.

If you're a Java developer and haven't given Solaris I try, I strongly suggest you do it. Maybe you'll start to benefit from other Solaris 10 technologies such as Zones and ZFS, even for running your home file or media server.

Complaints

I often hear complaints about Solaris coming from different sources and with the most imaginative arguments: proprietary, closed, old, difficult to use. I usually answer inviting users to try it and see for themselves before judging it (if that's the case). Most of the times I'm not surprised to discover that the complaining guy had minimal or null exposure to Solaris.

Also, I'd like to point out that no OS I tried is a swiss army knife. Solaris is a server-oriented OS with a good desktop but it's not comparable with other operating systems for such an use. So: no comparison with Linux, please. It would be so unjust as comparing Linux and Mac OS X for the average home user. ;)

Alternatives

Since Java "runs anywhere", there's plenty of choice for a Java developer.

Since I own a laptop with Mac OS X, I've built a small development environment with all of the tools I need. Mac OS X is a great operating systems that comes with many fancy features out of the box and, although it has some idiosyncrasy with Java (read: you have to use the JVM shipped by Apple), it's a good OS for a Java developer. Since the Mac OS X hype has begun, there's plenty of packages for it and a big ecosystem which is still growing. Still, many software packages run in the enterprise aren't supported on Mac OS X. Since I prefer to have an environment as close as possible as the production one, I think that OS X is not the best choice for the average Java EE architect.

I've also been an hardcore Slackware and Debian user for a long time. An enterprise Java developer would miss nothing in a modern GNU/Linux distribution, nowadays, and most of the software packages you'll find in the enterprise will run on your GNU/Linux distribution.

No need to talk about Windows, either.

So, why Solaris? Every OS has its own advantages and disadvantages. The point is to just recognize them. Mac OS X, in my opinion, is the best OS for a home user. I would change it for no Windows and no Linux. But as far as it concerns my developers' duties, every other OS just lacks the features and the stability that make Solaris great. ZFS, DTrace and Zones, for my use cases, are killer features.

What's Next?

You've decided to give Solaris a try, so: which is Your distribution? I don't know.

Solaris Express/Oracle Solaris

I strongly suspect that my wait will be prolonged and I will finally upgrade my machines as soon as Solaris Express has been released. Upgrading to Solaris 10 09/10 is not possible since I'm using some ZFS pools whose version is not yet supported by Solaris proper but it is a sound choice for a starter.

The advantage I see in using one of these versions is the availability of optional support and the good level of integration with the most commonly used software packages that Oracle is likely to guarantee.

OpenIndiana

You should also know that OpenSolaris sources have been (sort-of) forked and two new projects are born: Illumos and OpenIndiana. The project were started by Nexenta employees and volunteers of the OpenSolaris community. The first projects aims at maintaining the OpenSolaris code and the parts of the code that are closed or code that upstream might choose not to maintain. The OpenIndiana project aims at producing binary distribution of the operating system built upon the Illumos source code. OpenIndiana will provide a really open source, binary compatible alternative to Solaris and Solaris Express.

Sounds good and I'll willingly support it. In the meantime I've installed OpenIndiana in a couple of virtual machines and the first impressions are very good. I suppose it hasn't passed enough time yet for diverging changes to have emerged.

If you prefer a more modern desktop with a recent Gnome interface, drop Solaris 10 and go for OpenIndiana, if you don't feel like waiting for Solaris Express. In any case, switching between the two shouldn't pose any problems. What's clear to me is that I won't consider using both operating systems: I'll have to make a choice.

Support Availability

As an enterprise user and a Java developer, I've always been more concerned about OS support and support for the packages I use, rather than about eye candy. Even at the cost of running a proprietary platform.

In conclusion: I'll wait for Solaris Express to be released and only then will decide which one I'll use for my purposes between Oracle Solaris Express and  OpenIndiana. My heart is betting for OpenIndiana. My brain is betting for Oracle Solaris Express and Solaris proper. Only time will tell which one is right (for me.)

Follow-Up

A follow-up of this blog post is avaible at this address. In this post I'll try to summarize some use cases in which the technology we introduced in this post are effective and add real value to your development duties.

I hope you enjoy it.

Encoding an Unicode Character to UTF-8

Introduction

I'm living in an UTF-8 world. Everthing, from the operating systems I use (Solaris, Linux and Mac OS X) to my terminals. Even the file systems I use must be able to support the UTF-8 names I give to my files.

UTF-8 is a flexible and well supported encoding for Unicode and it's supported, out of the box, on all the operating systems I use. UTF-8 allows me not to worry (ever) about the characters I use in file names or in the files I write. Being a native Italian living in Spain, it's essential for me to have an encoding that supports all of the languages I use in my daily file.

UTF-8 is the perfect solution: it's ASCII backwards compatible, so I need no conversion when writing ASCII files, and can encode every characters in the Unicode character set. No need to worry if one day I had to write some Japanese file name. The only "drawback" it may have it's a little space overhead compared to some other encodings (such as UTF-16) but in this particular case, UTF-8 beats them all.

In such an UTF-8 world, there's no need to worry: just use the tools you have and everything will be fine.

Well, almost. Sometimes, as described in that post, I need to know exactly how UTF-8 encodes a specific Unicode code point. Some other times, since I'm a sed and grep addict, it's really handy knowing what to look for. Some days ago, for example, I had look for file names that contained specific code points to correct an idiosyncrasy between Subversion and Mac OS X (I still cannot believe it...). In such a cases, an UNIX terminal and its utilities are really your best friends. Since the encoding process is very easy, I'm quickly describing it to you in the case you need it.

The UTF-8 Encoding

The UTF-8 encoding is a variable width encoding in which each Unicode code point can be encoded as a sequence of 1 to 4 octects. Each octect is composed by a heading byte and trailing bytes. Since the encoding is a variable width one, you need a way to tell where a sequence starts and where it ends. That information is stored in the head byte.

Heading Byte

The head byte can take one of these forms:

• 0xxxxxxx: Single byte.
• 110xxxxx: Head of a sequence of two bytes.
• 1110xxxx: Head of a sequence of three bytes.
• 11110xxx: Head of a sequence of four bytes.

You may have noticed that the number of 1s in a heading byte tells how long the sequence is. If the heading byte starts with 0, the sequence is single byte.

The 0xxxxxxx format guarantees that ASCII characters in the [0, 127] range are encoded by the identical function thus guaranteeing the backwards compatibility with ASCII.

Trailing Bytes

Trailing bytes in a multibyte UTF-8 sequence always have the following form:

• 10xxxxxx

Encoding

The 0s and 1s in the heading and trailing bytes format described in the previous sections are called control bits. In the UTF-8 encoding, the concatenation of the non control bits is the scalar value of the encoded Unicode code point. Because of the structure of the aforementioned forms, the number of required bytes to encode a specific Unicode code point with UTF-8 depends on the Unicode range where it falls (the ranges are given both hexadecimal and binary forms:

• [U+000, U+007F] [00000000, 01111111]: one byte.
• [U+0080, U+07FF] [10000000, 111 11111111]: two bytes.
• [U+0800, U+FFFF] [1000 00000000, 11111111 11111111]: three bytes.
• [U+10000, U+10FFFF] [1 00000000 00000000, 10000 00000000 00000000]: four bytes.

One Byte Range

In the one byte range, meaningful bits of the Unicode code points are in then [0, 6] range. Since the single byte form has a 1 bit overhead (the leading 0), a single byte is sufficient:

[0xxxxxxx  0xxxxxxxx]
[00000000, 011111111]

Two Bytes Range

In the two bytes range, meaningful bits of the Unicode code points are in the [0, 10] range. Since the head of a sequence of two bytes has a 3 bits overhead and the form of a trailing byte has a 2 bits overhead, there's room for exactly 11 bits.

[     fff ffssssss,      fff ffssssss]
[00000000 10000000, 00000111 11111111]

(* f are bits from the first byte of the encoded sequence)
(** s are bits from the second byte of encoded the sequence)

The encoded sequence is:

[110fffff 10ssssss]

Three Bytes Range

In the three bytes range, meaningful bits of the Unicode code points are in the [0, 15] range. Since the head of a sequence of three bytes has a 4 bits overhead and the form of a trailing byte has a 2 bits overhead, there's room for exactly 16 bits.

[ffffssss sstttttt, ffffssss sstttttt]
[00001000 00000000, 11111111 11111111]

(* f are bits from the first byte of the sequence)
(** s are bits from the second byte of the sequence)
(*** t are bits from the third byte of the sequence)

The encoded sequence is:

[1110ffff 10ssssss 10tttttt]

Four Bytes Range

In the four bytes range, meaningful bits of the Unicode code points are in the [0, 20] range. Since the head of a sequence of four bytes has a 5 bits overhead and the form of a trailing byte has a 2 bits overhead, there's room for exactly 21 bits.

[   fffss sssstttt tthhhhhh,    fffss sssstttt tthhhhhh]
[00000001 00000000 00000000, 00010000 11111111 11111111]

(* f are bits from the first byte of the sequence)
(** s are bits from the second byte of the sequence)
(*** t are bits from the third byte of the sequence)
(**** h are bits from the third byte of the sequence)

The encoded sequence is:

[11110fff 10ssssss 10tttttt 10hhhhhh]

Conclusion

You know see how easy is to convert an Unicode code point to its representation in the UTF-8 encoding. The UTF-8 encoding of the Byte Order Mark (BOM) character, for example, whose code point is U+FEFF, can be easily be computed as explained above.

The U+FEFF code point falls in the three byte range and its binary representation is:

[F    E    F    F   ]
[1111 1110 1111 1111]

According the the aforementioned rule, the conversion gives:

[E   F    B   B    B   F   ]
[11101111 10111011 10111111]

that corresponds to the \xEF\xBB\xBF expression used with sed in our previous example.