[sip-comm-dev] We need you (again) !


#1

Hi all,

*** if you're not a (devil) windows user you can stop reading here ***

You have ten free minutes ? You are convinced that sip communicator is the only escape for a decadent humanity ? You always wanted to do something extraordinary but you never known what to do ?

Today is YOUR day !

1: download Xlite v 3.0 if you don't have it (here: http://www.counterpath.com/index.php?menu=download_xlite&platform=win)

2: create a new SIP account in Xlite with the username 'sctester' and same password for the domain 'iptel.org' (simply right click anywhere on xlite and follow the menus)

3: add 'zerealneo@iptel.org' as your friend (it's me :slight_smile: )

4: tell me the secret phrase : 'welcome in the real world'

5: that's it, you've just saved the humanity !!!

Hurry up, there won't be a place for all of you !
If, while you're saving the world, you encounter any problem, please post a little message on the dev mailing list. If everything is ok, you should see me available and we will be able to communicate.

Good luck,
Ben

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Hi Ben,

I've just tested the SIMPLE support. It is GREAT! It really works very
well! Very good job!

Now there's only one issue with it but I am not sure it only concerns
the SIMPLE implementation. Now, as you send messages, you wait for the
final OK response before firing the MessageDeliveredEvent. This is
great. This is exactly why the MessageDeliveredEvent class exists.

However, since SIMPLE is apparantely the first protocol that uses them
properly (other implementations would fire the delivery events right
after sending the message) this has uncovered a problem with the user
interface.

Right now when you hit send while using SIMPLE, the text would remain
in the editable pane. What's more, the user would still be able to
modify it, or simply continue writing text. Then, when the final SIP
response comes, and the MessageDeliveredEvent is fired, all text is
removed from the send pane.

So we basically have 2 usability problems. 1 - Your messages are not
cleared immediately and give you a sense of lag, 2. All text that you
type after hitting the send button is lost when the delivery event
arrives.

I am thinking that it would probably be better to not wait for the
delivery event and remove the text from the send pane immediately
after hitting the send button. Then, depending on whether we receive a
MessageDeliveredEvent or a MessageDeliveryFailed event, we'd get the
corresponding indication in the non-editable message pane.

I am not completely sure but I don't think that this would require a
lot of modification in the UI.

Yana, what do you think?

Oh, and btw Ben, I tried X-Lite with iptel.org and I wasn't able to
register. I get absolutely no reponses to my REGISTER requests.
Strange indeed.

Emil

···

On 7/27/07, Benoit Pradelle <ze_real_neo@yahoo.fr> wrote:

Hi all,

*** if you're not a (devil) windows user you can stop reading here ***

You have ten free minutes ? You are convinced that sip communicator is
the only escape for a decadent humanity ? You always wanted to do
something extraordinary but you never known what to do ?

Today is YOUR day !

1: download Xlite v 3.0 if you don't have it (here:
http://www.counterpath.com/index.php?menu=download_xlite&platform=win)

2: create a new SIP account in Xlite with the username 'sctester' and
same password for the domain 'iptel.org' (simply right click anywhere on
xlite and follow the menus)

3: add 'zerealneo@iptel.org' as your friend (it's me :slight_smile: )

4: tell me the secret phrase : 'welcome in the real world'

5: that's it, you've just saved the humanity !!!

Hurry up, there won't be a place for all of you !
If, while you're saving the world, you encounter any problem, please
post a little message on the dev mailing list. If everything is ok, you
should see me available and we will be able to communicate.

Good luck,
Ben

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hi again Emil,

Emil Ivov a �crit :

Hi Ben,

I've just tested the SIMPLE support. It is GREAT! It really works very
well! Very good job!
  
Thanks :slight_smile:

Now there's only one issue with it but I am not sure it only concerns
the SIMPLE implementation. Now, as you send messages, you wait for the
final OK response before firing the MessageDeliveredEvent. This is
great. This is exactly why the MessageDeliveredEvent class exists.

However, since SIMPLE is apparantely the first protocol that uses them
properly (other implementations would fire the delivery events right
after sending the message) this has uncovered a problem with the user
interface.

Right now when you hit send while using SIMPLE, the text would remain
in the editable pane. What's more, the user would still be able to
modify it, or simply continue writing text. Then, when the final SIP
response comes, and the MessageDeliveredEvent is fired, all text is
removed from the send pane.

So we basically have 2 usability problems. 1 - Your messages are not
cleared immediately and give you a sense of lag, 2. All text that you
type after hitting the send button is lost when the delivery event
arrives.

I am thinking that it would probably be better to not wait for the
delivery event and remove the text from the send pane immediately
after hitting the send button. Then, depending on whether we receive a
MessageDeliveredEvent or a MessageDeliveryFailed event, we'd get the
corresponding indication in the non-editable message pane.

I am not completely sure but I don't think that this would require a
lot of modification in the UI.

Yana, what do you think?
  
I've noticed this behavior and it's true, it's a little bit disturbing.

Oh, and btw Ben, I tried X-Lite with iptel.org and I wasn't able to
register. I get absolutely no reponses to my REGISTER requests.
Strange indeed.
  
Argl... It seems that XLite is not able to register an iptel.org account. It's sad as XLite is, AFAIK, the only one client to support SIMPLE (except us now :slight_smile: ).
So, sorry guys but you won't be able to save the world today. However, I repeat my question... Does anyone knows a good public SIP server allowing presence and messaging ?
Hey this also mean that we are probably the only one software in the whole world able to use SIMPLE on this server :slight_smile:

Ben

···

Emil

On 7/27/07, Benoit Pradelle <ze_real_neo@yahoo.fr> wrote:
  

Hi all,

*** if you're not a (devil) windows user you can stop reading here ***

You have ten free minutes ? You are convinced that sip communicator is
the only escape for a decadent humanity ? You always wanted to do
something extraordinary but you never known what to do ?

Today is YOUR day !

1: download Xlite v 3.0 if you don't have it (here:
http://www.counterpath.com/index.php?menu=download_xlite&platform=win)

2: create a new SIP account in Xlite with the username 'sctester' and
same password for the domain 'iptel.org' (simply right click anywhere on
xlite and follow the menus)

3: add 'zerealneo@iptel.org' as your friend (it's me :slight_smile: )

4: tell me the secret phrase : 'welcome in the real world'

5: that's it, you've just saved the humanity !!!

Hurry up, there won't be a place for all of you !
If, while you're saving the world, you encounter any problem, please
post a little message on the dev mailing list. If everything is ok, you
should see me available and we will be able to communicate.

Good luck,
Ben

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hi Emil,

completely agree. I'll change this asap.

Yana

Emil Ivov wrote:

···

Hi Ben,

I've just tested the SIMPLE support. It is GREAT! It really works very
well! Very good job!

Now there's only one issue with it but I am not sure it only concerns
the SIMPLE implementation. Now, as you send messages, you wait for the
final OK response before firing the MessageDeliveredEvent. This is
great. This is exactly why the MessageDeliveredEvent class exists.

However, since SIMPLE is apparantely the first protocol that uses them
properly (other implementations would fire the delivery events right
after sending the message) this has uncovered a problem with the user
interface.

Right now when you hit send while using SIMPLE, the text would remain
in the editable pane. What's more, the user would still be able to
modify it, or simply continue writing text. Then, when the final SIP
response comes, and the MessageDeliveredEvent is fired, all text is
removed from the send pane.

So we basically have 2 usability problems. 1 - Your messages are not
cleared immediately and give you a sense of lag, 2. All text that you
type after hitting the send button is lost when the delivery event
arrives.

I am thinking that it would probably be better to not wait for the
delivery event and remove the text from the send pane immediately
after hitting the send button. Then, depending on whether we receive a
MessageDeliveredEvent or a MessageDeliveryFailed event, we'd get the
corresponding indication in the non-editable message pane.

I am not completely sure but I don't think that this would require a
lot of modification in the UI.

Yana, what do you think?

Oh, and btw Ben, I tried X-Lite with iptel.org and I wasn't able to
register. I get absolutely no reponses to my REGISTER requests.
Strange indeed.

Emil

On 7/27/07, Benoit Pradelle <ze_real_neo@yahoo.fr> wrote:

Hi all,

*** if you're not a (devil) windows user you can stop reading here ***

You have ten free minutes ? You are convinced that sip communicator is
the only escape for a decadent humanity ? You always wanted to do
something extraordinary but you never known what to do ?

Today is YOUR day !

1: download Xlite v 3.0 if you don't have it (here:
http://www.counterpath.com/index.php?menu=download_xlite&platform=win)

2: create a new SIP account in Xlite with the username 'sctester' and
same password for the domain 'iptel.org' (simply right click anywhere on
xlite and follow the menus)

3: add 'zerealneo@iptel.org' as your friend (it's me :slight_smile: )

4: tell me the secret phrase : 'welcome in the real world'

5: that's it, you've just saved the humanity !!!

Hurry up, there won't be a place for all of you !
If, while you're saving the world, you encounter any problem, please
post a little message on the dev mailing list. If everything is ok, you
should see me available and we will be able to communicate.

Good luck,
Ben

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hi Ben,
   
  I have tried the xLite with iptel.org and was not able to register.
  Some research revealed the xLite use TCP connection (only?) and the iptel.org listen on UDP. I was able to connect with AdiPhone client setting to UDP connection.
   
  Regarding the public server, I would like to operate such a server. What does it take to present SIMPLE support on JAIN-NIST server?
   
  So, how do we save the world?
   
  Michael
   
  Hi again Emil,

Emil Ivov a �crit :

Hi Ben,

I've just tested the SIMPLE support. It is GREAT! It really works very
well! Very good job!

Thanks :slight_smile:

Now there's only one issue with it but I am not sure it only concerns
the SIMPLE implementation. Now, as you send messages, you wait for the
final OK response before firing the MessageDeliveredEvent. This is
great. This is exactly why the MessageDeliveredEvent class exists.

However, since SIMPLE is apparantely the first protocol that uses them
properly (other implementations would fire the delivery events right
after sending the message) this has uncovered a problem with the user
interface.

Right now when you hit send while using SIMPLE, the text would remain
in the editable pane. What's more, the user would still be able to
modify it, or simply continue writing text. Then, when the final SIP
response comes, and the MessageDeliveredEvent is fired, all text is
removed from the send pane.

So we basically have 2 usability problems. 1 - Your messages are not
cleared immediately and give you a sense of lag, 2. All text that you
type after hitting the send button is lost when the delivery event
arrives.

I am thinking that it would probably be better to not wait for the
delivery event and remove the text from the send pane immediately
after hitting the send button. Then, depending on whether we receive a
MessageDeliveredEvent or a MessageDeliveryFailed event, we'd get the
corresponding indication in the non-editable message pane.

I am not completely sure but I don't think that this would require a
lot of modification in the UI.

Yana, what do you think?

I've noticed this behavior and it's true, it's a little bit disturbing.

Oh, and btw Ben, I tried X-Lite with iptel.org and I wasn't able to
register. I get absolutely no reponses to my REGISTER requests.
Strange indeed.

Argl... It seems that XLite is not able to register an iptel.org
account. It's sad as XLite is, AFAIK, the only one client to support
SIMPLE (except us now :slight_smile: ).
So, sorry guys but you won't be able to save the world today. However, I
repeat my question... Does anyone knows a good public SIP server
allowing presence and messaging ?
Hey this also mean that we are probably the only one software in the
whole world able to use SIMPLE on this server :slight_smile:

Ben

···

Benoit Pradelle <ze_real_neo@yahoo.fr> wrote:

Emil

On 7/27/07, Benoit Pradelle wrote:

Hi all,

*** if you're not a (devil) windows user you can stop reading here ***

You have ten free minutes ? You are convinced that sip communicator is
the only escape for a decadent humanity ? You always wanted to do
something extraordinary but you never known what to do ?

Today is YOUR day !

1: download Xlite v 3.0 if you don't have it (here:
http://www.counterpath.com/index.php?menu=download_xlite&platform=win)

2: create a new SIP account in Xlite with the username 'sctester' and
same password for the domain 'iptel.org' (simply right click anywhere on
xlite and follow the menus)

3: add 'zerealneo@iptel.org' as your friend (it's me :slight_smile: )

4: tell me the secret phrase : 'welcome in the real world'

5: that's it, you've just saved the humanity !!!

Hurry up, there won't be a place for all of you !
If, while you're saving the world, you encounter any problem, please
post a little message on the dev mailing list. If everything is ok, you
should see me available and we will be able to communicate.

Good luck,
Ben

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Hi Emil, Ben,

It's done. We now clear the write area right after user clicks the send button. Ben, let me know if it works properly for SIMPLE?

Yana

Yana Stamcheva wrote:

···

Hi Emil,

completely agree. I'll change this asap.

Yana

Emil Ivov wrote:

Hi Ben,

I've just tested the SIMPLE support. It is GREAT! It really works very
well! Very good job!

Now there's only one issue with it but I am not sure it only concerns
the SIMPLE implementation. Now, as you send messages, you wait for the
final OK response before firing the MessageDeliveredEvent. This is
great. This is exactly why the MessageDeliveredEvent class exists.

However, since SIMPLE is apparantely the first protocol that uses them
properly (other implementations would fire the delivery events right
after sending the message) this has uncovered a problem with the user
interface.

Right now when you hit send while using SIMPLE, the text would remain
in the editable pane. What's more, the user would still be able to
modify it, or simply continue writing text. Then, when the final SIP
response comes, and the MessageDeliveredEvent is fired, all text is
removed from the send pane.

So we basically have 2 usability problems. 1 - Your messages are not
cleared immediately and give you a sense of lag, 2. All text that you
type after hitting the send button is lost when the delivery event
arrives.

I am thinking that it would probably be better to not wait for the
delivery event and remove the text from the send pane immediately
after hitting the send button. Then, depending on whether we receive a
MessageDeliveredEvent or a MessageDeliveryFailed event, we'd get the
corresponding indication in the non-editable message pane.

I am not completely sure but I don't think that this would require a
lot of modification in the UI.

Yana, what do you think?

Oh, and btw Ben, I tried X-Lite with iptel.org and I wasn't able to
register. I get absolutely no reponses to my REGISTER requests.
Strange indeed.

Emil

On 7/27/07, Benoit Pradelle <ze_real_neo@yahoo.fr> wrote:

Hi all,

*** if you're not a (devil) windows user you can stop reading here ***

You have ten free minutes ? You are convinced that sip communicator is
the only escape for a decadent humanity ? You always wanted to do
something extraordinary but you never known what to do ?

Today is YOUR day !

1: download Xlite v 3.0 if you don't have it (here:
http://www.counterpath.com/index.php?menu=download_xlite&platform=win)

2: create a new SIP account in Xlite with the username 'sctester' and
same password for the domain 'iptel.org' (simply right click anywhere on
xlite and follow the menus)

3: add 'zerealneo@iptel.org' as your friend (it's me :slight_smile: )

4: tell me the secret phrase : 'welcome in the real world'

5: that's it, you've just saved the humanity !!!

Hurry up, there won't be a place for all of you !
If, while you're saving the world, you encounter any problem, please
post a little message on the dev mailing list. If everything is ok, you
should see me available and we will be able to communicate.

Good luck,
Ben

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Hi Michael,

I didn't know AdiPhone and if it support presence and messaging (it seems to but the website isn't really explicit) it may be useful to do some compatibility tests with it.

If you like to create a SIP server we can use for testing SIMPLE, it'll simply have to correctly retransmit MESSAGE, SUBSCRIBE, NOTIFY and PUBLISH requests (and responses). If it is able to do it, it would be fantastic for us :slight_smile: and if it is able to act as a presence server it would be event better but it's not an obligation.
Now if you're asking me how to configure a specific server, I really don't know but perhaps someone else here knows ?

Ben

mik a �crit :

···

Hi Ben,
I have tried the xLite with iptel.org and was not able to register.
Some research revealed the xLite use TCP connection (only?) and the iptel.org listen on UDP. I was able to connect with AdiPhone client setting to UDP connection.
Regarding the public server, I would like to operate such a server. What does it take to present SIMPLE support on JAIN-NIST server?
So, how do we save the world?
Michael

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

Hi All,
   
  After spending 5 hours (!) figuring out why my debug messages are not shown, and why log file is not created, I learned that this is an initialization "property file" issue.
   
  To cope with this implicitly, I have created a method that check to see if log file is registered and if not, make the registering.
   
  You might want to add it to the logger.java code:
   
  /**
     * SETUP the logger propery values so log file will produce and FINE messgaes gets recorded

logging.txt (2.56 KB)

···

*
     * Check that some logger initializeation paramteres exists. If not do make some defualt initialization.
     * It was developed because the ConsoleLogger did not output debug ('fine") information.
     * @Author Michael Kraizleman at 29 July 2007
     */
    private static void checkInitializationParameters() {
        LogManager logManager = LogManager.getLogManager();
        String value = logManager.getProperty("java.util.logging.FileHandler");
        if (value != null && value.length() > 0) return;
        
        String params =
"# \"handlers\" specifies a comma separated list of log Handler \n" +
"# classes. These handlers will be installed during VM startup. \n" +
"# Note that these classes must be on the system classpath. \n" +
"# By default we only configure a ConsoleHandler, which will only \n" +
"# show messages at the INFO and above levels. \n" +
"handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler \n" +
"\n" +
"# Default global logging level. \n" +
"# This specifies which kinds of events are logged across \n" +
"# all loggers. For any given facility this global level \n" +
"# can be overriden by a facility specific level \n" +
"# Note that the ConsoleHandler also has a separate level \n" +
"# setting to limit messages printed to the console. \n" +
".level= FINE \n" +
"\n" +
"############################################################\n" +
"# Handler specific properties.\n" +
"# Describes specific configuration info for Handlers.\n" +
"############################################################" +
  "# default file output is in user's home directory.\n" +
"java.util.logging.FileHandler.pattern = %h/.sip-communicator/log/sip-communicator%u.log\n" +
"java.util.logging.FileHandler.limit = 5000000\n" +
"java.util.logging.FileHandler.count = 1\n" +
"java.util.logging.FileHandler.formatter = net.java.sip.communicator.util.ScLogFormatter\n" +
"java.util.logging.FileHandler.level = FINEST\n" +
"# Limit the message that are printed on the console to FINE and above).\n " +
"java.util.logging.ConsoleHandler.level = FINE\n" +
"java.util.logging.ConsoleHandler.formatter = net.java.sip.communicator.util.ScLogFormatter\n";
         
         InputStream in = new ByteArrayInputStream(params.getBytes() );
        try {
            logManager.readConfiguration(in);
        } catch (IOException ex) {
            ex.printStackTrace();
        }
    }
    
    static { checkInitializationParameters(); }


#9

Hello Mik,

Thanks for sending the patch over.

Right now all SIP Communicator installers as well as the run target in
the build.xml file configure the logger to send output to both a file
under $HOME/.sip-communicator/log and the console. These settings are
available in sip-communicator/lib/logging.properties.

People could change this behaviour in custom deployments of SIP
Communicator. Personally I don't see a compelling reason as to why we
should be hardcoding it.

As things currently are if someone tries to modify logging behaviour and
gets it wrong (e.g. messes up the logging.properties file and makes it
imparsable) our logger would simply use the default logging policy and
formatting for java.util.logging. I believe this is best for debugging
and predictability.

Other opinions?

Emil

mik wrote:

···

Hi All,

After spending 5 hours (!) figuring out why my debug messages are not
shown, and why log file is not created, I learned that this is an
initialization "property file" issue.

To cope with this implicitly, I have created a method that check to see
if log file is registered and if not, make the registering.

You might want to add it to the logger.java code:

  /**
     * SETUP the logger propery values so log file will produce and
FINE messgaes gets recorded
     *
     * Check that some logger initializeation paramteres exists. If not
do make some defualt initialization.
     * It was developed because the ConsoleLogger did not output debug
('fine") information.
     * @Author Michael Kraizleman at 29 July 2007
     */
    private static void checkInitializationParameters() {
        LogManager logManager = LogManager.getLogManager();
        String value =
logManager.getProperty("java.util.logging.FileHandler");
        if (value != null && value.length() > 0) return;
       
        String params =
"# \"handlers\" specifies a comma separated list of log Handler \n" +
"# classes. These handlers will be installed during VM startup. \n" +
"# Note that these classes must be on the system classpath. \n" +
"# By default we only configure a ConsoleHandler, which will only \n" +
"# show messages at the INFO and above levels. \n" +
"handlers= java.util.logging.FileHandler,
java.util.logging.ConsoleHandler \n" +
"\n" +
"# Default global logging level. \n" +
"# This specifies which kinds of events are logged across \n" +
"# all loggers. For any given facility this global level \n" +
"# can be overriden by a facility specific level \n" +
"# Note that the ConsoleHandler also has a separate level \n" +
"# setting to limit messages printed to the console. \n" +
".level= FINE \n" +
"\n" +
"############################################################\n" +
"# Handler specific properties.\n" +
"# Describes specific configuration info for Handlers.\n" +
"############################################################" +
"# default file output is in user's home directory.\n" +
"java.util.logging.FileHandler.pattern =
%h/.sip-communicator/log/sip-communicator%u.log\n" +
"java.util.logging.FileHandler.limit = 5000000\n" +
"java.util.logging.FileHandler.count = 1\n" +
"java.util.logging.FileHandler.formatter =
net.java.sip.communicator.util.ScLogFormatter\n" +
"java.util.logging.FileHandler.level = FINEST\n" +
"# Limit the message that are printed on the console to FINE and
above).\n " +
"java.util.logging.ConsoleHandler.level = FINE\n" +
"java.util.logging.ConsoleHandler.formatter =
net.java.sip.communicator.util.ScLogFormatter\n";
        
         InputStream in = new ByteArrayInputStream(params.getBytes() );
        try {
            logManager.readConfiguration(in);
        } catch (IOException ex) {
            ex.printStackTrace();
        }
    }
   
    static { checkInitializationParameters(); }
   
------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#10

Hi Mik!
  

After spending 5 hours (!) figuring out why my debug
messages are not shown, and why log file is not created,
I learned that this is an initialization "property file"
issue.
   
To cope with this implicitly, I have created a method
that check to see if log file is registered and if not,
make the registering.
   
You might want to add it to the logger.java code:

[snip]

You can also set the system property "java.util.logging.config.file" to
point to the logger configuration property file which you have embedded in
the code. It will be read when the Java VM starts. This way, no code has to
be changed and it is easier to adapt the settings to your personal
(debugging) needs.

As a matter of fact, I have just seen that this is already done in the "run"
task of the SIP-Communicator build file. Just edit the
lib/logging.properties to your needs.

On an only slightly related matter, a thing which I see as a bit of a
drawback is that all logging calls go through the logging class instead of
calling the Java API directly. Because of this, the log file doesn't show
which class and method the logging call came from. I wonder if it would be
possible or sensible to change this.

Regards
Michael Koch


#11

Hi Emil Ivov and Michael Kock,
   
  As I mentioned, I was spending 5 hours figuring out the reason for absent log records. I was using sip-communicator components in our implementation, using Netbeans debug mode.
   
  The default hard code I proposed allows programmers to produce log files when they are using their debugger without special configuration (and investigation required). It might shorten the learning curve of newcomers to sip-communicator.
   
  Best regards,
   
  Mik

···

Emil Ivov <emcho@sip-communicator.org> wrote:
  Hello Mik,

Thanks for sending the patch over.

Right now all SIP Communicator installers as well as the run target in
the build.xml file configure the logger to send output to both a file
under $HOME/.sip-communicator/log and the console. These settings are
available in sip-communicator/lib/logging.properties.

People could change this behaviour in custom deployments of SIP
Communicator. Personally I don't see a compelling reason as to why we
should be hardcoding it.

As things currently are if someone tries to modify logging behaviour and
gets it wrong (e.g. messes up the logging.properties file and makes it
imparsable) our logger would simply use the default logging policy and
formatting for java.util.logging. I believe this is best for debugging
and predictability.

Other opinions?

Emil


#12

Hi Michael,

(see inline)

Koch Michael wrote:

Hi Mik!
  

After spending 5 hours (!) figuring out why my debug
messages are not shown, and why log file is not created,
I learned that this is an initialization "property file"
issue.
   
To cope with this implicitly, I have created a method
that check to see if log file is registered and if not,
make the registering.
   
You might want to add it to the logger.java code:

[snip]

You can also set the system property "java.util.logging.config.file" to
point to the logger configuration property file which you have embedded in
the code. It will be read when the Java VM starts. This way, no code has to
be changed and it is easier to adapt the settings to your personal
(debugging) needs.

As a matter of fact, I have just seen that this is already done in the "run"
task of the SIP-Communicator build file. Just edit the
lib/logging.properties to your needs.

On an only slightly related matter, a thing which I see as a bit of a
drawback is that all logging calls go through the logging class instead of
calling the Java API directly. Because of this, the log file doesn't show
which class and method the logging call came from.

This is strange. Here's what I see in my log file:

20:35:48.890 FINE: impl.protocol.sip.OperationSetPresenceSipImpl.fireProviderMsgStatusChangeEvent().745 status dispatching done.
20:35:48.890 FINE: impl.protocol.sip.OperationSetPresenceSipImpl.unsubscribeToAllContact().3896 trying to unsubscribe to every contact
20:35:48.890 FINE: impl.protocol.sip.OperationSetBasicInstantMessagingSipImpl.registrationStateChanged().573 The provider changed state from: RegistrationState=Registered to: RegistrationState=Unregistering
20:35:48.891 FINE: impl.protocol.sip.ProtocolProviderServiceSipImpl.registrationStateChanged().2127 Received a RegistrationStateChangeEvent: RegistrationStateChangeEvent[ oldState=Registered; newState=RegistrationState=Unregistering;reasonCode=0;reason=]

The only thing our logger is stripping is the net.java.sip.communicator
prefix (if it exists) in an effort to shorten lines a little bit. Other
than that we do have the calling class, method, and even line number.
Are you sure you are using SIP Communicator with the default logger
settings?

Cheers
Emil

I wonder if it would be

<> possible or sensible to change this.

···

Regards
Michael Koch

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#13

Hi Emil!

The only thing our logger is stripping is the
net.java.sip.communicator
prefix (if it exists) in an effort to shorten lines a little
bit. Other
than that we do have the calling class, method, and even line number.
Are you sure you are using SIP Communicator with the default logger
settings?

Thanks for your answer. I'm sorry, I should have looked at the source closer
before commenting. I was only looking at the log messages as produced by
SIP-Communicator when embedded in our application, which uses our own
logging configuration. What I haven't seen is that SIP-Communicator uses a
custom log formatter which does the caller inference. I think this is a bit
of duplication of functionality, since the LogRecord already does this. But
on the other hand, with this approach you are also logging the line number,
which is really nice. So I take back my original comment.

Regards
Michael Koch