I'm not sure I fully understand what you are driving at so let me try and
paraphrase your question and answer that. You can come back and tell me
I've misinterpreted it. ;)
Sorry, my english is not a whole better then my c++ source code, my babelfish is on holiday :)
Should someone developing J2EE applications for deployment on JBoss require the JBoss source code?
... for building a 'internal' reference implementation of the JBoss to support different OSs and JDKs and JITCs - different infrastructures.
There is usually no need to have the JBoss source code. The examples and
paid-for-documentation are sufficient. The prebuilt production release
binaries work fine. There is an assumption that you already have
experience or at least have familiarity with building J2EE applications.
So if you have knowledge on J2EE application development and deployment,
you can pick up the extra details on configuring the JBoss specific
deployment descriptors should you need to employ these. We've used JBoss
for many years without having to delve into the source code to understand
how to deploy a web application.
Yep, i do not talking about: development of J2EE apps. I am talking about: Using (and providing to someone) the JBoss infrastructure in a reproducible manner. Risk management.
As with any J2EE container though, the J2EE spec leaves open some areas
for vendor interpretation and JBoss is no different to any other container
in this respect. Therefore the examples are necessary to understand how
JBoss addresses such gaps or implements the solution. However, this is a
different issue to requiring the JBoss source code. I have 10 days worth
of training in SilverStream and two large example tutorial manuals
covering SilverStream specific development and deployment. I have about
the same with the different WebSphere configuration releases.
Even with these, unless you have had experience with application servers
before, the training doesn't help you the first time the server install
doesn't work on site, or something clashes with pre-existing software. At
least with JBoss, the subsystems are documented, and relatively
transparent in configuration. And you don't usually need to spend another
half day re-installing the app server.
The source code is only necessary if you believe there is a bug and you
feel inclined to track it down. The other users of this open-source
product will thank you if you can make things better for them. But that
is the co-operative nature of the project/collective.
And this is hard to explain to a non-cooperative gaming company.
But OTOH, i have the strong feeling, that one will rather sooner need the source in a medium havy project for tracking down the stuff. Why not starting with this? Like test-first is the afterburner of debugging.
Posting the JBoss and/or underlying infrastructure improvements has to go without saying.
JBoss application deployment is simple and transparent, IMHO. You can usually figure out why something broke, if you know your J2EE. And if things break in the JBoss engine, you can always ask here or at the forums. There is always someone willing to offer their experience.
Remember that this is an open-source product. People have spent their free-time contributing and helping out. Constructive criticism is appreciated - doing something to address a shortcoming even more appreciated. Denigrating what someone has laboured over in their own time - probably not in the spirit of open-source.
Oh, i have something mistakeable written? Sorry for that.
If you do want professional support for JBoss deployments, there are
various organisations including JBoss Group LLC who provide such
commercial services. I understand they all provide professional quality
support as good as, if not better than any commercial organisation.
Own bitter experience:
Some people take the 1st class JBoss product as a binary like shrink-wrapped CloseWare, filling it into their tin-boxes and are then bitching about opensource because they are not using one of the three leading operating systems in the last two versions and the latest jdk.
I hope that in some way hits somewhere close to your question as I have attempted to interpret it, as well as cover some of your additional concerns - and I may have misinterpreted your intent so correct me if I have blundered.
Thanks a lot for the long post
best regards
bax
Best regards,
JonB.
<smime.p7s>-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Holger Baxmann - bitwind Sent: Saturday, 26 July 2003 7:50 PM To: [EMAIL PROTECTED] Subject: [JBoss-user] The Source or not the Source
Hi all,
i have, in my point of view, a rather pointless question. Seem to be like "Why do i brush my teeth every morning?" It comes out of the so called 'real world':
'Why should one use the source release and whole stuff and knowlegde for building and testing? The binary build seems to be good enough.'
I know this is a light-stupid question, but i have to argue against. I
am frankly not able to do it at last. All arguments about 'Look the
tests for learning, the test&build make you sure that the whole stuff
is running with exactly defined errors and failures' does not help: 'We
will use the JBoss, we will neither developing for it, nor we have the
time or the money to dive into the deep forest of how JBoss handle his
things'
So, is anybody out there who is using _only_ the binary package and has
good experience in doing so ??
IMHO it is a little bit unprofessional, isn't it?
my the source be with you
bax
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
