blob: 685d2d9d7aee7617950151c81cc2f97cab0e820a (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
|
$ID$
This example implements and tests runs a simple logging service using
TAO. You can either run the client and server as seperate processes
in the same, or different windows (or machines), or you may run the
"runtests.pl" script which will start both executables.
By default, the client and server use the Naming Service. The
Logging_Service has its own NamingServer implementation, so it doesn't
require you to start the NamingService before starting the client and
server.
Ignore the multicast timeout error. It is a result of probing for the
nameservice and not finding it (and thus being forced to create its
own).
If you encounter problems with the test, try increasing the sleeptime
in the run_test.pl script.
The client program will generate 4 logging messages which will be
logged to the screen. The first message will be in the "verbose_lite"
format. The rest will be fully verbose messages. Successful output is:
LM_DEBUG@::log() test (1)
Mar 8 16:31:06.000 1999@128.252.165.142@822@LM_EMERGENCY@::log() test (2)
Mar 8 16:31:06.000 1999@128.252.165.142@822@LM_INFO@::logv() test (3)
Mar 8 16:31:06.000 1999@128.252.165.142@822@LM_EMERGENCY@::log2() test (4)
server: ------
% server [-d]
client: -------
% client [-d]
Options: -------
-d Debug flag. It is an additive flag, so more -d's will increase
the debugging level. Only one flag is necessary to enable the
debugging output from the executables, but the debug level
affects how the utilized TAO methods act (including mysterious
debugging messages).
That's all there is to it. If you desire, feel free to change the
logging priorities, verbosity levels and messages in the client
program but note that the maximum length of the message is 1023
characters.
|
