Voting ends Friday May 21st, so act now!

1. You’ll need to register for an account on JBoss.org (Remember when creating an account that you’ll need to use a valid email address for registration confirmation!)
2. Vote – for “Beautiful Java EE: Use PrettyFaces to Harness SEO, Improve User Exp, and Ease Dev by Lincoln Baxter” – otherwise known as “Beautiful Java EE: Next-generation web application for next-generation web users.”
3. If you have problems voting after registration, log out, clear your cookies, log in, then navigate back to the contest and vote.

Do your part: Vote!

]]> http://ocpsoft.com/opensource/vote-for-prettyfaces-at-judcon-jboss-world-red-hat-summit/feed/ 1 http://ocpsoft.com/java/jsf-2-0-cross-field-form-validation-simpl-in-reality/ http://ocpsoft.com/java/jsf-2-0-cross-field-form-validation-simpl-in-reality/#comments Wed, 05 May 2010 14:55:50 +0000 Lincoln http://ocpsoft.com/?p=1254 I’d like to start by saying that using JSF by itself can sometimes feel trying to pull your own teeth out with a pair of tweezers, but there’s hope. JSF was designed to be a platform of extensions – a foundation for building web-frameworks, and that it’s done very well. JSF 2.0 addresses most of the concerns about usability (so there’s less tooth pulling,) and provides even more extensibility. That’s where Seam Faces comes in, that’s where PrettyFaces comes in.

On many occasions you might find yourself needing to compare the values of multiple input fields on a given page submit: confirming a password; re-enter password; address lookups; and so on. Performing cross-field form validation is simple – just place Seam’s <s:validateForm> component in the form you wish to validate, then attach your custom Validator.

I’d like to introduce you to Seam’s intuitive answer, taken directly out of the reference manual. If you want to try it out, you can check out the source or use a snapshot:

        <dependency>
            <groupId>org.jboss.seam.faces</groupId>
            <artifactId>seam-faces</artifactId>
            <version>${seam-faces-version}</version>
        </dependency>

Seam Faces’ <s:validateForm>

<h:form id="locationForm">
     <h:inputText id="city" value="#{bean.city}" />
     <h:inputText id="state" value="#{bean.state}" />
     <h:inputText id="zip" value="#{bean.zip}" />
     <h:commandButton id="submit" value="Submit" action="#{bean.submitPost}" />
 
      <s:validateForm validatorId="locationValidator" />
</h:form>

The corresponding Validator for the example above would look something like this:

@FacesValidator("locationValidator")
public class LocationValidator implements Validator
{
   @Inject
   Directory directory;
 
   @Inject
   @InputField
   private Object city;
 
   @Inject
   @InputField
   private Object state;
 
   @Inject
   @InputField
   private ZipCode zip;
 
   @Override
   public void validate(final FacesContext context, final UIComponent comp, final Object values) throws ValidatorException
   {
      if(!directory.exists(city, state, zip))
      {
         throw new ValidatorException(new FacesMessage("Sorry, that location is not in our database. Please try again."));
      }
   }
}

Tip – You may inject the correct type directly.

@Inject
@InputField
private ZipCode zip;

Notice that the IDs of the inputText components match the IDs of your Validator @InputFields; each @Inject @InputField member will be injected with the value of the form input field who’s ID matches the name of the variable.

In other words – the name of the @InputField annotated member variable will automatically be matched to the ID of the input component, unless overridden by using a field ID alias (see below.)

<h:form id="locationForm">
     <h:inputText id="cityId" value="#{bean.city}" />
     <h:inputText id="stateId" value="#{bean.state}" />
     <h:inputText id="zip" value="#{bean.zip}" />
     <h:commandButton id="submit" value="Submit" action="#{bean.submitPost}" />
 
      <s:validateForm fields="city=cityId state=stateId" validatorId="locationValidator" />
</h:form>

The field with ID “zip” will still be referenced normally; you need only specify aliases for fields that differ in name from the Validator @InputFields.

Tip – Using @InputField

Using @InputField("customID") with an ID override can also be used to specify a custom ID, instead of using the default: the name of the field. This gives you the ability to change the name of the private field, without worrying about changing the name of input fields in the View itself.

@Inject
@InputField("state")
private String sectorTwo;

A few last thoughts

First, as of the current version, cross-field validation does not work unless you are using the <s:validateForm> component. As soon as a new version of weld-extensions is released, however, this functionality will work even without the <s:validateForm> component, and you’ll be able to reference cross-fields in any JSF validator!

