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.

solved windows 7 sleep problem

Sleep mode was grayed out on new Dell laptop (Latitude E6420) on Windows 7.

The fix was to disable the legacy VGA driver, which came up with a yellow warning icon in Device Manager ("device cannot start").

Simply installing the latest Intel Graphics drivers did not fix the issue - the legacy VGA driver had to be explicitly disabled.

502 Proxy Error solved

I was getting mysterious, intermittent proxy errors using Apache mod_proxy to talk to an older version of Glassfish (2.x). It turned out the root cause was size of HTTP headers as cookies were accumulating, which caused the underlying app server to close the socket without a response.

A similar phenomenon was documented here:
http://kenai.com/jira/browse/KENAI-2727

The fix was trivial: increase the "receive-buffer-in-bytes" setting in domain.xml to 8192 bytes.

Finding it was a pain, because the older version of Glassfish had a bug such that the underlying IOException that aborted the request never got logged anywhere!
http://java.net/jira/browse/GLASSFISH-5181

JSF + JPA without EJB or Spring

I've had success using JSF 2.0 with JPA on Glassfish 3.0.1, without using Spring or EJB for managing middle-tier services or DAOs. (I actually do like Spring - the goal in this case was to minimize dependencies, moving parts and learning curve, rather than to avoid any particular technology.)

A similar approach was detailed here:
http://www.swview.org/blog/best-way-use-jpa-web-tier

 Using only the JSF @ManagedBean and @ManagedProperty annotations, along with the JPA @PersistenceContext, you can refactor business services or DAOs into other JSF managed beans that are injected into the one exposed directly to the UI. What this looks like in practice:

 orders.xhtml:

OrderBean.java:

@ManagedBean
public class OrderBean {
  @ManagedProperty(value="#{orderDao}")
  private OrderDao orderDao;
  private List orders;
   
  @PostConstruct
  public void init() { 
    this.orders = orderDao.getOrders();
  } 
  public List getOrders() { 
    return orders;
  }
}

OrderDao.java:

@ManagedBean
@ApplicationScoped
public class OrderDao {
   @PersistenceContext(...)
   private EntityManager em;
   
   public List<Order> getOrders() { 
     return em.findAll(Order.class);
   }
}

In this example, the DAO (OrderDao) is just another JSF managed bean, but not actually referenced directly from a page, only from another managed bean. This approach lets you isolate the logic tied to EntityManagers from the rest of your "normal" JSF managed beans, and makes it (marginally) easier to unit-test your managed beans because you can mock the DAO at a higher level instead of mocking the entity manager.

 This does NOT buy you declarative transactions or any of the other good stuff you get with Spring or EJB. (You can inject a UserTransaction with @Resource, and call it explicitly, though.) So it works best for simple apps with mostly read operations and basic single-object CRUD transactions.

 Also, with Java EE 6 CDI, all this may become moot because @Named and @Inject annotations effectively blur the line between all the different managed bean flavors (EJB, JSF, Spring/POJO), although I haven't found a good way to replace JSF @ViewScoped without buying into Seam.

WebSphere "invalid Oracle URL specified" error

Another unhelpful WebSphere error, this time with an assist from Oracle.

This happened to me when I configured my JDBC data source with the default wpdbJDBC_oracle JDBC provider, using the XA datasource (OracleXADataSource), and used the "container managed" J2C authentication alias instead of "component managed".  The WebSphere admin console will successfully test the connection, but when you use it in a web application, it will fail with this "Invalid Oracle URL specified" error.  It was so hard to track down because it made me focus on the JDBC URL, which wasn't ever the problem.  It never occurred to me that the admin console and the web applications would somehow be getting connections and signing into Oracle differently, which tricked me into thinking that my configuration was really ok when it wasn't.

For the record, the web application was just doing a straight JNDI datasource lookup without any resource-ref mapping in web.xml, using the same JNDI name as bound in the server.

Also, changing to a different non-XA JDBC provider using plain OracleConnectionPoolDataSource resulted in "invalid username/password".

When I changed the datasource to use the component-managed alias instead, and restarted, everything worked.