Discussions

Bill Burke, JBoss Chief Architect, announced a little while ago that Hibernate has officially joined the JBoss family, and Gavin King, the mind behind Hibernate is now a member of JBoss Group LLC. This comes shortly after JavaGroups from Bela Ban joined as well.

Below is the email that Bill sent out announcing this:
------------------------------------------------------

All,

I would sincerely like to welcome Gavin and Hibernate to the JBoss Group and JBoss.org umbrella. I can't tell you how incredibly psyched and excited we at JBoss are about this. Over the past year, I can't tell you how many times we've encountered customers that are using Hibernate
or are looking to use Hibernate to replace the clunky design that EJB CMP is.

Technically this is a perfect marriage for both projects. We at JBoss have been looking at replacing our aging CMP persistence for over a year now in JBoss 4.0. We are excited that we will be able to leverage Hibernate as the backbone of our persistence solutions rather than having to patch our existing, aging solution or rewriting it from scratch. Hibernate will also become part of our POJO/AOP based solution and a key component of our aspect-oriented middleware offering. These two things alone will expand the userbase and developer base of Hibernate. This means more people finding bugs and more people fixing bugs.

JBoss developers have also done a lot of distributed caching work that will be applicable to Hibernate. We will also help Gavin create tighter integration of Hibernate with JBoss for those of you who are interested in that. Things like packaged Hibernate components that can be hot-deployed. JMX management of Hibernate components. Those are just a few of the things that we can introduce.

JBoss Group is proud to pionner a model we all "Professional Open Source" whereby JBoss.org grows and Boss Group recruits the top talent from succesful open ource efforts. It enables developers to work fulltime, become pro, on their own projects. Recently JBoss Group recruited Remy Maucherat, the lead developer of Tomcat 5, Julien Viet the developer of Nukes, Bela Ban, creator of JavaGroups, more are coming. JBG offers the rare opportunity to turn from hobbyist open source to professional open source. All core JBoss developers are ro
themselves(myself included). JBoss Group professional open source sponsors the top developers to work full time on their projects and thus provides a boost to the projects involved by sponsoring their leaders. Finally the availability of professional services is a boost to corporate adoption of succesful open source projects such s Hibernate. We strongly believe this is the way of the future at JBoss.

All and all, I hope you all look favorably on this new relationship. I know I do.

Ah, so Mr. Fluery's consolidation of Open Source products under the JBoss umbrella continues. Thank the Lord we have Geronimo to counter-balance the ever increasing bulk and marketeering of the JBoss Group.

I agree with Mike, it's a shame if these projects end up tightly coupled with JBoss and hence and harder to use with other stacks. I have no problem with showing how to integrate them and them working well with JBoss but if this means I can't use Hibernate or JavaGroups without a bunch of JBoss code then it's a murky path.

\Christian Bauer\
Can you point out the part of Gavins or Bills message where it says "will only be usable with JBoss"? I really wonder why all you guys never read any article, you don't even have to click somewhere.
\Christian Bauer\

It's merely speculation at this point, but it's speculation with some interesting evidence behind it. Also, before I go on please keep in mind that Mr. Fluery is _not_ going to stand up and announce "I'm slowly pulling in popular Open Source projects under my umbrella in an embrace and extend strategy with an ultimate goal of locking people into JBoss proprietary features". That sort of thing just isn't done :-)

First, please notice that in the past several months people (myself included) have commented on how open source projects are being absorbed into the JBoss group. Notice also how each time a fundamental goal is integration with JBoss. So far, so good.

Now take a peak at various JBoss developer lists, and see arguments popping up that end up with two sides:

- "XYZ Feature will be tightly integrated into the JBoss server to leverage the ABC code there".

vs.

- "XYZ Feature should be written so that it can run standalone; I'm leary of hooking into other JBoss bits for XYZ"

Increasingly, JBoss has been touting new features that can be used in a limited sense standalone, but only allow for the full bang-for-the-buck when used with JBoss. The latter aspect is not by chance, but by design. See also AOP features, new JMS features, etc. You can use this stuff in stripped down/crippleware mode, or with all sorts of cool things if you happen to be using a significant majority of the JBoss server stack.

The only question to me is - what was the decision behind the design? Is this a technical thing, to modularize concerns. Or is it a marketing thing - let's tightly integrate everything a-la Microsoft to lock people in?

My own belief is that Fleury et al are actively working to entice people with new features, and lock the best of those new features into JBoss-only deployments. Contributors to JBoss which are not part of The JBoss Group appear to be fighting this trend (again, see the developer debates on integrated vs. standalone), but we all know who has the commit power in JBoss after what happened with the CDN folks.

Personally, I wouldn't care very much about this except that I think JavaGroups is very cool (based on my own experiences with it), and I've heard the same of Hibernate. It would really, really suck if the best new development on either of those components (or other previously non-JBoss items) became locked into the JBoss stack.

It's merely speculation at this point, but it's speculation with some interesting evidence behind it. Also, before I go on please keep in mind that Mr. Fluery is _not_ going to stand up and announce "I'm slowly pulling in popular Open Source projects under my umbrella in an embrace and extend strategy with an ultimate goal of locking people into JBoss proprietary features". That sort of thing just isn't done :-) <

There is no evidence because you don't show any, only speculation. Using features in JBoss that are simply not available outside (e.g. using the classloader to do interesting things to persistent classes at runtime) is natural. Welcome to software engineering. You don't want that? Why do you demand what should be cooked if you are only invited for dinner? </rant>

>>> and I've heard the same of Hibernate. It would really, really suck if the best new development on either of those components (or other previously non-JBoss items) became locked into the JBoss stack. <
It helps if you try it and not only "hear" it. Yes, it would suck. Thats why it won't happen. You know that some lines above your text there are several statements, by both Gavin and Bill, that this will not happen in any way? Did you read that? Is it not clear enough? Should we add a FAQ page to the website (seriously) and explain it in more words and more detail?

I can also offer to sing and dance it and put a video online, but I guess no one wants to see _that_ :)

\Christian Bauer\
There is no evidence because you don't show any, only speculation. Using features in JBoss that are simply not available outside (e.g. using the classloader to do interesting things to persistent classes at runtime) is natural. Welcome to software engineering. You don't want that? Why do you demand what should be cooked if you are only invited for dinner? </rant>
\Christian Bauer\

JMS folks have complained about several JMS features being tied into JBoss - meaning you can only run non-persistent, non-durable-sub JMS stand alone. People have complained about AOP only working in a stripped down environment. Others have complained in other areas.

There are excellent technical reasons for wanting to run certain components stand alone - particularly if you want to leverage such components in another app server (as well as possibly in a pure Java application running on its own). However, the direction the JBoss Group leadership is pushing towards is that you won't be able to use any significant piece of Jboss without a JBoss server hanging around somewhere. And this does not seem to be for technical reasons, but for marketing and market share reasons.

\Christian Bauer\
It helps if you try it and not only "hear" it. Yes, it would suck. Thats why it won't happen. You know that some lines above your text there are several statements, by both Gavin and Bill, that this will not happen in any way? Did you read that? Is it not clear enough? Should we add a FAQ page to the website (seriously) and explain it in more words and more detail?
\Christian Bauer\

Everything you said makes alot of sense. Until you read Marc Fleury's various posts in various media. And then realize that Gavin and Bill work for Marc Fleury. And then see what happened to the CDN folks' commit privileges when they very publically bucked Mr. Fleury and his company. And then see developers complaining about over-integration between disparate JBoss components.

Please remember, I'm not talking about individuals. I'm talking about employees of JBoss Group who work for Fleury. And Mr. Fluery has a pretty obvious agenda going on (if you can read between the double-speak lines).

Everything you said makes alot of sense. Until you read Marc Fleury's various posts in various media. And then realize that Gavin and Bill work for Marc Fleury. And then see what happened to the CDN folks' commit privileges when they very publically bucked Mr. Fleury and his company. And then see developers complaining about over-integration between disparate JBoss components. <

Have you ever spoken with Marc about this or have you "heard"? Do you know what contracts Hibernate, Gavin and JBoss Group have?

What reasoning, that follows any kind of known logic, should JBoss have to "embrace and extend" Hibernate, if they have

- factual feature request priority because they employ the lead developer?
- revenue from selling support for as much scenarios as possible?

Can you show me a reason why it would be an advantage for JBoss Group if they cripple Hibernate? Because you read somewhere that Marc is not nice? Again, welcome to marketing.

I've had several, ahem, interesting discussions with Mr. Fleury here on TSS. You can go look them up if you'd like.

\Christian Bauer\
What reasoning, that follows any kind of known logic, should JBoss have to "embrace and extend" Hibernate
\Christian Bauer\

Ah, this is simple: the "best" Hibernate will be JBoss Hibernate. And of course, who do you turn to for consulting services, training, etc on the boatload of JBoss stuff that comes along with Hibernate? Why, JBoss Group of course!!

Couple the above with Joe Developer thinking, "Hibernate's stand alone is pretty cool - but look at Hibernate/JBoss AOP! Yeah, we'll have to abandon <mumble> app server to try it, and send a few guys to JBoss training, but the result might be worthwhile".

I've had several, ahem, interesting discussions with Mr. Fleury here on TSS. You can go look them up if you'd like.

>
> \Christian Bauer\
> What reasoning, that follows any kind of known logic, should JBoss have to "embrace and extend" Hibernate
> \Christian Bauer\
>
> Ah, this is simple: the "best" Hibernate will be JBoss Hibernate. And of course, who do you turn to for consulting services, training, etc on the boatload of JBoss stuff that comes along with Hibernate? Why, JBoss Group of course!!
>

We are not selling licenses so we don't need to lock people into the technology. We do sell services though and Hibernate and JavaGroups support/training/consulting will be a new part of our business offering. Get it now? Both business, technology, and livelyhood are all in harmony here. They all help one another. See the synergy? We make each other stronger. Both integrated and standalone.

> Couple the above with Joe Developer thinking, "Hibernate's stand alone is pretty cool - but look at Hibernate/JBoss AOP! Yeah, we'll have to abandon <mumble> app server to try it, and send a few guys to JBoss training, but the result might be worthwhile".
>
> -Mike

Developers are already running en-masse to JBoss from other application servers, so JBoss itself doesn't need this spin. BUT, this works for Hibernate and JavaGroups though. JBoss CMP on top of Hibernate expands the Hibernate user base by at least an order of magnitude.

Again, what we're doing is creating a Professional Open Source organization. Expanding our market, yet working with technologies that compliment and enhance one another. JBoss Group isn't all about JBoss anymore. This is what's happening.

There is no "bootload of JBoss stuff" that comes along with Hibernate. You don't know anything about Hibernate and certainly can't judge what "the best" is.

Of course you may propably ask JBoss Group for Hibernate support if you want support for the Hibernate integration in JBoss. Have you read the announcments this time or did you figure out that one on your own?

"Eclipse standalone is pretty cool - but look at all those great Plugins! Yeah, we will have to abandon Notepad and try some of them, maybe send a few guys to IBM Java training, but the results will be great."

\Christian Bauer\
There is no "bootload of JBoss stuff" that comes along with Hibernate. You don't know anything about Hibernate and certainly can't judge what "the best" is.
\Christian Bauer\

Duh - the announcement just happened.

\Christian Bauer\
"Eclipse standalone is pretty cool - but look at all those great Plugins! Yeah, we will have to abandon Notepad and try some of them, maybe send a few guys to IBM Java training, but the results will be great
\Christian Bauer\

Very, very poor analogy. If you want something more along the lines I was thinking of "Eclipse standalone is pretty cool, but it can only deploy EJBs on Websphere". Think "Hibernate standalone is pretty cool, but it can only XXX on JBoss". Stop knee-jerk protecting JBoss and actually think through the scenarios.

> There is no "bootload of JBoss stuff" that comes along with Hibernate. You don't know anything about Hibernate and certainly can't judge what "the best" is.
> \Christian Bauer\
>
> Duh - the announcement just happened.
>
> \Christian Bauer\
> "Eclipse standalone is pretty cool - but look at all those great Plugins! Yeah, we will have to abandon Notepad and try some of them, maybe send a few guys to IBM Java training, but the results will be great
> \Christian Bauer\
>
> Very, very poor analogy. If you want something more along the lines I was thinking of "Eclipse standalone is pretty cool, but it can only deploy EJBs on Websphere". Think "Hibernate standalone is pretty cool, but it can only XXX on JBoss". Stop knee-jerk protecting JBoss and actually think through the scenarios.
>
> -Mike

Stop belittling the Hibernate folks. We negotiated for 3 months on this and much thought was put into how the relationship would work and how the development would work. Much more thought than the 30 seconds you took to write your response.

Again, what you don't GET "Mike" is that it really doesn't make much sense for us to lock in Hibernate users to JBoss as we have the same potential of getting a service contract with or without this "lock in". In fact, we limit Hibernate's user base and potential customer base if we limit Hibernate features outside the JBoss world. Although we will eventually be 99% of the app server market just as Apache because 99% of the web server market, this currently isn't the case. BEA and IBM still have large user bases that can leverage Hibernate.

Although we will eventually be 99% of the app server market just as Apache because 99% of the web server market, this currently isn't the case. BEA and IBM still have large user bases that can leverage Hibernate.

Someone better check their facts. I suspect that Microsoft alone has way more than 1% of the web server market with IIS (not to mention the use of WebSphere, IBM and Oracle for web server only deployments).

As for the comment that JBoss will have 99% of the AS market that just way way too ridiculous to comment on.

I understand (and partly agree with, but not wholly) Mike's comments about some things that Fleury has said, but I don't think he's acting any different than most other companies. Making contradictory statements can have a number of reasons, including a lack of integrity (outright lying), a change of mind (new facts), or a change of direction (project needs to go a different way). Knowing that he has made contradictory statements COULD mean a lack of integrity, but does not PROVE one. I have no "inside knowledge", and until I am shown that he is being deliberately misleading, I see no reason to villify him or JBoss (the project or the group).