For right now, however, you’ll have to deal with using the component – but – it’s really not that complicated if you think about it Happy coding!

Using Embedded Glassfish

The Embedded Glassfish project is hosted on java.net, and as it is described, is very simple: “This project develops APIs and tools around “embedded GlassFish v3″. Embedded GFv3 is a delivery vehicle of GFv3 so that applications and tools can use GFv3 just as a library, inside their JVM, instead of having GFv3 as the overload of the entire JVM process. (And no, embedded GFv3 is not meant to be run on JavaME.)”

1. You’ll need to add this plugin repository to your POM:

        <pluginRepositories>
		<pluginRepository>
			<id>Glassfish</id>
			<url>http://download.java.net/maven/glassfish/</url>
		</pluginRepository>
	</pluginRepositories>

2. Then add the following plugin to your POM:

          <build>
                 <plugins>
			<plugin>
				<groupId>org.glassfish</groupId>
				<artifactId>maven-embedded-glassfish-plugin</artifactId>
				<version>3.0</version>
				<configuration>
					<goalPrefix>glassfish</goalPrefix>
					<app>test.war</app>
					<port>8080</port>
					<contextRoot>test</contextRoot>
				</configuration>
				<executions>
					<execution>
						<phase>install</phase>
						<goals>
							<goal>run</goal>
						</goals>
					</execution>
				</executions>
			</plugin>
                </plugins>
         </build>

3. Commands

• embedded-glasfish:run – starts the embedded server if it is not already running and deploys the specfied application. The goal keeps the server running, so the user can make changes in the application, reploy and test iteratively.
• embedded-glassfish:start – starts the embedded server with the specified parameters
• embedded-glassfish:deploy – deploys the specified application
• embedded-glassfish:undeploy – undeploys the application identified by the “name” parameter. If no name is specifed all applications are undeployed.
• embedded-glassfish:stop – stops the embedded server
• embedded-glassfish:admin – executes the specified admin command on the embedded server. For example, you could create a jdbc resource.

Reference:

http://blogs.sun.com/sirajg/entry/using_maven_plugin_for_v3

If you’ve ever programmed in PHP, Ruby, Perl, Groovy, and probably others, then you know how nice it is to have a central, official space for reference documentation and inline community feedback.

This is something that has sorely been missing from the JEE community, and something that has caused many disparate websites to attempt putting forward a weak effort in providing useful documentation — you leave the community part aside to think that this is a good thing for any open-source technology.

A successful open-source community documentation initiative has:

