Logger usage?

vinceivincei Vincent IbeachumOrganization: Sherman ObservatoryProject: Remote Observatory ControlMember ✭✭
I'm confused - which isn't too hard.

I implemented a custom logger:

....
Ice::InitializationData initdata;
initdata.properties = properties;
initdata.logger = new FilterLoggerI;
ic_ = Ice::initialize(argc, argv,initdata);
.....

I don't see any of the low level ice messages get passed to the 4 routines I've implemented in FilterLoggerI.

I've read the manual but need some clarification.

Thanks, Vince

Comments

  • matthewmatthew NL, CanadaMatthew NewhookOrganization: ZeroC, Inc.Project: Internet Communications EngineMember ✭✭✭
    Have you enabled any tracing? What does the implementation of your logger look like? Ice itself contains three loggers that you can look at for an example (src/Ice/EventLoggerI, src/Ice/LoggerI, src/Ice/SysLogger).
  • vinceivincei Vincent IbeachumOrganization: Sherman ObservatoryProject: Remote Observatory ControlMember ✭✭
    Thanks Matt.

    My logger is modeled after the interface in demo/mfchelloS/LogI.cpp&h
    I was working under the the assumption that installing this simple logger
    would intercept the low level ice messages that are currently printed to
    my console - without having to change/enable anything. Am I way off base?

    I'll study the Loggers that you pointed out.

    -- Vince
  • matthewmatthew NL, CanadaMatthew NewhookOrganization: ZeroC, Inc.Project: Internet Communications EngineMember ✭✭✭
    Yes, that is the idea. If you cannot work out what the problem is post the source to the logger and I can take a look. One way you can easily find out whether your logger is being used is to try printing to it. For example, something like:

    communicator->getLogger()->trace("test", "test");
  • vinceivincei Vincent IbeachumOrganization: Sherman ObservatoryProject: Remote Observatory ControlMember ✭✭
    Here you go:
    class FilterLoggerI : public Ice::Logger
    {
    public:
    
    	FilterLoggerI(){};
    	virtual ~FilterLoggerI(){};
    
        virtual void print(const std::string&);
        virtual void trace(const std::string&, const std::string&);
        virtual void warning(const std::string&);
        virtual void error(const std::string&);
        
    private:
    };
    
    typedef IceUtil::Handle<FilterLoggerI> FilterLoggerIPtr;
    
    void FilterLoggerI::print(const std::string& msg)
    {
    	std::cerr << "[info   ] "  << msg;
    }
    void FilterLoggerI::trace(const std::string& category, const std::string& msg)
    {
    	std::cerr << '[' << category << ']' << " " << msg;
    }
    void FilterLoggerI::warning(const std::string& msg)
    {
    	std::cerr << "[warning] "  << msg;
    }
    void FilterLoggerI::error(const std::string& msg)
    {
    	std::cerr << "[error  ] "  << msg;
    }
    
    ......
    
    
    Ice::InitializationData initdata;
    initdata.properties = properties;
    		
    FilterLoggerIPtr log = new FilterLoggerI;
    initdata.logger = log;
    
    ic_ = Ice::initialize(argc, argv,initdata);
    
    ic_->getLogger()->trace("Vince","Was here");
    


    The trace call works, however, the Ice connection related messages don't come through this code. I set a breakpoint to be sure. I'm sure it's something real simple that I'm missing.

    -- Vince
  • matthewmatthew NL, CanadaMatthew NewhookOrganization: ZeroC, Inc.Project: Internet Communications EngineMember ✭✭✭
    If you are seeing tracing messages through the Ice logger and not your own logger then the only possible explanation is that you have more than one communicator in the process -- one using your logger and the other using the Ice logger.
  • vinceivincei Vincent IbeachumOrganization: Sherman ObservatoryProject: Remote Observatory ControlMember ✭✭
    Hi Matt,

    Thanks. I have only one communicator. It is based on the demo/ice/bidirS
    sample. My custom Logger is implemented on the Server side.

    I went back to basics and modified the demo/ice/bidirS/Server.cpp sample
    code and added my custom logger thus:

    #include <CallbackI.h>
    #include <Ice/Application.h>
    
    using namespace std;
    using namespace Demo;
    
    class FilterLoggerI : public Ice::Logger
    {
    public:
    
        FilterLoggerI(){};
        virtual ~FilterLoggerI(){};
    
        virtual void print(const std::string&);
        virtual void trace(const std::string&, const std::string&);
        virtual void warning(const std::string&);
        virtual void error(const std::string&);
        
    private:
    
    };
    
    typedef IceUtil::Handle<FilterLoggerI> FilterLoggerIPtr;
    
    void FilterLoggerI::print(const std::string& msg)
    {
    	std::cerr << "[info   ] "  << msg << std::endl;
    }
    void FilterLoggerI::trace(const std::string& category, const std::string& msg)
    {
    	std::cerr << '[' << category << ']' << " " << msg << std::endl;
    }
    void FilterLoggerI::warning(const std::string& msg)
    {
    	std::cerr << "[warning] "  << msg << std::endl;
    }
    void FilterLoggerI::error(const std::string& msg)
    {
    	std::cerr << "[error  ] "  << msg << std::endl;
    }
    
    
    
    class CallbackServer : public Ice::Application
    {
    public:
    
        virtual int run(int, char*[]);
    };
    
    int
    main(int argc, char* argv[])
    {
        CallbackServer app;
    #if 0
        return app.main(argc, argv, "config.server");
    #else
        // plug in the properties here for now ...
    
        Ice::PropertiesPtr props = Ice::createProperties();
        props->setProperty("Callback.Server.Endpoints","tcp -p 10000");
        props->setProperty("Ice.ACM.Client","0");
        props->setProperty("Ice.Warn.Connections","1");
        Ice::InitializationData id;
        id.properties = props;
    
        // new Logger ...
        id.logger = new FilterLoggerI;
    
        return app.main(argc, argv,id);
    #endif
    }
    
    
    int
    CallbackServer::run(int argc, char* argv[])
    {
        Ice::ObjectAdapterPtr adapter = communicator()->createObjectAdapter("Callback.Server");
    
        // **** This works ***** //	
        communicator()->getLogger()->trace("Monster", "Truck rally");
    
        CallbackSenderIPtr sender = new CallbackSenderI(communicator());
        adapter->add(sender, communicator()->stringToIdentity("sender"));
        adapter->activate();
    
        sender->start();
        try
        {
            communicator()->waitForShutdown();
        }
        catch(...)
        {
            sender->destroy();
            throw;
        }
        sender->destroy();
    
        return EXIT_SUCCESS;
    }
    

    I ran the server and I see the trace "[Monster] Truck rally" on the console. When I terminate the client the low level trace messages do not pass through my logger. Just so that we're on the same page the messages I'm referring to are these low level server side ICE messages:
    ConnectionI.cpp:2226: Ice::CloseConnectionException:
    protocol error: connection closed
    

    This is on Windows XP with Ice-3.2.0 and VS2005


    Thanks, Vince
  • benoitbenoit Rennes, FranceBenoit FoucherOrganization: ZeroC, Inc.Project: IceAdministrators, ZeroC Staff ZeroC Staff
    vincei wrote: »
    I ran the server and I see the trace "[Monster] Truck rally" on the console. When I terminate the client the low level trace messages do not pass through my logger. Just so that we're on the same page the messages I'm referring to are these low level server side ICE messages:
    ConnectionI.cpp:2226: Ice::CloseConnectionException:
    protocol error: connection closed
    

    This message isn't from the Ice runtime but from the demo server code, check out the implementation of the CallbackSenderI::run() method in CallbackI.cpp, it prints the exception on the stderr output.

    Try running the server with --Ice.Trace.Network=2 for example, the traces should be printed with your logger. For warnings, you can try to "kill -9" the client, the server should eventually print a connection warning with your logger.

    Cheers,
    Benoit.
  • vinceivincei Vincent IbeachumOrganization: Sherman ObservatoryProject: Remote Observatory ControlMember ✭✭
    Ah. The light goes on. Twa's a bad assumption as to where the messages
    come from - too many hours in front of the sceen I guess. I'll take a fresh
    look.

    Thank you.

    -- Vince
  • vinceivincei Vincent IbeachumOrganization: Sherman ObservatoryProject: Remote Observatory ControlMember ✭✭
    Works great now. Thanks.

    -- Vince
Sign In or Register to comment.