<Mike Spille>
Very, very poor analogy. If you want something more along the lines I was thinking of "Eclipse standalone is pretty cool, but it can only deploy EJBs on Websphere".
...
I do begrudge the fact that JBoss Group is (effectively) buying up more and more Open Source, and will most likely constrain my own options more and more (and those of others) as they bend what I'll call "pure, unencumbered" open source bits like JavaGroups and Hibernate into something "tightly integrated" with JBoss.
</Mike Spille>
The first makes sense, but I don't see why it's a problem. The second makes no sense. If IBM dumps millions into a product which is freely available, and some additional money goes into "special" features (in IBM's case for WebSphere), who cares? If Gavin gets $1, and part of it goes to "core" Hibernate and part to "tight integration" who cares? At least part of it is free/stand-alone.

Look at it the other way. Before this Gavin had a "real job", but now he can do hibernate during work hours. If he works 40 hours, and 30 are for core and 10 are for JBoss, that's 30 extra hours. And assuming you complain "but what if its the other way, a 10/30 split", again, that's 10 more hours.

Anyway, back to the important stuff. Once again, congratulations Gavin - enjoy your new "job"!

I don't really see anything wrong with JBoss, Marc Fleury, and all "his" developers acting in their own interests. We'd much rather pay a little to them to get support and help get some new features than pay a whole lot to something that truly will tie you into a whole host of fees. Both BEA and IBM are a million times more guilty of that than Marc Fleury ever will be.

In addition, it's funny the people who are now bitching about JBoss being too tightly integrated are the ones a few weeks ago who were like "Thank GOODNESS Geronimo will be MORE TIGHTLY INTEGRATED with other apache products!" You guys want it both ways. :)

<quote> In addition, it's funny the people who are now bitching about JBoss being too tightly integrated are the ones a few weeks ago who were like "Thank GOODNESS Geronimo will be MORE TIGHTLY INTEGRATED with other apache products!" You guys want it both ways. :)</quote>

Any piece of Jakarta project can be used in any Standard Java/Servlet/J2EE Container, because they are modular by design. They created their logging API, Log4J, and then created Commons-logging, permitting the exchange between Log4J, javax.logging, etc. If they were to produce some AOP framework, it would work outside Tomcat or Geronimo, it would be possible to deploy it in any Container, maybe even used in standalone applications.

Apache doesn't try to lock us in their products, they don't make any revenue from them, JBoss does.

<quote> In addition, it's funny the people who are now bitching about JBoss being too tightly integrated are the ones a few weeks ago who were like "Thank GOODNESS Geronimo will be MORE TIGHTLY INTEGRATED with other apache products!" You guys want it both ways. :)</quote>

>
> Any piece of Jakarta project can be used in any Standard Java/Servlet/J2EE Container, because they are modular by design. They created their logging API, Log4J, and then created Commons-logging, permitting the exchange between Log4J, javax.logging, etc. If they were to produce some AOP framework, it would work outside Tomcat or Geronimo, it would be possible to deploy it in any Container, maybe even used in standalone applications.
>
> Apache doesn't try to lock us in their products, they don't make any revenue from them, JBoss does.

As far as JBoss AOP, it comes in a standalone downloadable package. YOu can run it anywhere you have total control of the ClassLoader or can replace the classloader with one that implements the JBoss AOP api. I am looking into how AspectWerks allows for this. AFAICT, they are able to do this because they run under the JPDI (debugger interface) which allows Hot Swapping. I'm not sure if they've Hot Swapped java.lang.ClassLoader itself, or if they HotSwap modified classes instead. My guess is the former because HotSwap AFAICR, may or may not allow the addition of methods/fields. It depends on the JVM implementation. We will also be creating a compiler by exposing our Instrumentor class, although I'd rather not have a compiler.

The problem is that you must be able 1) precompile your java code/bytecode to insert aspects, like AspectJ 2) have control of the classloader or 3) rely on JPDI. JPDI may/may not have its limitations and I am unsure of its affects on overall JVM performance. Some tell me it has on overall 50% hit, others tell me it has none. I'll have to find out for myself.

JBoss AOP, in and of itself, isn't very compelling. There are far more complete and mature AOP products out there (AspectWerks, AspectJ, etc etc).

What is compelling to some people are the aspects you've developed - the actual meat of the JBoss "J2EE a la carte" message. Sadly, these suffer two problems:

1) They are hardwired into JBoss. They aren't designed in any way to be portable to another App Server.

2) The definition of their behavior - the semantics of them, the "spec" if you will - lays between barebones and nothing. The web page does not cover the full behavior, and yourself and Bela's descriptions of what they do does not match the actual code.

For many people, they'll find you can run JBoss AOP standalone, with no useful prebuilt aspects they can use beyond toys. Then they'll find several seemingly useful goodies - all of which only work inside of JBoss. Then, if they drink the Kool Aid and actually try to use them, they'll find innumerable corner cases in the actual implementation that diverges significantly from the documentation's claims.

n Bauer\
>
> Everything you said makes alot of sense. Until you read Marc Fleury's various posts in various media. And then realize that Gavin and Bill work for Marc Fleury. And then see what happened to the CDN folks' commit privileges when they very publically bucked Mr. Fleury and his company. And then see developers complaining about over-integration between disparate JBoss components.
>

Again, "Mike", you are misinformed. Commit privileges were not revoked for bucking Fleury and the business(June), but for bucking the JBoss project(August). Forking, copyright infringement, LGPL violation is a pretty strong case for removal.

> Please remember, I'm not talking about individuals. I'm talking about employees of JBoss Group who work for Fleury. And Mr. Fluery has a pretty obvious agenda going on (if you can read between the double-speak lines).
>

The agenda is clear and obvious. To build a Professional Open Source organization.

\Bill Burke\
Again, "Mike", you are misinformed. Commit privileges were not revoked for bucking Fleury and the business(June), but for bucking the JBoss project(August). Forking, copyright infringement, LGPL violation is a pretty strong case for removal.
\Bill Burke\

I'm afraid LGPL violation and copyright infringement are wholly made up charges. Or have you sued anyone yet? What exactly were the violations?

\Bill Burke\
The agenda is clear and obvious. To build a Professional Open Source organization.
\Bill Burke\

BTW - you _do_ realize that it's far more interesting to note the comments here that you _don't_ respond to then what your actual responses are, right? As someone in another JBoss thread said, your silence often speaks more than when you're speaking.

> Again, "Mike", you are misinformed. Commit privileges were not revoked for bucking Fleury and the business(June), but for bucking the JBoss project(August). Forking, copyright infringement, LGPL violation is a pretty strong case for removal.
> \Bill Burke\
>
> I'm afraid LGPL violation and copyright infringement are wholly made up charges. Or have you sued anyone yet? What exactly were the violations?
>

Again, have you done any actual research "Mike"? Or again, is your research solely through the "Search TheServerSide" text box?

> BTW - you _do_ realize that it's far more interesting to note the comments here that you _don't_ respond to then what your actual responses are, right? As someone in another JBoss thread said, your silence often speaks more than when you're speaking.
>
> -Mike

I think I've answered everything I need to answer here. Your app server lock in arguments are silly since we don't sell licenses. Why take the roundabout approach of getting a "better" Hibernate only with JBoss to sell services? Why not just sell services directly to the Hibernate community? This is much easier. We are about services, not licenses.

Again, have you done any actual research "Mike"? Or again, is your research solely through the "Search TheServerSide" text box? <

Bill, I tried to avoid web forums for these reasons some years, but this is what has been around 10 years on usenet. He just wants some attention and will continue with whatever dubios, misinformed or aggressive claim he can make up. Is he a known troll on TSS? I've only started to read TSS for the last 2 years sporadically so I might have missed that one. I got the "Mr. Bauer" after all :)

\Bill Burke\
I think I've answered everything I need to answer here. Your app server lock in arguments are silly since we don't sell licenses. Why take the roundabout approach of getting a "better" Hibernate only with JBoss to sell services? Why not just sell services directly to the Hibernate community? This is much easier. We are about services, not licenses.
\Bill Burke\

Wow, this is density approaching a neuron star.

As an exercise, Mr. Burke: name same ways (more than just the one, please) in which a company such as yours can increase services revenue in a highly competive market as we have today.

As a homework assignment, do research on how freebies can be used to entice customers into greater service commitments. For bonus points, figure out how tight integration of multiple products can also lead to increased service revenue (hint: call the guys at SAP or Peoplesoft).

> Again, have you done any actual research "Mike"? Or again, is your research solely through the "Search TheServerSide" text box?
> \Bill Burke\
>
> Mr. Burke, I demonstrated my research abilities:
>
> Here>
> And I'm still waiting for you to answer my questions.
>
> \Bill Burke\
> I think I've answered everything I need to answer here. Your app server lock in arguments are silly since we don't sell licenses. Why take the roundabout approach of getting a "better" Hibernate only with JBoss to sell services? Why not just sell services directly to the Hibernate community? This is much easier. We are about services, not licenses.
> \Bill Burke\
>
> Wow, this is density approaching a neuron star.
>
> As an exercise, Mr. Burke: name same ways (more than just the one, please) in which a company such as yours can increase services revenue in a highly competive market as we have today.
>

- IT shop using Weblogic wants to use Hibernate and needs support for Hibernate. Gavin gets paid.
- IT shop using Websphere wants to use Hibernate within and needs support for Hibernate. Gavin gets paid.
- IT shop using Tomcat wants to use Hibernate within and needs support for Hibernate. Gavin gets paid.
- An ISV wants training on how to use Hibernate because they embedd it in their product that is usable on Webshpere, Weblogic, and JBoss. Gavin gets paid.

JBossGroup sells insurance and training on free products. The thing is that not everybody needs the insurance or training. Before I joined JBossGroup I worked at a company using JBoss. They didn't need support or training because I was good enough to figure out things myself. There are multitudes of engineers with my talent and many companies do the same.

Some companies however, want immediate help when critical issues arise. So they buy an insurance policy with us. It is that simple.

> As a homework assignment, do research on how freebies can be used to entice customers into greater service commitments.
>For bonus points, figure out how tight integration of multiple products can also lead to increased service revenue (hint: call the guys at SAP or Peoplesoft).
>
> -Mike

> Mr. Burke, I demonstrated my research abilities:
>
> Here
>
> And I'm still waiting for you to answer my questions.

Conveniently ignored, yet again.

\Bill Burke\
1) IT shop using Weblogic wants to use Hibernate and needs support for Hibernate. Gavin gets paid.
2) IT shop using Websphere wants to use Hibernate within and needs support for Hibernate. Gavin gets paid.
3) IT shop using Tomcat wants to use Hibernate within and needs support for Hibernate. Gavin gets paid.
4) An ISV wants training on how to use Hibernate because they embedd it in their product that is usable on Webshpere, Weblogic, and JBoss. Gavin gets paid.
\Bill Burke\

I am slowly learning patience. I have taken the liberty to renumber your bullets above so I may reference them more conveniently.

#1, #2, #3 - Gavin gets paid. OK.

#4 - seems rather strange, but allright.

But, of course, you neglected to add in #5:

5) IT shop wants to use Hibernate and finds JBoss is the best container to run it in. They need support for Hibernate and JBoss. Gavin gets paid. Bill Burke gets paid. Bela gets paid. "N" additional JBoss consultants get paid.

You see - in a Websphere environment, for example, JBoss is going to get a microscopic piece of the consulting pie, let's say for Hibernate. IBM will most likely get an order of magnitude (probably several) more consulting dollars on Websphere services and other services. There'll be the one poor Hibernate expert from JBoss group surrounded by a (literal) horde of IBM consultants. Jboss gets one guy paid - whoopdeedoo.

Now let's say just "Hibernate" becomes very hot, someone is very hot to get it, and JBoss Group just happens to make Hibernate a bit sucky under other app servers but golden under JBoss. You may just get one or two big wins here - but those wins aren't just "Gavin gets paid". The win is "a horde of Jboss developers replace those IBMers and get paid".

It's the business version of scalability - it's turning a foot in the door of a JPMorgan or a US Healthcare on something like Hibernate, and expanding the breach and flooding them with JBoss services (cuz it runs best on JBoss).

I've always said that Mr. Fleury was smart when it came to selling things and working it in the IT market. And I don't begrudge JBoss Group the money. I do begrudge the fact that JBoss Group is (effectively) buying up more and more Open Source, and will most likely constrain my own options more and more (and those of others) as they bend what I'll call "pure, unencumbered" open source bits like JavaGroups and Hibernate into something "tightly integrated" with JBoss. It's a great strategy for the company. But it kind of sucks for those of us who don't want to use JBoss.

>
> > Mr. Burke, I demonstrated my research abilities:
> >
> > Here
> >
> > And I'm still waiting for you to answer my questions.
>
> Conveniently ignored, yet again.
>
>
> \Bill Burke\
> 1) IT shop using Weblogic wants to use Hibernate and needs support for Hibernate. Gavin gets paid.
> 2) IT shop using Websphere wants to use Hibernate within and needs support for Hibernate. Gavin gets paid.
> 3) IT shop using Tomcat wants to use Hibernate within and needs support for Hibernate. Gavin gets paid.
> 4) An ISV wants training on how to use Hibernate because they embedd it in their product that is usable on Webshpere, Weblogic, and JBoss. Gavin gets paid.
> \Bill Burke\
>
> I am slowly learning patience. I have taken the liberty to renumber your bullets above so I may reference them more conveniently.
>
> #1, #2, #3 - Gavin gets paid. OK.
>
> #4 - seems rather strange, but allright.
>
> But, of course, you neglected to add in #5:
>
> 5) IT shop wants to use Hibernate and finds JBoss is the best container to run it in. They need support for Hibernate and JBoss. Gavin gets paid. Bill Burke gets paid. Bela gets paid. "N" additional JBoss consultants get paid.
>

Yes, I hope this is the case. The requirements are that they want Hibernate and need a container too. JBoss should be the best container and Hibernate should work best within it. Yeah, so? Non-Hibernate guys will make sure Hibernate works best in JBoss rather than Weblogic. So? If we don't we're stupid. We have access to the main dude himself, Gavin! Does this mean Hibernate will not work as best as possible within Weblogic considering Weblogic is closed-source? Please. You're sounding ridiculous.

Ya know, it works both ways. Gavin can ensure Hibernate works really really well with JBoss because he can modify the JBoss source code to do so. he can't do the same with others.

> See how it works? Hibernate stand alone means Gavin gets paid. Big deal. Hibernate hooks into JBoss in many advantageous, JBoss-only ways - suddenly, the investment in Gavin may get "N" additional consultants paid.
>
> You see - in a Websphere environment, for example, JBoss is going to get a microscopic piece of the consulting pie, let's say for Hibernate. IBM will most likely get an order of magnitude (probably several) more consulting dollars on Websphere services and other services. There'll be the one poor Hibernate expert from JBoss group surrounded by a (literal) horde of IBM consultants. Jboss gets one guy paid - whoopdeedoo.
>

JBoss Group is not in the contracting business. We focus on support. IBM Global services is about providing full solutions. JBoss Group is mostly about support, mentoring, and training. We honestly would rather not get in that business.

> Now let's say just "Hibernate" becomes very hot,

It is already hot. If it wasn't we wouldn't have recruited them heavily.

> someone is very hot to get it, and JBoss Group just happens to make Hibernate a bit sucky under other app servers but golden under JBoss. You may just get one or two big wins here - but those wins aren't just "Gavin gets paid". The win is "a horde of Jboss developers replace those IBMers and get paid".
>

You are just silly, spitting out nonsense. There are a multitude of reasons why you'd want to use Javassist, JavaGroups, and Hibernate outside of JBoss. Why would we limit our market? Silly just silly....

> It's the business version of scalability - it's turning a foot in the door of a JPMorgan or a US Healthcare on something like Hibernate, and expanding the breach and flooding them with JBoss services (cuz it runs best on JBoss).
>

Support is much easier to scale than consulting. Consulting/contracting requires many bodies. As you need a consultant per contracted project. AND the consultant needs to fly out there. One JBoss Group employee can handle > 40 support contracts.

