Thanks to the Atlanta Java Users Group for the opportunity to present at the first annual AJUG DevCon. I thought that it was a good program – good value for money. Where else can you get a day full of solid technical content and interaction with other developers plus 2 meals for $50?

My slides and example code are available here. From the glance I got at the evaluations, it seemed that many people enjoyed the presentation, and many people found it to be too low level. If you have any other comments on how I can deliver a better presentation, I welcome them – my email address is in the presentation slides, or you can just post comments here.

An early draft of the slides and code for my presentation at tomorrow’s AJUG Java DevCon 2004 are posted here. The presentation and code are a bit further along, but I want to solicit feedback on this earlier version to see what you think, and so that people will actually attend tomorrow.

The focus of the presentation is on the components of J2EE application security that help manage user authentication and authorization, but are often overlooked. In keeping with my tendencies, the focus of the presentation is on the practical, meat-and-potatoes functionality that can be used in every day applications, not on exotic and esoteric themes that you may use some day in the distant future. Post your thoughts and feedback here – I’ll be glad to consider them for inclusion in the final presentation. What’s missing? What’s unclear? What could use additional illustration?

We recently experienced regular java.lang.OutOfMemoryError exceptions on HP/UX any time our J2EE application came under significant load. We have since determined that it is due to a native issue with threading.

The HP/UX kernel has a parameter named max_thread_proc, which sets the maximum number of threads that a process can have. Apparently the default is 64. Considering that JBoss starts up with almost 60 threads when it’s doing nothing, this cap of 64 is quite low.

There are 2 options to fix the problem. One is to pass the -green parameter to the JVM when you start your app server. This causes the JVM to use its own green threading model rather than that of the operating system. The advantage of this approach is that it can be tested and implemented quickly. The disadvantage is that Java’s green threading model isn’t as sophisticated as the native threading model of the underlying operating system (Sun has said as much), so you may pay a performance penalty for this.

The other option is to recompile the HP/UX kernel with a higher max_thread_proc value. We set it to 3000, just to be safe, although we haven’t exceeded 250 yet. The biggest disadvantage to this is that you have to recompile the kernel. The other disadvantage is that you haven’t completely avoided the problem, you’ve only moved the threshold at which it will occur. The advantage is that you get the performance, monitoring, and tuning of using the native thread model.

I don’t think that Linux users need to worry. I believe that Linux’s threading model is native green threading. Note that this is still different from the JVM’s green threading, so -green should still not be used in this case either – Linux will handle it for you.

