New message model notes (part 1 - brief)

[gd...@macromedia.com]

Hi all!

I have to go get some dinner now, so this note will be brief.  More later.

The code is there, and sort of works.  I've attached a test program which
calls the "EchoString" method of a server conforming to the SOAP Interop
tests.  For instance, try:

java EchoTest -lhttp://soap.4s4c.com/ilab/soap.asp "hi there 4S4C!"

Things to note:

1) There are still debugging printlns() in various places.  In general the
code needs a serious cleanup pass.  I plan to do this over the weekend if
possible.  In the meanwhile, Sam can use this as a starting point to get
going with interop.

2) IDs/HREFs do not work yet in any way, though we do note them during
parsing.

3) The deserialization/serialization framework is really raw, and the
ServiceDescription is really just a proof-of-concept at this point (check
out how it works in EchoTest).  Both need serious expansion, and I'd like to
be able to easily integrate Castor into the mix at some point.

4) Exception handling needs some major work.

5) I would REALLY like to get a JUnit framework in place soon.  Unit tests
of components like the NSStack would have been invaluable to me during the
past few days.

6) We need to decide what we're going to do for logging and reporting soon.
I'd like to have a real infrastructure in place for this.  On a related
note, you'll see the pattern of using a private static final boolean called
DEBUG_LOG in various places for development-level debugging.  Since this is
a constant, the compiler just gets rid of anything in an if (DEBUG_LOG) {}
block when it's false.

In general, I would not normally check in code at this level of
incompleteness, but (points at Sam) he made me do it.  Speaking of which -
we should coordinate what pieces of extension/cleanup are going to be done
by whom, so we don't step on each other's toes in the next week or two.

OK, I *have* to get some food now.  Let me know what you think of the basic
design of all this stuff, and keep in mind that the code is not considered a
finished product by any means.

Glen Daniels
Macromedia
Engineering Manager
http://www.macromedia.com/
                                Building cool stuff for web developers

Re: New message model notes (part 1 - brief)

[Aleksander Slominski <as...@cs.indiana.edu>]

gdaniels@macromedia.com wrote:

> 6) We need to decide what we're going to do for logging and reporting soon.
> I'd like to have a real infrastructure in place for this.  On a related
> note, you'll see the pattern of using a private static final boolean called
> DEBUG_LOG in various places for development-level debugging.  Since this is
> a constant, the compiler just gets rid of anything in an if (DEBUG_LOG) {}
> block when it's false.

you may consider logging framework i implemented for SoapRMI - it is basically trimmed down
version of JDK 1.4 logging API and consists only of 4 files (Logger, LogManager, level and
Log), see:

http://www.extreme.indiana.edu/soap/rmi/download/soaprmi11/src/java/soaprmi/util/

it could be easily incorporated in axis package eliminating need for external logging
utility. it has also nice ability to specify logging options using command line parameters:

debug all: -Ddebug [equivalent to -Dlog=:ALL]
debug only specified package: -Dlog=soaprmi
debug everything of level higher or equal to CONFIG: -Dlog=:CONFIG
debug specific class file only: -Dlog=my.package.Class
debug list of packages with different output levels:
-Dlog=soaprmi:FINE,samples:ALL,tests:OFF

Note also that in code i use
if(Log.ON) logger.fine("...")

so changing Log.ON constant to false and recompiling will completely eliminate logging
statements - very suitable for performance testing :-)

best,

alek
--
Aleksander Slominski, LH 316, IU, http://www.extreme.indiana.edu/~aslom
As I look afar I see neither cherry Nor tinted leaves Just a modest hut
on the coast In the dusk of Autumn nightfall - Fujiwara no Teika(1162-1241)