>
>I agree, but I'm loathe to just blame Evermind for this. Have you seen the
>J2EE specs? They detail the way it's supposed to be. Are they clear? Well,
>no, not really... but they ARE the Orion documentation, more or less, and
>what peopel are clamoring for is for Orion to document the specs, but
>clearly. Orion doesn't really differ from the J2EE spec, that's one of the
>reasons it excels - if you know the spec, you can use Orion. (OTOH, if you
I disagree here. of course, orion is very good at conforming to the spec
but j2ee knowledge doesn't help you set up o/r mapping or find out how to
specify your datasources for your entity beans etc. etc.. yes, there are a
lot of questions on this list that indicate lack of j2ee knowledge but
(hope i'm not offending anyone) those shouldn't worry evermind. IMO the
j2ee spec is not that bad to read and not as unclear as you indicate. there
are a few grey areas but most things that have neen asked on this list
regarding j2ee are very clearly defined in (or intentionally excluded from)
the spec. we have worked with orion for just over 10 months now and 90% of
the problems we had with documentation were not lack of j2ee knowledge but
orion-specific things. especially when internal things changed (like dtds
for datasources etc.) and we didn't notice until we ran into problems. I
have to admit that in many cases a look at the commented dtd would have
solved the problem earlier ;-) but still there should be something like a
change log especially when important things like dtds are changed.
for very simple applications you can use orion with just j2ee knowledge.
for advanced use you still have to dig into the internals yourself. the
commented dtds (which hardly anyone seems to read) are a good start for
docs but I think what's required is lots of examples that show advanced
features like ssl, clustering, complex o/r mapping, deploying the same
application multiple times on top of different datasources, use of
servlet-chaining/filtering. could be just one large app that's well
documented with an architecture diagram, sequence diagrams for the flow of
control for certain scenarios etc.. I believe in learning by example and
think that this kind of documentation would really be able to replace a
formal reference manual (which is a lot more work).
>know the spec, you still have to know JRunisms, or Weblogic-isms, or
>whatever, due to wavering compliance.) This is a J2EE problem, not an
>Evermind problem.
>
snip
>No doubt, but ... refer to the spec. Evermind does have a priority on
>docs, but the documentation has a num,ber of difficulties to work with
>that other servers don't - Orion has a goal of being ahead of the pack
>technologically, and since the drafts change all the time, Orion changes
>WITH them. (Did you know Orion supports EJB 2.0? Did you know there *was*
>an EJB 2.0?) That's one of the reasons the specs are used as documentation
>at the moment - Orion tracks them as they're coming out. Out-of-date docs
>aren't much better than no docs at all.
well, hate to give the impression I'm con evermind (which I'm not) but the
docs for the stable orion version (and therefore ejb1.1 which has been
final for quite some time now) haven't improved a lot over the past few
months. IMO changing specs are no excuse for lack of docs in this case. it
has been a conscious decision on their part to put documentation on a lower
priority than ejb2.0 compliance and overall stability and that's it. it's a
legitimate decision but it's hard to imagine that they couldn't have
invested more manpower for documentation in the past 6 months.
regards,
robert
>-----------------------------------------------------------
>Joseph B. Ottinger [EMAIL PROTECTED]
>http://cupid.suninternet.com/~joeo HOMES.COM Developer
>
(-) Robert Kr�ger
(-) SIGNAL 7 Gesellschaft f�r Informationstechnologie mbH
(-) Br�der-Knau�-Str. 79 - 64285 Darmstadt,
(-) Tel: 06151 665401, Fax: 06151 665373
(-) [EMAIL PROTECTED], www.signal7.de