• Comprehensive documentation provided on a central, official website (http://seamframework.org)
• Inline comments and user feedback.
• The most common paths on the website are the most visible, intuitive paths.
• Fluent navigation and document hierarchies. (The URL matches the Breadcrumbs matches the content. If users get lost, users give up.)
• Accurate and relevant official information, well vetted information.

I’m sure there is more, but that’s what I have at the top of my head.

Making progress happen:

In kick-starting my (hopefully long) tenure with Red Hat, I’m focusing on improving community documentation for the Seam Framework, and for Java EE as a whole. I’ve started by updated the Seam Framework website to more clearly display the links to Seam and Weld JIRAs; you previously had to do a little digging.

All of my efforts can be tracked here: https://jira.jboss.org/jira/browse/JBSEAM-4585

Please, I ask if you find any outstanding problems, or points of pain with the Seam or Weld documentation, to add it to this Jira. If you can’t, then comment here and I’ll see that it’s addressed.

SeamFramework.org needs work, and I do think that the community really belongs on jboss.org, in order to fully get credit for their hard work and great achievements. Jboss.org also provides much of the functionality that I’m looking for in a community management tool, but we’ll see what everyone wants

Happy communities make happy software!

Add PrettyFaces to an existing JSF2 application less than 5 minutes:

• Non-invasive! – never change your application internals, simply lay PrettyFaces on to an existing application.
• Zero configuration* in a Servlet 3.0 environment – PrettyFaces core classes are automatically registered with the servlet container and JavaServer Faces. (No need to modify web.xml!)
• Rapid development via automatic configuration reloading (when java.faces.PROJECT_STAGE = Development)

• Custom Inbound/outbound URL rewriting rules – with built in support for canonicalization such as appending or removing trailing slashes, lowercasing, custom rewrites, and more.
• Enhanced SEO and Rewriting support – including the ability to choose 301, 302, or internal redirects.
• Outbound URL mapping rewriting – removes the need for <pretty:link> now <h:link> can be used to generate pretty, SEO-friendly URLs.
• Named pattern / path-parameters – for integration with JSF2 and non-JSF applications – not all applications support EL, but they all understand ServletRequest.getParameter(…)

Maven Dependency

<dependency>
	<groupId>com.ocpsoft</groupId>
	<artifactId>ocpsoft-pretty-faces</artifactId>
	<version>2.0.4</version>
</dependency>

Sometimes things are worth writing about.

While working on the PrettyFaces: bookmarking, and SEO extensions for JSF / JSF2, I came across a need to modify the current request parameters in order to “trick” the system into thinking that additional query parameters had been supplied.

Naively, I tried:

    request.getParameterMap().put("name", new String[]{"value1", "value2"});

But that doesn’t work, because you aren’t allowed to modify request parameter values once the request has begun processing:

    java.lang.IllegalStateException: Cannot find message associated with key parameterMap.locked
	at org.apache.catalina.util.ParameterMap.put(ParameterMap.java:213)

This means we need to wrap the current request with our own special HttpServletRequestWrapper that will provide the ability to merge in some extra parameters up front.

The magic is quite simple:

But be careful! If you call request.getParameterMap() or any method that would call request.getReader() and begin reading, you will prevent any further calls to request.setCharacterEncoding(...), which is a big deal if you are processing i18n requests, or requests with a special content type.

You need to ensure that the new parameters are merged with the original request parameters only when the parameters are requested, so that everyone still has a chance to set the encoding. Otherwise you get nasty warnings like this:

WARNING: PWC4011: Unable to set request character encoding to UTF-8 from context 
/ocpsoft-pretty-faces-tests, because request parameters have already been read, or 
ServletRequest.getReader() has already been called

Our little HttpServletRequestWrapper:

You could simply provide a modifiable map implementation, but that would break the contract of the request parameter map.

So using a bit of lazy processing, here’s how we avoid reading the parameters until they are actually requested, while still maintaining the immutable nature of the Map.

/*
 * PrettyFaces is an OpenSource JSF library to create bookmarkable URLs.
 * Copyright (C) 2010 - Lincoln Baxter, III <lincoln@ocpsoft.com> This program
 * is free software: you can redistribute it and/or modify it under the terms of
 * the GNU Lesser General Public License as published by the Free Software
 * Foundation, either version 3 of the License, or (at your option) any later
 * version. This program is distributed in the hope that it will be useful, but
 * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License
 * for more details. You should have received a copy of the GNU Lesser General
 * Public License along with this program. If not, see the file COPYING.LESSER
 * or visit the GNU website at <http://www.gnu.org/licenses/>.
 */
import java.util.Collections;
import java.util.Enumeration;
import java.util.Map;
import java.util.TreeMap;
 
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletRequestWrapper;
 
public class PrettyFacesWrappedRequest extends HttpServletRequestWrapper
{
    private final Map<String, String[]> modifiableParameters;
    private Map<String, String[]> allParameters = null;
 
    /**
     * Create a new request wrapper that will merge additional parameters into
     * the request object without prematurely reading parameters from the
     * original request.
     * 
     * @param request
     * @param additionalParams
     */
    public PrettyFacesWrappedRequest(final HttpServletRequest request, 
                                                    final Map<String, String[]> additionalParams)
    {
        super(request);
        modifiableParameters = new TreeMap<String, String[]>();
        modifiableParameters.putAll(additionalParams);
    }
 
    @Override
    public String getParameter(final String name)
    {
        String[] strings = getParameterMap().get(name);
        if (strings != null)
        {
            return strings[0];
        }
        return null;
    }
 
    @Override
    public Map<String, String[]> getParameterMap()
    {
        if (allParameters == null)
        {
            allParameters = new TreeMap<String, String[]>();
            allParameters.putAll(super.getParameterMap());
            allParameters.putAll(modifiableParameters);
        }
        //Return an unmodifiable collection because we need to uphold the interface contract.
        return Collections.unmodifiableMap(allParameters);
    }
 
    @Override
    public Enumeration<String> getParameterNames()
    {
        return Collections.enumeration(getParameterMap().keySet());
    }
 
    @Override
    public String[] getParameterValues(final String name)
    {
        return getParameterMap().get(name);
    }
}

Once you have your handy request wrapper, you can get working! Keep in mind that you’ll need to do a servlet forward if you want your entire system to gain access to your new parameters. Otherwise, you can just pass this new wrapped object around as needed.

    //"request" is the current HttpServletRequest
    Map<String, String[]> extraParams = new TreeMap<String, String[]>()
    HttpServletRequest wrappedRequest = new PrettyFacesWrappedRequest(request, extraParams);
    request.getRequestDispatcher("url").forward(wrappedRequest, response)

Happy hacking! As a final note, I’d like to say that JEE 6 has really turned out to be a great experience. Very pleasant to program on. Well done, SUN!

The Beginning

When we started OcpSoft, we were working on what is now ScrumShark – using JSF 1.2 , Hibernate, and many other technologies.  At first it was very overwhelming, challenging to figure out which technologies to use; though, even after we had chosen our technology stack, we fought with poor documentation, lack of support, and integration as we explored new features of the stack.

During that time Lincoln saw a need for pretty URLs, because what was currently on the market wasn’t intuitive, and was painful to work with.  The enhancements we requested weren’t getting approved or were too slow coming, even providing patches.  So Lincoln set out to do it himself, and as he puts it: “destroyed Thanksgiving 2008.”

PrettyFaces

Thanks to PrettyFaces, Lincoln dug-in to JSF and started to really understand the inner workings of both problem and solution; within a few weeks of releasing version one, we were seeing many supporters.  Soon after, Lincoln was contacted by Dan Allen from JBoss/Red Hat, and started assisting him with an enhancement to JSF’s navigation system.

During that same time Lincoln convinced us – at OcpSoft – to start using JSF 2 Beta to build ScrumShark.  JSF 2 was undergoing continuous changes at that time, and the specification wasn’t even public, so we were seeing different results in our application every week.  Lincoln started posting the issues on the JSF 2 mailing list, and quickly became known as the JSF 2 tester, bug-finder.  Without ScrumShark, and Lincoln willing to take a chance on a bleeding edge technology, I don’t think the JSF 2 team would have found and fixed all the bugs as fast as they did.  Not too long after this, he joined the JSF Expert Group and was presenting PrettyFaces at JSFSummit.

Congratulations Lincoln!

He just got a job with JBoss at Red Hat, as a Senior Software Engineer. I am proud of of what my partner and best friend Lincoln has accomplished.

In summary: I would recommend buying this reference if you are a consumer, designer, UI-developer who is working with existing component libraries, Facelets or JSF 2.0, and not so much focused on creating custom Java-components of your own. I don’t, for every-day web-site components, see why you would need much more than what is featured between the covers of this book. Ian Hlavats does a fantastic job of making bringing JSF to the everyday development setting.

JSF 1.2 Components By Ian Hlavats Download Chapter 2: Facelets Components as a PDF

In detail:

Initially hesitant to buy a reference on components, I have to admit that I was surprised to learn so much by reading through this book. As a member of the JavaServer Faces 2.0 expert group, and a full-time software engineer, components are not my strong-suit. If you’re at all like me, then you’re probably asking yourself the same question I did:

“What can I learn in this book that I can’t find on Google? JavaServer Faces has a huge online community, and there’s a lot of information available already.”

It’s a valid question, but you should keep reading because this book offers something important that I rarely find in blog entries or wikis: “features you wouldn’t think to look for; features that you wish you’d thought of, or don’t know how to make yourself.” I wish I had found this book when I started using JSF, because I’d probably have been more comfortable, and much more productive with our component side of the life-cycle, so to speak; I discovered features of the framework, and pre-made UI-tools that I wish I’d known about years ago.

Things you’ll learn about:

Modal windows, menus, wizards and workflows, AJAX anything with Ajax4JSF, i18n and localization, gCal-like schedules with Apache Tomahawk, multi-field validation, calendars, charts and graphs, file-uploads, user permissions/security, skinning, styling, and all major component libraries are covered in this book (save PrimeFaces, which gets a mere mention.)

If you think you’re looking at “Just another book on JSF component writing,” that’s not entirely the case. This book provides real solutions, real examples on how to get started writing JSF applications using existing component libraries and plug-ins. There are two types of chapters in this book: tutorials and references. The tutorials will get you up and running with a quick example, while the reference sections go in depth on usage of individual components within each library.

You’ll also (as a bonus, in my opinion) get some appetite-whetting information on the JBoss Seam framework, which is a user-friendly and business-oriented extension to the Java EE technologies. I didn’t get a very good picture of all of the concepts until I actually looked at the code samples (downloadable here, or just follow the link in the preface,) but that’s hardly a strong criticism; though, it may have helped if the code samples were more explicitly, frequently referenced.

In the end “The title doesn’t lie”:

• I haven’t seen a more comprehensive book on component libraries and component writing made available to date.
• JSF2 component writing has been simplified, but if you want to supplement your app with everyday things like in-place editing, accordions, and more, you’re going to want good examples; this book provides examples in abundance (even examples of JSF2 EzComp, which is a dream to use. UI like it was meant to be)
• Even if components and UI design are not your strong-point, that is exactly why you should read this book; it makes component-based design easy to understand, and easy to implement.

The author covers many of the advancements in component writing and simplified configuration that are provided by JSF 2.0, but I would have liked to hear some information on the component behaviors model, and mention of integration with frameworks like CDI (JSR-299) and Spring; however, this is not entirely relevant to component writing, and plenty of information exists on sites like www.javaserverfaces.org or Google.

My one complaint is that for a book titled “JSF 1.2 Components,” it did not explain, or teach me how to create custom Java-based components, which are essential for complex behavior and interaction at some level. JSF 2.0 has done a good job of making Java-based components unnecessary, but this book is titled JSF 1.2 components, thus, I would have liked to see how to write a Java-based component in JSF 1.2.

End notes:

Make sure you check out www.javaserverfaces.org. It’s a great starting point and reference for JSF that you will undoubtably bookmark if doing a lot of work, and doing the work with this book. Also check out http://ocpsoft.com/prettyfaces/ for more information on Pretty URLs in JSF, and building client-facing JSF web applications.

Part 1: What are Regular Expressions?

Regular expressions are a language of string patterns built in to most modern programming languages, including Java 1.4 onward; they can be used for: searching, extracting, and modifying text. This chapter will cover basic syntax and use.

Table of Contents:

1. Syntax

Regular expressions, by definition, are string patterns that describe text. These descriptions can then be used in nearly infinite ways. The basic language constructs include character classes, quantifiers, and meta-characters.

1.1. Character Classes

Character classes are used to define the content of the pattern. E.g. what should the pattern look for?

.  	Dot, any character (may or may not match line terminators, read on)
\d  	A digit: [0-9]
\D  	A non-digit: [^0-9]
\s  	A whitespace character: [ \t\n\x0B\f\r]
\S  	A non-whitespace character: [^\s]
\w  	A word character: [a-zA-Z_0-9]
\W  	A non-word character: [^\w]

However; notice that in Java, you will need to “double escape” these backslashes.

String pattern = "\\d \\D \\W \\w \\S \\s";

1.2. Quantifiers

Quantifiers can be used to specify the number or length that part of a pattern should match or repeat. A quantifier will bind to the expression group to its immediate left.

*      Match 0 or more times
+      Match 1 or more times
?      Match 1 or 0 times
{n}    Match exactly n times
{n,}   Match at least n times
{n,m}  Match at least n but not more than m times

1.3. Meta-characters

Meta-characters are used to group, divide, and perform special operations in patterns.

\   	Quote the next meta-character
^   	Match the beginning of the line
.   	Match any character (except newline)
$   	Match the end of the line (or before newline at the end)
|   	Alternation (‘or’ statement)
()  	Grouping
[]  	Custom character class

2. Examples

2.1. Basic Expressions

Every string is a regular expression. For example, the string, “I lost my wallet”, is a regular expression that will match the text, “I lost my wallet”, and will ignore everything else.

What if we want to be able to find more things that we lost? We can replace wallet with an expression that will match any word.

"I lost my \\w+"

As you can see, this pattern uses both a character class and a quantifier. “\w” says match a word character, and “+” says match one or more. So when combined, the pattern says “match one or more word characters.”

Now the pattern will match any word in place of “wallet”. E.g. “I lost my sablefish”, “I lost my parrot”, but it will not match “I lost my: trooper”, because as soon as the expression finds the ":" character, which is not a word character, it will stop matching.

If we want the expression to be able to handle this situation, then we need to make a small change.

"I lost my:? \\w+"

Now the expression will allow an optional ":" directly after the word ‘my’.

2.2. Basic Grouping

An important feature of regular expressions is the ability to group sections of a pattern, and provide alternate matches.

|   	Alternation (‘or’ statement)
()  	Grouping

These two meta-characters are core parts of flexible regular expressions. For instance, in the first example we lost our wallet. What if we knew exactly which types of objects we had lost, and we wanted to find those objects but nothing else?

We can use a group (), with an ‘or’ meta-character in order to specify a list of expressions to allow in our match.

"I lost my:? (wallet|cell phone|car|marbles)"

The new expression will now match the beginning of the string “I lost my”, an optional ":", and then any one of the expressions in the group, separated by alternators, "|"; any one of the following: ‘wallet’, ‘cell phone’, ‘car’, or our ‘marbles’ would be a match.

"I lost my wallet"		matches
"I lost my wallets"		matches		the ‘s’ is not needed, is ignored
"I lost my: car"		matches
"I lost my- car"		doesn’t match	‘-‘ is not allowed in our pattern
"I lost my: cell"		doesn’t match	all of ‘cell phone’ is needed
"I lost my: cell phone"		matches
"I lost my cell phone"		matches
"I lost my marbles"		matches

As you can see, the combinations for matches quickly become very large. This is not the complete set, as there are several more phrases that would match our simple pattern.

2.3. Matching/Validating

Regular expressions make it possible to find all instances of text that match a certain pattern, and return a Boolean value if the pattern is found/not found. (This can be used to validate input such as phone numbers, social security numbers, email addresses, web form input data, scrub data, and much more. Eg. If the pattern is found in a String, and the pattern matches a SSN, then the string is an SSN)

Sample code:

import java.util.ArrayList;
import java.util.List;
 
public class ValidateDemo {
	public static void main(String[] args) {
		List<String> input = new ArrayList<String>();
		input.add("123-45-6789");
		input.add("9876-5-4321");
		input.add("987-65-4321 (attack)");
		input.add("987-65-4321 ");
		input.add("192-83-7465");
 
 
		for (String ssn : input) {
			if (ssn.matches("^(\\d{3}-?\\d{2}-?\\d{4})$")) {
				System.out.println("Found good SSN: " + ssn);
			}
		}
	}
}

This produces the following output:

Found good SSN: 123-45-6789
Found good SSN: 192-83-7465

Dissecting the pattern:

"^(\\d{3}-?\\d{2}-?\\d{4})$"

^		match the beginning of the line
() 		group everything within the parenthesis as group 1
\d{n}		match n digits, where n is a number equal to or greater than zero
-?		optionally match a dash
$		match the end of the line

2.4. Extracting/Capturing

Specific values can be selected out of a large complex body of text. These values can be used in the application.

Sample code:

import java.util.ArrayList;
import java.util.List;
import java.util.regex.*;
 
public class ExtractDemo {
	public static void main(String[] args) {
		String input = "I have a cat, but I like my dog better.";
 
		Pattern p = Pattern.compile("(mouse|cat|dog|wolf|bear|human)");
		Matcher m = p.matcher(input);
 
		List<String> animals = new ArrayList<String>();
		while (m.find()) {
			System.out.println("Found a " + m.group() + ".");
			animals.add(m.group());
		}
	}
}

This produces the following output:

Found a cat.
Found a dog.

Dissecting the pattern:

"(mouse|cat|dog|wolf|bear|human)"

()		group everything within the parenthesis as group 1
mouse		match the text ‘mouse’
|		alternation: match any one of the sections of this group
cat		match the text ‘cat’
 
//...and so on

2.5. Modifying/Substitution

Values in text can be replaced with new values, for example, you could replace all instances of the word ‘clientId=’, followed by a number, with a mask to hide the original text. (See below)

For sanitizing log files, URI strings and parameters, and form data, this can be a useful method of filtering sensitive information. A simple, reusable utility class can be used to encapsulate this into a more streamlined method.

Sample code:

import java.util.regex.*;
 
public class ReplaceDemo {
	public static void main(String[] args) {
		String input = "User clientId=23421. Some more text clientId=33432. This clientNum=100";
 
		Pattern p = Pattern.compile("(clientId=)(\\d+)");
		Matcher m = p.matcher(input);
 
		StringBuffer result = new StringBuffer();
		while (m.find()) {
			System.out.println("Masking: " + m.group(2));
			m.appendReplacement(result, m.group(1) + "***masked***");
		}
		m.appendTail(result);
		System.out.println(result);
	}
}

This produces the following output:

Masking: 23421
Masking: 33432
User clientId=***masked***. Some more text clientId=***masked***. This clientNum=100.

Dissecting the pattern:

"(clientId=)(\\d+)"

(clientId=) 	group everything within the parenthesis as group 1
clientId=	match the text ‘clientId=’
(\\d+)		group everything within the parenthesis as group 2
\\d+		match one or more digits

** Notice how groups begin numbering at 1, and increment by one for each new group. However; groups may contain groups, in which case the outer group begins at one, group two will be the next inner group. When referencing group 0, you will be given the entire chunk of text that matched the regex.

(  ( ) (  ( ) ( )))		//and so on
 1  2   3  4   5		//0 = everything the pattern matched

3. Conclusion & Next Steps

Wrapping up, regular expressions are not difficult to master – in fact, they are quite easy. My strategy, whenever building a new regular expression, is to start with the simplest, most general match possible. From there, I continuously add more and more complexity until I have matched, substituted, or inserted exactly what I need.

Don’t be afraid to “express” yourself! When you’ve got the hang of these techniques, or need something a little fancier, read Guide to Regular Expressions in Java (Part 2).

Part 2: Look-ahead & Configuration flags

Have you ever wanted to find something in a string, but you only wanted to find it when it came before another pattern in that string? Or maybe you wanted to find a piece of text that was not followed by another piece of text?

Normally, with standard string searching, you would have to write a somewhat complex function to perform the exact operation you wanted. This can, however, all be done on one line using regular expressions.

This chapter will also cover the configuration flags available to modify some of the behaviors of the regular expression patterns language.

Table of Contents:

1. Look-ahead & Look-behind

Look-ahead and look-behind operations use syntax that could be confused with grouping (See Ch. 1 – Basic Grouping,) but these patterns do not capture values; therefore, using these constructs, no values will be stored for later retrieval, and they do not affect group numbering. Look-ahead operations look forward, starting from their location in the pattern, continuing to the end of the input. Look-behind expressions do not search backwards, but instead start at the beginning of the pattern and continue up to/until the look-behind expression.

E.g.: The statement “my dog is (?!(green|red))\w+” asserts that ‘green’ will not the word to the look-ahead’s direct right. In other words: My dog is not green or red, but my dog is blue.

Look-ahead/behind constructs (non-capturing)

(?:X) 			X, as a non-capturing group
(?=X) 			X, via zero-width positive look-ahead
(?!X) 			X, via zero-width negative look-ahead
(?<=X) 			X, via zero-width positive look-behind
(?<!X) 			X, via zero-width negative look-behind
(?<X) 			X, as an independent, non-capturing group

So what does this all mean? What does a look-ahead really do for me?

Say, for example, we wanted to know if our input string contains the word “incident” but that the word “theft” should not be found anywhere. We can use a negative look-ahead to ensure that there are no occurrences.

“.*(?!.*theft)incident.*”

This expression exhibits the following behavior:

"There was a crime incident"			matches
"The incident involved a theft"			does not match
"The theft was a serious incident"		does not match

A more complex example is password validation. Let’s say we want to ensure that a password is made at least 8, but at most 12 alphanumeric characters, and at least two numbers, in any position.

We will need to use a look-ahead expression in order to enforce a requirement of two numbers. This look-ahead expression will require any number of characters to be followed by a single digit, followed by any number of characters, and another single digit. E.g.: …4…2, or …42, or 42…, or 4…2.

Example code:

import java.util.ArrayList;
import java.util.List;
 
public class LookaheadDemo {
	public static void main(String[] args) {
		List<String> input = new ArrayList<String>();
		input.add("password");
		input.add("p4ssword");
		input.add("p4ssw0rd");
		input.add("p45sword");
 
		for (String ssn : input) {
			if (ssn.matches("^(?=.*[0-9].*[0-9])[0-9a-zA-Z]{8,12}$")) {
				System.out.println(ssn + ": matches");
			} else {
				System.out.println(ssn + ": does not match");
			}
		}
	}
}

This produces the following output:

password: does not match
p4ssword: does not match
p4ssw0rd: matches
p45sword: matches

Dissecting the pattern:

"^(?=.*[0-9].*[0-9])[0-9a-zA-Z]{8,12}$"

^				match the beginning of the line
(?=.*[0-9].*[0-9]) 		a look-ahead expression, requires 2 digits to be present
.*				match n characters, where n >= 0
[0-9]				match a digit from 0 to 9
[0-9a-zA-Z]			match any numbers or letters
{8,12}				match 8 to 12 of whatever is specified by the last group
$				match the end of the line

Note**: Multiple look-ahead operations do not evaluate in a specific order. They must all be satisfied equally, and if they logically contradict each other, the pattern will never match.

2. Configuring the Matching Engine

Pattern configuration flags for Java appear very similar to look-ahead operations. Flags are used to configure case sensitivity, multi-line matching, and more. Flags can be specified in collections, or as individual statements. Again, these expressions are not literal, and do not capture values.

Configuration flags

(?idmsux-idmsux)  	Turns match flags on - off for entire expression
(?idmsux-idmsux:X)   	X, as a non-capturing group with the given flags on – off

Case insensitivity mode

(?i)  			Toggle case insensitivity (default: off, (?-i)) for the text in this group only

UNIX lines mode

(?d)  			Enables UNIX line mode (default: off, (?-d)) 
			In this mode, only the '\n' line terminator is recognized in the behavior of ., ^, and $

Multi-line mode

(?m)  			Toggle treat newlines as whitespace (default: off, (?-m))
			The ^ and $ expressions will no longer match to the beginning and end of a line,
			respectively, but will match the beginning and end of the entire input sequence/string.

Dot-all mode

(?s)  			Toggle dot ‘.’ matches any character (default: off, (?-d))
			Normally, the dot character will match everything except newline characters.

Unicode-case mode

(?u)  			Toggle Unicode standard case matching (default: off, (?-u)
			By default, case-insensitive matching assumes that only characters 
			in the US-ASCII charset are being matched.

Comments mode

(?x)  			Allow comments in pattern (default: off, (?-x))
			In this mode, whitespace is ignored, and embedded comments starting with '#'
			are ignored until the end of a line.

Global toggle

In order to toggle flags for the entire expression, the statement must be at the head of the expression.

"(?idx)^I\s lost\s my\s .+     #this comment and all spaces will be ignored"

The above expression will ignore case, and will set the dot ‘.’ character to include newlines.

Example code:

public class ConfigurationDemo {
	public static void main(String[] args) {
		String input = "My dog is Blue.\n" +
				"He is not red or green.";
 
		Boolean controlResult = input.matches("(?=.*Green.*).*Blue.*");
		Boolean caseInsensitiveResult = input.matches("(?i)(?=.*Green.*).*Blue.*");
		Boolean dotallResult = input.matches("(?s)(?=.*Green.*).*Blue.*");
		Boolean configuredResult = input.matches("(?si)(?=.*Green.*).*Blue.*");
 
		System.out.println("Control result was: " + controlResult);
		System.out.println("Case ins. result was: " + caseInsensitiveResult);
		System.out.println("Dot-all result was: " + dotallResult);
		System.out.println("Configured result was: " + configuredResult);
	}
}

This produces the following output:

Control result was: false
Case insensitive result was: false
Dot-all result was: false
Configured result was: true

Dissecting the pattern:

"(?si)(?=.*Green.*).*Blue.*"

(?si)			turn on case insensitivity and dotall modes
(?=.*Green.*) 		‘Green’ must be found somewhere to the right of this look-ahead
.*Blue.*		‘Blue’ must be found somewhere in the input

We had to enable multi-line and case-insensitive modes for our pattern to match.

The look-ahead in this example is very similar to the pattern itself, and in this case, the pattern could be substituted for another look-ahead. Because we don’t care in which order we find these two items, the way this is written, substituting “(?=.*Blue.*)” for “.*Blue.*” would be an acceptable change; however, if we did care in which order we wanted to find these colors, we would need to be more precise with our ordering. If we wanted to ensure that the ‘Green’ came after ‘Blue’ we would need to move the look-ahead as seen below, and so on.

"(?si).*Blue.*(?=.*Green.*)"

3. Conclusion

Regular expressions provide an extremely flexible and powerful text processing system. Try to imagine doing this work using String.substring(…) or String.indexOf(…), with loops, nested loops, and dozens of if statements. I don’t even want to try… so play around! Think about using regular expressions next time you find yourself doing text or pattern manipulation with looping and other painful methods. Let us know how you do.

Read the previous article in this series: Guide to Regular Expressions in Java (Part 1)