I have seen a lot of discussion on the bugzilla list itself, ideas, discussion,
etc should be put in bugzilla which then publishes it.

From Doug Schmidt

> I thought the whole idea is that if you run the ACE Logging Client 
> daemon before you run any CORBA executable, the log records should 
> automatically be routed ACE Logging Client daemon. Am I missing 
> something here?

Yes - you'll need to instruct the CORBA executable to connect to the client 
logging daemon.  I think that's what James's examples do.  James, can you 
please confirm/deny?

Hi Doug,

Hmmm, why do I need to instruct the CORBA executable to connect to the client 
logging daemon?

There is an option in TAO -ORBServiceConfigLoggerKey logger_key 

The Documentation says the following:

----------------------------------------------------------------
Description: 
This option allows you to specify where to write ORB logging output.
This option is equivalent to passing the key to the
ACE_Service_Config::open() function:

Usage: 
Both server and client applications may use this option. The default value is 
ACE_DEFAULT_LOGGER_KEY, which depends on the platform type.
Platforms that support stream pipes use /tmp/server_daemon. Others use 
localhost:20012.
----------------------------------------------------------------

Given the above info, I don't need to call the Service Configurator or 
instruct the executable to connect to the client logging daemon. If I run the 
client logging daemon before I run the program below, all log output should go 
to the client logging daemon and forwarded to the server logging daemon. Are 
you assumption/understanding of this incorrect?

#include <tao/ORB.h>
#include <ace/Log_Msg.h>

int
main(int argc, ACE_TCHAR* argv[])
{
  CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);

  ACE_DEBUG((LM_DEBUG, "Hello world\n"));
  ACE_ERROR((LM_ERROR, "ERROR\n"));

  return 0;
}

Thanks,
Abdul

I believe you are correct.  I think the problem here might be what the format 
of the logger_key is, e.g., you need to make sure that the port number matches 
where the client logging daemon is listening.  What is the format that you're 
passing as the logger_key?

Thanks,

        Doug

I'm not passing anything at all. The logger_key defaults to
localhost:20012 on some platforms, and on other it uses a default pipe.
I'm relying on default behavior. But I did also try to pass localhost:20012, 
it didn't work ;-(

Thanks,
Abdul

Right, the question is "what port is the client logging daemon listening to by 
default."  If it's not port 20012 then this isn't going to work!
A cursory look at the svc.conf file in ACE_ROOT/netsvcs/servers/ suggests it 
may be listening to port 20009, so please take a look and see if passing that 
port into the logger_key will help.

Once we confirm that things are indeed working we should update the default 
settings in the svc.conf file and document this carefully so it doesn't change 
again!

Thanks,

        Doug

It runs on port 20012 by default.

When I ran the client logging daemon, it printed the following:
starting up Client Logging Daemon, bounded to local port 20012 on handle
6
Client Logging Daemon is connected to Server Logging Daemon 
localhost.localdomain on port 20009 on handle 7

I also stepped through the debugger and verified that the logger key is 
actually localhost:20012.

>>A cursory look at the svc.conf file in ACE_ROOT/netsvcs/servers/ 
>>suggests it may be listening to port 20009, so please take a look and 
>>see if passing that port into the logger_key will help.

This is the contents of my svc.conf for the client logging daemon.
dynamic Client_Logging_Service Service_Object *
netsvcs:_make_ACE_Client_Logging_Acceptor() active "-h localhost -p
20009 -k localhost:20012"

The -p 2009 is the port of the server logging daemon, not the client logging 
daemon.

>>Once we confirm that things are indeed working we should update the 
>>default settings in the svc.conf file and document this carefully so
it
>>doesn't change again!

I don't think this is a problem with the svc.conf.

Thanks,
Abdul

Hey Folks,

I was able to look into the problem the solution is that you were missing a 
configuration file for the main program. Basically, just starting the logging 
server and client aren't enough. The configuration files are correct, but you 
still have to explicitly connect to the logging client. The following is the 
svc.conf file for the application.

# main -f client.conf
dynamic Client_Logging_Service Service_Object *
netsvcs:_make_ACE_Client_Logging_Acceptor() active "-h localhost -p 20009"

# main -f server.conf
dynamic Logger Service_Object * ACE:_make_ACE_Logging_Strategy() "-w -s 
foobar.log -f STDERR|OSTREAM|VERBOSE|LOGGER"
dynamic Server_Logging_Service Service_Object *
netsvcs:_make_ACE_Server_Logging_Acceptor() active "-p 20009"

# svc.conf
dynamic Logger Service_Object * ACE:_make_ACE_Logging_Strategy() "-w -f
STDERR|VERBOSE|LOGGER"

Thanks,

James

Hey Folks,

You can also use the -ORBSvcConf options to explicitly specify what file to 
use when configuring the services for the CORBA application. The default 
configuration is svc.conf

Thanks,

James

Hi James,

   What you're suggesting works fine for ACE applications.  I think Abdul is 
