Just wondering….

Yahoo website performance tips

The master list is here.

But just in case it goes away here is the list (pruned for java 6):

Performance Options

Debugging Options

type parameters of T cannot be determined; no unique maximal instance exists for type variable T with upper bounds T,java.lang.Object

In java 1.6u2 running in maven 2.0.7, we started getting this message but in eclipse 3.3.0 we were not. (and in idea we also were failing)

First, what the hell does this message means? Second, why can eclipse handle the issue and not the regular jdk?

Anyhow the problem was caused by this (our example was a little more complex than this):



public <T> T getFoo() {
T result;
result = getBar();
return result;
}

public <T> T getBar() {
return (T) map.get(”bar”);
}

The workaround is casting the line:



result = getBar();

to:



result = (T)getBar();

So I struggled for hours trying to get apache to connect via the ajp13 worker to tomcat 5.5 We are using a Debian box on the production server. Could not make it happen…. until I set the worker to be ‘ajp13′.

Don’t understand what wierdness is going on but… I do know this. if my /etc/libapache-mod-jk/workers.properties file looks like this (comments removed):

workers.tomcat_home=/usr/share/tomcat5.5
workers.java_home=/usr/local/java
worker.list=ajp13
worker.ajp13.port=8009
worker.ajp13.host=localhost
worker.ajp13.type=ajp13
worker.ajp13.lbfactor=1
worker.loadbalancer.type=lb
worker.loadbalancer.balanced_workers=ajp13

Apache 2 talks very nicely with Tomcat 5.5.20

If it looks like this:

workers.tomcat_home=/usr/share/tomcat5.5
workers.java_home=/usr/local/java
worker.list=amplafi_ajp13
worker.amplafi_ajp13.port=8009
worker.amplafi_ajp13.host=localhost
worker.amplafi_ajp13.type=ajp13
worker.amplafi_ajp13.lbfactor=1
worker.loadbalancer.type=lb
worker.loadbalancer.balanced_workers=amplafi_ajp13

Everything is broken!

Does anyone have a clue here on why?

I don’t know either! But fortunately I found this great post.

So I just had an interesting realization, Hibernate uses various default listeners in it’s poorly documented event system to do all of its persistence work.

For example, saving an object through a Hibernate Session object quickly goes to the Session.fireSaveOrUpdate, which by default calls DefaultSaveOrUpdateEventListener. DefaultSaveOrUpdateEventListener does all the heavy lifting of checking to see if the object legal to save prior to actually saving the object.

These default listeners also invoke interceptors as briefly described in section 12.1 of the 3.2.0.cr4 manual.

This means that if someone starts adding event listeners of their own, they better make damn sure that they add in Hibernate’s as well. Otherwise Hibernate will very quietly do nothing!

I filed this bug in the hopes that the documentation would get changed:

Please add this (or equivalent) to the bottom of section 12.1. (Interceptors):

===========================================
Interceptors are invoked by Hibernate’s default event listeners. For example, interceptors’ onSave() method is invoked by Hibernate’s DefaultSaveOrUpdateEventListener
===========================================

Please add this (or equivalent) to the bottom of section 12.2 (Event System):

===========================================
When changing the event listeners be sure to keep the various Hibernate default listeners. These listeners actually perform much of Hibernate’s persistence work, including invocation of the interceptors. Without those default listeners, Hibernate will quietly do nothing.
===========================================

I am now implementing my persistence layer with a vengence. I decided to take a chance with using the hibernate-annotation to define my persistence objects because of all the work with Seam and Trails that is happening to leverage those annotations.

Unfortunately, I got to experience the joys of being a trailblazer with CR code as opposed to released code. These are some of the issues I ran into with the hibernate-annotation 3.2.cr1 release:

The biggest problem so far is with compound primary keys. (keys that are composed of multiple fields). I wanted to create a @Entity class that had a compound field that was partially generated using the @GenerateValue flag and partially supplied with an application-defined value.

These are the problems I ran into:

1. If you have a @Entity that has two or more fields annotated with @Id *and* @IdClass is not used,  then only the first one is respected. So the primary key is only the first field. However, all such fields are labeled as requiring a value (as if @NotNull specified). I filed this report about this problem.
2. If using you do use @IdClass then the @Ids are respected with regards to the primary key definition. However, @GenerateValue is ignored when placed on @Embeddable’s (supplied in the @IdClass) fields. This makes sense for a bunch of reasons. The best one being that the @Embeddable may be used by multiple @Entity classes. Unfortunately, @GenerateValue is also ignored when placed on the @Entity class’s id fields.
3. Using @EmbeddedId doesn’t have any mechanism for specifying a @GeneratedValue. And once again, @GenerateValue is ignored when placed on the @Embeddable class’ fields.
4. When using @EmbeddedId, if @Id is used on the @Embeddable class’ fields this causes an error message that is completely wrong. 3.2.0.cr1 reports that the @Embeddable doesn’t have id fields. The problem is solved by removing the @Id’s, not by using them. I filed this report.

Now that I am passed these issues, I still don’t know how to create a compound key with part of it generated. So I posted this on the hibernate forums.

I discovered this neat feature of maven2 that allows a project to specify the minimum version of a dependency but accept any higher version. This allows project writers to not have to hard-coded version dependencies to other projects.

This allows users of those projects to use newer versions of the project’s dependencies automatically. For example, “transparent-politics” depends on “tapestry” which depends on “commons-httpclient”.

If tapestry’s pom.xml specifies its commons-httpclient dependency as:

<dependency>
  <groupId>commons-httpclient</groupid>
  <artifactId>commons-httpclient</artifactId>
  <version>[3.1-alpha1,)</version>
</dependency>

Then when a newer version of commons-httpclient comes out, say 3.1-alpha1, the transparent-politics build will pick that up automatically.

If you get the following error when starting Tomcat in debug mode:

FATAL ERROR in native method: No transports initialized
Transport dt_socket failed to initialize, rc = 509.

The solution is to copy dt_socket.dll from $JDK14ROOT/jre/bin to $JDK14ROOT/bin. This seems to be fixed in J2SE 5.