Let’s get a new release for Openfire out. I suggest that we, in order:
stop creating issues for the 3.6.5 release (put them in another release instead);
fix the outstanding bugs for 3.6.5;
release a beta.
Over the past few days, I’ve been working on several issues, and I noticed that others are already starting to join in on the fun. I ask you all to review the outstanding 3.6.5 bugs, and contribute where possible. That way, we should be able to release something pretty soon.
I’m looking for help on a couple of things:
Can someone make a 3.6.6 version in JIRA please? I don’t have the appropiate privileges.
OF-87 is killing me. I’ve been looking and trying, but I can’t figure out what’s going wrong there. Help much appreciated!
Generic testing of (both existing and new) functionality - we’ve touched a lot of code recently. It would be good to verify that everything is still working as expected, before we release a beta.
Fix outstanding issues. Feel free to claim an issue by re-assigning it to yourself and mark the issue as “in progress.” That should prevent people working on the same issue.
I will do my best to test OF-72 fix as soon as possible, but we have lots of work at work, so… I won’t mind to push it to a next release if me or someone else won’t be able to test it.
The XSF has declared 5280 as the default port for BOSH (or formerly HTTP-Bind) so I think we should change our default configuration (Port 7070) (see OF-81). Maybe we also change the secured port from 7443 to 5281 or 5243?
Or should we keep the old default ports to be backward compatible and avoid maybe additional configuration for the admins?
I think we should follow the new standards. If we’re not going to do it now, we’re probably not going to do it at all. It will be very visible that another port is being used. If we document it properly in the release notes, it should be fine.
setting this as the default port is right. Anyhow one may want to allow the Openfire administrator to modify it with a system property. And it would be nice if one can bind it to a random ip address/interface.
It may make sense to document which version is implemented, maybe with a copy of it. At least within PubSub the new XEP versions did create a lot of confusion as Openfire implemented a very early one.
I’ll bet you that our implementation is based on an old version of that XEP. Taking this into account, I’d like to change my vote. Lets keep the current implementation on the existing port. We should then create a new implemenation which we can make available on the new ports. This will allow us to be backwards compatible for existing environments, as well as provide better/newer support in the future.
If you all agree, I’m going to push this to the 3.6.6 release though.
I agree that we should review and update the BOSH implementation for the 3.6.6 release. I think BOSH becomes more important and we should test the compatiblity with the current XEP and more clients (read in the forum that there were some problems). I would change the default port for the 3.6.5 release, but I can live with your suggestion.
Is Matt or someone working on OF-90? It would be cool if we release a new version when this scripting vulnerability is fixed, or we start releasing a beta and release the final when this issue is fixed.
Let’s push this to 3.6.6 then. Keeping the port linked to the ‘old’ implementation will enable us to run an old and new implementation next to eachother. This might benefit users that wish to roll-out a migration plan.
Generic testing of (both existing and new) functionality - we’ve touched a lot of code recently. It would be good to verify that everything is still working as expected, before we release a beta.
I would like to write some funcionality tests, but don’t know how to start. I would copy the SmackTestCase class to the src/test/java folder and start to write some MUC tests based on the XEP to discover OF-122. Or do somebody know a more appropriate way to achieve this?
I had to use Smack to do the testing for all the pubsub fixes/changes I made as well. Not the ideal approach but it did server the purpose.
Why would you have to copy the SmackTestCase file? I simply wrote the test cases in Smackx to test the pubsub features, which is basically doing functional testing of the pubsub feature set on the server. I would think you could do the same for MUC as well.
Thinking out loud: As the tests will be very static, you might be able to find a simple way to simply stream raw XML to the server, and check if the responses correspond with something that was predefined too. Unit tests would/should generate the exact same XMPP stanzas anyway. It’d be nice not having to depend on any particular client implementation. I think that for most unit tests, writing and maintaining a lot of setup code (generate a new account, log in, subscribe to another user, etc) that can be re-used between tests requires more work than cleverly copy/pasting some XML snippets. One problem might be the order in which XML elements are returned by the server - if the order is not guaranteed, this might be harder to test for. Another issue might be encryption.
I’d like to see an XML schema validor within Openfire which can be turned on or off (likely with a more advanced logic to enable it for specific users, groups or remote servers, ingoing and or outgoing traffic). One could write a plugin for Openfire or maybe add this to Tinder so even Smack could validate the XMPP traffic. Is a validator something you’d add to Tinder or would a plugin the better solution?
The basic Unic tests should be run within Openfire using XML sinppets but for deeper tests (threads, concurrency) one does need a test client which uses TCP/IP to connect to Openfire.
Although I get only part of it, it sounds interesting. In effect, Openfire is an XMPP validator (your stream will be closed if you’re sending invalid data). How far do you want to take the concept?
A couple of reservations:
I wonder if we’re not defeating the purpose in that way. The XML parsing in Openfire (which we’d skip) is part of the system that we want to test.
Don’t we need a clients session anyway? A lot of Openfires calculations are probably based on session state.
Yes, this is what I would like to see as well. In fact, it was brought up here a few months back when I started contributing code. Unfortunately, until such a thing is introduced, I will probably continue down the path of using the Smack testcases to test the client libs as well as the service.
It would also be a lot simpler if OpenFire modules used Dependency Injection for configuration as to easily enable both unit and functional testing those modules without running the server. This would make testing with static xml stanzas a breeze as no connection, authentication or other setup would be required. Just simple testing of input and output, preferably by copying the stanzas directly from the specs themselves.
I completed a crude triage of all outstanding bugs in the old JM-### Jira project. All of those old bugs that were fixed for 3.6.5 are now showing up as fixed in 3.6.5 release of the OF- Jira project. I changed assignments for a few bugs, asked for updated info, etc…
The moral of the story is that everything current should be in the OF- project now.