The AJUG sponsored Atlanta Java DevCon (http://www.ajug.org/devcon2004/) has released a tentative schedule (but not posted it on the web). The $50 registration fee gets you breakfast and lunch in a day that runs from 8 am to 6 pm. My talk on J2EE security is scheduled for 1:15 pm, just after lunch, and runs for an hour and a half. It’s been smartly positioned opposite a talk on Swing & JGoodies – good call. I’m covering a J2EE topic opposite a J2SE topic. Something for everyone.

I’m also looking forward to Jason Chambers’ case-study style session on large web apps (is Delta.com big enough for you?) and Neal Ford’s talk on Open Source MVC Frameworks. I’ve entrenched myself in Struts not because I know it’s the best, but because it’s the de facto standard. This talk will give me a jump start getting into Tapestry and WebWork (Cocoon just seems like overkill).

“Not Possible” I was told, due to limitations of XDoclet. It is possible, but only really worthwhile under certain circumstances. Start with the understanding that if you’re going to use a composite key, you need to wrap it in a composite identifier class that is serializable and overrides hashcode() and equals().

Most people would tell you to solve the problem by introducing an artificial key rather than mapping a composite primary key. While this is, indeed, ideal, one of the premises of O/R mapping is that you, as a developer, often have little control over the database structure.

In situations where a composite key appears just once, I would encourage you to use XDoclet to generate the initial mapping (specifying an @hibernate.id for the identifier class property) and fill in the blanks, using a hand-coded mapping file for those classes.

If, however, you have a composite id class that is repeatedly used in multiple classes throughout the application, there is a way to generate the mapping properly, albeit a bit ugly. Suppose you have a composite Id class, com.acme.data.SkuLineId, with 2 attributes, salesObjectId and sku. Your persistent class would have an attribute of type SkuLineId, possibly named skuLineId.

By specifying a blank @hibernate.id tag for this attribute’s getter in each persistent class that uses the id, you can use the following addition to your Ant script to update the generated mappings with the correct code (all &, &lt, etc. must be copied verbatim – they aren’t typos):

<replaceregexp match=”&lt;composite-id\s*name=&quot;skuLineId&quot;\s*class=&quot;com.acme.data.SkuLineId"\s*>\s*&lt;/composite-id>”
replace=”&lt;composite-id name=&quot;skuLineId&quot; class=&quot;com.acme.data.SkuLineId&quot;> &lt;key-property name=&quot;salesObjectId&quot; column=&quot;sls_obj_id&quot; type=&quot;java.lang.Long&quot;/> &lt;key-property name=&quot;sku&quot; column=&quot;sku&quot; type=&quot;java.lang.String&quot;/>
&lt;/composite-id>”>
<fileset dir=”${build.classes.dir}”>
<include name=”**/*.hbm.xml”/>
</fileset>
</replaceregexp>

What this code does is search for all hibernate mappings containing a composite id attribute names skuLineId, of type SkuLineId, that doesn’t have any of its details declared, and replaces it with the full mapping. The assumptions are:

• You have used the same composite id in mutliple classes
• That composite id has the same field name in each class
• The columns for each part of the id must be the same for all tables

So this solves the problem for a very limited subset of possible problems, and it is a bit of a hack solution, but it does the job. For other situations, while it would be nice to have other ways to use XDoclet to generate these mappings, I’ve looked extensively and can’t find it. This seems to be the only situation where using XDoclet makes much sense. Even then, it reveals a case where the tools just don’t meet the need. Perhaps JSR175 metadata can bail us out of this mess.

Statler and Waldorf are the 2 old guys on the balcony from The Muppet Show. You know, the ones that did nothing but rag on the show from on high, saying things like:

Statler: What would you do if you were a rich man?
Waldorf: I’d buy the network and cancel this show!

and

Statler: And there you go, there’s nothing like good comedy.
Waldorf: Nothing like it on this show!

Some of the recent round of blogging from The Server Side Symposium reminds me of those guys in some ways – sitting out in the weblog balcony making wisecracks for the web audience to read. Some commentary is even-handed, praising good sessions, and blasting the bad ones. Others seem to hold ambivalence as the highest compliment they’re willing to pay, and they are the Statlers and Waldorfs. Though few remember those old Muppets’ names, their commentary on the show is one of the things people seem to remember most about the Muppet Show, and with a smile. Similarly, the philosophy of blasting everything has an interesting place in the Java community. Certainly, such personalities are memorable, and bring humor to the community, but is there anything useful beyond the humor in it all?

G.K. Chesterton wrote, “But the new rebel is a Sceptic, and will not entirely trust anything. He has no loyalty; therefore he can never be really a revolutionist. And the fact that he doubts everything really gets in his way when he wants to denounce anything. In short, the modern revolutionist, being an infinite sceptic, is always engaged in undermining his own mines. Therefore the modern man in revolt has become practically useless for all purposes of revolt. By rebelling against everything he has lost his right to rebel against anything.”

This too carries with it a measure of truth. My transient conclusion is that there is a strange value in such viewpoints, in humor and memory, but that it doesn’t really add much to the community or profession. Sounds a lot like a jester (or perhaps a joker?).

The recent vote on the JDO 2.0 JSR reveals the unseemly underbelly of Enterprise Java. That ugly truth is that the commercial wing of Java is willing to try to derail perfectly viable technologies in order to meet the needs of themselves rather than the community. The simple truth of JDO is that developers want a standardized way to abstract their persistence that doesn’t require an EJB container. The single most important aspect of the specification is the standardization of the interface to relational databases. Nearly all JDO implementations already support this functionality in a non-standard way. It’s what developers want to use JDO for. Why not standardize it. Let’s look at the offenders:

• Oracle – claims it overlaps with JDO 3.0. In addition to having an app server, Oracle also owns the TopLink technology. It’s clear that this spec steps on their toes twice over. Once in driving developers away from their app server, and again in commoditizing TopLink-like functionality.
• BEA Systems – It’s obvious here. If developers don’t need an EJB container to manage persistence, they don’t need to pay $15k per CPU licensing fees to BEA. They can develop freestanding applications, or use Tomcat to achieve the same results.
• IBM – Same as BEA. IBM has nothing to gain and plenty to lose with this JSR.

The key flaw in these arguments, as highlighted by Sun, is that if JDO did not exist, the overlap with EJB 3.0 might matter. The fact is that JDO does exist, and gaping holes in the specification have led vendors to fill in the blanks with non-standard solutions. JDO must either receive these enhancements or wither on the vine. If these details can not be standardized, developers are just as well-served using a non-JDO persistence solution such as Hibernate or OJB, because unless they’re using an object database, the JDO standard buys them nothing but limitations.