> \Bill Burke\
> You're funny. Holy shit! You mean we're trying to increase our service revenue? You caught us red handed! Wow, you're wicked smaht.
> \Bill Burke\
>
> I've always said that Mr. Fleury was smart when it came to selling things and working it in the IT market. And I don't begrudge JBoss Group the money. I do begrudge the fact that JBoss Group is (effectively) buying up more and more Open Source, and will most likely constrain my own options more and more (and those of others) as they bend what I'll call "pure, unencumbered" open source bits like JavaGroups and Hibernate into something "tightly integrated" with JBoss. It's a great strategy for the company. But it kind of sucks for those of us who don't want to use JBoss.
>
> -Mike

How many times do we have to tell you that YOU DON'T HAVE TO USE JBOSS! JavaGroups and Hibernate WILL RETAIN THEIR OWN CVS's! Stop with the bull Mike.

\Bill Burke\
Yes, I hope this is the case. The requirements are that they want Hibernate and need a container too. JBoss should be the best container and Hibernate should work best within it. Yeah, so? Non-Hibernate guys will make sure Hibernate works best in JBoss rather than Weblogic. So? If we don't we're stupid. We have access to the main dude himself, Gavin! Does this mean Hibernate will not work as best as possible within Weblogic considering Weblogic is closed-source? Please. You're sounding ridiculous.
\Bill Burke\

Funny, you say I sound ridiculous, and yet you _just confirmed what I've been saying_. It took long enough, but it was worth the wait.

\Bill Burke\
JBoss Group is not in the contracting business. We focus on support. IBM Global services is about providing full solutions. JBoss Group is mostly about support, mentoring, and training. We honestly would rather not get in that business.
\Bill Burke\

First, I find it funny that you say "We". Mr. Fleury seems to regularly contradict you both here and on the JBoss forums, and Bela consistently contradicts your technical comments. From where I sit you don't appear to talk for the company since everyone else from your company regularly corrects what you say.

With that out of the way, here's what www.jboss.org says:

"JBoss Group is a worldwide organization, founded by the core developers of JBoss, dedicated to the professional servicing of JBoss technology. JBoss Group is the best resource available for your training, support and consulting needs."

\Bill Burke\
You are just silly, spitting out nonsense. There are a multitude of reasons why you'd want to use Javassist, JavaGroups, and Hibernate outside of JBoss. Why would we limit our market? Silly just silly....
\Bill Burke\

In addition, JavaGroups and Hibernate were only recently acquired by JBoss. Let's sit and see what your boss does with these technologies over the coming year. My money says JavaGroups and Hibernate are going to become heavily JBoss-ized, and the answer to many questions about them will be "That only works in the container". And as a result you will get more consulting gigs (yes, Mr. Burke, as Chief Archtect you don't seem to know it, but you work for a consulting company).

\Bill Burke\
Support is much easier to scale than consulting. Consulting/contracting requires many bodies. As you need a consultant per contracted project. AND the consultant needs to fly out there. One JBoss Group employee can handle > 40 support contracts.
\Bill Burke\

You're a worldwide company, remember? So "flying" should not be much of an issue.

As for support contracts, you're correct. Now - how can you increase core JBoss support contracts? Hmmm? And given that you're talking about open source, just how many support contracts are you going to have?

Finally - consulting is a business with ridiculously low overhead and pretty decent margins. Now imagine you're Mr. Fleury, you really want to get very very rich, and you want to grow your business. Are you going to grow that business on training and support contracts for open source stuff? Or are you going to grow it by slinging bodies that are specially differentiated in the market?

\Bill Burke\
How many times do we have to tell you that YOU DON'T HAVE TO USE JBOSS! JavaGroups and Hibernate WILL RETAIN THEIR OWN CVS's! Stop with the bull Mike.
\Bill Burke\

Please forgive me if I don't take _your_ word for it, because your word is obviously worthless. I went to great pains to point out the errors in your comments about your own TxCache code, and you plainly lack the moral courage to acknowledge that effort, or to admit that you made a misstatement or a mistake. Your own colleagues routinely contradict your statements in public forums.

Given the above - why in the _world_ would I believe you speak for JBoss Group, or that you actually mean what you say, or that you have in any way, shape or form the power to make your statements have force?

Bill, please stop wasting your time arguing with these guys. They post their flamebait and you fall for it. I'm sure you have more productive things to do than spend time arguing with this stuff. TSS has turned into TheFlameSide...

I think I've answered everything I need to answer here. Your app server lock in arguments are silly since we don't sell licenses. Why take the roundabout approach of getting a "better" Hibernate only with JBoss to sell services? Why not just sell services directly to the Hibernate community? This is much easier. We are about services, not licenses.

>

Not getting into an argument here.....

"App server lock in" is not just about licenses, and it _can_ be about services.

I think what our friend, Mike (don't put quotes round his name - it's pretentious), is afraid of, is that in bringing several OS projects under the JBoss Group Umbrella, these projects will focus more on being integrated with JBoss (AS), than being improved for the more general community, leading to a potential schism where the only way to acheive X is to use a once 'all-features-for-all-people' product, is to use it in conjunction with the rest of the JBoss AS.

For example, the Idea that some of the JavaGroups clustering going into Hibernate - will this require JavaGroups installation with Hibernate or will said class libraries be available just for Hibernate in a downloadable version, or will Hibernate get new classes, based on Javagroups?

You must admit that it would be easier to take the whole of the pieces and interconnect them together as a Jboss AS

The intermixing of these projects will require careful management to avoid locking projects into one another.

I hope that this doesn't enflame anyone, but merely as a cautionary message

For example, the Idea that some of the JavaGroups clustering going into Hibernate - will this require JavaGroups installation with Hibernate or will said class libraries be available just for Hibernate in a downloadable version, or will Hibernate get new classes, based on Javagroups?

>

Hibernate already requires JCS integration for similar functionality and the JCS jars are already part of the Hibernate distribution. I for one would like to see JavaGroups replace JCS, as it is much more powerful and better supported. So, to me, this would be a _good_ thing. However, you don't need JCS libraries to run Hibernate if you're not using JCS. This should be the same for JavaGroups or any other 3rd party library, imo.

> Can you point out the part of Gavins or Bills message where it says "will only be usable with JBoss"? I really wonder why all you guys never read any article, you don't even have to click somewhere.
> \Christian Bauer\
>
> It's merely speculation at this point, but it's speculation with some interesting evidence behind it. Also, before I go on please keep in mind that Mr. Fluery is _not_ going to stand up and announce "I'm slowly pulling in popular Open Source projects under my umbrella in an embrace and extend strategy with an ultimate goal of locking people into JBoss proprietary features". That sort of thing just isn't done :-)
>

Considering Gavin is on the JDO 2 expert group, this is a ridiculous statement. Hibernate is clearly superior to JDO 1, hence, Gavin was invited to join the group. The problem is that some of the specifications CMP and JDO 1 are very weak which is why people are running to proprietary solutions like Hibernate.

Bela Ban, creator of JavaGroups, and another new JBoss Group hire, is on the JCache JSR and working to implement this within JBoss CVS.

JBossGroup is a JCP member and has also agreed on Suns terms to license J2EE TCK.

> First, please notice that in the past several months people (myself included) have commented on how open source projects are being absorbed into the JBoss group. Notice also how each time a fundamental goal is integration with JBoss. So far, so good.
>
> Now take a peak at various JBoss developer lists, and see arguments popping up that end up with two sides:
>
> - "XYZ Feature will be tightly integrated into the JBoss server to leverage the ABC code there".
>
> vs.
>
> - "XYZ Feature should be written so that it can run standalone; I'm leary of hooking into other JBoss bits for XYZ"
>
> The only question to me is - what was the decision behind the design? Is this a technical thing, to modularize concerns. Or is it a marketing thing - let's tightly integrate everything a-la Microsoft to lock people in?
>

Misinformed statements "Mike". JavaGroups is the backbone for JBoss clustering. Hibernate will be the backbone for JBoss CMP. Hibernate is also leading the JDO charge. Of course we want tighter integration with Hibernate. We want JBoss/Hibernate users to have the same advantages of JBoss/CMP developers. Hot deployment of any component type. Packagable components. Exploded archives. Our component lifecycle provided by our JMX microkernel. JMX management. This is the tight integration we talk about here.

> My own belief is that Fleury et al are actively working to entice people with new features, and lock the best of those new features into JBoss-only deployments. Contributors to JBoss which are not part of The JBoss Group appear to be fighting this trend (again, see the developer debates on integrated vs. standalone), but we all know who has the commit power in JBoss after what happened with the CDN folks.
>

You couldn't be more wrong "Mike".

JBoss Group is not all about JBoss anymore. We're about Professional Open Source. Without a professional services organization around an open source project it is much more difficult for a given open source project to gain widespread adoption. Hibernate and JavaGroups are complicated intricate libraries/frameworks that can solve many application development issues. Many companies demand support services if they are to adopt such technologies. JBoss Group offers the infrastructure, processes, and resources for open source developers to take their projects "big time".

Another thing you should notice is that JBoss, Hibernate, JavaGroups, Javassist, Nukes, AOP are all projects that can compliment, enhance, and build off one another's strengths. We're not just throwing a bunch of arbitrary projects at the wall and seeing what sticks.

> Personally, I wouldn't care very much about this except that I think JavaGroups is very cool (based on my own experiences with it), and I've heard the same of Hibernate. It would really, really suck if the best new development on either of those components (or other previously non-JBoss items) became locked into the JBoss stack.
>
> -Mike

Will Gavin and Bela have more time to do JBoss specific stuff? Yes. Will Gavin and Bela have more time to do Hibernate/JavaGroups specific enhancements? Yes. They will not have to work on open source in their free time since they are being paid to do it now.

It works the other way too. Bela, Harald Gliebe, Ben Wang, and myself have been doing a lot of distributed caching work under the JBoss umbrella. We will be able to apply this technology to Hibernate and thus enhance the Hibernate offering.

In conclusion, our technologies and experience all compliment each other. Which is why we pursued the relationship in the first place. It made sense on all sides.

\Bill Burke\
Considering Gavin is on the JDO 2 expert group, this is a ridiculous statement. Hibernate is clearly superior to JDO 1, hence, Gavin was invited to join the group. The problem is that some of the specifications CMP and JDO 1 are very weak which is why people are running to proprietary solutions like Hibernate.

Bela Ban, creator of JavaGroups, and another new JBoss Group hire, is on the JCache JSR and working to implement this within JBoss CVS.

JBossGroup is a JCP member and has also agreed on Suns terms to license J2EE TCK.
\Bill Burke\

I think perhaps you missed the thrust of my argument. Which is: what can run w/out a JBoss server lurking about in the background?

\Bill Burke\
Misinformed statements "Mike". JavaGroups is the backbone for JBoss clustering. Hibernate will be the backbone for JBoss CMP. Hibernate is also leading the JDO charge. Of course we want tighter integration with Hibernate. We want JBoss/Hibernate users to have the same advantages of JBoss/CMP developers. Hot deployment of any component type. Packagable components. Exploded archives. Our component lifecycle provided by our JMX microkernel. JMX management. This is the tight integration we talk about here.
\Bill Burke\

What's up with the quotes around my name?

As for the rest - there are many open source implementations of various J2EE components that can run independently on their own, or mix and match as need be. In fact, a big goal of many open source projects is to break the monolithic app server mold and let you pick best-of-breed components as you need them.

\Bill Burke\
JBoss Group is not all about JBoss anymore. We're about Professional Open Source. Without a professional services organization around an open source project it is much more difficult for a given open source project to gain widespread adoption. Hibernate and JavaGroups are complicated intricate libraries/frameworks that can solve many application development issues. Many companies demand support services if they are to adopt such technologies. JBoss Group offers the infrastructure, processes, and resources for open source developers to take their projects "big time".

Another thing you should notice is that JBoss, Hibernate, JavaGroups, Javassist, Nukes, AOP are all projects that can compliment, enhance, and build off one another's strengths. We're not just throwing a bunch of arbitrary projects at the wall and seeing what sticks.
\Bill Burke\

You completely missed another aspect - one that's very important to JBoss Group, the for-profit company: the more projects under your umbrella, the more people will assume y'all have expertise in them, and the more consulting and services revenue you can bring in. Obviously, there's nothing wrong with that. But if pulling component "XYZ" means pulling in the whole JBoss kit'n'kaboodle, there's vast potential to expand that consulting and services revenue (since users are pushed towards all-JBoss). If "XYZ" were stand alone, you might get a little slice for that, with the rest going to IBM/BEA/whoever, as the end-users mix and match their technology as they see fit.

But the "tight integration" approach has the potential for higher consulting revenue.

Just for the record - I'm not one of those people who think money is bad, or for-profit companies are bad. But it kinda sucks seeing an open source for-profit start talking "tighter integration" of open source products, because we _all_ know where that sort of talk leads to.

#1 Replicated Cache (TreeCache, TreeCacheAop)
This is my first task. I'm almost at the point where I can package a standalone version. I want to write some better doc, then I'll release this. You will be able to use this with your *own* TransactionManager.

#2 (related to #1)
Gavin will be integrating TreeCache standalone into Hibernate standalone. So you will be able to download Hibernate with a replicated cache, allowing for use of Hibernate in a cluster environment.

#3 (related to #2)
What I discussed in #2 will be used to implement entity bean replication and caching across a JBoss cluster (shared DB though in first iteration). This is an example of built-in I was referring to earlier

#4 JCache
I will provide a standalone fully JCache compliant package. It will come with a number of JBoss JARs, but you shouldn't care about this.

I hope this makes it clear where we are headed. In short: standalone versions of all subsystems I write; and excellent integration with the container if run inside JBoss.

I agree with Mike, it's a shame if these projects end up tightly coupled with JBoss and hence and harder to use with other stacks. I have no problem with showing how to integrate them and them working well with JBoss but if this means I can't use Hibernate or JavaGroups without a bunch of JBoss code then it's a murky path.

Hi Bill,

JGroups will always work *without* JBoss code. There is NO dependency from JGroups to JBoss. There *is* dependency from JBoss to JGroups, but not the other way round.

I will never (repeat after me: NEVER) introduce a dependency to JBoss into JGroups.

We will be making a major announcement soon, and I would prefer that everyone here learns about this development here, rather than in the press, or on TSS.

As you must realise, Hibernate and the Hibernate project have been created entirely by people working in their spare time, using donated resources. Development of Hibernate was never at any stage supported by any commercial (or nonprofit) organization, and the project never had any kind of income.

The people who have contributed code are all (I hope) listed in the changelog. I also need to single out Christian Bauer who, though his name does not appear there, has been essential to the success of the project due to his work on the website and documentation and many other thankless tasks.

Its also a good point at which to thank all our users for being one of the coolest developer communities on the Internet. Even when I'm a rude grumpy bastard answering forum posts at 3am, I'm always happy to see people using Hibernate.

The success of the project (and it is now a very successful project) has taken an enormous amount of time from my personal life. It is incredibly difficult to keep up with the huge amount of traffic in our forum, let alone find time for development, while at the same time holding down a
"real" job.

Fortunately, we've now found a way to out.

