Re: [Springframework-developer] database for demos

[Luke T. <ne...@fr...>]

Rod Johnson wrote:
>>I do wish they
>>would separate the JBoss Group from JBoss the Open Source Project more
>>clearly.  Right now they share the website and it is hard to tell where
>>the line is drawn.
> 
> Absolutely. Selling consultancy around a product, whether open source or
> commercial, is absolutely fine. But when there's no division between OSS
> development and a commercial operation there's always a risk that the open
> source offering will intentionally leave gaps for the consulting to fill.
> (Not that I think there's a problem with JBoss as a product.)
> 

As there have been endless discussions elsewhere, I don't think this 
should become a forum for expressing opinions on the ethics of the JBoss 
development approach. However as someone who done some work on JBoss and 
benefitted from working with/for the JBoss Group I feel I should put 
forward a few points in their defence and a few general comments on 
using the server.

On documentation: Contrary to popular opinion there is not a conspiracy 
to deliberately provide inadequate documentation in order to force 
people to buy the pay-for version. It has always been seen as a pressing 
issue that the documentation was inadequate and I have been asked 
previously to help with updating it so I am probably as much to blame as 
anyone. There is the beginning of a rewrite languishing at

http://www.monkeymachine.ltd.uk/JBossStart/JBossStart.html

but it is little more than an intro to the server layout at present. 
Writing decent, accurate documentation is painstaking stuff and takes a 
lot of time and like most people I have other things to do and it tends 
to take a back seat. The introduction of pay-for docs was an attempt to 
solve this problem by giving an incentive to the developers to write and 
maintain documentation. There was a genuine realization that something 
as complicated as a J2EE server was going to require in-depth 
documentation and that's where Scott Stark's book comes in. It's 
meticulously detailed and the repeated editing cycles quickly stretch 
out into "a lengthy and stressful process" ((c) Rod Johnson :-); there's 
no way someone could realistically be expected to put in that much work 
for nothing. Most of us buy IT books - I don't see why the attitude to 
paying for books written by JBoss folk should be any different.
(NB. I wasn't actually aware of the Wrox JBoss book or the serverside 
arguments until I read about them here, so not having read it I can't 
comment on that one way or the other).

On violating the "Open Source Spirit": There is no way JBoss would be 
where it is today without the commitment of Marc Fleury and the other 
core developers who are working full or part-time for JBoss Group. It 
would just not be possible. They have done an extraordinary job in 
keeping it together. As with most projects there are voices raised 
everywhere complaining about one thing or another - I remember at one 
point the web site was being run from Marc's home and he was wrestling 
with the attention of script-kiddie hackers and being a newbie linux 
admin, as well as architecting the JBoss code and dealing with the all 
the corporate level issues as well. Such things are never perfect and it 
has often been very much a seat-of-the-pants thing. Bringing full time 
people on board (like Scott Stark) to manage the development and keep a 
grip on the codebase was an essential step if JBoss was to compete 
realistically with commercial servers. These guys have been hard at it 
for several years, mainly because it's what they want to do and they 
fight hard because they take a lot of flak from all sides - from the OS 
purists and from the commercial vendors who slag them off for giving 
away their work for free. They could all probably have made more money 
working for some investment bank or other - they certainly aren't taking 
the easy option. And the J2EE landscape is all the more interesting for it.

The JBoss code is open source and always will be. Whatever the 
attractions of other commercial servers may be they are still black 
boxes and I've been badly burnt in the past by bugs in servers like JRun 
and Weblogic. With any J2EE server you will invariably become familiar 
with some of the internal server classnames - with commercial servers 
that will usually be through some stacktrace and that will be your lot. 
This can be immensely frustrating. With open source you always have the 
option of tracking things into the server code and that is often 
invaluable. To argue that JBoss isn't doing open source as some people 
would like it defined and therefore go with a completely closed source 
commercial option for the full J2EE server seems like strange logic to me.

On the default Datasource: This is extremely useful when setting up a 
demo - all other servers that I am aware of require setting up an 
external database. I think someone mentioned that it was an old version 
of HSQL that is included but it is in fact an up to date one (1.7x).

On the "multiple configuration files issue": This is something which has 
  again caused a lot of complaints but once you start to see JBoss as a 
set of pluggable components, rather than a monolithic server with a 
single configuration file crammed with unrelated entries then it starts 
to make more sense. As someone has already pointed out, it is easier to 
supply an extra service configuration file along with your application 
and say "drop these into the deploy directory" than it is to ask users 
to edit particular sections of an existing configuration file. This 
approach can be used for adding datasources, JMS destinations or other 
services which are required for your application. This is one thing I 
*have* covered in the stalled "Intro to JBoss" docs mentioned above - 
please send any constructive feedback to lukeATmonkeymachine.ltd.uk :-).

On server startup speed: having hot deployment of both services and 
applications makes this less of an issue, but you can always remove the 
services you don't need from the deploy directory and increase the 
startup speed substantially.

Luke.

-- 
  Luke Taylor.                      Monkey Machine Ltd.
  PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk