An Open Source encounter

I really like Open Source software. I use it a lot: Linux, apache, postfix, amavis-new, clamav, openSSL, openLDAP, PostgreSQL, PHP are just a few of the OSS products I have on my servers.

When developing JAVA, I use Eclipse, Ant, JUnit and heck even Java 🙂

OSS is actually very important for be, being a Freelance I/T consultant, it allows me to play with features, technologies and implementations, in an effective manner, without having to pay a lot in license fees!

I’m not a big committer. Not that I don’t want to, but usually when I hit a bug or a poorly implemented feature, I either accept it or code around it.

Only 3 times since I started using OSS for the first time in about 2002 have I been in a situation where I had something to contribute with:

  1. Some missing Locale handling in Struts. I was just about to submit a patch when I discovered someone else had done just that a few days before.
  2. A bug in Stripes – also related to Locales – rendering some of the features useless if the Locale does not contain a valid country code. This was somewhat accepted by Tim Fennel and made it into version 1.4.
  3. A serious performance problem in Hibernates WebSphere transaction adaptor. This I fixed and submitted as a patch and then the story being told here is about to begin.

Apart from that, I try to contribute with helpful comments when I see someone report a problem I’ve seen and possibly solved myself. At least to let the other users know there are others with the same problem.

Does it make me a bad person? I think not – I’m no more different than 99.99% of all other OSS users.

This blog entry (or article) is meant as a warning to anyone who considers making a contribution to a major open source product.

The conclusion

To start with the conclusion – here’s what I’ve learnt from trying to “do the right thing” and submit a patch to an OS project:

  1. Don’t expect to be treated with any respect at all, unless you are already a known committer – “one of the guys”.
  2. If you do commit anything, expect that you are to be considered the maintainer of the feature from that point on.
  3. Expect to have your name and personal email specified as author of source and comments that you have not written.
  4. Be aware that when you submit anything, the project owner can do with it as he pleases; even break the implementation, and still call the bug fixed…
  5. Be aware, that if you do not agree with the King of the project, he can call you anything he likes, telling that you are being spiteful and things that are worse.


Now, I was assigned to this interesting project. My first task was to rewrite the entire persistence layer from EJB 2.1 CMP to JPA. J2EE Application server was WebSphere version 6.1 (WAS).

After an initial discussion, the lead architect and I decided we would go with the Hibernate-JPA implementation. I developed a small PoC that demonstrated we could persist some of the important business entities and that the JPA implementation could integrate with the WebSphere transaction manager. Everything looked good and we proceeded.

After about one week of “hard coding” I ran the first small test suite and was quite happy to realize the entire suite passed without a single error!

I showed it to the lead architect and he had one comment: “Yes, they all pass. But they are slow!”

The tests in the suite would normally run in 100-200ms each. With the Hibernate JPA implementation, they took about 1-2 seconds each to run! This was effectively a showstopper…

The lead architect and I sat down and discussed different options. But we really had no short-term solutions – we kind of had to use Hibernate-JPA or wait for IBM WebSphere to deliver a “real” JEE 5 compliant EJB container…

So I was allowed to spend some time trying to figure out why Hibernate-JPA was so slow and eventually come up with a fix.

Now, there were a lot of strange log messages in the server log. They all indicated the creation of an InitialContext with no properties. As if something is looked up in JNDI all the time. Looking at the log, I could see the messages were from a NamingHelper class. I added a stack trace to the logging in the NamingHelper, so I could see from where it was called: all except one originated from the WebSphereExtendedJTATransactionLookup class!

It showed that in the Hibernate core version 3.2.3, an initial context creation and a lookup of the WebSphere proprietary “extendedJTATransaction” object was done each time a TransactionAdapter was created, which in turn is done each time the getTransaction() method was called on the TransactionManagerAdapter…

This again amounts to 4 times during EntityManager creation, one for each non-trivial call into the EntityManager instance and one when the transaction is about to end – (5 + n) for each transaction, n being the number of non-trivial EM calls during the transaction.