JBoss Group will support the development of Hibernate, by hiring me to work full time on Hibernate, and on JBoss/Hibernate integration. In addition, myself and other members of the Hibernate team will now be able to provide commercial support and professional training through
JBoss Group. This is something that many people have emailed me about, and I simply havn't been in a position to be able to do.

What this means for Hibernate users
===================================
* more resources for Hibernate development
* able to buy professional training / commercial support
* assurance that the Hibernate project continues to exist and grow

What the means for the Hibernate team
=====================================
* a chance to make some money :)
* Gavin gets his life back (maybe)
* no longer have to beg and scrounge for money for things like domains

What this means for the Hibernate project
=========================================
* more developers
* Hibernate will be distributed with JBoss application server
* lots more users
* an easier "sell" to management types
* we get a marketing team!

What this means for the JBoss project
=====================================
* JBoss will use Hibernate as backbone of CMP layer
* Hibernate will complement JBoss AOP, being a POJO-oriented persistence layer

What this means for JBoss Group
===============================
* JBoss gets a great persistence engine!
* lends credibility to jboss.org as an umbrella for more than just the appserver project
* JBoss is able to sell Hibernate training and support

What it does NOT mean
=====================
* Hibernate will not become dependent upon JBoss! It is a central goal of the project to remain platform independant!
* you will not have to start paying for documentation
* we will not stop giving great support in the forums
* Hibernate will not be "swallowed" into the JBoss project; it remains a seperate project, now affiliated with jboss.org and supported by JBoss Group
* our central goals do not change: we remain committed to building the killer ORM implementation for Java!

Just in case its not yet clear, this is great news, and is a huge coup for both Hibernate and JBoss! The future of this project is now guaranteed.

I wonder wow this will affect JBoss JDO? I'm a big fan of JDO and I've been playing with Hibernate and from what I've seen I really like it. As for JBoss using Hibernate, that is good news that they are not wasting time and effort on their CMP engine. Personally I'm not even sure why we have CMP anyway with Hibernate & JDO available. Overall, a great win for Hibernate as they will increase their already expanding user base.

JBoss Group is pleased to announce that it has hired the project lead for JavaGroups, Bela Ban. If you don't already know, JavaGroups is the backbone for our clustering implementation and this hiring is a real coup for us. Bela's resume is impressive and his experience with fault tolerance is amazing. Having his expertise on payroll full time will greatly improve the JBoss project as a whole.

Besides working on JavaGroups full time, Bela is going to lead our caching efforts as well as help out with clustering and serverless, JavaGroups-based, JMS.

JavaGroups now comes under the JBoss Group umbrella and Bela will be providing professional services for JavaGroups as needed.

I just hope this collaboration effort will not be as painful, as the JBoss/Jetty one.

Sorry for possible misunderstanding caused by mixing the announcement and my comment.
here is Bill Burke's announcement:
"JBoss Group is pleased to announce that it has hired the project lead for JavaGroups, Bela Ban. If you don't already know, JavaGroups is the backbone for our clustering implementation and this hiring is a real coup for us. Bela's resume is impressive and his experience with fault tolerance is amazing. Having his expertise on payroll full time will greatly improve the JBoss project as a whole.

Besides working on JavaGroups full time, Bela is going to lead our caching efforts as well as help out with clustering and serverless, JavaGroups-based, JMS.

JavaGroups now comes under the JBoss Group umbrella and Bela will be providing professional services for JavaGroups as needed."

And here is my comment: "I just hope this collaboration effort will not be as painful, as the JBoss/Jetty one."
Vlad

And here is my comment: "I just hope this collaboration effort will not be as painful, as the JBoss/Jetty one."

Obviously, if it doesn't go well, they can part ways as well. No one is making anyone work with anyone else. We still use Jetty in our JBoss implementation, and JBoss has supported us just fine. If we feel we need to migrate we will.

Well, this could've been good news, but coming from JBoss, it's not.
We developed our application using EJB CMP 2.0. It took two years and thousands of man hours. There's no reason to migrate to JDO, Hibernate, POJO/AOP or whatever the latest buzz word is.
I'm not saying that EJB is the best and only solution for all enterprise projects, but it has been for ours and we are happy with it.
Now, the fact that now Hibernate is part of Jboss shouldn't be any problem for anyone using EJB, but now all of the sudden we are told from Jboss that EJB CMP is a 'clunky design' and that 'We at JBoss have been looking at replacing our aging CMP persistence for over a year now ..' . Well, we have been using JBoss as our application server, but the future of it for EJB applications looks very much uncertain since the 'Why I love EJB' pamphlet.
The good news: Geronimo.

And Geronimo will have magic persistence without Entity Beans? What is amazing is: No one forces you to change anything in your existing persistence layer. Isn't that great? We don't even want money for that service! :)

Have you read the part where it says "Hibernate will be the CMP _implementation_". It will not replace (only if you like to use it that way) Entity Beans, but give you more power in the CMP descriptor. Hey, how about that: We include that in our free service of not forcing you to do anything. Deal?

EJB CMP has been a clunky design for years (not neccessarily CMP, but Entity Beans in general), this is nothing new. Replacing CMP is not replacing Entity Beans though.

There's nothing in this new announcement that implies they will not be supporting EJB CMP. The implementation will be different, but the spec will be supported. It's just interfaces and some XML, and I *seriously* doubt future versions of JBoss won't be supporting EJB CMP. If anything, these changes (and JBoss 4 AOP) will allow JBoss to be 1) more compliant and 2) leave more time for even more real innovation.

Paul;
I think you misunderstood the statement. The current JBoss implementation of CMP2 is what is being referred to as "aging", "creaky" and "clunky". The word is that CMP2 will be migrated over to Hibernate in JBoss 4. This also from Bill:

"JBoss 3.2 is a production release and will not change except for bug
fixes and performance improvements.

Starting in JBoss 4 the old CMP2 engine will be slowly phased out.
Much
as we phased out the JAWS CMP 1.1 implementation in JBoss 3. JBoss 4
CMP2 will be written on top of Hibernate's persistence engine. The old
CMP2 engine will be usable with JBoss 4 if so desired, but will be
deprecated and removed in the future."

Hopefully, most of the XDoclet will seamlessly move from one to the other....

EJB Clunky design is something more and more people is saying out loud, so there ain't no suprises in this one!

I will also mind you that similar wordings about EJB's and especially CMP's has been said in the Geronimo mailing lists ;)

Furthermore - if you read the announcements, Hibernate will be used as the backbone for JBOSS's CMP engine so CMP will still be there - just by a better implementation - that should be good news for you, right ?

So, please guyz - look at the good stuff in this ,)

The bad stuff you mention; "Hibernate will be assimilated", "Hibernate will be dependent on JBOSS" etc. will simply NOT happen!

All the developers of hibernate (especially Gavin) have thought and talked about this for a while - and we would not have entered this agreement if it was not possible to keep Hibernate build- and runtime-independent from JBOSS!

Hibernate will be even better than before - we will have fulltime developers, we will be able to provide direct and commercial support to those user wanting it (and guyz - we get those questions all the time) - just good stuff for the developers, the community and the Java Persistence world.

Lets assume that Geronimo code is "similar" to jBoss, why would you imply that Geronimo code is better?
If jBoss allreay has EJB why not also have other J2EE API, such as JDO or even an DAO that might be better than JDO or EJB (Hibrenate)? This way you can pick the persistance layer.

jBoss will also supports Tomcat, and no one is woried that you now can't get TC5 without jBoss now, right.

This thread is just a flame war, with a low signal to noise ration,
Are the comercial vendors posting? I hope they have other J2EE API, such as Portlets and JSF, would that lower the Sun share price even more?
From what I know jBoss has a lot of coporate client brand recognition, and they are open source, which implies quality and support, and a very friedly (profitable) license. Why pay BEA $80K? (Why is no one upset that BEA supports both JSP and EJB? What if I ask them a non EJB persistance question) jBoss has been the best thing for J2EE vs .NET.
DId any one widley use Xdoclets and AOP prior to inovations sponsored by jBoss?

There are many open source sites, codehouse, sf.net, pgsql.org, tigris.org and more.

ANd my prediction is: jBoss support of a non EJB persistance will FORCE other J2EE vendors to follow suit. jBoss is a invoator and a market leader.

"jBoss is not Sun's J2EE, its better becuase of the Community"

.V

(ps: I got half a mind to move bP to the default standard J2EE reference production implementation)!!!

I've personally looked at both codebases for JBoss and Geronimo. Sections of Geronimo are CLEARLY cut-n-pasted from the JBoss source (as shown by visually inspecting, as well as running diff. Many parts are "identical", not just "similar".

The ASL does nothing more than provide slave labor for Sun, since you can do whatever the heck you want with the source (and Sun does whatever the heck they want with it). At least the GPL and LGPL provide some integrity to the developers who work hard for the ideals of open source.

Anyway, JBoss is an excellent example of the LGPL working for the community. Their architecture only enhances this community and the other open-source products it uses. If "Mike" or anyone else looked at JBoss's core architecture, they would realize their JMX microkernel allows one to write an MBean wrapper for practically ANY product to allow it to use inside JBoss. That kind of flexibility is unreal in an enterprise level product, and is almost the antithesis of tight-coupling. AND it allows us to use Hibernate unmodified inside JBoss. Any additions to Hibernate to make integration easier are icing on the cake and won't change the fact that Hibernate can be used (and always will be available) as a standalone product.

Gavin has proven himself to be a man of his word. If he says Hibernate won't be tightly coupled into JBoss, such that you couldn't use Hibernate (or any really useful future features) without using JBoss first, then I trust him.

You can't just come on to this list and assume that the Hibernate developers, having worked years and thousands of man-hours to benefit the wider open-source community, are going to just lose their ideals and slap the faces of those they've been working for all this time. Such an assumption is ignorant and downright disrespectful. The Hibernate folks thought long and hard for months before agreeing to the partenership.

P

(P.S. Vic, this post isn't directed to you...Your "similar" comment just caught my eye, and then I wanted to add my 2 cents in to the rest of the core discussion ;) )

Les (who signs "P"): I've personally looked at both codebases for JBoss and Geronimo. Sections of Geronimo are CLEARLY cut-n-pasted from the JBoss source (as shown by visually inspecting, as well as running diff. Many parts are "identical", not just "similar".

That's a serious allegation, and if it is true, and the sections in question in Geronimo are not being explicitly donated by their outright copyright holders, then you need to list who the offenders are and what the sections are. I am certain that neither the JBoss community nor the Apache community will tolerate any misappropriation of copyright or violation of license.

OTOH, if you can't actually substantiate the claim, then it is a claim that is better left not made.

Sorry, sometimes I sign that way to correspond to a username I use on other lists...I got the two confused ;)

> That's a serious allegation, and if it is true, and the sections in question in Geronimo are not being explicitly donated by their outright copyright holders, then you need to list who the offenders are and what the sections are. I am certain that neither the JBoss community nor the Apache community will tolerate any misappropriation of copyright or violation of license.

It is a serious allegation. However, I noticed this over 2 months ago, and I have sinced stopped participating in the Geronimo development discussions, for the same reason (which I found very disturbing). I supposed I could go back and check out the code for both releases, do comparisons, and submit my findings to both development groups. But quite frankly, I don't have the time nor the care to go through that process again. I suspect that is something JBoss employees would/should do. Besides, I'm definitely not the only one to notice, so perhaps the two groups have cleared the issue by now. Next time I'll limit my allegations to those for which I can easily submit proof (I almost always do that anyway...I seemed to have lost my wits in the wee hours of the morning ;) ).

As an aside.. I was curious so I just downloaded both source trees and ran Eric Raymond's code tree comparing tool on them, and it didn't turn up any matches of significance. It can be fooled by reformatting and variable changes, but certainly would catch cut and paste sort of activitiy..

As an aside.. I was curious so I just downloaded both source trees and ran Eric Raymond's code tree comparing tool on them, and it didn't turn up any matches of significance. It can be fooled by reformatting and variable changes, but certainly would catch cut and paste sort of activitiy..

Search for similar file names and start from there. If you know JBoss code, start looking at other sections and comparing code structure and such.

The program I ran compared both trees independantly of filenames. Basically it slices each file into tiny blocks, calculates MD5 hashes, and then looks for matching hashes. So if you cut one method from a file into some other named file in your tree, it would still catch it. (Unless you have extensively reformatted it and changed variables and such..)

I'm not saying people did or didn't copy code.. just that this tool didn't find any occurances of it.

I knew that quote would come back to haunt me (not that you can litterally merge to disticntly different implementations anyway)....

Fortunately, there is no Geronimo JAAS code at all to complain about, nor is there any in progress -- we've been focusing all our security time on JSR 115 (JACC).

Rest assured, the Geronimo JAAS implementation will be it's own beast. Both the JACC and JAAS implementations will be tied together and written against our JMX-based federated security realm infrastructure.

Les, it would be great if you or anyone can provide line/file references if easy (yes, I could download CVS of both.... but if anyone has urls. I do not normaly build jars. My private e-mail is cekvenich_vic at basebeans.com, if you don't wish to make it public.)

I am ashamed that an open source project would do this.

.V

ps: people that feel that jBoss is expensive, are free to purchase and depploy or ressel their products on top of IBM/BEA.

always, JBoss is a threatening entity for many established vendors and a show-stopper for many would be startup companies. Our model is visceraly disgusting for the "establishment". We are now making a living and money at it which makes it even worse as many would like to dismiss our model as youthful idealism. It isn't it is succesful capitalism and competition as far as I am concerned. We found a new model, we got lucky, and we are exploiting it.

For profit open source is a crazy and scary construct for many vendors. In their mind it is OK for you to slave away on open source software so they can use it, not give anything back and think you are an idiot for giving away your work under BSD licenses, but god forbid should you actually create wealth for a great number of people. That is one of the problems I have with BSD licenses.

>
From what I know jBoss has a lot of coporate client brand recognition, and they are open source, which implies quality and support, and a very friedly (profitable) license.
>

Thank you for stating fact :). We are seeing a stampede of adoption, migration, new projects. We can't keep up on sales and I am helping on the sales these days. We had RECORD SALES for the past 2 month. These are the boom times. The brand is a household name, that drives business, and we can deliver great quality of service. You will see some news out of us on wins.

>
ANd my prediction is: jBoss support of a non EJB persistance will FORCE other J2EE vendors to follow suit. jBoss is a invoator and a market leader.
>

JBoss Group already has seen many instances of market leadership and "follow suit", BEA on JMX and AOP recently. It is normal when you think about it, JBoss Group take more risks than an IBM. I was presenting at IBM Wattson the other day to the guys who do Aspect at IBM, I even met adrian and the AspectJ team (great folks :) but anyway the point is that IBM moves like mollases, they *must* move like mollases. JBoss Group CAN explore wild new ways of technology. To the un-initiated it may make no sense. To us the "technology truth" is very clear and simple. We feel it. We know it. So we do it. We have no barriers at JBoss Group, no "focus groups" of ignorant pigs that tell us they want a red button pre-pressed because the customer wants "solutions not product".

>
"jBoss is not Sun's J2EE, its better becuase of the Community"
>

So JBoss Group is about doing the right thing from a product standpoint, doing the right thing from a people standpoint and doing the right thing from a money standpoint. Let me expand briefly.

