Eclipse debugger WTFs

Bug renders Eclipse debugger useless if class has/uses generics:
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=344856

Also, Eclipse Glassfish plugins are incapable of launching in debug mode unless the domain.xml is set up to use the default debug port (9009).  if your domain.xml has been changed or customized, Eclipse will not be able to attach the debugger when launching the server in debug mode.  Unfortunately, the "connection refused" doesn't give you much of a clue what's going on.

http://stackoverflow.com/questions/8344454/oepe-glassfish-debug-connection-refused

Read More

Handling poison JMS messages in Glassfish - infinite loop WTF?

I found this post useful for understanding problems with handling "poison messages" in message-driven beans:

http://weblogs.java.net/blog/felipegaucho/archive/2009/09/24/handling-poison-messages-glassfish

The gist of it is that even if you think you caught an exception, your transaction still might roll back and cause the JMS message to be re-delivered.  (The MDB is an EJB, which will default to container-managed transactions, equivalent to having REQUIRED on each method.)

There are two small caveats to add:

1. The specific issue with JPA is that certain persistence exceptions mark the transaction for rollback, even if the exception is actually caught.  It matters not whether that JPA activity is happening directly in onMessage() or in a "sub-transaction".

2. Simply annotating another method in the same MDB with @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW) does not actually create a separate transaction context.  If you are calling a method locally within the same EJB, "this" refers to the object itself, while the transaction behavior lives in the EJB proxy wrapper.  (See http://stackoverflow.com/questions/427452/ejb-transactions-in-local-method-calls)  So you actually have to put this transaction in a separate EJB and inject it into the MDB with @Inject or @EJB annotations.

And now for the "WTF" part.

The thing that really surprised me is the retry behavior.  If the MDB throws an exception, and the transaction rolls back as a result, Glassfish recognizes that there was an exception and will only re-deliver the message once.  There is some setting somewhere that controls how many retries are attempted, I believe.  (Haven't found it.)

If you catch an exception that marked the transaction for rollback (or the transaction was marked for rollback programmatically), the transaction still rolls back, and the message is redelivered.  However, the rollback without exception does not fire Glassfish's retry counter, so you end up in an infinite loop.

Either way the solution is the same, but still -WTF!
Read More

equals and hashCode on @Entity classes: just say no

I've come to the conclusion that you should avoid defining equals and hashCode on JPA @Entity objects unless you have a really good reason to.

Doing it right is non-trivial, with all the gotchas and caveats.  First, the logistics:
  • You can't use the primary key because multiple unsaved objects all have a null PK and would be "equal".  
  • Using the PK with object identity as fallback means an object won't be equal to itself before and after being persisted, and hash-based collections won't work properly if the hash code changes during the collection's lifespan.
  • A unique business key could work, if that's an option - but you have to remember to maintain the equals and hashCode method if those properties or relations change.  Also if that key isn't immutable, you have a similar problem as with PK + fallback above.
  • Creating a UUID in the constructor just to make equals and hashcode work is... yucky.
  • Often these methods are insufficiently covered by unit tests.
Second: there's the deeper question of what should "equals" mean in the context of a mutable business entity?  What comparison makes sense is often context-dependent.  Sometimes you might want to compare based on primary key, other times you might want to compare on some other property.

So what's the worst thing that happens if you just don't do anything, and take the default based on object identity?

Usually, you won't even miss these methods.  The default implementation will work fine unless you're trying to compare objects loaded in two different persistence sessions/transactions,with either equals() or contains().   I've found this is the exception case - much of my collection manipulation in practice is manipulating objects all loaded in the same session to hand off to the view layer, so HashSet recognizes duplicates and contains() works just fine.  And I almost never use an entity as a key in a hashmap.

The price you pay is more verbosity when you do need to compare objects between a session-scoped cache and the current request.  You have to remember that obj1.equals(obj2) doesn't work, and needs to be replaced with obj1.getId().equals(obj2.getId()).  Contains is a bit more verbose, and a utility method like containsById(collection, obj) might be helpful.  Some people will say it's confusing that equals doesn't "just work" but I find it less confusing to be explicit about what you're comparing on - and less confusing than a broken or unmaintained equals() method.

Finally, if this were C#, we wouldn't even have this discussion.  With closures and LINQ extension methods we would just say "collection.Where(obj => obj.id = foo.id)" and be done with it!

Related links:
http://community.jboss.org/wiki/EqualsAndHashCode

http://onjava.com/pub/a/onjava/2006/09/13/dont-let-hibernate-steal-your-identity.html?page=3

http://stackoverflow.com/questions/1929445/to-equals-and-hashcode-or-not-on-entity-classes-that-is-the-question

http://stackoverflow.com/questions/1638723/equals-and-hashcode-in-hibernate

https://forum.hibernate.org/viewtopic.php?t=928172

http://www.ibm.com/developerworks/java/library/j-jtp05273/index.html: "For mutable objects, the answer is not always so clear. Should equals() and hashCode() be based on the object's identity (like the default implementation) or the object's state (like Integer and String)? There's no easy answer -- it depends on the intended use of the class... It is not common practice to use a mutable object like a List as a key in a HashMap."

http://burtbeckwith.com/blog/?p=53
Read More

Code coverage - unintended benefit

Unit test coverage is not a panacea.  You can reach 100% unit test coverage without a single assertion about outputs or business logic, in which case the tests aren't that useful.

Or are they?  Just the act of executing every single line and branch of code does provide one important value: it demonstrates that you can show what inputs or conditions trigger which parts of the code.

More importantly, the act of getting there helps reveal sections of code and conditionals that you might not even need.  Having a coverage target also gives you incentives to stay "clean" and avoid gratuitous not-null checks or try/catch blocks, two pet peeves of mine.  (I've seen too many not-null checks that looked defensive at first but in reality just kicked the can down the road, further obscuring the real problem.)

The other benefit I've found is that a coverage goal encourages refactoring that you should be doing anyway, because well-factored code is easier to unit test.  For instance I had one JSF/JPA application where I was accessing JPA EntityManagers directly in the JSF managed beans.  This made unit tests on the managed beans annoying because I had to mock out EntityManager.createQuery and dozens of Query.setParameter calls for each JPA action.  By pulling the JPA actions into a separate DAO layer, I could just mock a single call to myDAO.getStuff(arguments).  Plus, after isolating the DAO, I could then write an integration test on the DAO hooking up to a real database.

Other related links:
http://www.wakaleo.com/blog/316-code-coverage-as-a-refactoring-tool
http://codebetter.com/patricksmacchia/2009/06/07/high-test-coverage-ratio-is-a-good-thing-anyway/

Read More

Primefaces AJAX callbacks: onstart vs. onclick

I just learned the hard way that onstart and onclick are not the same thing.

In particular, a "return ..." has very different semantics in both cases.

Consider this code: 
<p:commandLink action="#{bean.method}" onstart="return func()" ...>

If "func()" return false, this code will abort the AJAX request and bean.method() won't get called.
If "func()" returns true, the AJAX request processes.
If you replace onstart with onclick, the AJAX request will abort even if func() returns true.

That's because the Primefaces puts the code to generate the AJAX request in the onclick handler, pre-pending your code from the p:commandLink onclick before it.  If your code returns, the AJAX request never gets sent.
Read More

Atlas Debugged: The Fountainhead, YAGNI and "clean code"

The last time I re-read The Fountainhead, I felt like many of the ideas in the book could be useful for software developers.  It seemed like there are many parallels between the values demonstrated by the book's hero, Howard Roark, and good development practices.

Many of the ideas dovetail nicely with some Agile development principles, especially the various "keep it simple" ones like YAGNI and DRY (along with DRY's cousins,"once and only once", and "three strikes and refactor").  Roark's designs are driven entirely by purpose, function and constraints, with an open disdain for non-functional or ornamental additions.  For example, about the house he builds for Austen Heller, Roark says:

“Every piece of it is there because the house needs it – and for no other reason… You can see each stress, each support that meets it... But you’ve seen buildings with columns that support nothing, with purposeless cornices, with pilasters, moldings, false arches, false windows… Your house is made by its own needs. The others are made by the need to impress. The determining motive of your house is in the house. The determining motive of others is the audience.”

Keeping things simple and focused is hard work, just as agile development and YAGNI is not an excuse for sloppiness.  If done correctly, it should be quite the opposite.  In Roark's designs, “Not a line seemed superfluous, not a needed plane was missing. The structures were austere and simple, until one looked at them and realized what work, what complexity of method, what tension of thought had achieved the simplicity.” [emphasis added]

This made me think of the quote in Uncle Bob's Clean Code: "Learning to write clean code is hard work... You must sweat over it. You must practice it yourself, and watch yourself fail. You must watch others practice it and fail."

There were some other ideas I'm hoping to examine in more depth:
- right tool for the job - using technology idiomatically vs. legacy patterns with new technology
- the architect as a hands-on practitioner (vs. ivory tower)
- leveraging innovations - new methods, technologies etc.
- professional satisfaction / motivation
- interactions with business stakeholders, "people skills" and organizational politics
- making best of bad situations - looking for best possible solution even if you don't agree with the business problem to be solved
Read More

Primefaces global AJAX events

You can use jQuery global AJAX events with PrimeFaces to refactor behaviors that appear on multiple components.  A good example is if you have a data grid with multiple p:commandLinks and other controls that execute different methods and re-render the grid, and need to run the same onComplete in all of them.

For example, if you start with something like this:

<h:panelGroup id="grid">...</h:panelGroup>
<p:commandLink update="grid" actionListener="#{bean.update1}" onComplete="updateGrid()"/>
<p:commandLink update="grid" actionListener="#{bean.update2}" onComplete="updateGrid()"/>
<p:commandLink update="grid" actionListener="#{bean.update3}" onComplete="updateGrid()"/>

You could pull the updateGrid() statement out into an AJAX listener like this

jQuery(document).ajaxComplete(function(e, xhr, opts) {
  $response = jQuery(xhr.responseXML);
  if ($response.find("div[id$='grid']").length > 0) {
     updateGrid();
  }
});
By using ajaxComplete and parsing the XHR response object, you can see which DIV was going to be impacted by the partial update.  That way, if you had some other AJAX controls (say, an autocompleter) that you didn't want to trigger the updateGrid() function, you could filter that out.  Another option would be to set global=false on the specific Primefaces components that you don't want to fire the global jQuery ajaxComplete event.  The Primefaces autocompleter doesn't support this in Primefaces 2.x but does in 3.0.  

      


      Read More
    

  
    


      
Primefaces p:ajax and jQuery AJAX events


      

        All of Primefaces' JSF components use the jQuery AJAX engine, which means you can catch global AJAX events with $(document).ajaxStart and $(document).ajaxStop.

Standard JSF components like h:selectOneMenu will also go through jQuery when using a p:ajax facet (vs. standard f:ajax).

Conversely, jsf.ajax.onEvent does not appear to work with Primefaces components as it does for f:ajax.  

See also:
http://stackoverflow.com/questions/6166352/fajax-and-jquerys-document-ajaxstart-dont-work-together

      


      Read More
    

  
    
  
    


      
Serialization, class hierarchy and preserving sessions


      

        If you have a class that implements Serializable, superclass fields do NOT get serialized unless the parent class also explicitly implements Serializable.  That bit me the other day with session-scoped objects and preserving sessions across restarts, using Glassfish 3.1.1.    Glassfish will complain if any objects in session scope or their properties don't implement serializable, but if those objects extend some parent class, the parent class fields are silently ignored and end up being null on session restore.  So the source of the problem wasn't immediately clear, like it would have been if individual session objects or properties within them weren't serializable.
      


      Read More
    

  
    


      
Quick and dirty SSO with LTPA


      

        
If you have WebSphere application server in your environment, it is in fact possible to decode the “LtpaToken” cookie in code for quick-and-dirty SSO with non-WebSphere apps.



      


      Read More
    

  
    


      
Quick and dirty SSO with LTPA


      

        If you have WebSphere application server in your environment, it is in fact possible to decode the "LtpaToken" cookie in code for quick-and-dirty SSO with non-WebSphere apps.

The main reason you might want to do this is if you have a portal-like application on WebSphere and want to link to other applications on different non-WebSphere servers.  This is only useful if WebSphere is your main point of entry.

Here's how you do it:

  • Export the LTPA encryption key to a file from WebSphere using the admin console.  You provide a passphrase and a filename.  
  • Find the "com.ibm.websphere.ltpa.3DESKey" value in the exported file.  This is the encrypted key.
  • Base64 decode the above key and decrypt with 3DES, using the passphrase provided.  The decrypted value is the actual key for decrypting LTPA tokens.
  • Take the "LtpaToken" cookie, base64 decode it, and decrypt it with the key.  The legacy LtpaToken cookie (which you can get with "interoperability mode") is encrypted with 3DES; the newer LtpaToken2 cookie uses AES.
  • Convert to String and parse.  The string looks like "values%expiration%signature" where the expiration is a standard UNIX timestamp, which you should use to ensure the token is still valid; and the values somewhere will contain the user DN (e.g., uid=user,ou=company,dc=com).
The Alfresco codebase contains a good example of how to do this in Java
http://svn.alfresco.com/repos/alfresco-open-mirror/alfresco/HEAD/root/modules/quickr/source/java/org/alfresco/repo/lotus/ws/impl/auth/LtpaAuthenticator.java

Relevant fragments of code:

    private static final String AES_DECRIPTING_ALGORITHM = "AES/CBC/PKCS5Padding";
   private static final String DES_DECRIPTING_ALGORITHM = "DESede/ECB/PKCS5Padding";

    private byte[] getSecretKey(String ltpa3DESKey, String ltpaPassword) throws Exception
    {
        MessageDigest md = MessageDigest.getInstance("SHA");
        
        md.update(ltpaPassword.getBytes());
        
        byte[] hash3DES = new byte[24];
        
        System.arraycopy(md.digest(), 0, hash3DES, 0, 20);
        
        Arrays.fill(hash3DES, 20, 24, (byte) 0);
        
        final Cipher cipher = Cipher.getInstance(DES_DECRIPTING_ALGORITHM);
        
        final KeySpec keySpec = new DESedeKeySpec(hash3DES);
        
        final Key secretKey = SecretKeyFactory.getInstance("DESede").generateSecret(keySpec);

        cipher.init(Cipher.DECRYPT_MODE, secretKey);
        
        byte[] secret = cipher.doFinal(Base64.decodeBase64(ltpa3DESKey.getBytes()));
        
        return secret;
    }
    
    private byte[] decrypt(byte[] token, byte[] key, String algorithm) throws Exception
    {
        SecretKey sKey = null;

        if (algorithm.indexOf("AES") != -1)
        {
            sKey = new SecretKeySpec(key, 0, 16, "AES");
        }
        else
        {
            DESedeKeySpec kSpec = new DESedeKeySpec(key);
            SecretKeyFactory kFact = SecretKeyFactory.getInstance("DESede");
            sKey = kFact.generateSecret(kSpec);
        }
        Cipher cipher = Cipher.getInstance(algorithm);

        if (algorithm.indexOf("ECB") == -1)
        {
            if (algorithm.indexOf("AES") != -1)
            {
                IvParameterSpec ivs16 = generateIvParameterSpec(key, 16);
                cipher.init(Cipher.DECRYPT_MODE, sKey, ivs16);
            }
            else
            {
                IvParameterSpec ivs8 = generateIvParameterSpec(key, 8);
                cipher.init(Cipher.DECRYPT_MODE, sKey, ivs8);
            }
        }
        else
        {
            cipher.init(Cipher.DECRYPT_MODE, sKey);
        }
        return cipher.doFinal(token);
    }
    
    private IvParameterSpec generateIvParameterSpec(byte key[], int size)
    {
        byte[] row = new byte[size];
        
        for (int i = 0; i < size; i++)
        {
            row[i] = key[i];
        }
        
        return new IvParameterSpec(row);
    }
// How to use it:
byte[] secretKey = getSecretKey(ltpa3DESKey, ltpaPassword);
byte[] ltpaTokenBytes = Base64.decodeBase64(ltpaToken.getBytes());
String token = new String(decrypt(ltpaTokenBytes, secretKey, DES_DECRIPTING_ALGORITHM));
// or
String token = new String(decrypt(ltpaTokenBytes, secretKey, AES_DECRIPTING_ALGORITHM));

      


      Read More
    

  
    


      
Bizarre Glassfish JSF/EL performance issue


      

        I found a performance issue with JSF on Glassfish 3.1.1 (and prior) in an unexpected place: a seemingly innocuous line of code like

<h:outputText rendered="#{request.requestURL.indexOf('page') ne -1}" .... />

It turns out that invoking methods through EL expressions (new in EL 2.2) triggers creating a new ExpressionFactory, which in turn calls findResource/getResourceAsStream - a file I/O operation. 

These expressions in the "rendered" attribute are particularly bad because they get executed multiple times in various parts of the JSF lifecycle. 

See:
http://java.net/jira/browse/JAVASERVERFACES-2223
http://java.net/jira/browse/UEL-19

On the plus side - jvisualvm totally rocks.  I am shocked by how easy it was to get started with for tracking down these issues and it was right there in $JAVA_HOME/bin all along.
      


      Read More
    

  
    


      
Infinite loop in Glassfish exception logging


      

        When Glassfish catches a ServletException, it calls getRootCause recursively on each successive unwrapped, nested exception by reflection.  This is fine for wrapped ServletException and JspException, which have well-defined semantics for this method, but creates a big problem if you have an application-defined exception that happens to use the same "getRootCause" name with different semantics. 

So I created a Glassfish bug report:
http://java.net/jira/browse/GLASSFISH-17390

Related original bug in Tomcat, since fixed:
https://issues.apache.org/bugzilla/show_bug.cgi?id=39088
      


      Read More
    

  
    


      
Connecting Microstrategy 8


      

        
Connecting MicroStrategy 8.x Web SDK to a MicroStrategy 9.x Intelligence Server (iServer) doesn't work.  That in itself isn't a surprise.  What is surprising, though, is that the failure persists and then prevents the 8.x Web SDK from working with an 8.x iServer like it's supposed to on subsequent connections, resulting in an error "The required encryption level is not supported in this release."

Apparently, this is a result of initializing "static" fields on the first session creation, such that those values get stuck for the lifetime of the classloader.  In this case, the connection to 9.x sets some of these values in ways that are incompatible with 8.x.  If the first session creation is to an 8.x iServer, then there's no problem - attempting to connect to 9.x will break but won't prevent subsequent connections to 8.x.

This is an unusual edge case, to be sure.  I only encountered it during development in a heterogeneous environment, with a custom portal that connects to multiple iServers. 

      


      Read More