This is the reason why it performed badly!


We had been looking into OpenJPA but had discarded it for a number of reasons. But as far as we knew, the IBM JPA feature pack for WAS is based on OpenJPA and there is an IBM developerWorks article describing how to use OpenJPA with WAS.

One of the authors of this article (Kevin Sutter, Senior Software Engineer, IBM) is also one of the authors of the WASManagedRuntime – the OpenJPA implementation similar to the Hibernate WebSphereExtendedJTATransactionLookup.

In the WASManagedRuntime, the WebSphere proprietary “extendedJTATransaction” object is only looked up once, during “configuration” and stored as an instance variable. As the WASManagedRuntime instance is a static in another class, it means the “extendedJTATransaction” object is effectively stored in a static!

I then hacked the Hibernate core version 3.2.3 of the WebSphereExtendedJTATransactionLookup implementation to only lookup the “extendedJTATransaction” object once and then store it in a static.

Now the test suite passed, the PoC was still working, and performance was equal to the EJB 2.1 CMP implementation!

The patch

Now, happy with myself, I decided that it would make sense to contribute to Hibernate core – I believed my patch would be helpful…

I read the instructions in READ THIS BEFORE USING JIRA. Trying to follow procedures, I searched the user forum and JIRA for anyone reporting a similar problem. I found one entry in the user forums Performance prob many JNDI-lookups to Websphere transaction and nothing directly related in JIRA.

Nobody had posted a reply to the entry in the user forum, so I decided to subscribe to the developer mailing list and discuss my patch there.

My message to the developer mailing list (Note: I had 2 points, only the first one is relevant here):


just trying to follow the guidelines in the section "READ THIS BEFORE 
USING JIRA!", I'm submitting minor changes to the classes 
WebSphereExtendedJTATransactionLookup and FromClause for anyone to 