Product: Hibernate and JavaGroups are tier 1 open source projects. nothing to do with J2EE. Bela's project is even mature and the reputation in academia sky-high. Gavin just reminds me of Rickard when he was young ;) and was causing a stir with his project, I like that. We heavily use both products in JBoss so BILL wanted them both on board. YES! JBoss Group IS BUYING UP open source real estate, so that the products become solid, professional, supported, really-real. The projects remain independent but sponsored by JBoss Group for professional goals. JBoss Group believes in professional open source as a way to make the products first class, SCOTT, BILL and the 30 guys of JBoss Group are living proof. That is professional open source.

People: when I was a kid in open source, months into JBoss, I dreamt of being sponsored. It didn't happen, I was even 'abused' by someone of took advantage of me. Today we are in a position at JBoss Group, sitting on some money, where we can sponsor the best open source projects and do the right thing. We select the few that are making it and turn them PRO. Pro as opposed to hobbyist open source. That means that Gavin and Bela (as they say in their mails) can work fulltime on their projects. I am an altruist by nature and believe in giving people opportunities I didn't get as a kid. That is professional open source.

Money: besides the obvious, the salary and bonuses for services, the liquidity in the company is what will pay everyone billions of dollars (evil laugh and pinky to mouth :). I believe in growing the company and giving stock to all the main heads. The company has value and I am making sure that that value turns into real dollars (the liquidity part) so that we can all make some mullah out of it. The goal is to attract top talent since it means they will make a lot more money with our company. I am here for 10years, I won't go anywhere, but it is not the case with everyone in the company, I recognize guys want payout and I am working on that. That is professional open source.

Bela and Gavin fit right into our organization, smart open sourcers itching to go professional. Remy maucherat from Tomcat 5 is the same and JBoss Group is the place to be for it. JBoss Group is emerging as a powerhouse of professional open source, with a wide base. I am glad that the structure is attracting the top talent in our field, our company today is a who's who of professional open source, and I am proud of that. It is just the beginning you will see just as big news on recruitment (business side) coming out of our PR arm in a couple of weeks... he he, "I am so excited that I just can't hide it".

I have been searching the web for good examples of using hibernate replacing entity bean in ejb design. but little is found. Hopefully, the combination can promote the application of hibernate in ejb stack.

We can't change the license. JBoss is LGPL and every jboss CVS and patch committer retains copyright. We would need permission from every developer to change the license. If we wanted to do this we would have developed under the ASL or BSD license. LGPL was specifically chosen because we wanted JBoss code to remain open source.

The commercial app server vendors are committed to ever larger stovepipes that have tightly coupled components some of which are mediocre or discredited. Scot McNealy mocks developers who pick and choose components. He says we build jalopies and are wasting time and money when a single giant vendor would deliver something better in a single package. Oracle, IBM, & BEA make a similar pitch. Ten years from now this may be true but today they make White Elephants compared to some of our jalopies.

Marc and Bill rightly criticize vertically integrated app servers and promote JBoss AOP as J2EE à la carte but it seems when Marc wears a CEO hat he's swayed by the businessman's penchant for vertical integration. Yes, I know JBoss AOP, Javaassist, Nukes, JDO, and now Hibernate are available stand alone. And yes, JBoss AOP is one way to incrementally add system services but I'm not ready to take that pill. JBoss à la carte should let me begin with, say, Hibernate + Spring + Tomcat and then be as simple to add Coherence or Bela's JCache, SonicMQ or JBoss JMS etc. This makes JBoss valuable in 2 ways; a source of J2EE components and way to package heterogeneous J2EE components. I think Marc, Bill, & Gavin could get paid for this and even get love from TSS.

I agree with your description of a perfect world - you should be able to mix and match, and you'd think an Open Source solution would especially promote that.

At the same time, I can't agree with your characterizations of JBoss AOP. If you try any aspect of it, you find the runtime weight just as heavy (if not heavier) than any J2EE aspect - there's just somewhat less up front code. But what it shares with, as you call it, "larger stovepipes that have tightly coupled components", is lock in and heavy run time weight. The minute you commit to any JBoss aspect code (as in jboss-aspects in the code base), you are locked into JBoss _and_ you are implicitly coupled into the larger container. As I said, you don't see it in the code you write, but the end result is even more heavy weight when you run it (in terms of memory and CPU cost) than J2EE.

Oh, I agree the _message_ of JBoss AOP is a light-weight, a-la-carte approach, but the actual implementation completely opposes this message.

And Mr. Burke, if you're listening, this characterization is not based on a TSS search box, it's based on exhaustive dissection of the JBoss AOP code and attendant aspects.

Disregarding the long, involved, and somewhat inappropriate discussion thread debating JBoss as a company (Yet again), and ignoring the comments from both Hibernate and JBoss as to what their directions will be, I would like to say that I'm very happy for Hibernate about this.

Gavin has always been helpful and the Hibernate team has produced a great product. I am very encouraged to see what will happen when he is able to work full time on enhancing it.. and it will be very interesting to see some ties to JavaGroups as well.

So Gavin (and Bela).. good job, and good luck in the new org!

Honestly, I'm not sure why people are so worked up over this. It lets people develop the code they want, continuing in the same public visibility and access as before, but allows them to make a living. What is so damn evil about that? You may not like Jboss or Marc or something, but given what people have said, thats outside of this scope. Personally, I don't see somebody like Gavin just dumping the codebase into JBoss, blending it tightly with JBossMX, and serving with a side of fruit. He has a lot invested into it as a project, and is obviously going to want it to continue in the same vein as before.

If some of you are so worked up that they will be tainted by the Evil JBoss (EJB!), then either contribute to similar projects you feel are better or can be made better.. or get active as contributors in these projects to ensure they are open and active. They are still open projects, so get involved if you feel that something so important to you is threatened.

I'm happy that Gavin apparently has a paying job doing something he loves - this is everyone's dream.

It just would've been nicer if someone else had done the paying.

I don't think that anyone questions either Gavin or Bela's integrity (or technical expertise for that matter). However, I have personally witnessed people working for someone like Marc Fleury (in fact have worked for the same personality myself, if not the exact same incarnation).

Such people are not coerced into anything "evil" (in fact, I think this is the first invocation of the term in this thread) in this sort of situation. They do not crazy and irrevocably integrate everything in a frenzy.

Instead, it's a slow, steady, inevitable progression. Using an imaginary person Joe: "Joe, profits are tight this quarter", "Joe, Morgan Stanley wants this", "Joe, think of the possibilities!" (shudder), and of course, the always popular "Joe, we're in a bind; if you don't do this I don't see how we can afford to pay you".

I'm happy that Gavin's getting paid to do what he loves. I'm sad that Hibernate has been captured by an organiztaion such as JBoss.org. Despite Gavin's best intentions and expertise, it _will_ get twisted into a JBoss-ism, and then rejected in a later cycle (just like SpyderMQ, just like various CMP implementations). This is not any fault of Hibernate or its many authors - it's the nature of the landlord.

Yes, people can contribute elsewhere, or even fork (and face Bill Burke's evil wrath!), but allow those of us who have watched JBoss for awhile a brief period of mourning and anguish. If you doubt the reasoning behind this, look at how JBoss has treated old partners (CDN, Rickard, et al). Look at old products sucked in and eventually spit out. Look at the _wording_ around JBoss 4 in describing components being replaced. Assuming JBoss survives, this _will_ happen to Hibernate as well some day.

I just want to point out to everyone reading this thread, that nothing that has been said here has not been thoroughly considered and debated by us Hibernate guys before entering into this!

We have a very clear vision of what we want for Hibernate - and that _certainly_ includes running inside and outside of any Java appserver - and we will not change this vision.

The feedback on this announcement (from actual Hibernate -users-) on the Hibernate devel list and forum has been very positive. Our users trust us and know that we would make the right decisions, in the best interests of the Hibernate project. In my email I -explicitly- laid out a bunch of stuff that will NOT happen - by everyone's complete agreement - and that stuff includes all the concerns that have been raised here.

I'm not going to try and argue with anyone - its completely pointless. They are just going to have to trust me. I would like to think I've earned this trust.

(And I would like to assure people that, contrary to Mike Spille's suggestion, I am quite capable of taking care of myself. This idea that I would somehow crumble under the force of Marc's personality is just insulting.)

> (And I would like to assure people that, contrary to Mike Spille's suggestion, I am quite capable of taking care of myself. This idea that I would somehow crumble under the force of Marc's personality is just insulting.)
>
> peace
>
> Gavin

No insult to you was intended, but I can certainly see where you might see one. And for that I apologize.

At the same time, please realize that from an outsider's viewpoint, you are now a JBoss Group employees, and the last time I checked employees of companies generally do what the company wants, not what they want themselves. There's something about getting a paycheck that makes a corporation think they can tell you what to do, for some bizarre reason.

A lot of posters on TSS are masquerading competitors. The Mike Spille
guy has it in for me because I've embarassed him a few times. I think
he is an alias anyways....

What's good is that there are 40 posts within a few hours. People care.
Shows that people care about Hibernate. About JBoss. This is a good
thing.

I do apologize though for some of the idiots on TSS. Although we did
send the announcement and related Hibernate forum links to TSS before I
posted to the JBoss mailling lists, it seems that TSS got the jboss-user
email first. They only posted my announcement on JBoss mail list. They
didn't post Gavin's email to TSS.

====================================================

From: Christian Bauer (christian@hi...)

> A lot of posters on TSS are masquerading competitors. The Mike Spille
> guy has it in for me because I've embarassed him a few times. I think
> he is an alias anyways....

Yeah, I expected that because he is just too stupid for a "real" person.

====================================================

A few things, fellas:

1) Stupid is as stupid does. Posting the above on a public mailing list I think out-does anything I may have done in recent memory.

2) In google, do the following search:

[ "Mike Spille" resume New York ]

I am the only result. I think you will find I am not a competitor

3) If it comes down to it a few people on TSS _do_ know who I work for at the moment. They know I do not work for any competitors to any J2EE vendor. I prefer not to divulge it so that my company's legal department do not fry my nuts on Park Avenue for kicks (it's a very legal & security conscious company).

4) Bill (may I call you Bill, since you've gotten so intimate?), embarrasment is a relative term. I think having an unknown individual (me!) have to point out, in public, how your statements about your own code don't actually match what your own source code does is far more embarassing then anything that has happened to me in recent memory.

5) To both of you treasured individuals: never post anything in public that you haven't personally verified. It's just plain dumb.

Wandering off topic ever so slightly... Mike, I've followed your posts in the past on the nuances of throughput and reliability in JMS - however having read your online resume (via your helpfully supplied google search terms :) I was slightly surprised to learn that you were using OpenJMS. Is it likely that any modifications you've made will be fed back into the OpenJMS codebase? I'm guessing probably not (unless you have unusually kosher employers), but there's no harm in asking, right? ;)

Meandering back onto the topic, as an avid hibernate user I'd just like to express my hope that the project will be strengthened by this announcement. I can understand the concerns that Hibernate could potentially become tied to the Jboss platform, and as someone who does not (and has no plans to) use JBoss, to an extent I share them. But Gavin has always had a very strong mission statement for Hibernate, and I trust him to continue to do the right thing. And whatever happens, this is far better than the project eventually crumbling under time and commercial pressures, right?

\Dave Hewitt\
Wandering off topic ever so slightly... Mike, I've followed your posts in the past on the nuances of throughput and reliability in JMS - however having read your online resume (via your helpfully supplied google search terms :) I was slightly surprised to learn that you were using OpenJMS. Is it likely that any modifications you've made will be fed back into the OpenJMS codebase? I'm guessing probably not (unless you have unusually kosher employers), but there's no harm in asking, right? ;)
\Dave Hewitt\

I've been working for awhile to get the general changes I've made fed back into the OpenJMS site, but it's a slow process in my company, and I'm uncertain how it will turn out in the end. As I mentioned, they're very security conscious, and the idea of publishing their source code is very radical to them. But there are also clear benefits involved in doing so (beyond altruism).

As it is, we went with OpenJMS because the code was very clean, very modular, had already implemented the bulk of features we needed, and had a BSD-style license. If was (L)GPL it would not have flown at all.

Mike: 3) If it comes down to it a few people on TSS _do_ know who I work for at the moment. They know I do not work for any competitors to any J2EE vendor. I prefer not to divulge it so that my company's legal department do not fry my nuts on Park Avenue for kicks (it's a very legal & security conscious company).

I'll vouch .. Mike's name is Mike, and he works in New York for a large "financial services" company that would fry his nuts if he told you who it is.

For those of you making app servers tools or whatever, Mike is what you could call "your potential customer". Or for those of you who have made various claims that Mike has diligently taken apart in piecemeal by downloading your product or your source or whatever and seeing if it actually works as advertised, and then instead of fixing the problem you resorted to attacking him (or just ignoring his findings), Mike is probably not going to be "your customer".

There are two ways to deal with criticism: You can accept it, assuming that that it has some basis in reality, and try to use it as a guide for improvement, or you can reject it and attack the messenger. The latter is a sign of immaturity or at best insecurity. The former doesn't imply that you have to like criticism (it doesn't personally make me feel good) and it doesn't imply that you even have to like the messenger, but it does imply that you have learned to respect the opinions of others, even when they disagree with you.

Unfortunately, it's not all criticism. Much of it was just FUD. :) By the time Mike probably got down to the actual critique I stopped caring what he had to say. If Mike was soooo innocent and high-minded, he would have *started* with critique and ended with FUD, at least. ;)

\Steve Lewis\
Unfortunately, it's not all criticism. Much of it was just FUD. :) By the time Mike probably got down to the actual critique I stopped caring what he had to say. If Mike was soooo innocent and high-minded, he would have *started* with critique and ended with FUD, at least. ;)
\Steve Lewis\

The critique actually started several months ago on several other TSS threads - I didn't copy them down here primarily from exhaustion. I also clearly labelled that this thread is primarily speculation on my part, and showed what I was basing that on - feel free to believe it or discredit it as you like.

As for "innocent and high-minded" - where did I ever claim either? My innocence was lost decades ago, and I've got too much code to write to be high-minded. I am, however, somewhat simplistic in my outlook - I expect people to tell the truth. This is what often gets me into the most trouble.

Thanks for the vouch, Cameron, and for the words after it. I realize my own personal style, or lack thereof, leaves something to be desired and can be contentious at times. At the same time, I generally stick with what I know, I'm constantly on the lookout for new technology and new techniques, and I'm not afraid to go document and code diving to find out the truth behind the marketing slogans. Every once in awhile I hit pay dirt, with something like AspectJ, or as it happened with OpenJMS over a year ago.

But the thing that's guaranteed to kick my contentious-ness level up a notch or seven are misleading technical claims, as well as misleading marketing claims (the latter I usually ignore, however, marketing being marketing). More importantly, it kicks up alot of other people's "I-will-not-use-them" levels up a notch or seven as well - people like technology purchasing decision makers.

