JM-1465 is still not solved, so I created an updated version of my bugfix plugin. Version 0.5 does not longer dump repaired XML packets into info.log. By default is does log an short message only. You may also disable logging completely by setting system property plugin.dropper.log to false and restarting the plugin.
Question is now if this is worth an “official” announcement, since this is annoying bug and most people would assume this was solved with 3.6.1?
I’m sorry i dont quite understand. Announcement of what should be done? Of that problem in Openfire or about your plugin? Maybe i dont understand all the technical details, but as i understand this can be done to make Openfire to handle such not legal packets more elegant.
As I said in the Jira issue, I wouldn’t use a plugin to solve this problem. The idea of making the disconnection optional or not can be handled by the fix in the core itself. Therefore, I would recommend not spreading the use of this plugin if we are going to “deprecate” it soon.
Thanks,
– Gato
Therefore, I would recommend not spreading the use of this plugin if we are going to “deprecate” it soon.
The problem is, what means “soon” to you? If this takes again 2 months…
I’m sorry i dont quite understand. Announcement of what should be done?
An announcement that there is still an “blocker” issue in Openfire which makes it unusable when some of the users use Miranda or some of the other clients (list see JIRA). And there is an simple temporary workaround by using that plugin until 3.6.2 is released. (We should have made this announcment two months ago, when we discovered this problem.)
Example: I’m in the contact list of approx. 1000 users (one side subscription by shared group). If only one of this 1000 people comes online with an old Miranda client he kicks ME from the server. This results for me in kicked from the server every few minutes. The user himself will not even notice that he kicked most users in this roster from the server.
If release of 3.6.2 is planned within next two weeks, I would also recommend not to spread this plugin.
Hey Martin,
The problem is, what means “soon” to you? If this takes again 2 months…
I have to say that comments like that take away any fun I can find working on this project. Please lets keep a positive attitude and stop beating the dead horse.
– Gato
Hi coolcat,
Coolcat wrote:
If only one of this 1000 people comes online with an old Miranda client he kicks ME from the server. This results for me in kicked from the server every few minutes.
whoa, I haven’t been closely following this issue, but that is truely the case?!
daryl
If it’s truly a blocker then yes, we can do another release within a couple of weeks.
-Matt
I have to say that comments like that take away any fun I can find working on this project.
Sorry, was not meant that way.
but that is truely the case?!
That’s why I wrote that plugin, so I could use my server again…
Hi Matt and Gato,
I was skeptical of this at first, but now I am a believer in what coolcat says. Here is a more concrete example:
I send this to gato:
<iq type='get' to='gato@igniterealtime.org/blah'>
<query xmlns='jabber:iq:version'/> </iq>
Gato gets logged out of the server
daryl
Hey Daryl,
Bug confirmed. This is clearly a blocker. Fixing it now and pushing a new release this Thursday. I will see what else we can includle for 3.6.2. So far we have 5 things solved.
Thanks,
– Gato
Hi Gato,
Sorry, I have another ‘blocker’ candidate for you.
http://www.igniterealtime.org/issues/browse/JM-1496
This prevents httpbind from starting up at openfire start. You have to reconfigure httpbind on the admin console to get it to start!
daryl
Hey Daryl,
Perfect. Thanks for the input. I updated Jira with what I think I will be able to solve for 3.6.2.
Thanks,
– Gato
FYI, http://www.igniterealtime.org/issues/browse/JM-1465 has been fixed. Code is in repository now.
– Gato
dombiak_gaston wrote:
Fixing it now and pushing a new release this Thursday. I will see what else we can includle for 3.6.2. So far we have 5 things solved.
I think i remember you mentioned somewhee that 3.6.2 will be a beta first. Will it?
Right. Since this is a blocker issue I want to push a final release. I was going to spend some time testing the plugin fix before the final release. Is anyone can help with the testing let me know.
Thanks,
– Gato
I don’t know if i can help. I’m now with 11.18 nightly build and i have already descibed how plugins are acting for me in Windows (Jira comment).
Strange thing. Has anyone received such a message “Alert:_Exploit_exploited” from igniterealtime.org user (i’m using IM Gateway so it looks like igniterealtime.org@xmpp.server to me. I’ve got two such messages in a few minutes.
Strange thing. Has anyone received such a message “Alert:_Exploit_exploited” from igniterealtime.org user (i’m using IM Gateway so it looks like igniterealtime.org@xmpp.server to me. I’ve got two such messages in a few minutes.
I’ve found out You better update Ignite Openfire server soonish too
@ JM-1465 (ID-attribute bug)
Ok, gave it a quick test, looks good. However, I suggest a default value of true instead of false for the new system property xmpp.server.validation.enabled
My initial value was true but decided to go with false to be backwards compatible. The server should be fine with a false value as long as the IQ packet is sent to a full JID. Going with a true value may affect many clients that would be disconnected so I preferred the false value.
– Gato
PS: Update to ignite.org is on its way.
Hi,
I prefer simple bug fixes for more or less urgent “BLOCK” issues which are based on the current version and do address only these issues. Those releases are much more easy to test and do likely contain no new bugs. 3.6.1 does contain 14 fixes and 3.6.2 will contain 9 fixed issues. I would have prefered a 3.6.0b version which addresses the four BLOCK issues and a 3.6.0c version which adresses the two BLOCK issues.
I know that backports are not popular for developers, but regarding QA they are imho “needed”.
LG