trying to use the TAO -ORBServiceConfigLoggerKey option.  BTW, there is no 
documentation for this in TAO_ROOT/docs/Options.html, despite the fact that it 
appears it was added at some point:

Thu Jun  7 20:34:18 2001  Douglas C. Schmidt  <schmidt@ace.cs.wustl.edu>

        * tao/TAO_Internal.cpp (open_services): Added support for the
          new -ORBServiceConfigLoggerKey option, which allows applications
          to specify which loggerkey to use for ORB logging.  Thanks to
          Paul Caffrey <pcaffrey@iel.ie> for reporting this.

        * docs/Options.html: Added documentation for the new
          -ORBServiceConfigLoggerKey option.

Johnny/Will, can you please let me know how to use SVN to find out what 
happened to this entry?

Abdul, I suspect no one uses this option very much since it's not well 
documented.  Do you know how it is being called in your program?

Thanks,

        Doug

I see.

I just ran the example he provide and based on his description, the solution I 
provided would allow him to get the results he wasn't seeing. :o)

- James

Ok, that's definitely a step in the right direction ;-)  Abdul, please let us 
know if James's solution worked for you.

Thanks,

Doug

Hi,

According to svn it got zapped with this commit below, there was a huge amount 
of changes in this specific commit. I will readadd it today.

Johnny

Sat May 17 09:44:42 2003  Balachandran Natarajan  <bala@dre.vanderbilt.edu>

        * docs/Options.html: Revamped the original documentation to be
          more usefule for the users. Thanks to Tao Lu, Andy and
          Dr. Schmidt for working on this and donating it to TAO.

        * doc/Options_new.html: Removed from the repository. 

Great, thanks!  We should also see if anything else relevant got zapped!

Thanks,

        Doug

Right. I found the -ORBServiceConfigLoggerKey in the TAO's Developer's Guide 
1.4a page 677. Apparently, I misunderstood its description. It seems the only 
way to make it work is what James suggested.
 
>>I see.
>>
>>I just ran the example he provide and based on his description, the 
>>solution I provided would allow him to get the results he wasn't 
>>seeing. :o)
>>
>>- James

I'm seeing the results I wasn't seeing before indeed. Thank you all very much 
for helping out. That closes Bugzilla 2708 ;-)

Thanks,
Abdul

Hi Abdul,

> Right. I found the -ORBServiceConfigLoggerKey in the TAO's Developer's 
> Guide 1.4a page 677. Apparently, I misunderstood its description.

Since it's not in TAO_ROOT/docs/Options.html it's not clear to me how this is 
supposed to work!

> It seems the only way to make it work is what James suggested.

It would be nice if we could make this more "invisible".  Absent that, we 
should update the online documentation so that it points to a webpage that 
explains how to actually use this feature!

Thanks,

        Doug

Hi Doug,

>>> Right. I found the -ORBServiceConfigLoggerKey in the TAO's
Developer's
>>> Guide 1.4a page 677. Apparently, I misunderstood its description.
>>
>>Since it's not in TAO_ROOT/docs/Options.html it's not clear to me how 
>>this is supposed to work!

It is not clear to me either; I spent a lot of time trying to figure it out. 
So it is fair to assume that this might confuse other users.

>>> It seems the only way to make it work is what James suggested.
>>
>>It would be nice if we could make this more "invisible".  Absent that, 
>>we should update the online documentation so that it points to a
webpage
>>that explains how to actually use this feature!

That would be nice indeed. However, I think there are other challenges here 
that would make it difficult to hide. I encountered this while I was trying to 
use the ACE distributed logging service under a simple CIAO application. Since 
I compile everything statically to save on footprint, I had to add the 
following code snippet to the StaticDanceApp.cpp which is part of the CIAO 
distribution (other users would have to add this before they initialize the 
ORB):

#include <ace/Logging_Strategy.h>

/*
* This code defines the LoggingStrategy statically so we
* can use it under the Service Configurator framework */ ACE_STATIC_SVC_DEFINE
(LogStrategy,
                      ACE_TEXT("Logger"),
                      ACE_SVC_OBJ_T,
                      &ACE_SVC_NAME(ACE_Logging_Strategy),
                      ACE_Service_Type::DELETE_THIS |
                      ACE_Service_Type::DELETE_OBJ,
                      0)

ACE_STATIC_SVC_REQUIRE(LogStrategy)


int
ACE_TMAIN (int argc, ACE_TCHAR *argv[])
{
   // these macros portably register these services
   // if needed by a certain platform.
   ACE_STATIC_SVC_REGISTER(LogStrategy); 

I also had to change $ACE_ROOT/netsvcs/servers/main.cpp similarly to make it 
work on static builds (and take static directives in the svc.conf). So unless 
we can make this stuff work out of the box on static builds, hiding the 
details of -ORBServiceConfigLoggerKey would only work on dynamic builds.

Thanks,
Abdul