In the case of JBoss, they have a history, whether they like it or not. A very checkered history. At this point, when they make an announcement like this, they should expect their history to come up in public forums. You'd think they'd have a plan to deal with it, but apparently not. By not having a plan, and by ranting and raving in public about the injustice of the world, at best they're confirming people's preconceptions about the JBoss Group (I'll leave it up to the reader to fill in their own preconceptions :-).

Anyway, while it's a hopeful sign for Jboss Group that Bela and Gavin are on board, it's not a layup. For two simple reasons: Mr. Fleury still owns and runs the company, and Mr. Burke is still the Chief Architect. On the one hand, a guy who tears all over the place from day to day and focus to focus who changes strategic direction like the wind, and on the other hand a 20-something Chief Architect who doesn't have it in him to say "whoops, I screwed up, my bad". In a sane world you'd think Gavin or Bela would be in charge of the technical side - they've got the creds, and they've got the integrity, and even someone like _me_ would take their word at face value. But those guys, good as they are, are not in charge, and are are bossed by Mr. Fleury and Mr. Burke.

Bring things back to Cameron's point: people like Bela and Gavin can clearly take criticism, and learn from it, and dish it back out when it makes sense - and their own products show this in spades. Mr. Fleury and Mr. Burke just as clearly cannot stand any sort of criticism, ignore that which is uncomfortable for them, and live mostly on a mix of arrogance and hubris. Maybe the Gavins and Belas in the new JBoss mix will turn the boat around, and their influence and ideals will dominate - or maybe the Gavins and Belas will be chafe under the "direction" of their corporate superiors, and end up abandoning the ship sometime in the future just like the CDN folks did.

[Cameron]
There are two ways to deal with criticism: You can accept it, assuming that that it has some basis in reality, and try to use it as a guide for improvement, or you can reject it and attack the messenger. The latter is a sign of immaturity or at best insecurity.

... (it doesn't personally make me feel good) and it doesn't imply that you even have to like the messenger, but it does imply that you have learned to respect the opinions of others, even when they disagree with you.
[Cameron]

I could not have said it better. As a Hibernate user (my favorite open source tool) the reaction to what should have been antcipated criticism disturbes me. I think Gavin has handled it well, but some of his "lieutenants" have not.

Mike, I knew that was you. Hey, congrats, I didn't know you got married last year. Good for you.

To all, I'll vouch for Mike because I know him personally and I worked with the guy for about a year in New York. I've been in this field for about 5 years now and I have yet to meet someone as knowledgeable and technically talented as him. I'm serious. He really knows his shit and I wouldn't discount his opinions or his posts, no way.

On the other hand, I can't get over the rambling nonsense that goes back and forth at this place. This is one of the reasons why I stopped posting; it can really get a guy worked up! Is it so difficult to respect another persons opinions and ideas? I'm sure Bill deserves respect as well and for that I don't know why so many people are "playa haters" towards JBoss. Practically every new post relating to JBoss in some way ends up being flame bait for the masses at this place. Damn shame, really. Don't forget that we are all in the same boat, conceptually speaking, of course, in that we share a common interest in J2EE technology, software, blah, blah, whatever....so why not show more respect to each other? I guarantee you'll get a warm and fuzzy feeling inside when you respect each other. Who knows, you might be driving along one day and find yourself swerving off the road in an ice storm and hanging on for dear life just before you fall off a cliff when suddenly you realize that the only person around for 200 miles is driving by, but the guy unfortunately is the same person you insulted on TSS last month and all he does is laugh (really hard) while he watches you die.

Now, all of you, be happy and go make a friend, plant a flower or some shit and ponder about the wonders of the world...

Raffi, I hear what you're saying (and am flattered by your characterization). But does everyone universally deserve respect? If you have 10 conversations with someone, and in all 10 conversations at least one factually wrong statement is forcibly asserted by that person, what do you do? Do we give honors to the man who insists the sky is red?

No, of course not, not universally. The guy that insists the sky is red is more than likely related to the Bat Child, who can be seen on the cover of The Globe Weekly, a very credible magazine. Actually, that was a joke, but it makes a very clear point. I wouldn't give honors to someone who is flat-out, plain-as-day, in-your-face wrong. I would respect someone who has ideas and opinions different from me, as long as they are decent and/or contributing persons of society. I may not agree or like the culture at Microsoft, but I definitely respect them as a company for all they have contributed to the world.

I wouldn't give the least bit of respect to a crack whore for obvious reasons.

Ahh, whatever, it's all forgotton a few minutes later, what's the point! :-)

I have to chime in here and say that I agree with the mutual respect that should be obvious in every public forum. I also apologize for the "not real stupid person" phrase I posted. As my excuse, I can only add that it is very difficult to say nice things if you have way too much work to do. For everyone involved in Hibernate, the last year has been very successful, but the project also consumed all of our spare time and most weekends.

I think the real power of the LGPL and Open Source in general is to prevent exactly what some posters fear will happen, but I also agree that some of the arguments ("Best Hibernate only with JBoss") are valid. I just miss the point where this is a bad thing... If its technically possible to have a feature outside outside JBoss, everyone can do that. There are some things with persistence layers that are just not possible in Java if you don't control most of the execution environment, Bill named some in one of his postings. But all parties here agreed that it is one of the most important objectives to have a standalone Hibernate fully supported. Nothing will change for you if you don't want any change.

Christian, it's not necessary to apologize, but I strongly appreciate the sentiment behind it anyway. And having done so myself on more than one occasion, I can appreciate how difficult it can be sometimes. But, in fact, many arguments such as this go on for far too long because someone is too afraid or too embarrassed, or too hubristic, to admit that they have made a mis-statement or committed an error.

On the rest of your post - code is important, but people are even infinitely more so. Copy/fork/steal a piece of code and you get a snapshot of what exists today - often a very complicated snapshot :-) Hire the person who _wrote_ that code, and you get not only their present knowledge but future potential and ideas as well. We all know (except perhaps Mr. Burke) that the generic codebase of JavaGroups is suffering somewhat due to Bela's work with JBoss caching and other work, and we expect something similar to happen with Hibernate. I don't expect support to drop, but I expect the best and brightest efforts to go into JBoss integration and value enhancement, and somewhat less effort into non-Jboss areas. As I said in another message, this may be a good thing for JBoss Group, and it appears to be a fabulous thing for Gavin, but it's not the greatest news in the world for those of us who don't use JBoss.

As I said in another message, this may be a good thing for JBoss Group, and it appears to be a fabulous thing for Gavin, but it's not the greatest news in the world for those of us who don't use JBoss.
>

Mike, READ GAVIN'S MAIL and stop the conspiracy theories. He says that he used to work at night on Hibernate and now he can work FULL TIME because we sponsor him. That has got to be THE GREATEST NEWS for those of you that use hibernate, with JBoss or not. PEEEE-REEEE-OOOOD.

This will probably drive ya nuts, but let's apply some old fashioned logic to your statements, Mr. Fleury:

- In your "White" paper, you state "We have a policy of allocating 50% of our time to coding JBoss and 50% of our time to professional services. It keeps us real and focused". This point is apparently so important it's in a call-out box in like 18-point type.

- Hibernate will be the basis of JBoss 4's CMP implementation. I imagine it will take Gavin more than a day or two to re-write your CMP engine from scratch.

- Gavin has shown a huge amount of glee to the idea of having a life again. I assume this means he won't be coding non-JBoss Hibernate at home afterhours and on weekends after coding JBoss CMP all day "at work".

So JBoss people spend 50% of their time out on billing, and almost certainly the other 50% for Hibernate people will be the CMP implementation.

I see how this is good for JBoss, but tell me - - how's this good for Hibernate? Where exactly will Gavin be finding time to do non-JBoss stuff?

This will probably drive ya nuts, but let's apply some old fashioned logic to your statements, Mr. Fleury:

>
> - In your "White" paper, you state "We have a policy of allocating 50% of our time to coding JBoss and 50% of our time to professional services. It keeps us real and focused". This point is apparently so important it's in a call-out box in like 18-point type.
>

50% maximum. Being exposed to customers is an advantage, not a weakness.

> - Hibernate will be the basis of JBoss 4's CMP implementation. I imagine it will take Gavin more than a day or two to re-write your CMP engine from scratch.
>

Alex Loubyansky is the CMP Lead and has done most of the maintenance of it since January. He is the one responsible for CMP/Hibernate integration. Gavin is there to help. In fact, we explicitly stated in Gavin's contract that he would not be the primary developer for the CMP/Hibernate integration. The reason being, we want him to focus on Hibernate and the JDO 2 committee, because in all honesty, this is the future of Java persistence. CMP over HIbernate is Alex's job and he has already begun.

> - Gavin has shown a huge amount of glee to the idea of having a life again. I assume this means he won't be coding non-JBoss Hibernate at home afterhours and on weekends after coding JBoss CMP all day "at work".
>

Gavin does not sleep AFAICT. He is on Australia time, and I am on EST, yet he is always available on MSN Messenger, day or not when I've wanted to talk to him. Trust me, if you work on an open source project in your spare time for too long, you start to burn out. I did this with JBoss for over 12 months before I joined and my wife was quite pissed that I burned the midnight oil many nights.

> So JBoss people spend 50% of their time out on billing, and almost certainly the other 50% for Hibernate people will be the CMP implementation.
>

Wrong.

> I see how this is good for JBoss, but tell me - - how's this good for Hibernate? Where exactly will Gavin be finding time to do non-JBoss stuff?
>
> -Mike

Also, as I said in the original announcement, Hibernate is a big part of our POJO-based strategy that we are pursuing.

======================================================
So happens that I'm bored tonight and have nothing better to do (a sad comment, I know), so I decided to run through all the TxCache with some discipline to really figure out what it does.

My findings don't quite match the postings here. This is based off of the CVS Head that I downloaded a few days ago, most files are dated July 8th or earlier (except for DistributedTxCache, which I haven't looked at).

First the summary, then the running commentary on what's happening. Only the truly die-hard will read the running commentary, I figure.

Summary:

- Versions are indeed held per field.
- Each object has one global "workspace", which holds all the per-field workspaces.
- workspace creation is triggered on the first _update_.
- read operations never create a workspace, but they may access it
- It looks like if a transaction has started, reads will break (unless
someone's written first).
- Dirty, inconsistent reads look quite likely, especially if you read
first in your tran, then write, then read some more.
- There's two sets of stuff: DistributedXXX, and VersionedXXX. Following from TxCache, it looks like only the DistrubtedXXX stuff gets used.
- The Versioned stuff looks unused. Maybe it was used in DR2 but got switched around in the cvs head? I dunno. The Versioned stuff is indeedy one version per object, not per attribute.
- My headache has come back and re-trebelled, so perhaps I've misread it all, and wasted my time.
======================================================

Mr. Burke, I didn't ask you - why would I? Where have you proven that what you say is accurate?

>
> But, I'll tell you what - here's the capsule summary from:
>
> TxCache Diving >
> Try to respond to it openly and honestly, and maybe there's hope that your words are worth something. Give it your usual silent treatment when someone speaks an uncomfortable truth, and, well, we'll know what your words mean.
>
> ======================================================
> So happens that I'm bored tonight and have nothing better to do (a sad comment, I know), so I decided to run through all the TxCache with some discipline to really figure out what it does.
>
> My findings don't quite match the postings here. This is based off of the CVS Head that I downloaded a few days ago, most files are dated July 8th or earlier (except for DistributedTxCache, which I haven't looked at).
>
> First the summary, then the running commentary on what's happening. Only the truly die-hard will read the running commentary, I figure.
>
> Summary:
>
> - Versions are indeed held per field.

Yes. On a write a version is created.

> - Each object has one global "workspace", which holds all the per-field workspaces.

Yes.

> - workspace creation is triggered on the first _update_.

Yes.

> - read operations never create a workspace, but they may access it

Yes true. Later I want read operations to either a) create a workspace for the field they are reading and b) trigger a workspace for the entire object. Since I already have per-field snapshots created per writes, it is very trivial to add A and B. In other words:

A enables Repeatable Reads for fields read within a transaction

B enables Repeatable Reads for the entire object.

As the code is constituted now, it gives READ_COMMITTED behavior at the field level. Whether or not field-level READ_COMMITTED behavior makes sense or is usable or not is debateable, but I think it is. The A and B functionality I describe above can easily be added though, and I want this to be configurable at the cache level, or even per class or field via JBoss AOP metadata.

