Nathaniel Stoddard

Rahul,

Thanks for the reply. I hadn't thought about it that way. I suppose the web container could remember whether there was any HttpSessionListeners so it could just delete the passivated HttpSession immediately (from a database for example), if possible. It probably wouldn't want to go to all the trouble of activating every single passivated HttpSession just so it could finalize it without any listeners being called.

It's a bummer the servlet spec doesn't have those nice lifecycle charts for a HttpSession like the EJB spec has for all its beans.

I couldn't figure this out by reading the spec. What happens when a session is passivated by the server (for memory usage for example), and later is invalidated by the session-timeout configured in the web.xml? Will the session be activiated and then the sessionDestroyed method of HttpSessionListener called, or will the session just quietly be killed?

EJBs are quietly destroyed when passivated, so I thought it might be the same with HttpSessions, but I couldn't find anything conclusive. Anybody have an insight into this?

When you have a literal number in your source code, it's an int. You can see below how to have a literal long.
int a = 12; long b = 12L;

Here's the kicker: while polymorphism (overriding methods) is done during runtime, overloading is done at compile time. Therefore, whatever your variable is typed as will determine which method is run. Since your literal is an int, it calls the int-overloaded method. You can cast it as a long if you'd like to get the long-overloaded method.

This is best illustrated when you have a null value, but want to invoke a specifically-overloaded method. (Which isn't really the best design-wise, but oh well.)
import java.util.Date; public class Test { public static void main(String[] args) { invoke(null); } private static void invoke(String v) { System.out.println("String"); } private static void invoke(Date v) { System.out.println("Date"); } }

You should get a compile-time error saying the call to invoke is ambiguous. There's no type associated with a null value, so it doesn't know which method to call (a static, compile-time problem).

Fix this by casting the null value to either String or Date.
import java.util.Date; public class Test { public static void main(String[] args) { invoke((String) null); } private static void invoke(String v) { System.out.println("String"); } private static void invoke(Date v) { System.out.println("Date"); } }

Interfaces are abstract, so while adding the "abstract" keyword to the definition is redundant it's still correct. As you mentioned, constructors can't be overridden, so using the "abstract" keyword on a constructor definition isn't just redundant, it's just plain incorrect, ergo the compile-time error.

Well, you definitely can nest enums. But, I don't think you can do what you want. You can mess around with your enum definitions to pass in an enum class (that has the states you're interested in). But at that point, it's a runtime issue and I don't think there's any way you can reference them statically in your code. (You'd have to resort to methods to get at the states you're interested in.)

The "type" attribute is used in a variety of scenarios ... such as mapping custom data types you've created. Also, some times can be mapped to many different SQL types (consider java.util.Date being mapped to either "date" or "timestamp"). Etc ....

ejbLoad should be called on each BMP at the start of the transaction, which allows each bean to load in the "current" data. Your only problem would be when the transactions overlap. In that case you'd have to change the isolation level of the connection so that it will lock the rows you're interested in until the completion of the transaction (at which point the second BMP would proceed as usual).

I guess this question goes out to the folks in here lucky enough to be working for themselves .... but when it comes to accepting contracts described as "corp to corp", do people differentiate between an actual corporation and an LLC?

There's certainly nothing to prevent you from adding a field to the list of attributes for the aggregation. I think the reason most people don't do it is because it would duplicate other information on the diagram--mainly, the actual association itself.

I recently had the opportunity to write a short article on the new generics feature in JDK 1.5. I figured it might be helpful for some greenhorns around the ranch. So ... if you're still trying to figure generics out or just plain curious, feel free to check it out.

Bartender: I wasn't quite sure where to put this, so feel free to move it if this is in the wrong place.

The url is here.

You probably need to put the java bin directory in your PATH.

I would recommend you take a long, slow stroll through the J2EE tutorial.

If the session bean method is enlisted in the same transaction as the client's then you can just get a reference to the UserTransaction and roll it back yourself. I'm not familiar with the possibility of passing around the SessionContext so anybody can roll back it's transaction. It probably violates some container rules. If you want a client to have control over the session's transaction, make it part of the same transaction and have the client use the UserTransaction. That's what it's there for.

The MDB option would give you more control over the resources used. Having a trigger would may just bog down the database server.

It's been a while since I've done XDoclet stuff, but I'm thinking those asterisks in the middle of your quoted query string aren't good. Try removing them since they might be screwing up XDoclet. You might want to check out what XDoclet is actually generating and see if your query is making it into the deployment descriptor.