public boolean isValid(String s,
ConstraintValidatorContext constraintValidatorContext) {
if ( s == null ) {
return true;
}
...

Why would you ever return true (i.e. valid) for an input that is null? That doesn’t make sense until you realise that validation is a *combination* of all constraints.
This means that your validator should only return false for your specific test. If it fails for a chained validation, for example if input is null, it should return true and rely on the NotNull validation to report that error.
You still have to guard for null and empty inputs but return true if they occur rather then returning false.
Hide any required basic validations inside your custom constraint annotation. For example NotBlank does that:

...
@NotNull
public @interface NotBlank {
...

The post JSR 303: Combining custom and standard validators appeared first on The Story of David Kaspar.

There is no fixed mapping between clients and stateless instances. The container simply delegates a client’s work to any available instance that is method-ready.

This means that even with a single remote interface, the container will delegate what bean instance should serve a client call.
With stateful beans the case is the contrary. A remote interface will always guarantee calls are delegated to the same stateful session bean. This of course is crucial to enable a dialog between a client and a stateful bean.
2. The JNDI lookup of a home interface is the costly part of locating an EJB. As such, storing a reference to the home interface is a second approach.
Because application servers may use the create() method as load balancing trigger this approach may behave better in a clustered environment. Consider using the service locator pattern to collect all your service lookups to a single point.
3. A handle to an EJB has the advantage of being serialisable and valid between multiple JVMs. It seems to be the superior way of storing a reference to an EJB.
It is only possible to acquire a handle to EJBs that implement remote interfaces. With EJB 2.0, you will see that many EJBs implement local interfaces only to improve performance. Only the session facades will be exposing both local and remote interfaces.
Conclusion:
To be future proof, it is safest to assume as little as possible about the behaviour of your J2EE server and avoiding short cuts.
This will ensure that your application can move from a testing environment to a full clustered, load balanced production environment or a different j2ee application server.
JNDI lookups of the home interface is the expensive operation so implement a service locator that caches home interfaces. Make sure all of your code is using this single point of looking up EJBs. It will then be possible to change the lookup strategy in the future if needed.
References:
The server side
Service Locator pattern
EJB 2.1 Specification

The post Caching the remote interface of a Stateless Session Bean appeared first on The Story of David Kaspar.

The post Hello J2ME World appeared first on The Story of David Kaspar.

The post Netbeans 3.6 appeared first on The Story of David Kaspar.

“Note that the method Connection.isClosed is guaranteed to return true only when it is called after the method Connection.close has been called. As a result, a programmer cannot depend on this method to indicate whether a connection is valid or not. Instead, a typical JDBC client can determine that a connection is invalid by catching the exception that is thrown when a JDBC operation is attempted.”

The only safe way of ensuring that a connection is valid is to execute a tiny query and catch any SQLExceptions thrown. If no exceptions are thrown, you can go on and using that connection.

If any exceptions are thrown, it is safest to close that connection, set the reference to null and create a new connection.

What query to execute?

It would be nice to execute a general (database independent) method like Connection.getMetaData(). Unfortunately I have seen some indication that this may be successful even when a connection is invalid.

To be on the safe side it is best to execute a query like “SELECT COUNT(*) FROM WHERE 1 = -1″. We are using SQL server so the table sysusers is a safe bet:

    /**
     * A method that tests whether a connection is valid by executing
simple query and catch any exceptions
     */
    private boolean connectionIsValid(Connection dbConn) {
        //log.debug("ENTER connectionIsValid(): "+dbConn);        
        boolean result = true;
        
        PreparedStatement psr = null;
        try {
            //Prepared statement is used to cache the compiled SQL
            psr = dbConn.prepareStatement("SELECT COUNT(*) FROM sysusers WHERE 1 = -1");
            psr.executeQuery();
        } catch (SQLException e) {
            log.debug("Excpetion occured, connection is not valid. "+e.getMessage());
            try {
                dbConn.close(); //dbConn is never null at this point
                dbConn=null;
            } catch (Exception ee) {
                //quite
            }
            result = false;
        } finally {
            try {
                //free up resource kept by the test statement
                if (psr!=null) {
                    psr.close();
                }               
                psr=null;
            } catch (Exception e) {
                //quite
            }
        }        
        //log.debug("EXIT connectionIsValid(): "+result);
        return result;
    }

The post Validating a DB Connection appeared first on The Story of David Kaspar.

The CVS integration is great as it lets your check in and out source files directly from the development environment. I have only tested it together with Microsoft VSS (what a pain that is btw) but it supports other CVS profiles. While it is handy it can be a bit slow on large directory structures so I tend to use it for single files only. When I want to manipulate large amount of source files, I use the VSS client instead.
NetBeans has good XML and XSL support. It lets you validate your XML documents and you can do XSL transformations right there in the IDE. No XSLT debugging though, so get your self a decent XSL IDE (XML Spy or Xcelerator) for serious XSLT.
Javadocs are always tedious to write but NetBeans makes your life little bit easier. It has a nice JavaDoc GUI where all the important fields are listed. It can also auto correct missing fields for you which again saves time.
Ant is integrated in a way that you can browse your build.xml files and execute specific targets.
If you ever need to write localised property files NetBeans helps out with that as well. It will display keys and the various localised values in a matrix, making it easier to modify them all at once.
The GUI Editing in NetBeans looks extensive but I have not got around using it since all work has been web related and did not include any AWT or Swing coding.
There are some disadvantages that I have found. I miss a refactoring functionality the most. Other IDE’s (eg IntelliJ) have features like “find usages” of a method or “refactor” that lets you change package and method names across the whole source. With NetBeans, I have to use the “Find…” functionality and manually make any changes.
Large projects often have source code across multiple modules and directories but are built into one single directory structure. One approach that other IDEs take is that they allow you to set up matching patterns on where to build a source. You probably want different directories for Servlets and other front-end classes, libraries and EJBs. NetBeans is very difficult to set up to build to multiple targets. One has to basically manually specify the build directory for each source file… time consuming.
I also miss J2EE support (templates, wizards). Having grown custom to Borland JBuilder‘s J2ee support I find some task very repetitive and manual in NetBeans.
Another new and upcoming OpenSource IDE is Eclipse. Some knowledgeable people (Sean and Matt) have been swearing by it, saying that it is indeed better than NetBeans. I had a brief look at it but because the UI and other crucial details seems to be working differently I did not dare to use it for actual development yet.

The post Netbeans IDE, pros and cons appeared first on The Story of David Kaspar.

The post java.io.Reader issues appeared first on The Story of David Kaspar.

The post And all that Work appeared first on The Story of David Kaspar.