toilet fishing with JBoss 4.0
I’m sure we’re all highly impressed that the fleury clan actually managed to get compliance for J2EE 1.4. When I heard the news, I naively and foolishly thought that their incompetent days are now over. This is the dawn of a new era in the dirty incestuous little family’s sordid history.
Of course, a 90mb (!!) download later, I’m very rudely corrected. Wary from bad past experience, I thought I’d first just unpack the server and run. No customisations, purely out of the box experience.
What do I find? Well, the console output (standard size console), is 73 pages long. Of those 73, 61 are stacktraces (it’s hard to tell, but it’s one exception that’s nested about 12 times). Nice to see they’re still letting the same old inbred halfwits code. Of the remaining 12 pages, I’m given some very crucial information about startup, stuff that will hugely aid debugging and my usage of said server, I’m sure.
I mean, who wouldn’t want to know a 800 character IOR corba unique identifier (or two)? Surely the fact that the patch URL is ‘null’ is of vital importance! Don’t even get me started on those bastards who think that ‘Initialized REST’ is a useless bit of info. Why, we should all refuse to use those cryptic servers who don’t tell us all these vital things we must know in order to use J2EE!
Anyway, in the time it took me to write this, server is now up. The shameless little runt even admits to taking 2m:31s:305ms just to start up, clean, without a single application deployment (by me anyway).
Let’s try shutdown….Not as bad now. A mere page and a half of output, and about 10 seconds. Why a server has to take 10 seconds to shut down when it doesn’t have anything deployed yet is a mystery best left unsolved.
So, armed with an ear, maybe it’s time to deploy something for shits and giggles and see what sort of evil that might bring forth. A deployer.sh and deployer.bat in the bin directory look most promising. Whoops, guess again. The scripts complain that there’s no deployer.jar in the current dir. One has to wonder at the marketing/packaging genius who thought to ship shell scripts for non-existent components.
The bin dir contains other misfits too. One doesn’t know whether to laugh or cry at the self-professed ‘primitive’ jboss_init_redhat.sh and jboss_init_suse.sh, with their cutesy hardcoded paths and lack of support for any kind of external config.
There’s also the delightful ‘twiddle.sh’, which apparently allows you to ‘twiddle’ remote jboss instances. This sounds somewhat reminiscent of diddling said remote servers, and I’m not sure about you fleurites, but I for one would rather plop my genitalia on the wrong end of a piledriver than even think of any sexual activities with anything jbossian. Merely viewing the help output of this diddler will, of course, result in a twiddle.log file deposited in the current directory, with nothing but debug messages.
Deployment is still the painful arduous hope-and-pray-you-get-a-helpful-hint process we’ve all come to know and love. The smallest hiccup will cause the server to flail about wildly, spewing error messages with a frequency that is only matched by the number of new pointless codehaus projects every week. The error message themselves are as delightfully whimsical as they’ve always been. Random ObjectNames, with tantalisingly empty ‘I depend on:’ proclamations. The ‘Depends on me’ of course still impressively manages to insist that ejb’s within a module depend on a seemingly random other ejb in a far flung module that has absolutely no dependencies to anything. Hot redeployment of apps that failed to start up doesn’t work worth crap, the stacktraces seem longer, and the whole thing just makes you run to your nearest j2ee vendor and beg them to let you fling cash at them just to stop the pain.
There are some silver linings though. For one thing, JBoss 4.0 should serve as a great motivator for the Geronimo folks. It sets such a low bar that their goal actually seems attainable (as long as they avoid going after commercial vendors, who will wipe the floor with them). It’s also an excellent advert for BEA, IBM, and pretty much all the other players in the field. People who start with JBoss will learn to appreciate professional products so much more (alright, well maybe not websphere, but anything else).
For anyone having high expectations of JBoss 4.0, time to put them away. It’s the same old shit, just 9 times the size, half the speed (well, twice the slowness, to be accurate), 3 times the incompetence, and an order of magnitude more hype. Calling this ‘professional’ open source can only be a very very sick joke, or the most filthy example of doublespeak yet this year.
Still, to their credit, the jboss fucktards have realised one vital fact: it’s pointless to spend money on development or developers if you’re stick with a truly rotten team at the core, and much more useful for the ‘business’ if it were all poured into marketing, where the art of conning people is far far easier to perfect than with boring old code.
October 5th, 2004 at 3:39 am
uno
October 5th, 2004 at 6:31 am
Man, you’ve got some bad karma happening. These dudes are writing _free_ software. If you don’t like it, don’t use it.
Chill out, take a pill or something ..
October 5th, 2004 at 7:04 am
My shit is free, doesn’t mean I go out to markets and try to peddle it as food.
October 5th, 2004 at 7:07 am
There once was a man named mfleury
Who produced some code in a hurry
Politely he coughed
As he held it aloft
“4.1 will rule, don’t you worry”
October 5th, 2004 at 8:10 am
Hani, could you be so kind to bile on Stylereport PRO as well? Thankyou! :)
October 5th, 2004 at 8:18 am
Just out of interest… is there a RIGHT end of a piledriver for genitalia?
October 5th, 2004 at 8:35 am
“… is there a RIGHT end of a piledriver for genitalia?”
That probably depends on your sexual orientation.
October 5th, 2004 at 8:53 am
I’ve used JBoss and others. I am not sure JBoss is any worse then some of the commercial main stream app servers. I have struggled with it at times, but I’ve struggled with all of them at times.
However, I find that Resin provides the best error messages. Resin is a joy to work with. Even when I am forced to work with something else. I often keep a copy of Resin around. I deploy to said copy when I getting a non-meaningful (meaningless for those playing the home game of blog) error message from the app server I am suppose to use to get a decent error message.
Resin is gold.
Tomcat 5.x is darn good as well (not as good as Resin, but it has really started to catch up). Once remove all of the war files that Tomcat comes with, you can get it to start in under 4 seconds.
On a side note, JSF ROCKS!!
October 5th, 2004 at 9:19 am
JBOSS 4 and the dumbasses that develop it are alltogether a huge pile of shit
October 5th, 2004 at 9:57 am
One day He forced out (grasp firm on His ankles)
Jars in abundance to duel IBM’s, Bea’s and Oracle’s
And as He held them on high
You could hear far His cry
“Behold, for these are my uncles”
October 5th, 2004 at 11:05 am
Rick,
What commercial servers did you struggle with? Deploying on Weblogic is as simple as dropping your war or ejb jar files in the applications directory (provided you wrote your descriptors properly). Won’t comment on the state of WebSphere as I haven’t touched it since 3.5
October 5th, 2004 at 1:09 pm
You spent a good deal of time talking about start up and shutdown time..are kidding me? You think Weblogic is a speedy appserver….I think you are so full of it it’s amazing.
You allude to commercial apps like Weblogic as this golden piece of software..people spend 10′s of thousands of dollars to wait forever for an app to deploy…minutes for the server to startup….
At this poing JBoss is going to focus on fixing bugs, tuning speeds and such and I can look at the code…yea that’s a big freaking deal..
The only reason I give this post the time of day is some newbie may think you actually know what you’re talking about
October 5th, 2004 at 1:11 pm
Deployment is still painless? wtf? You think deployment with Workshop and Weblogic is fun.
Deployment with JBoss 3.2 was as simple as typing ‘go’ on an ant script. So you’re other claim that ‘deployment is STILL painless’ is totally false
October 5th, 2004 at 1:14 pm
You haven’t said what you do like? Weblogic? I’d love to share all the nasty yet truthfull knowlege I know about that company and they’re product. I’ve unfortunately worked with it extensively because I’m fighting they’re million dollar marketing machine.
What appserver do you recommend?
October 5th, 2004 at 2:15 pm
Oh puhleeease dahling, learn to spell properly. It’s “their” not “they’re”. And there is only one “l” in “truthful” sweetie. Go back to school like a good little boy or I’ll spank your botty with my big….thing.
October 5th, 2004 at 2:25 pm
mr anonymous: hani has multiple times clearly stated that resin and orion are the leading app-servers/servlet containers. Please get some clue before posting.
October 5th, 2004 at 2:36 pm
“Oh puhleeease dahling”….I didn’t know this was a blog for gay Java programmers.
October 5th, 2004 at 2:38 pm
No wonder all the phalic references….and comparing resin to JBoss is comparing apples to oranges.
October 5th, 2004 at 2:41 pm
Yes! Thank you! I also thought “Hey, can’t be that bad…” and downloaded it. Whoops, was I wrong. Damn thing didn’t even start!?!?! WTF?!?! Who releases hunks of crap like this? If they native download spews forth obtuse error messages, then how do they EVER expect me run an app in it? My confidence went from 0 to way, way below 0. What a waste of time.
Call me when the stupid thing runs out of the box.
October 5th, 2004 at 3:09 pm
I remember using JBoss 3.2 when it came out. I thought it was reasonable to have to deal with what is basically a pretty complex bit of sofware randomly crapping out all the time and spewing out useless reams of shit until I started using Tomcat + Spring + Hibernate to do exactly the same thing in half the time.
I know I could have spent ages configuring it and working out all its nasty little warts and shit, but frankly I would rather do something less pointless with my limited time on planet earth.
October 5th, 2004 at 5:45 pm
I agree with the last comment. I like my apps runnable from Tomcat 5. Keep it simple. Use Spring.
October 5th, 2004 at 6:23 pm
Regarding:
“What commercial servers did you struggle with?”
I am a principal in two companies. One company uses WebLogic and Resin. They have the same application, and it can deploy to either. I was involved in the creation of this app (as a developer).
In additional I am a principal at a training, and consulting company (different company). At the start of this year, I worked on an app that used JBoss 3.x. Later, I worked on an App that used Tomcat 5.x. I also consulted on two projects that used WebLogic 6.1 and WebSphere 4. I did some architectural analysis on a project that used Sybase Jaguar (this year).
I’ve used at one point or another WebSphere 4 and 5; WebLogic 4.5, 6.1, 7 and 8; Tomcat 3, 4 and 5; and multiple versions of Resin. I do a lot of consulting so I see a lot of app servers.
I prefer Resin. My next project, starting on Monday, uses JBoss (the clients choice not mine). (I am currently at a client site where they are using JBoss 4, and I have not had any of the problems that Hani mentioned).
Regarding:
“Deploying on Weblogic is as simple as dropping your war or ejb jar files in the applications directory (provided you wrote your descriptors properly). Won’t comment on the state of WebSphere as I haven’t touched it since 3.5″
JBoss also supports hot deploys. The issue is not how well hot deploys work per se. The issues is how fast does the server startup, how well does the server respond when you have something misconfigured, etc. JBoss error handling, at times, is baffling. Then again, I can same the same thing about most of the commercial app servers that I have used.
Resin, on the other hand, provides the best error handling in my opinion. When you do something wrong, it gives you the best clues what you did. I found I keep a copy of Resin around even if I am using another app server. It is good to deploy to it, and get some useful error messages.
Useful error messages, can mean the difference of a few minutes of figuring something out to a few days of figuring something out.
I will say this about the JBoss community. They do a good job of answering questions (unless it is already been asked and answered a few times, then they flame you).
BTW Hot deploys were broken in WebLogic 7. You could do it about three times before it would not allow you to do it anymore. This fact is even mentioned in several WebLogic books. WebLogic 8.1 fixes this problem. WebLogic would not even tell you it stopped working. It just stopped. Then you had to restart the server.
WebLogic is actually the server that I have the most experience with. I’ve been working with WebLogic back when WebLogic was the name of the company and Tengah was the name of the server. I think WebLogic has really solid documentation. JBoss does not.
I am not a fan or proponent of JBoss. However, I like it well enough. I think the bile blog is wrong. JBoss is okay.
October 6th, 2004 at 1:48 am
it’s certified??? did they fix their shitty classloading structure or what?
October 6th, 2004 at 2:03 am
Anonymous wrote:
“comparing resin to JBoss is comparing apples to oranges”
Like comparing apples with a big pile of turds don’t you mean?
October 6th, 2004 at 9:19 am
Yeah, resin is the best. Even EJBs work better on Resin. And on Tomcat Issue, how can tomcat be 12.7 MB and Resin only 5.8 and still deliver shittier performance.
Tomcat is even bigger than Resin Pro which includes support for EJBs and other J2EE service.
Can someone explain that to me. And don’t bring JBoss into that picture. JBoss is an even bigger pile of bile out there.
Hani you rock man.
October 6th, 2004 at 10:02 am
JBoss is fucking wank.
Written by fucking wankers.
For fucking wanky fucking wankers.
October 6th, 2004 at 3:35 pm
not using some crap, doesn’t mean we can’t rant and bile about it – real knowledge on the subject is just a bonus.
October 6th, 2004 at 4:09 pm
“…One has to wonder at the marketing/packaging genius who thought to ship shell scripts for non-existent components. ”
Just use Maven and all will be peachy!
“…the most filthy example of doublespeak yet this year. ”
You obviuosly haven’t heard John Kerry speak this year.
October 6th, 2004 at 5:27 pm
Resin performance does ROCK! Not just runtime speed, but startup speed, and deploy speed too (important to developers).
Resin is my first pick. Unless the application absolutely need some features it does not provide.
The odd thing is that most clients I work with never heard of Resin so I end up using: WebLogic, WebSphere, Tomcat or JBoss.
BTW I have been using JBoss 4.0.0 all this week, and I have not seen any of the nasty stact traces or the extremely slow startup that Hani refers to.
JBoss 4.0.0 starts up in 24 seconds or less in an older P3 with 500MB of memory. My guess is that on a newer machine, the speed might get down to 18 or 14 seconds. If you remove all of the example (queues and such), probably you could get it to start in under 10 seconds.
The time is not too bad considering everything that JBoss provides. There are several app servers that I know of that would love to have a startup time of 24 seconds.
Come on Hani… what gives?
October 6th, 2004 at 5:43 pm
Rick,
Even 14 seconds is painfully slow when you’re deploying every few minutes during development. I just timed Orion, a stock install starts up in less than 3 seconds. Which I can live with.
October 6th, 2004 at 6:59 pm
I’ve used JBoss 3.2.4 for the High Availability JMS stuff and it actually works great for that. I was pretty impressed with it.
As for the rest of Hani’s rant, I have to agree about the startup. I had JBoss down to a minimal configuration that would support the application I was doing (that’s nice that you can pick and choose components), but the startup was…slow. Too slow for the edit-deploy-debug cycle. Also, there are many unexplained wierdnesses in the log like exceptions thrown for no apparent reason, odd disconnects on the JMS that are not related to timeouts, etc. It all works reliably but there is a hint of a feeling of non-determinism to the thing that is troublesome.
I’ve recently been using Tomcat5 and I’m impressed. They actually got their startup time down to a reasonable interval. Resin is hands-down the winner though. For my current work it wins by a large amount: resin startup is 28s and Tomcat5 is 58s. This is the exact same webapp deploy on the exact same hardware (same startup options to the VM also). Part of the slowness is that the Spring and Hibernate initialization. I turned on TRACE logging for both of these things and the output was, to put it mildly, staggering.
Tomcat5 takes 22s to startup with no apps deployed except for the admin, balancer and admin (which are required). Resin can deploy completely empty in 2s. All timings are on my elderly 1GHz PIII laptop.
Tomcat5 also supports JMX, which is useful in instances where you have behind-the-scenes processes that you want to be able to poke with a stick through the bars. The stability has been good (running the application), except for the fact that I can’t shutdown/restart a webapp from the web console reliably. It gives me a FATAL error after about 3 go-arounds of restarts and petulantly refuses to continue.
October 7th, 2004 at 5:20 am
Suspect Hani is using OS X on a not-too-quick box – I get the same spewing of stacktraces on my home Powerbook with a startup time of about 35s, but not on my work PC which starts in 20s.
October 7th, 2004 at 9:11 am
Regarding:
“Even 14 seconds is painfully slow when you’re deploying every few minutes during development. I just timed Orion, a stock install starts up in less than 3 seconds. Which I can live with. ”
I’ve played with Orion but never used it in production or for development. Resin is also very fast.
I’ve always heard good things about Orion.
Compared to Orion and Resin, JBoss may be slow. Compared to other app servers, JBoss is an out and out speed demon.
October 7th, 2004 at 9:15 am
Tomcat5 starts up in 4 seconds on my laptop (empty w/ no apps, no extras).
October 7th, 2004 at 1:24 pm
Back when I used WebSphere I could go off and have a shit AND a wank (not at the same time) whilst waiting for it to start.
JBoss is a slow pig, but every time I gripe at its slowness, I remember things could be worse.
October 7th, 2004 at 3:59 pm
thanks for the too-much-info there, dr. pizza ..
October 7th, 2004 at 5:36 pm
Those were calmer, milder days.
WebSphere 5.0 seems to be much better than earlier versions like WebSphere 3.5 for example.
I used Cactus quite a bit with Resin. I thought it was a great way to test web components. Then I tried to use Cactus with other app servers (I wont mention them by name, since I may do business with the company one day), I stopped using Cactus and started using MockObjects.
Why? The development speed went to a crawl b/c the container was too slow.
I remember before that, folks were complaining about Cactus. I thought they were crazy, then after the switch to another app server, I understood why.
So slow app servers, allowed me to find the wonder of Mock Objects.
One of the many advantages of Mock Objects is that they can run in your IDE.
October 8th, 2004 at 9:17 am
“other app servers (I wont mention them by name, since I may do business with the company one day)”
It’s OK, we already know that IBM drink steaming diarrhoea direct from the anus.
Cock Objects are moronic. They’re too fucking complicated (meaning that they are themselves a point of fucking failure) and at the end of the day, who the hell cares if it works with the mocks. I want to know if it works with the fucking container. And I’m not going to switch the fucking container because life is just too fucking short. I want to write tests and not worry about how tight the mock’s sphincter is. Just use fucking cactus and write the goddamn tests and stop dicking about with the anally retentive cockmongery of mock objects.
Unless you use WebSphere in which case you could shit, wank, read IBM’s 100+ page porting document (write once run away?) and port your application to JBoss *AND* start up JBoss in its “all” configuration in the time it takes WebSphere to start up.
October 8th, 2004 at 9:48 am
This is off topic, but will interest you Ted, as we know you come in left of center. The news has to spread. Salon.com is running a groundbreaking expose of President Bush and the GOP’s campaign tactics of wiring the president during speeches and debates. Blogs such as http://www.isbushwired.com and http://www.cannonfire.blogspot.com have been carrying the story as well. There are even rumors that the President might be suffering from premature Alzheimer’s. Will Promptergate turn the tide in the 2004 election?
October 8th, 2004 at 11:31 am
Be warned!
When shit hit the fan it’s too fucking late to run. Here is a minimal short list of items you’ll need before unpacking JBoss:
-First-aid kit
-Footwear, safety (i.e., protective shoes/boots)
-Gloves, heavy and disposable (e.g., surgical, latex)
-Helmets, safety/hard hats
-Kneepads
-Outerwear, protective (e.g., disposable suits, weather gear)
-Personnel support items (e.g., food, water, hygiene items, shelter)
-Reflective tape
-Respiratory equipment (e.g., particle masks, breathing equipment)
Possessing the proper tools and equipment is key to any task, and never more so than in emergency situations.
-Support your Local People Against Goodness And Normality
October 8th, 2004 at 7:59 pm
At one point in time, I felt the same way about mock objects. My first real introduction to using mock objects was StrutsTestCase. It was useful. It worked well. I found it a lot more productive then deploying, waiting, testing, fixing, redploying, waiting, testing, fixing.
I remember when I was at the first server side symposium in Boston. Vincent Massol spoke about mock objects (he is the guy that created Cactus). I could not belive it. He liked mock objects, and was advocating them. At the time I felt the way DrPizza felt (minus the colorful language). Of course I was using Cactus with Resin and did not see the performance overhead.
After using mock objects with some projects, I must admit it can speed development by reducing the need to deploy to the container to test.
It is no silver bullet or golden hammer, but it seems to be very productive. It also forces you to refactor your code base to be testable outside of a container as much as possible.
Although speed was the reason I originally choose mock objects, I use them for other things. It actually works out fairly well for many things.
I
October 8th, 2004 at 8:25 pm
“It also forces you to refactor your code base to be testable outside of a container as much as possible.”
What a waste of fucking time.
I don’t give a fuck if the code is testable outside a fucking container BECAUSE IT LIVES IN A CONTAINER. The tools exist to easily test INSIDE a container, so why test outside?
Lemme guess, you’ll spew some wank about testing things in “isolation”. What the fuck next? Making them testable outside the fucking JVM?
October 11th, 2004 at 10:24 am
HELLOW?!?
Whoa DrPizza, you’re turning me tf on with that language. Come to #java later this week and we’ll have a.. chat.
October 11th, 2004 at 12:39 pm
Hani
It sounds there will be another generation of JBoss 4.0 books out there.
You know it so frustrating that an application server work out of the box like it should.
I am sure the design is wonderful and such, the
newests EJB 3 plug-in stuff is cool, but the
vendors whether open source or commercial have got
to sell us the thing. You wouldn’t use an IDE
that spewed up umpteen stack traces. If Eclipse
did that I would respect it as I do. Maybe it
is because Gamma and Beck are on the team, then
that is why Eclipse is just solid where as it
sounds like JBoss 4 is less than evergreen.
You are right about Geronimo folks getting close
to something. THe standard of the Apache software
has been very high and successful year on year.
Oh yes what happen the WHITE paper, I remember
last year reading the RED and BLUE papers that
Marc Fluery wrote, but we never saw the final
third paper.
Ok I guess it is 2/3 solution then.
Peter P
October 12th, 2004 at 11:01 pm
“The tools exist to easily test INSIDE a container, so why test outside?”
Development speed. I use to agree with you.
I use to argue like you are arguing. Now I don’t. I like mocks.
“You know it so frustrating that an application server work out of the box like it should.”
It worked out of the box on my machine, and 24 people I was working with that week.
Maybe Hani’s env. was screwed up. Or he could be one of those Mac users (warning flame bait).
Why don’t you download 4 and try it for yourself?
I was running JBoss 4 against JDK1.5.
October 12th, 2004 at 11:08 pm
“Whoa DrPizza, you’re turning me tf on with that language. Come to #java later this week and we’ll have a.. chat. ”
I don’t have quite the artistic lic. that Dr. Pizza has. Partly b/c I am using my REAL NAME!
I have these people, I like to call them clients who I don’t want to scare away.
Now obviously such colorful language does not bother you…. You read the bile blog after all.
I am very positive person and I try not to be too shocking.
October 12th, 2004 at 11:12 pm
Regarding:
“Whoa DrPizza, you’re turning me ######### language. Come to #java later this week and we’ll have a.. chat. ” says jwzrd.
I don’t have quite the artistic lic. that Dr. Pizza has. Partly b/c I am using my REAL NAME!
I have these people, I like to call them clients who I don’t want to scare away.
Now obviously such colorful language does not bother you…. You read the bile blog after all.
Hmmmmmmmm….. wait a minute… so do I.
I am very positive person and I try not to be too shocking. Any one who knows me know I am no prude.
October 12th, 2004 at 11:21 pm
Regarding: “I don’t give a **** if the code is testable outside a ******* container BECAUSE IT LIVES IN A CONTAINER. The tools exist to easily test INSIDE a container, so why test outside?” say DrPizza
I find your speech eloquent. Your parents must be proud. What does your wife and kids think of their daddy and husband?
Please don’t use Spring either as it helps you to allow most of your code to run outsite of a container, which is great for TDD. Spring will mess up your goal of tying your code tightly to the container. Apparently you like to watch the JBoss, Tomcat, WebLogic, WebSphere console all day instead of writing code.
Have fun. I prefer to write code. I dig TDD. It focuses my efforts. Mocks are no silver bullet but they do help.
October 13th, 2004 at 3:39 pm
hello girls
i know you all just want to poop on each other dont you
October 13th, 2004 at 4:54 pm
Rick, please shut up! You sure sound more and more like a bitch with a big mouth. Please spend your time refund people the money you robbed from them (hint: mastering resin)
You suck to n th degree.
October 13th, 2004 at 10:45 pm
Thanks.
October 14th, 2004 at 1:23 am
who is rick hightower?
is he Chiara with a (little bit of) gray matter?
October 14th, 2004 at 2:56 am
But Wait! There’s More!
If you act now, we’ll include AOP at no extra charge!
That’s right you get all this AND AOP for the low low price of your own sanity!
October 15th, 2004 at 5:09 am
Hani,
JavaLobby is looking for 2 contributing editors. Why don’t you apply? I’m sure Rick and Matt will love you….
October 15th, 2004 at 7:43 am
Could you do a blog on WADI, another lovely excretion from core developers
October 16th, 2004 at 11:41 am
Don’t you know? We love him already. Maybe I should not speak for Matt.
I have no problems with Hani. I don’t always agree, and apparently most people don’t understand his humor.
October 17th, 2004 at 8:04 pm
John Keller (or whatever your real name is),
If you don’t like a different opinion, don’t read my comments. Commanding me to shut up or calling me names has no effect, and is not logical. Why don’t you rebut what I’ve said. Oh…. b/c you can’t.
Let’s see your comment equates to shut up, I don’t agree with you.
Personal attacks and whitty rebutals like name calling do little to disuade me. Go ahead. I am an easy target. I wont fight back in kind.
Hani is free to delete my comments.
October 20th, 2004 at 11:18 am
“Apparently you like to watch the JBoss, Tomcat, WebLogic, WebSphere console all day instead of writing code. ”
Yeah, or not. Because fuck knows, it’s not like I can hot deploy, is it.
October 20th, 2004 at 11:27 pm
Even hot deploy can take a while if you have a fairly large application. Oh yeah, and hot deploy always works… sure.
So let’s see building a war file and hot deploying is faster than running a test in your IDE….. Nope, and it gets worse as the project gets bigger.
Hey Mikey, try it, you’ll like it. I use to sing from the same song book. Now I sing a different tune.
November 26th, 2004 at 3:14 am
When ANY group, either OSS or commercial, releases code that they say is release-ready then I expect it to be a credible and professional job. There are those of us who would rather not waste our time with total crap.
They may be working for free but, that does NOT excuse them of the responsibility to deliver what they claim or to deliver to the minimal professional standard. Releasing crap with down-rev dox and calling it production-ready is dishonest and unethical. It vastly detracts from the credibility of the OSS movement (which was set to an extremely high standard by Linux).
Both the Apache/Tomcat folks and the JBoss folks continue to fail at understanding the simple concept that, without complete current dox (especially if you fail to follow current admin standards), the code is garbage and has no value.
They may be working for free but, crap is crap and they should be held accountable for it like anyone else. How many man-weeks are being wasted right now, by those unfortunate enough to walk down this trail? How many will get bad reviews or lose their jobs because they couldn’t get this technology to work on time and their boss thought it was the industry standard? How many will lose their professional credibility simply because these tools do NOT perform as advertise or have copious minefields to walk through?
No, I’m with the original poster, crap is crap, whether or not it’s OSS is irrelevent. Jakarta Tomcat and JBoss do NOT meet the “useful/usable” bar.
November 14th, 2005 at 10:39 am
installation documentation
jboss: unzip somewhere and set JAVA_HOME to point to a dir containing a jdk.
PUT_ANY_NAME_HERE commercial server: 100+ pages documentation (in some cases 270p.)
November 18th, 2005 at 4:30 am
Jboss rocks….Cheers..