Problems with latest stable 2.3.4 Release

[dw2412]

Hi Sebastian, hi Manfred,

updated lately to Z-Push 2.3.4 and saw that after you've updated the logging to have file and syslog there seems to be issues with file based logging and Windows Phone 8 device. This device does not send any username in GET Params, has no User in the Base64QueryString and so Z-Push according to code can only work with PHP_AUTH_USER. Unfortunately the logger gets only initialized with this PHP_AUTH_USER after the User Auth is being processed. But this is not covered by current lib/core/zlog.php . Means the User Name & Device ID never gets updated after initalize and authorization of user took place.

I've helped myself by adding some function in Write function but I'm sure that can be solved much more clever... Please have a look at it.

Thanks

Andreas

BTW... Please do a grep for DeviceInformaton in core/base/zpushdefs.php and core/wbxml/wbxmldefs.php ... and replace it with correct "spellchecked" word DeviceInformation - will save log from ugly automapping entries ;-)

[manfred]

Hi Andreas,

we will only be able to look into the WindowsPhone issue next week as we're both more or less out of the office now where our test device is.

I've fixed the typo: . However could you provide more information or logs and what do you mean by automapping entries? I've never seen any errors regarding DeviceInformaton in my tests. Is it with the ZCP/Kopano backend?

Manfred

[dw2412]

Hi Manfred,

thanks for rapid quick reply ;-) The Issue with Windows Phone for me at least right now fixed with my patch - it is just that it should be fixed good way because I don't think it is a good way and for sure in Z-Push Source for upcoming releases...

For the logfile entries - I found them on user/device level with high logging (what you see below is just a quick grep on the log):

[manfred]

Hi Andreas,

there will always be such messages in the log on WBXMLSTACK level. Everywhere in the code like:

if (self::$decoder->getElementStartTag(SOME_TAG)) {

and the tag doesn't match, there will be "WBXMLDecoder->getElementStartTag(): unmatched WBXML tag: ..." output in WBXMLSTACK log level.

WBXMLSTACK is only useful when you're working on e.g. a not yet implemented command. I don't recommend to use it in production or even testing, WBXML is sufficient.

Manfred

[dw2412]

Sure there will be - especially if there are Typo's in the definition files ;-) If you replace them and make them consistent like I suggested for DeviceInformaton vs DeviceInformation the shown messages simply disappear ...

As I wrote already - it is not critical but stops filling up logfiles. Especially if you debugging something you don't need avoidable messages in the logs...

Andreas

[manfred]

Hi Andreas,



No, they won't. I've replaced all occurrences of DeviceInformaton with DeviceInformation and:



The tag names don't make any difference as they're actually for the better readability in logs and easier to code only. So as long as CodePage:TagName (e.g. Settings: DeviceInformation) match the defined namespaces and codes of the DTD in wbxmldefs.php it doesn't actually matter what name a tag has. Because in the incoming WBXML at some place there will be 0x12 (for the Settings namespace) and 0x16 (for the DeviceInformation tag).


If currently the WBXMLDecoder is at page 0x12 (Settings) and tag 0x07 (Get) and in the code there's "if (self::$decoder->getElementStartTag(SYNC_SETTINGS_DEVICEINFORMATIO N)) {" then the last message from above log output will be logged because SYNC_SETTINGS_DEVICEINFORMATION is "Settings: DeviceInformation" and the DeviceInformation tag (0x16) doesn't match the Get (0x07) tag. So, it actually doesn't matter if the tag is named DeviceInformation or DeviceInformaton or BugsBunny as long as those names are consistent in wbxmldefs.php and zpushdefs.php.



Those messages only would disappear if we would heavily change how the request classes process incoming WBXML.


Manfred

[dw2412]

Hi Manfred,

got your point... You're right... sorry, had a typo in my 2nd grep that made me believe it looks better afterwards. At least in end just a typo got fixed...

Andreas