> - It looks like if a transaction has started, reads will break (unless
> someone's written first).
> - Dirty, inconsistent reads look quite likely, especially if you read
> first in your tran, then write, then read some more.

Dirty reads cannot happen. When a read happens, it asks a TransactionLocal object is there is a transctional copy of that particular field, that is, has this transaction ever changed that field. If it hasn't, then it pulls the field value from the global workspace. The TransactionLocal is similar to ThreadLocal, but is a per transaction data rather than per thread data. Get me? At commit time, the Synchronization object pulls the changed fields from the TransactionLocal object, locks all affected objects, and does the optimistic checks. Rolls back if any field versions conflict. At commit, it updates fields (global workspace) with the new values and releases the locks.

Now, do we have field-level Repeatable Reads? No. Not all data has the requirement of being repeatable. But functionality A and B described above can be easily implemented. The code is there and easily extended.

> - There's two sets of stuff: DistributedXXX, and VersionedXXX. Following from TxCache, it looks like only the DistrubtedXXX stuff gets used.

Distributed and Local. Local is a non-replicated cache.

> - The Versioned stuff looks unused. Maybe it was used in DR2 but got switched around in the cvs head? I dunno. The Versioned stuff is indeedy one version per object, not per attribute.

This stuff was a first play with field interception. It is a relic. Quick and dirty proof of concept.

> - My headache has come back and re-trebelled, so perhaps I've misread it all, and wasted my time.

You're probably the first person to actually look at the code besides myself. Thanks. If you see any bugs pop me an email(bill at jboss dot org) or even better, post them to the AOP forum at jboss.org. TSS isn't the greatest place to discuss design, because, well, I don't always read it.

As far as Bela's stuff, he does pessimistic locking at the object level. We did different implementations because I was trying to optimize for POJOs and wanted to try optimistic locking at the field level. Bela is also interested in having a common codebase that can support a persistence layer as well, where I wanted to focus on pure in-memory pojos only.

The whole point of AOP based caching though is to make POJO caching, replication, and ACIDity transparent. We have achieved this and will work to improve the design and enhance the functionality and beef up the performance over time.

From my recollection, each Advisable object (recursively through the Graph) has versioned info attached to it as it is inserted. This may apply to primitives as well but my memory is dimmer there. A write within a transaction then triggers creation of a new version held in the workspace area. This has two implications:

- Memory requirements. There are several objects per field.
- Access speed - access of variables is through the versioning mechanism, not direct reference, once you're inserted into the cache.

\Burke\
> - read operations never create a workspace, but they may access it
[Info on read operation and workspace creation]
\Burke\

Yeah, what you say makes sense.

\Burke\
> - It looks like if a transaction has started, reads will break (unless
> someone's written first).
> - Dirty, inconsistent reads look quite likely, especially if you read
> first in your tran, then write, then read some more.

Dirty reads cannot happen. When a read happens, it asks a TransactionLocal object is there is a transctional copy of that particular field, that is, has this transaction ever changed that field. If it hasn't, then it pulls the field value from the global workspace.
\Burke\

Note that the above, on a read, uses the TX workspace if there is one, other wise it uses the regular field map. If you skip over to fieldWrite(), you'll find that it creates the workspace _but only adds the written field to the TX workspace_. The read-fields are never added to the workspace from what I can see.

The 2 reads should work. The write should work and create a new field version. The read field C will work and get the transaction field
version. The next read Field A, it appears, will return a NullPointer.

On the side of looking at multiple transactions running simultaneously, you have similar problems do the fact that version checks don't happen on read stuff, only on write stuff. Since there's only optimistic locking, and you don't check/track read versions, in code like this:

- tran A
read field 1
read field 2
read field 3

- tran B
write field 1
write field 3

...based on my read of the code, if trans A and B are running simultaneously, there's a race condition where tran A can read field 1 and 2, then tran B can take over, write field 1 & 3 and commit, then tran A can read the new field 1 value (and get inconsistent state).

The problem isn't really with any specific piece of code, but more conceptual and built-in to the design - optimistic locking and reads that don't create a workspace/version couple together to almost guarantee that you can read inconsistent state in a transaction.

\Bill Burke\
This stuff was a first play with field interception. It is a relic. Quick and dirty proof of concept.
\Bill Burke\

Communication and documentation (and image) are, IMHO, important. You call this code a quick and dirty proof of concept and a relic. What _I_ see is that TxCache and some relatives on the JBoss 4 AOP page are the only _documented_ aspects, and the tone and nature of the documentation suggestions that they're rugged, usable, and will be around for awhile.

This ties into what I've said before about JBoss documentation and developer comments in various forums vs. the actual state of the code - and the developer's intentions viz a viz the future direction of the code. If you want people to get hot and bothered about something new - like JBoss AOP and it's prepackaged aspects - they're going to want direction, stability, and docs on how it's supposed to work. Right now there's alot of shifting sands, and people like me will either just give up in frustration, or be forced to spend several hours sifting through the code. And even the latter may be a waste of time without an indication of future directions - as you said, TxCache is a quick and dirty relic, presumably to be replaced or redone with big semantic changes along the way, so my time was utterly wasted. But meanwhile this is what's advertised on your Web site, talked about in Interviews, discussed in detail on public forums. It's very frustrating, and not something calculated to endear people to you or the new stuff.

> > - Versions are indeed held per field.
>
> Yes. On a write a version is created.
> \Burke\
>
> From my recollection, each Advisable object (recursively through the Graph) has versioned info attached to it as it is inserted. This may apply to primitives as well but my memory is dimmer there. A write within a transaction then triggers creation of a new version held in the workspace area. This has two implications:
>
> - Memory requirements. There are several objects per field.
> - Access speed - access of variables is through the versioning mechanism, not direct reference, once you're inserted into the cache.
>
> \Burke\
> > - read operations never create a workspace, but they may access it
> [Info on read operation and workspace creation]
> \Burke\
>
> Yeah, what you say makes sense.
>
> \Burke\
> > - It looks like if a transaction has started, reads will break (unless
> > someone's written first).
> > - Dirty, inconsistent reads look quite likely, especially if you read
> > first in your tran, then write, then read some more.
>
> Dirty reads cannot happen. When a read happens, it asks a TransactionLocal object is there is a transctional copy of that particular field, that is, has this transaction ever changed that field. If it hasn't, then it pulls the field value from the global workspace.
> \Burke\
>
> That description doesn't seem to match the code, unless I'm missing something obvious. From DistributedPOJOState.java:
>

You are missing something not so obvious. The not so obvious part is that the global workspace uses the DistributedFieldUpdate class to hold field values, the TX map uses the same class. What is misleading is the name of the the variables.

The getTxState method accesses a TransactionLocal object. This object holds a HashMap of updates PER TRANSACTION. So.

HashMap map = getTxState() returns the hashmap of updates that CURRENT transaction has done. If that particular transaction hasn't updated the field, the value is pulled from the "real" global field map. Hence there are no dirty reads. (For those not know, dirty reads are reads of non-committed data between transactions.)

I can add REPEATABLE READS quite easily by implementing a DistributedFieldRead class that holds the copied field value and the current version ID and moving the optimistic locking function inside both the DistributedFieldUpdate and the new DistributedFieldRead classes as a polymorphic method. In fact, I think I will do this tonight.... :) Thanks for the motivation.

Yes, and I stated this before. The behavior, isolation level, is READ_COMMITTED at the field-level. I've been wanting to add REPEATABLE_READ for read fields for some time and it is just a matter of adding the read field to the TX workspace on a read, or adding the whole object's state to the TX workspace on the first read. I stated this in my above post.

Again READ_COMMITTED at the field level, but not REPEATABLE_READ.

>
> So I'd try the following (in psueudo-code):
>
> - start trans
> - read field A
> - read field B
> - write field C
> - read field C
> - read field A
> - commit
>
> The 2 reads should work. The write should work and create a new field version. The read field C will work and get the transaction field
> version. The next read Field A, it appears, will return a NullPointer.
>
> On the side of looking at multiple transactions running simultaneously, you have similar problems do the fact that version checks don't happen on read stuff, only on write stuff. Since there's only optimistic locking, and you don't check/track read versions, in code like this:
>
> - tran A
> read field 1
> read field 2
> read field 3
>
> - tran B
> write field 1
> write field 3
>
> ...based on my read of the code, if trans A and B are running simultaneously, there's a race condition where tran A can read field 1 and 2, then tran B can take over, write field 1 & 3 and commit, then tran A can read the new field 1 value (and get inconsistent state).
>

This isn't inconsistent state, this is READ_COMMITTED behavior. As I said, with the current implementation you will not get REPEATABLE READS. The code structure is there to add this behavior (See above)

> The problem isn't really with any specific piece of code, but more conceptual and built-in to the design - optimistic locking and reads that don't create a workspace/version couple together to almost guarantee that you can read inconsistent state in a transaction.

Again it is a matter of isolation level. Is READ_COMMITTED isolation useful at the field level? IMHO, yes. Can we narrow the isolation level? Quite easily, IMO.

>
> \Bill Burke\
> This stuff was a first play with field interception. It is a relic. Quick and dirty proof of concept.
> \Bill Burke\
>
> Communication and documentation (and image) are, IMHO, important. You call this code a quick and dirty proof of concept and a relic. What _I_ see is that TxCache and some relatives on the JBoss 4 AOP page are the only _documented_ aspects, and the tone and nature of the documentation suggestions that they're rugged, usable, and will be around for awhile.
>

I did not document the Versioned*.java classes.

> This ties into what I've said before about JBoss documentation and developer comments in various forums vs. the actual state of the code - and the developer's intentions viz a viz the future direction of the code.
> If you want people to get hot and bothered about something new - like JBoss AOP and it's prepackaged aspects - they're going to want direction, stability, and docs on how it's supposed to work. Right now there's alot of shifting sands, and people like me will either just give up in frustration, or be forced to spend several hours sifting through the code.

This may or may not be a lame excuse, but it is a developer release. As the saying goes "Release early, release often." This is what we tried to do. TSS is not the place to discuss design. The AOP forum at www.jboss.org is.

Hmmm...Geronimo is allowed to post a State of the Union on non-functional code, but we are not allowed to stick a stake in the ground on our aspect-oriented middleware? Give me a break... I think the direction is clear. We want ACID, replicatable cached POJOs. Transparent remoting. Transparent clustered remoting. J2EE a la carte, and POJO persistence a la Hibernate. I agree the docs are lacking, but IMNSHO, we have a functional code base to build upon for the real beta and production releases of JB4.

\Bill Burke\
You are missing something not so obvious. The not so obvious part is that the global workspace uses the DistributedFieldUpdate class to hold field values, the TX map uses the same class. What is misleading is the name of the the variables.

The getTxState method accesses a TransactionLocal object. This object holds a HashMap of updates PER TRANSACTION. So.

HashMap map = getTxState() returns the hashmap of updates that CURRENT transaction has done. If that particular transaction hasn't updated the field, the value is pulled from the "real" global field map. Hence there are no dirty reads. (For those not know, dirty reads are reads of non-committed data between transactions.)
\Bill Burke\

As my comments in the other thread indicated, I am fully aware of the DistributedFieldUpdate class and how it is used. And sorry on the terminology slip on "dirty reads" - you're correct.

What you're missing is that once the txState has a map, the fieldRead() method will always use that map - and it is not populated on reads, only on writes. Try some examples in a transaction that does read field A, write field B, read field C, read field A, and see what you get.

\Bill Burke\
Yes, and I stated this before. The behavior, isolation level, is READ_COMMITTED at the field-level. I've been wanting to add REPEATABLE_READ for read fields for some time and it is just a matter of adding the read field to the TX workspace on a read, or adding the whole object's state to the TX workspace on the first read. I stated this in my above post.
\Bill Burke\

You have sort-of READ_COMMITTED, modulo the bug above where reads are going to the txState workspace and the field isn't there.

Given that you do optimistic locking, it's a bit surprising that the optimistic part only works on write fields, and that certainly couldn't be divined by looking at the AOP page, and you wouldn't explain it until I had to go code diving. The reason to avoid REPEATABLE_READ is to avoid database read locks. But since you're doing field versioning and optimistic locking, there's no performance reason to avoid a REPEATABLE_READ.

Anyway, that's a whole 'nuther can of worms. The fundamental point was that you're trying to sell this "J2EE a la carte", which _will_ lock people into your code, and the code in question is very, very badly documented. And there is no J2EE spec this time that can do the documentation for you. I've had to go to extraordinary lengths just to get you to acknowledge that your code uses READ_COMMITTED, which may have been a giant surprise to anyone using the code. I've documented an outright bug where reads won't work at all, and you've glossed right over that.

\Bill Burke\
This may or may not be a lame excuse, but it is a developer release. As the saying goes "Release early, release often." This is what we tried to do. TSS is not the place to discuss design. The AOP forum at www.jboss.org is.
\Bill Burke\

This is not a universally accepted approach - release early, release often. In fact it's been rather tarnished since the dot-com bust.

As for where to post - you are no more forthcoming on the JBoss forums then you are here. What motivation do _I_ have to post there?

\Bill Burke\
Hmmm...Geronimo is allowed to post a State of the Union on non-functional code, but we are not allowed to stick a stake in the ground on our aspect-oriented middleware? Give me a break... I think the direction is clear. We want ACID, replicatable cached POJOs. Transparent remoting. Transparent clustered remoting. J2EE a la carte, and POJO persistence a la Hibernate. I agree the docs are lacking, but IMNSHO, we have a functional code base to build upon for the real beta and production releases of JB4.
\Bill Burke\

The Geronimo folks have been very forthcoming with the exact state they're in, and given that they're going for J2EE, it's pretty clear how things should work.

JBoss, on the other hand, has not been very forthcoming at all. You want to sell people on your new Aspects - buggy, very poorly documented aspects under the control of no specification, with a Chief Architect who would rather walk over hot coals then give a straight answer to a technical question. There's competing code within your own organization, and lots of confusion as to which code (and person) is correct - is it TreeCache, TreeCacheAOP, or TxCache? The message you're sending to users and potential users is pretty clear: chaos, mass confusion.

To sum up my perspective: Yourself and Mr. Fluery consistently keep trying to tell us what JBoss is trying to accomplish in the most general terms possible. Generalization is indeed the word of the day. Based on the current AOP docs, and docs for older JBoss portions, I have no expectation that the AOP documentation will improve as the final release date hits. Given that you're venturing outside of J2EE, this means that JBoss' rather incomplete docs are the only spec people will have. Worse - if someone posts a question, Bela will answer one way, you'll answer another, and most likely a third JBoss person will offer yet a third incompatible answer. Hell, it took me over a month to get you to explain how TxCache works, you fought the whole way, and it wasn't until this thread that you started admitting the real details.

If you want to know why people are cutting Geronimo slack, it's because they've been honest and forthright, they state clear goals, clearly state current limitations, and they'll give you a straight answer to a straight question. You have demonstrated in spades that people should not expect the same behavior from JBoss people.

You tried arguing in good faith wiht technical arguments. Do what I do, I can smell people with agendas from miles away. At this point the discussion sucks and is steeped in bad faith from spille. Bad faith is difficult, whatever you say they aim for your bum-hole... Do what I do, ignore bad faith as you get smeared any way by crazy people.

Ignore and move on. The market will decide, not the crazied and angry jboss bashers. Talke to the sensible 'mass' not the crazy wild datapoints.

\marc fleury\
You tried arguing in good faith wiht technical arguments. Do what I do, I can smell people with agendas from miles away. At this point the discussion sucks and is steeped in bad faith from spille. Bad faith is difficult, whatever you say they aim for your bum-hole... Do what I do, ignore bad faith as you get smeared any way by crazy people.
\marc fleury\

If you followed the entire thread, over-agressive argument was the only way to get anyone from JBoss to actually disclose what this piece of code actually does. Thanks to this "crazy person", people have a much clearer idea of what TxCache does, and can much better evaluate whether it makes sense for them to use it in their own code. At the same time, I've pointed out a fairly lethal bug in the code that's trivial to fix.

\marc fleury\
Ignore and move on. The market will decide, not the crazied and angry jboss bashers. Talke to the sensible 'mass' not the crazy wild datapoints.
\marc fleury\

I admit it can be subtle at times, but I'm not a Jboss basher. I just really, really hate it when people make incredibly vague technical statements - and this goes doubly so for boasts along the lines of "we will own 99% of the market". Most of what I've done in this thread and others is to strip away the buzz words and marketing-speak, and shown what your codebase actually does (as opposed to what it's claimed to do). And in a peverse and ironic twist, I think Bill Burke has learned more about Bela Ban's code here on TSS than anywhere else. And Bela has learned more about Bill Burke's code on TSS.

The crazy person, and JBoss basher, has also left a giant bread crumb trail of information that you could easily roll up and stick on your web site that would improve the AOP documentation by an order of magnitude. But apparently, you're so pissed off at someone criticizing your precious baby that you don't see the benefits in that criticism. Yes, there has been some negative speculation in this thread, and some pretty tenuous theoretical scenarios posted, but in between there has been very solid technical observations.

Many times you can learn alot more from honest and accurate criticism then you can from a bunch of yes-men and cheerleaders.

We all know (except perhaps Mr. Burke) that the generic codebase of JavaGroups is

> suffering somewhat due to Bela's work with JBoss caching and other work

Mike, I have to disagree strongly. If you look at the CVS commits for JGroups (on SourceForge) over the last couple of months, you'll see that my work on JGroups remained about constant.

I had one month paid by JBossGroups, in which I wrote the TreeCache code for them.

All the CVS commits on JGroups, all the emails I diligently reply to on the jg-dev or jg-users mailing lists, prove that I haven't invested less time in JGroups. Ask anyone on the mailing lists, and they will tell you thatI usually respond within 24 hrs to any question.

But be aware that all of this was done in my spare time. Now, with me joining JBG, I can do all of this and MUCH MORE broad during daylight :-)

We all know (except perhaps Mr. Burke) that the generic codebase of JavaGroups is

> > suffering somewhat due to Bela's work with JBoss caching and other work
>
>
> Mike, I have to disagree strongly. If you look at the CVS commits for JGroups (on SourceForge) over the last couple of months, you'll see that my work on JGroups remained about constant.
>
> I had one month paid by JBossGroups, in which I wrote the TreeCache code for them.
>
> All the CVS commits on JGroups, all the emails I diligently reply to on the jg-dev or jg-users mailing lists, prove that I haven't invested less time in JGroups. Ask anyone on the mailing lists, and they will tell you thatI usually respond within 24 hrs to any question.
>
> But be aware that all of this was done in my spare time. Now, with me joining JBG, I can do all of this and MUCH MORE broad during daylight :-)
>
> Bela

Add to this that JavaGroups is a VERY STABLE codebase and VERY WELL documented project already. Bela actively recruits people to work on JavaGroups and the Cache as well as leads them to his vision. This is called being a project lead.

Bill wrote: "Over the past year, I can't tell you how many times we've encountered customers that are using Hibernate or are looking to use Hibernate to replace the clunky design that EJB CMP is.
Technically this is a perfect marriage for both projects. We at JBoss have been looking at replacing our aging CMP persistence for over a year now in JBoss 4.0."
==============
Aging CMP persistence for over a year? Was it when JBoss 3.0.2 was just out and when JBoss 3.2 was in an early alpha status?

Here is what Mark Fleury wrote in December 2002 ("Why I Love EJBs", http://www.jboss.org/modules/html/blue.pdf, pp. 6-7): "CMP 20 persistence, mon amour", "In fact I would argue that CMP2.0 is doing what JDO failed to do, providing a robust and frameworkworthy persistence engine for java (once generalized). While it was widely used in designs a year ago, JDO will probably go down in history as the proverbial chicken that crossed the road when the CMP2.0 truck came along."

Well, everybody makes mistakes, and changing your mind and building CMP on a top of JDO and Hibernate (which should be JDO 2 compliant as I get this) is definitely a brilliant idea flowing in air for at least 2 years. Especially if the lead developer of the current CMP engine leaves the project, as it happened with Dain Sundstrom in August 2003.

Bill wrote: "Over the past year, I can't tell you how many times we've encountered customers that are using Hibernate or are looking to use Hibernate to replace the clunky design that EJB CMP is.

> Technically this is a perfect marriage for both projects. We at JBoss have been looking at replacing our aging CMP persistence for over a year now in JBoss 4.0."
> ==============
> Aging CMP persistence for over a year? Was it when JBoss 3.0.2 was just out and when JBoss 3.2 was in an early alpha status?
>

Our CMP 2 implementation has its roots in our CMP 1.1 JAWS implementation that is over 3 years old.

> Here is what Mark Fleury wrote in December 2002 ("Why I Love EJBs", http://www.jboss.org/modules/html/blue.pdf, pp. 6-7): "CMP 20 persistence, mon amour", "In fact I would argue that CMP2.0 is doing what JDO failed to do, providing a robust and frameworkworthy persistence engine for java (once generalized). While it was widely used in designs a year ago, JDO will probably go down in history as the proverbial chicken that crossed the road when the CMP2.0 truck came along."
>

Ask Gavin what he thinks about JDO 1. Also notice Marc's comment "once generalized". The generalization was promised, but just never delivered.

I still love EJB's the technology behind it, generalized indirection and interception is AOP-light and everything we do still comes from that solid and standard foundation.

> > Aging CMP persistence for over a year? Was it when JBoss 3.0.2 was just out and when JBoss 3.2 was in an early alpha status?
> >
>
> Our CMP 2 implementation has its roots in our CMP 1.1 JAWS implementation that is over 3 years old.
>

The CMP implementation in JBoss was not as good as it could be, it was good, it worked. It was not the same level of quality as the rest of the code. It was never refactored and the author of it never was able to refactor of it. Hibernate was in the works FOR A LONG TIME and building CMP and JDO on top of it makes sense.

CLEANING UP OUR HOUSE WAS IN ORDER. Getting a quality implementation in JBoss and then standard faces in JBoss (CMP JDO) is a clear way to go. That is all we are saying. Start taking what we say at face value.

> Ask Gavin what he thinks about JDO 1. Also notice Marc's comment "once generalized". The generalization was promised, but just never delivered.
>

The dream of transparent persistence is still a very valid one, Hibernate and JDO are pursuing it, JBoss will support both. Persistent interceptors are already present in JBoss and we are not far from "aspectization". The generalization is pure POJO support with the right configurations in XML for mapping and relations. Every spec has got some things right and some things wrong (CMP relations rule, abstract getters/setters suck make it transparent etc).

I think the persistence aspect is a couple of month away and then we will be done from a usage standpoint and optimization will be isolated. That is a very clear/crisp/simple technical image.

Congratulation to Hibernate and JBoss! It's good to hear that Open Source business model works good ;-)

To all that complains and worries that Hibernate will be dependent on JBoss:
C'mon, think about components. A good software developer - and Gavin is surely one of the best - will never add circular dependency (-> means depends on):

JBoss -> Hibernate
Hibernate -> JBoss

Building components mean "independency" as far as possible:
Hibernate is stand-alone (because this component can be re-used everywhere, not only in JBoss projects). JBoss server could add a dependency to Hibernate by adding a "glue component" like JBoss-Hibernate (just like JBoss-MQ, etc.).

At the end they will surely build some common components/libraries like Jakarta project common libraries, which can be used everywhere at all the JBoss projects. And this is the way to go, IMO. What I would love to see, is actually that JBoss, Apache, ObjectWeb, OpenSymphony, Tigris, etc. could make !ONE! general Common Libraries together (if the licenses are compatible) by building an ontology, so we never had to search for some common things again and again (Giant Java Tree has tried but fails I think...).

At the end they will surely build some common components/libraries like Jakarta project common libraries, which can be used everywhere at all the JBoss projects.

Love you too, Lofi.

I guess, since Gavin just started burning, that he has to serve at least 80 JBG support contracts now to earn the money. Of course, all Hibernate contacts will be added to JBG marketing mailing lists. So if you are a Hibernate user, expect a lot of spam. Absorbing Hibernate into JB (sucking in) will take about 1 year after which Gavin is burned out anyway and needs to get kicked out.

A nice review of this issue, straight to the point, can be found here.

>
> he he he
>
> -- Andreas

You call JBoss evil?

What about Apache.org? Who do you think funds them? Ever hear how IBM screwed the Jetspeed project? All the BS you spew about how JBossGroup is tarnishing open source, Hibernate, and JavaGroups, go look what takes place at Apache.org every day! Look at the AXIS project, IBM takes what's there, extends it for Websphere and sells it. Everybody states how EVIL JBoss Group is and bad for open source, but have they ever tried to distort the integrity of open source. The LGPL license and the fact that all their contributors retain copyright, shows , IMO how they feel about the integrity of open source. What about MySQL? They own all copyrights and distribute under GPL. Of course, you can buy a proprietary license from them so you don't get the virality of GPL. What about RedHat? They sell their distributions! Even have proprietary add-ons that they sell. Does JBoss Group sell software?

All JBoss Group does is sell services on the open source project that they run and manage. No different than what the PostgreSQL guys do.

I don't know what your beef with JBoss Group is, but go bash on other companies and organizations that are really and truly exploiting open source.

So? IBM didn't take away anything, but rather sells an extended version. Perfectly okay with the Apache License, which is deliberately more free than the (L)GPL in this respect (free in its original meaning, not the distorted GNUspeak version).

C-- There has been recent outbursts from you in the media, strongly attacking Mr.Marc Fleury and Jboss group.. Can you explain where are these strong feelings coming from.

MH- I don't know. But, i hate the guy. Like for example, i was kinda calm this morning, then someone sent me a link to the TSS discussions on Hibernate joining Jboss, i have seen Marc Fleury's name, and i went into a fit again, i got really angry and blood rushed to my head.

I don't know to call him an idiot, or just a misinformed youth. After all that happened with CDN, and everybody and their mother realizing what a fucker/master manipulator/jerk Marc Fleury is, he still joined them..

Wow, Gavin, as if money means everything.. Fleury has never been honest about anything.. So, he did seduce you too with his crappy blue/red pill bs. Cmon Gavin, i thought you were smarter than this.

With the rest of the idiots, with the likes of Burke, you will really get your life back. I assure you..

That may be the most boring blog entry I have ever read, but it competes with the sexlifeofapingpongball.com site I was looking at the other day, so its hard to say. There is also the blog somewhere that consists of about 10,000 "#" characters all in a row. So many boring web sites, so little time.

> Look at the AXIS project, IBM takes what's there, extends it for Websphere and sells it.
> /Hans Helmut/
>
> So? IBM didn't take away anything, but rather sells an extended version. Perfectly okay with the Apache License, which is deliberately more free than the (L)GPL in this respect (free in its original meaning, not the distorted GNUspeak version).

it is a matter of taste. (L)GPL is, once open source, always open source. If I ever find the time to commit to open source project, I want my hard work to remain open source. This is the choice an open source developer makes. I've heard Apache.org referenced sometimes as slave labor for IBM and Sun. Sometimes I don't disagree with this statement. Jetspeed being a perfect example.

It is funny you call LGPL a distorted meaning of free, since IBM is taking a free project and selling it. You should say less restrictive, not more free.

I do wish the LGPL license would be revised so that it is more applicable and understandable as it applies to the Java language. I like it because the code remains open source, but it does not (supposedly) prevent somebody from embedded it within a closed source project/product.

/Hans Helmut/
If I ever find the time to commit to open source project, I want my hard work to remain open source.
/Hans Helmut/

Do you think your hard work somehow disappears from the face of the earth if IBM takes it, extends it and sells the derived work (assuming you released it under a BSD-style license)? Tell you what, it doesn't. It is still there. It remains open source. The only difference is that you allow others to sell their derived works as closed-source. You grant others more freedom, not less.

This "they are stealing our work" notion of the GPL-zealots is exactly what I meant when I wrote "GNUspeak". EOD.

> If I ever find the time to commit to open source project, I want my hard work to remain open source.
> /Hans Helmut/
>
> Do you think your hard work somehow disappears from the face of the earth if IBM takes it, extends it and sells the derived work (assuming you released it under a BSD-style license)? Tell you what, it doesn't. It is still there. It remains open source. The only difference is that you allow others to sell their derived works as closed-source. You grant others more freedom, not less.
>
> This "they are stealing our work" notion of the GPL-zealots is exactly what I meant when I wrote "GNUspeak". EOD.
>

Oh it is very clear. If you do BSD, the best you can expect is some vendor to expand your work, not give you anything back and sell the work and again not give you a dollar back. That's exactly what SUN and IBM and other vendors do with Apache stuff.

BSD is *VENDOR* FRIENDLY. LOL.

LGPL on the other hand is END-USER/BUSINESS friendly as it makes sure that all derivative work of the server itself is FREE FOR EVER while the end-user work can be any license (LGPL allows that).

So at the end of the day you get the best server possible since all the contributions come back.

JBoss is the leading server in OEM (according to one analyst) for a simple reason, it allows for any usage and the base is ONE and UNITED. All the contributions come back to JBoss so we control the distribution. Very important in open source. And we can build a business.

at least that is my experience of the licenses. I am amused by the fanatic religiousness of the Apache crowd on their silly licenses.

\marc fleury\
Oh it is very clear. If you do BSD, the best you can expect is some vendor to expand your work, not give you anything back and sell the work and again not give you a dollar back. That's exactly what SUN and IBM and other vendors do with Apache stuff.
\marc fleury\

In case you weren't aware, Mr. Fleury, anyone can sell your LGPL code and not give you a dollar back. _Without doing any work to your code at all_.

\marc fleury\
BSD is *VENDOR* FRIENDLY. LOL.
\marc fleur\

Actually, BSD is everyone friendly. You retain your copyright, and you give people to do what they will with it.

\marc fleury\
LGPL on the other hand is END-USER/BUSINESS friendly as it makes sure that all derivative work of the server itself is FREE FOR EVER while the end-user work can be any license (LGPL allows that).
\marc fleury\

All that LGPL controls is distribution. If you don't distribute, you can do _anything you want_ with LGPL code. Let's assume for a moment I work for XYZ brokerage house. At XYZ, I could take JBoss, make massive changes to the source base to accomodate my environment, and never give those changes back to JBoss. The only restriction is I couldn't try to distribute my modified code base.

The only difference between LGPL and BSD is that I have to make source available if I distribute code based on LGPL. Note that I don't have to give the source back to JBoss - I just have to publish my own code. In fact I can massively fork Jboss if I feel like it and distribute it to the world. The only requirement is that if I do so I must publish the source.

Oh puh-lease, since when did chiara become the ultimate voice on technical issues?

Mike, I hear your concerns about the integration and I must admit I had the same concerns myself. I use Hibernate extensively and have to admit that I am very dependent on it.

Nevertheless, even under contract, I trust Gavin to remain steadfast to the original Hibernate vision. You don't take a project to the level that Hibernate has reached today without a lot of integrity of vision.

So, I would have to say that I welcome this integration. There are some really intersting possibilities here, including end-to-end XDoclet integration, shared caching and transaction strategies, and so on.

Again, I can't express in words how truly excited I am that Hibernate and Gavin are coming under the JBoss Group umbrella. The expertise in persistence that Gavin brings compliments greatly the expertise of our CMP lead Alex Loubyansky. I'm excited that our aspect-oriented/pojo based middleware offering will have a compeling story in that of Hibernate. I'm excited that Gavin is on the JDO 2 expert committee and has already commanded a bit of respect within that community.

When we first had the idea to recruit Hibernate, we thought it was a long shot. We never thought Gavin would take our overtures seriously since Hibernate was such a popular and successful open source project. I would like to thank TSS for inviting myself and Gavin to speak at the Symposium they had in the Boston area in June. This allowed Ben Sabrin and I to get with Gavin face to face to discuss what we felt was a compelling story. To my surprise, Gavin was actually receptive to what JBoss Group had to offer. I hope we don't let him down!

I also am very very excited about Bela Ban from JavaGroups, joining as well. This was lost on the title of this thread and shouldn't be ignored. Bela has had a long relationship with JBossGroup, and I knew eventually we would have the finances to hire him full time. JBoss Clustering would probably still be in development if not for JavaGroups so we owe Bela a lot for producing such a great piece of software. It is also great that Bela is on the cache JSR. His knowledge of distributed fault tolerance and clustering will be a boon to this implementation, and my bet is that we will have the best solution out there. Open source or not.

All and all, I think these additions prove that JBoss Group has a compelling, interesting story for those wanting to make their OSS project professional and to make a living doing open source. Organizations looking to adopt open source sometimes require development and production support in order to give the stamp of approval. We feel that JBossGroup can overcome this hurdle of adoption for OSS projects like Hibernate and JavaGroups, as we have already ironed out the infrastructure and processes with JBoss itself.

Thanks all for your posts both negative and positive. I hope we have answered your questions well enough.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.