1. We are using Hibernate JPA with WebSphere 6.1 and are experiencing 
serious bad performance. We are also seeing alot of "INFO 
org.hibernate.util.NamingHelper.JNDI InitialContext properties:{}" in 
the logs (as described in   

Our investigations shows that the logging statements come from 

Also, we can se that just creating an EntityManager from an 
EntitManagerFactory results in 4 times InitialContext creation and 4 
times lookup of the WAS specific 

A simple transaction results in 7-8 lookups !   

By looking at a similar implementation in OpenJPA's 
(openjpa-0.9.6-incubating) AutomaticManagedRuntime / 
WASManagedRuntime, it appears that OpenJPA only looks up the 
"extended transaction" object once, and stores it in a static.   

I've changed the WebSphereExtendedJTATransactionLookup so the 
innerclass TransactionAdapter ctor does the lookup and stores the 
extendedJTATransaction in a static in the 
WebSphereExtendedJTATransactionLookup class.   

This solves our performance problems.   

Now, the WebSphereExtendedJTATransactionLookup class is not heavily 
documented (...) so it is not obvious to us if this breaks something 

This started a nice and civilised conversation with Max Rydahl Andersen about the nature of the “extendedJTATransaction” object, and whether it was safe to store it in a global variable (a static).

We agreed that if the object was made instance of the WebSphereExtendedJTATransactionLookup class, that would ensure only one “extendedJTATransaction” object would be looked up for each EntityManagerFactory.

I changed my implementation, tested it and submitted it as a patch to Hibernate core 3.2.3 ( I demonstrated with excerpts from the logs that the patch did a tremendous difference.

Max commented kindly about me appending logs as comments and told me I should use attachments in the future, and had a comment that he would like to hear from Steve about the patch. Steve here is Mr. Steven Ebersole.

I was thrilled to experience that the patch was accepted and was targeted for inclusion in Hibernate core version 3.2.4.

This was April 19, 2007.

Almost 3 weeks later

On May 8, 2007 things start to change, fast.

Suddenly Mr. Ebersole decides the patch needs a rewrite before it can make it into the 3.2.4 version. Mr. Ebersole basically breaks the patch, reintroducing the performance problem. And he closes the patch as being “fixed”.

Via comments in JIRA I tried to tell Mr. Ebersole that his implementation reintroduced the performance problem; and I tried to tell him why I had chosen the original implementation (

Somehow this really pissed Mr. Ebersole off. I have no idea why – he only has some rather general ranting about WAS and tells me he prefers “correctness over performance”. Only if I can show him some resource stating my implementation is correct is he going to accept it. Somehow it is not enough for him that it is similar to the implementation in OpenJPA – or maybe Mr. Ebersole is just not paying attention.

And he asks me to take over maintenance! This I take as either sarcasm or him being bitter…

In my next comment (now I’m pissed) I tell Mr. Ebersole that I think his implementation sucks (it did), I demonstrate that I have actually tested it and prove that 4 initial context creates and lookups are still being performed when an EntityManager is being created.

Mr. Ebersoles sole reply is: “Ok, we’re done”.

The 3-day mail tirade

Now I start my email campaign: I write 3 different emails to 3 different IBM’ers that I think can help on the subject, I write Max to ask him if he knows what is going on. And I write the following to Mr. Ebersole:

Subject: Re: (HHH-2580) Performace: Too many lookups of WAS extended 
transaction support (Jesper Udby) 
From:    "Jesper Udby" 
Date:    Tue, May 8, 2007 16:17 
To:      "Steve Ebersole" <>
Excuuuse me,   

what did I do to piss You off this way ?   

I was actually trying to help...   

Maybe I should create a new issue regarding the problem that the Hibernate 
core implementation want's to create 4 seperate instances of the 
TransactionAdapter just creating an EntityManager (you _could_ take a look 
at the stacktraces I provided), then yet another one for each call into 
the EntityManager and then one when the transaction is about to end ?   

Seriously, that is something "somebody" should look into ?   

Just stating that You prefer "correcness over performance" is not the most 
wise statement, when You actually do not know what is correct - according 
to the not very well documented IBM proprietary API...   


Jesper Udby   

> [ 
> ... 
> ] 
> Steve Ebersole kommenteret på HHH-2580: 
> ------------------------------------- 
> Ok, we're done 

He did not take that lightly – here is his reply:

Subject: Re: (HHH-2580) Performace: Too many lookups of WAS extended 
transaction support (Jesper Udby) 
From:    "Steve Ebersole" <> 
Sender:  "Steve Ebersole" <> 
Date:    Tue, May 8, 2007 17:09 
To:      "Jesper Udby"
First, I have never used WAS.  I plan to never use WAS.  I think it is a 
piece of garbage.  And I hate that they make something difficult that is 
trivial in every other app server.  Then they claim that this is "to 
protect their customers" from themselves.  This is fucking bullshit, 
since they then turn around and expose the same exact functionality via 
proprietary APIs.  What they are trying to protect is their license 
revenue.  I am extremely happy that JEE5 makes this required 
functionality to be exposed for a compliant app server.  IBM will 
finally have to stop playing this silly, silly game they play.   

Second, calling someone else's work "crap" is not helping; its called 
being spiteful.  I don't help spiteful people.  This is not even 
anything I wrote, so trust me this is not personal protection and anger 
over "my code".  This has more to do with decency and respecting the 
fact that you are using people's work that they have let you use without 
even paying them a dime.   

Third, the change I made should limit the JNDI lookup to one per EM 
instance.  Have you even bothered trying it?   

Fourth, yes somebody should look into it.  You know who?  YOU!  You know 
why?  Because this is something called open source.  And this in 
particular is something in which you obviously have a vested interest. 
That is the whole idea behind open source.   

Fifth, don't lecture me about "wise things" to say.  Obviously doing a 
lookup each time is always going to give "correct" results.  Don't be 
silly; think about something before you speak it.

Now, I’m not allowed to say about his questionable implementation that it “sucks”, but he is allowed to call WAS garbage, using words like “fucking bullshit”, say ‘ve called someone else’s work “crap” (I didn’t), questions if I’ve tested his implementation (he obviously have not – I actually had) and he calls me spiteful.

My God, he must have a bad day! This answer is so filled with anger that I can hardly believe it! And I honestly was a little surprised he even bothered to answer. I had to try some Danish sarcasm on him, just to see if he was for real:

Subject: Re: (HHH-2580) Performace: Too many lookups of WAS extended 
transaction support (Jesper Udby) 
From:    "Jesper Udby" 
Date:    Tue, May 8, 2007 19:44 
To:      "Steve Ebersole" <>
Thanx for answering my mail.   

1. Some major customers seem to prefer IBM products for whatever reason. 
You may call it garbage b/c it is something some customers pay $$$ for ? 
For some of us this is just the reality we work in - and we have to live 
with it. But then again, I do earn good money working with this garbage... 
I can say I will never ever work with WAS or other garbage IBM products 
- and loose most of my customers...   

2. I don't remember calling someone else's work "crap". I said your 
implementation sucks. Sorry for that - I was only focusing on the 
implementation in the WebSphereExtendedJTATransactionLookup source 
file... (If you take a look at the ctor of the TransactionAdapter inner 
class, You will have to agree that the "null" checking of the instance 
variable and the "lazy instantiation" does look a bit strange, being in 
the ctor...)   

3. Yes, I tested the change... The (partial) stacktraces I added in the 
comment was meant as documentation of how many times the 
TransactionAdapter was instantiated - all within the same transaction. I 
did that by inserting a "new Exception().printStackTrace()" in the ctor 
just beneath the lookup... 
I was only focusing on the WebSphereExtendedJTATransactionLookup 
implementation. You mention you've made changes that limit the lookup to 
on per EM instance - then you must have changed other files as well. I 
will look into that tomorrow when I'm back at my customer.   

4. I did look into it some time ago. But, being paid by the hour by my 
customer, there are limits to how many hours I can spend trying to dig 
into the Hibernate core implementation. So I made a patch (my customer 
paid for that as well) and submitted it, hoping the performance problem 
would be solved in an upcoming release. 
I'm sorry, I work as a prostitute in JEE land. This is ok, but my spare 
time is rare, so I do not normally spend time digging into things unless 
it pays back (to me) somehow. Sorry for that.   

5. Doing (create initial context +) lookup each time you need something 
might always give "correct results" but is not necessarily the "correct" 
way to do it... Or am I completely wrong here ?   

And last: If you hate WAS and IBM so much (being a former IBM'er I don't 
actually fancy neither too much myself), why do you even care this much 
about the WebSphereExtendedJTATransactionLookup implementation ?? 
If the patch some stupid freelancer submits fixes a major performance 
problem, then why even bother bullying the poor guy this way ? 
Why change it to something else when you cannot even test your change ? 
Is this a good way to do software development ?   

Then again, thank you for working for free for me and all the other 
happy Hibernate users out there. 
And sorry for my English - it is not my native language. There might 
slip some unintentional bad language in.   


Jesper Udby

Not too bad? But I mean every single word of it! In my book it is generally good practice to cache stuff looked up in JNDI for as long as it makes sense…
Now, Mr. Ebersole didn’t resist this one either, and had the following angry reply – he just has to read my writing as Someone else reads the Bible:

Subject: Re: (HHH-2580) Performace: Too many lookups of WAS extended 
transaction support (Jesper Udby) 
From:    "Steve Ebersole" <> 
Sender:  "Steve Ebersole" <> 
Date:    Tue, May 8, 2007 20:28 
To:      "Jesper Udby"
> And last: If you hate WAS and IBM so much (being a former IBM'er I don't 
> actually fancy neither too much myself), why do you even care this much 
> about the WebSphereExtendedJTATransactionLookup implementation ?? 
> If the patch some stupid freelancer submits fixes a major performance 
> problem, then why even bother bullying the poor guy this way ? 
Whether or not I hate IBM has nothing to do with this issue.  Every so 
often someone comes along and requests a change to either 
WebSphereExtendedJTATransactionLookup or to 
WebSphereTransactionManagerLookup.  And the change "seems" reasonable; 
but we add it and it breaks someone else using Hibernate+WebSphere.  So 
I am done making ad-hoc changes to either of these classes until someone 
is willing to be accountable for integration with WebSphere (which is 
comprised of just these two classes).  Someone out there has a vested 
interest in having these two work together (as evidenced by your people 
"prefering" WAS) and willing to lend a hand.  Until then, I refuse to 
make any more of these changes.   

> Why change it to something else when you cannot even test your change ? 
> Is this a good way to do software development ? 
I can generalize that performing a contextual lookup *more often* will 
generally give correct results.  Again, don't be silly.  This and your 
previous comment about "wise statements" simply show that you are not 
thinking these questions through.  I'll give you the benefit of the 
doubt that you are not being spiteful.    

Also, you question me about good software development process; is a good 
process to leave integration development to someone who (a) does not 
know the product being integrated and (b) could not care less about the 
integrated product?   

BTW, you realize that this is a defined extension point of Hibernate, 
right?  If you don't like the provided implementation then supply your 
own, custom one.

Ok, he’s totally out of reach. But his last comment did give me a great idea. I repackaged my patch to fit the project structure and reconfigured the Hibernate solution to use my implementation. Tested it and agreed with the lead architect that this would do until IBM can provide a true JEE 5 compliant EJB container or perhaps a future switch to another application server vendor.

But, one thing bothered me: I didn’t knew the Danish word for spiteful, and Mr. Ebersole still indirectly implies that I am being spiteful… Looked it up and got very surprised! So, trying to help makes me SPITEFUL?!! Reading the past email conversation with Mr. Ebersole certainly makes him spiteful, in my optics.

In the meantime, I had a conversation with one of the 3 IBM’ers. He basically confirms that it is ok to cache the “extendedJTATransaction” instance, but he also tells me that I cannot quote him on this. Bugger – would have been a nice message to give…

I just had to try Mr. Ebersole again – but this time I was seriously pissed of, not trying to hide my sarcasm – and I try to give the message without quoting anyone in particular:

Subject: Re: (HHH-2580) Performace: Too many lookups of WAS extended 
transaction support (Jesper Udby) 
From:    "Jesper Udby" 
Date:    Wed, May 9, 2007 09:42 
To:      "Steve Ebersole" <> 
Cc:      "Max Rydahl Andersen"
Hello Steven. 
> BTW, you realize that this is a defined extension point of Hibernate, 
> right?  If you don't like the provided implementation then supply your 
> own, custom one. 
What a great idea - I've done just that and it works nicely. It does not 
improve the quality of the Hibernate core implementation, but what do I 
care: It is only a matter of time before I work in a JEE 5 compliant 


Now, I've taken the libery to look up the word "spiteful" in an English -> 
Danish dictionary and I'm kind of surprised that you call _me_ spiteful ?!   

I will try to repeat the sequence of events from my point of view, just 
trying to proove that I'm certainly not even trying to be spiteful. Please 
take the time to read the entire mail...   

* On a medium sized J2EE project, the persistence layer was converted from 
CMP EJB 2.1 to JPA. 
The Hibernate implemetation was chosen because it seemed to be the most 
mature implementation and could integrate with WAS' CMT...   

* Running the first few testcases showed serious performance problems: 
simple transactions normally in the 100-200ms range now took 1-2s with the 
Hibernate JPA implementation. 
This is basically a showstopper for the project.   

* I searched the Hibernate user forums and JIRA for anyone with similar 
problems and found one post:   

* Noone had answered the post and no bugs was reported so we decided to 
look at other persistence providers. OpenJPA was chosen as a candidate, as 
IBM's "EJB3 feature pack" for WAS is based on OpenJPA.   

* For a number of reasons, OpenJPA (or the feature pack) was not a 
possible short-term solution.   

* I was allowed - by the project lead architect - to spend some time 
trying to figure out if we could fix Hibernate in some way.   

* I found the performance problems was related to the (5+n)/tx lookups of 
the WAS' extended JTA support instance for each EM created in the tx - n 
being the number of non-trivial EM method calls in the tx. 
In the similar OpenJPA implementation (WASManagedRuntime), the extended 
JTA support instance is basically look'ed up once and stored in the 
WASManagedRuntime. As the WASManagedRuntime instance again is a static in 
another class, this is effectively the same as storing the extended JTA 
support instance in a static...   

* In order to try to follow procedures (and trying very hard NOT to be 
spiteful), I joined the hibernate-dev mailing list and started a 
conversation with Max about the issue.   

* Max does not like storing this instance in a static and we agree that 
caching it in the WebSphereExtendedJTATransactionLookup instance would 
ensure we have only one lookup per EntityManagerFactory. This is ok as 
creation of the EMF alone takes 8-10s - adding another 100ms is no big 

* Again, as agreed with Max, I made the change to the 
WebSphereExtendedJTATransactionLookup, tested it with our project and 
submitted it as a patch to hibernate.   

* Now, after some time, Steve comes into the picture, decides that the 
issue is not a Major issue (well, perhaps not if you don't use WAS, it 
Then deciding - w/o even bothering testing - that the implemtation is "not 
correct" and reimplents it, thereby reintroducing the performance problem 
and closes the issue as fixed !   

* I tried to tell Steve - trying very hard not to sound too bitter - that 
the reimplemtation basically broke the patch. And, btw, I DID test it 
before writing the comment in HHH-2580 

* Steve then basically tells me that he prefers "correctness over 

* I then take a look at the changed WebSphereExtendedJTATransactionLookup 
from svn... Now, seriously Steve, if you look at lines 115-117 of (11481) 
WebSphereExtendedJTATransactionLookup, you will have to admit that the 
implementation is questionable (testing an instance variable for "null" in 
a constructor ??). 
I did not use the C-word, but I did say that your implementation "sucked". 
And it does. We'd all be better of if you simply rejected the patch - now 
it has status closed+fixed but it is definately not fixed.   


Now, I've tried very hard to actually being helpfull, submitting 
"important" changes to improve the performance of Hibernate with WAS CMT. 
And trying to "follow procedures". 
Only a twisted mind can see this as being SPITEFUL ! 
Steve, I think you need a loong vacation or perhaps another job. 
What you are currently doing is to upset people who are seriously trying 
to help the OSS efforts of Hibernate. A man in you position should do the 
exact opposite. 
I don't believe I've given you any reason whatsoever to question my 
motives for "trying to help". 
You, on the other hand, behaves like a little Queen, having her period or 
a couple of bad hair days, bullying everyone that does not have the right 
Please step down from your throne and try to see things from a more 
constructive perspective - letting the arrogance and ignorance stay on the 
top of the throne.   


I've had a very interesting conversation last night with --beep-- --beep-- 
--beep-- --beep-- --beep-- --beep-- --beep--. He basically tells me it is 
ok to store the extended JTA support instance in a static. 
Ufortunately, he does not allow me to quote him on this - pointing me in 
the general direction of OpenJPA and WebSphere support...   

So, NOW we are done. 
I couldn't care less about the quality of Hibernate core. 
I've not used it in the past and I'm definately not going to try to fix 
anything else in it in the future (this probably makes you happy).   

Bye and thanks for showing me how big EGO's these OSS project lead's can 
be :->   


I put Max Rydahl on CC as he had shown an interest before, and he has actually been very helpful. Being a colleague to Mr. Ebersole, he might be able to persuade him into stop being such a bitter, angry man…

But, Mr. Ebersole did not resist this one either:

Subject: Re: (HHH-2580) Performace: Too many lookups of WAS extended 
transaction support (Jesper Udby) 
From:    "Steve Ebersole" <> 
Sender:  "Steve Ebersole" <> 
Date:    Wed, May 9, 2007 14:26 
To:      "Jesper Udby" 
Cc:      "Max Rydahl Andersen"
Here's the sequence of events from my point of view:   

* For well over 2 years now I have written code that you and many many 
others use without giving me anything in return. 
* During that time, integrating with WAS JTA "support" has been nothing 
but a pain in the ass.  People come along every so often and suggest 
some change.  More often then not their suggested change breaks other 
people's usage.  That's an indictment on how crappy WAS JTA support is, 
not the users suggestions per-se.  But regardless, here I am trying to 
figure out what the RightThingToDo is based on non-existent (public) 
documentation and zero experience with the product.  Yet none of these 
users want to take ownership of the integration, or even their suggested 
changes.  Really, they just want me to take over up-keep something that 
happened to work for them so they don't have to manage it with new 
Hibernate releases. 
* Along comes Jesper in the same vein described above, with his 
suggested change.  Does he want to own it or the integration?  No!  Can 
he point me at documentation or resources stating that his suggestion is 
valid?  No!  Can he at the very least assuage my concerns and verify 
that this is valid usage?  No!  How about at least be civil with regards 
to people who have allowed him unfettered use of their blood, sweat and 
tears?  No!  Instead he'd rather launch into a 3-day email tirade.   

Well at least at the end of the 3-day tirade you did verify that the 
suggested scoping works.  I'll change it back to what you initially 

And yes, saying someone's work "sucks" and being generally non-civil is 
being spiteful.  And please don't lecture me about how OSS works or my 
attitude.  I've done OSS work for 3 years now; how about you?  One patch 
does not give you the right to lecture me.  Trust me, my life is 
perfectly pleasant before you; and it'll be perfectly pleasant after you 
go away.  I have a big ego?!?!  LOL!  That's fucking hilarious.  A big 
ego is lecturing me about how I should run a project you use for free.   

*NOW* we are done.

Right, now we are getting somewhere:

  1. People come along and suggest changes to the WAS JTA integration, that breaks others usage (search JIRA and go figure – it ain’t happening or Hibernate does not want them documented).
  2. Integrating with WAS JTA “support” is a pain in the ass. WAS JTA support is crappy. Nice wording again Mr. Ebersole.
  3. Non-existent documentation? Googling e.g. “java:comp/websphere/ExtendedJTATransaction” gives as first hit a link into public IBM documentation, even with JavaDocs. And, one only have to look in OpenJPA for a sample implementation – done by at least one IBM’er…
  4. If “people who come along” mean business, they are supposed to take over the integration (yeah, right).
  5. Mr. Ebersole has done 3 years of OSS work now – this entitles him to use bad language against all us ignorant non-OSS workers? One patch does not give me right to lecture him. What if I had done 5 or 10 patches? Who, actually, are allowed to lecture Mr. Ebersole?
  6. 3-day email tirade. Now, if Mr. Ebersole would stop pouring out bile each and every time I email him, it would never had gone this far. And a little under 18 hours hardly makes it 3 days… If I were a paying customer of this product, I would have demanded to talk to Mr. Ebersoles Boss after his first bile outburst.
  7. Somehow Mr. Ebersole got the message – he had turned 180 degrees and decided to use my initial implementation. Now, should I laugh or cry?

Then, suddenly, a few hours later I receive the following surprising email form Mr. Ebersole:

Subject: Re: (HHH-2580) Performace: Too many lookups of WAS extended 
transaction support (Jesper Udby) 
From:    "Steve Ebersole" <> 
Date:    Wed, May 9, 2007 16:52 
To:      "Jesper Udby" 
Cc:      "Max Rydahl Andersen"
Forgot to mention that I made certain to give you deserved credit for 
your work on WebSphereExtendedJTATransactionLookup:   

 * TransactionManagerLookup implementation intended for use with WebSphere 
 * Application Server (WAS). 
 * WAS, unlike every other app server on the planet, does not allow direct 
 * access to the JTS TransactionManager.  Instead, for common transaction- 
 * related tasks users must utilize a proprietary API known as 
 * ExtendedJTATransaction. 
 * Even more unfortunate, the exact TransactionManagerLookup to use inside of 
 * WAS is highly dependent upon (1) WAS version as well as (2) the WAS 
 * container in which Hibernate will be utilized. 
 * WebSphereExtendedJTATransactionLookup is reported to work on WAS version 6 
 * in any of the standard J2EE/JEE component containers. 
 * @author Gavin King 
 * @author <a href="mailto:xxx" mce_href="mailto:xxx">Jesper Udby<a>

Now, Mr. Ebersole, being King of the Hibernate core implementation, suddenly thinks I should have credit for my work. Yeah, right.
Mr. Ebersoles implementation is not identical to mine, although they are similar and possibly equal in functionality. But, the comment is certainly not mine and I was not asked if it was ok for him to put my name and private email into the source. Saying my private email, the one I’d used with my conversation with him, and not the one I’d specified in my JIRA profile. Now, how professional is that ?

I had had enough. I was fed up with Mr. Ebersoles strange angry and bitter bile. But I was also sorry that the conversation had gotten so much out of hand.
So, I wrote one more email, this one trying to soften things and indicating that I think we should stop the conversion. I also cowardly blocked Mr. Ebersoles known email addresses in my mailserver. I am not going to repeat the mail here. But, somehow Mr. Ebersole had found the email address I’d specified in my JIRA profile, and sent the following to my gmail account:

I am no math genius, but you certainly are a programming genius.  Heck, you 
worked for IBM.  They only hire the best and the brightest.   

I am not the author of the implementation.  My name is not Gavin King. 
Apparently you are not a reading genius either.   

And I am not cowardly enough to block emails from you.  I can take it as 
well as I dish it out, unlike you. ;)   

But given your arrogance and belligerent attitude, I am removing you from 
being a member of our JIRA.   

BTW, what was that custom number again??? Riiiiiiight...   

And no, I did not have a lot of free time at Vignette.  Just that back then 
users weren't assholes (yes, you *are*) and there was actually a pretty cool 
community surrounding Hibernate.  Obviously that has since degraded with the 
coming along of "corporate developers" and folks who are forced to use it 
instead of wanting to use it such as yourself.  Such is life.   

Yes, now we are done.   


More bile… And the last sentences I can only interpret one way: Mr. Ebersole is fed up with “corporate developers” and folks forced to use Hibernate. They are generally assholes and are ruining the community. Back in the good old days the community surrounding Hibernate was pretty cool…
He should find himself a new job and a new OS project to be the King of.
And, by the way, if I had a customer number, I would have demanded a serious chat with Mr. Ebersoles boss about his language and manners towards users, committers, possible customers and competitors!

One last thing – I got the following reply from another of my 3 IBM emails sent:

Hi Jesper, 
I can confirm that WebSphere's ExtendedJTATransaction implementation is a 
stateless accessor object that needs only to be looked up once and not for 
each transaction. 
The most performant use of the class is to look it up once and cache it, 
exactly as you suggest.   

Ian Robinson 
STSM, WebSphere Transactions Architect 
IBM Hursley Lab, UK

Steve Ebersole is an incompetent idiot

About Jesper Udby

I'm a freelance computer Geek living in Denmark with my wife and 3 kids. I've done professional software development since 1994 and JAVA development since 1998.
This entry was posted in Java, Open Source and tagged , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.