Dear all,
I would like to upgrade the Openfire embedded Jetty web server from 7.4 to 9.1. The primary reason is the speed improvement with SPDY. especially SPDY push. I have fixed all of the compilation errors in building Openfire and implemented the changes required to use the new Connector objects in Jetty 9.x. I am running with Java 8 and everything seems to be working fine.
To have an idea of how fast SPDY is, please visit https://webtide.com/ (developers of Jetty) with a Chrome browser.
Could you show us a branch with the commits for jetty 9.1? I also suggest posting this in the Openfire Dev forum and not in the internal community planing forum.
Related issue: OF-709
Scheduled for 4.0, but unfortunately nobody has an idea for a roadmap for the near future (concerning the releases of 3.9.4/3.10/4.0) and the related bigger tasks, like Maven migration and Java 6 drop.
Ha, when I visited webtide, chrome crashed. Anyway, thanks for taking on this task.
The task is turning out to much more difficult than planned. SPDY does not work with Java 8. I have to use the very latest Jetty version 9.2RC and switch from NPN to ALPN.
I’m going to move this thread to the openfire dev forum and link OF-709 to it if there are no objections.
@Dele Please show us the related commits for review (e.g. as branch in your personal openfire clone at github).
Decided to stay with NPN for now. ALPN and Java 8 are not yet widely adopted. Downgraded to stable Jetty 9.1.5. The use of SPY is hiding behind a Jive Global property in openfire.xml and by default is off.
I will run some more tests locally over the weekend and release to a branch.
here you are
https://github.com/igniterealtime/Openfire/commit/20a12f210436d30eccdaeabb36676c 9d2a81eda7
Ran a SPDY test (http://spdycheck.org/) on my public openfire server
Network Server on 443
Nice, this host has a network service listening on port 443. SPDY works over SSL/TLS which listens on port 443.
SSL/TLS Detected
Good, this host is speaking SSL/TLS. SPDY piggybacks on top of SSL/TLS, so a website needs SSL/TLS to use SPDY.
Warning! Invalid X.509 Certificate
This website is responding with an invalid X.509 certificate. The specific problem(s) with the certificate are:
IncorrectHost
SelfSigned
. By default, most web browsers will not display content from sites with invalid certificates. Users may have trouble accessing this website and using SPDY. Use the Qualys SSL Labs SSL Server Test tool to investigate the problems with the certificate.
ServerHello Contains NPN Extension
Nice, this server including the NPN Entension during the SSL/TLS handshake. The NPN Extension is an additional part of the SSL/TLS ServerHello message which allows the web server to tell browser it supports additional protocols, like SPDY.
Success! SPDY is Enabled!
Hurray, this website is using SPDY! The following protocols are supported:
spdy/3
spdy/2
http/1.1
SPDY Protocol Support Update-To-Date
This website supports the latest version of SPDY, which is spdy/3.
HTTP Fallback Detected
This website is using SPDY, but it also supports traditional HTTP over SSL. This ensures that older web browsers can still access this site using HTTP
HTTP Traffic Allowed
This website can still be access via HTTP. HTTP does not provide any widely implemented mechanism for using other protocols like SPDY. Only traffic over SSL/TLS using the NPN Extension can be optimized with SPDY. By allowing HTTP traffic, this website is not even offering SPDY capable browsers the choice of using SPDY. If possible, this website should redirect all http:// to https://, ideally with a cachable HTTP 301 redirect.
Perfect, but please use next time your own personal openfire repo at github instead of the offical one. This has the advantage that people cloning the offical repo don’t get your development branch and that people watching the repo are not notified about new commits/changes. Instead they can opt-in if they want, by watching your repo.
Once you think your branch is ready for upstream, submit a pull request against ignite’s master to indicate that it’s ready for code review.
I am not sure I want to follow this advice
I am already updating the main repo for the videobridge, rayo and nodejs plugins. I don’t see the point of creating a personal openfire repo just to commit a change that is required and already logged as an issue (OF-709). It is not a new development and does not even need a branch.
I have been involved with updating openfire with Jetty three times now. 6.xx to 7.0, 7.0 to 7.4 and now 7.4 to 9.1. I know my way around the block. I maintain multiple private repos of openfire for my consultancy work and do not want to add any more complexity to my development process.
First let me assure you that I didn’t mean to doubt your skills regarding the jetty update. I just wanted to point out a few best practices when doing working together on open source software.
I don’t see the point of creating a personal openfire repo just to commit a change that is required and already logged as an issue
It is not relevant if the change is required or logged as an issue. Creating a dev branch in your own repository makes not only the the review process easier, it allows us to exploit githubs possiblities.
It is not a new development and does not even need a branch.
Every change to the source is development, Besides you already did create a branch for the jetty update. The name is just unnecessary long and complex. ‘jettyupdate’ or ‘of709’ would have been sufficient.
do not want to add any more complexity to my development process.
git makes such things an ease and if you feel that this adds adds an unjustified extra amount of complexity to your development process I assume you are just not familar enough with git. Those extra complexity is in my eyes minimal and the advantages are worth it.
Creating a dev branch in your own repository
I can understand Dele’s concerns with regard to complexity, because I have them, too.
What’s the point of having write access to the official repo, if Dele shall intsead work on a private repo and make a pull request? In consideration of the fact of very limited number of committers, probably nobody would understand the Jetty upgrade better than Dele anyway, making a review process not very useful.
In fact, the complexity you are trying to enforce is discouraging me to contribute more development work!
Currently, I am happy, when I manage to “git pull, commit, push” but it will need some time, until I/we understand the advantages of git(hub).
This has the advantage that people cloning the offical repo don’t get your development branch
My understanding is, that most branches should only be temporary anway and once the development has finished and merged with master, the branch can/should be deleted. Therefore clones would ideally not contain more than a few actively developed branches, which seems acceptable to have in a clone.
What’s the point of having write access to the official repo, if Dele shall intsead work on a private repo and make a pull request?
I already gave two arguments for not using the official repostroy for development.
probably nobody would understand the Jetty upgrade better than Dele anyway, making a review process not very useful.
That is not true. A second pair of eyes is always helpful to increase the code quality. Even if you are not faimilar with the related code, you are able to spot some mistakes. Trying to understand the proposed changes is also a good way to learn openfire.
In fact, the complexity you are trying to enforce is discouraging me to contribute more development work!
That would be sad, but I’m not going to sacrifice quality just because people don’t want to learn git or don’t want to stick to best practices regarding open source development.
Every commit, without a few exceptions, should get reviewed by at least one other developer before it get’s included into the offical master. I don’t think that this demanding to much. But I’m well aware that I’m the only one who seems to be experienced with git and that my idea of how we should develop openfire is not the same as the one of you, dele and tom. I think that mostly because all of you are git beginners. And I’m pretty sure you would share my opinion if you had more experience.
I mean seriously, it is not that hard to present changes you want to include in the offical repo to the fellow developers in a structured and neatly way, so that they can get reviewed before they are included. Openfire is not some simple piece of code where you can easily make changes without breaking things. We all have made that experience!
To be honest, I’m shocked and disapointed by the stance of my fellow developers when it comes to code quality and review practices.
Actually I aggree on all points. Code quality is important. Review is generally beneficial (I only meant the Jetty review might be not useful, because Dele probably has the most experience in this area).
It’s really only a lack of git experience or generally distributed OS development experience.
The only thing I don’t like so far is the “every-issue-on-a-separate-branch” policy, you suggested (in chat).
So, the best practices would be that everybody has his private repo (fork? clone?) and creates a branch for an issue (or just develops on the trunk) and makes pull requests to the official repo, so that every developer gets informed via email for reviewing?
Sounds reasonable!
Unfortunately there have only been a few answers on your “Future of OF development” thread, so that we could have found a consensus and a policy, we aggre upon. Until this has happened, we shouldn’t consider “bad practice” commit behaviors as strict.
Give us some time to get more familiar with git and I am sure we will approach best practices more and more…
(sorry for going off-topic here, further discussion should probably take place in the OF future thread).
I only meant the Jetty review might be not useful, because Dele probably has the most experience in this area
It is correct that he has likely the most domain knowledge, but is not relevant as it doesn’t mean that a second look over his commit by another developer is useless.
So, the best practices would be that everybody has his private repo (fork? clone?) and creates a branch for an issue (or just develops on the trunk) and makes pull requests to the official repo, so that every developer gets informed via email for reviewing?
That, and that at least somebody else gives his ‘+1’ for the commit before it gets merged, would be my minimal demand that I hope we all can aggree on. Developing with git happens usually in non-master branches, e.g. topic branches. For example if you start a new feature X, a git developer would usually create a new branch for that feature.
I write usually because the experienced git users actions may differ from this practice. Like they say one should not do a forced push. But if you are experienced with git and know the consequences, you will do a forced push when appropriate.
The Smack network graph of today demonstrates that: Network Graph · igniterealtime/Smack · GitHub
I have my master branch with a few additional fixes and on top of that a experimental ‘abstractcon’ branch that is work-in-progress. The commits in my master branches are considered finished but not yet reviewed. Once I hear no oppossing voices from the users in Smack I will push them to official smack repository.
Before git was svn and before svn was cvs. In a galaxy far, far away, people used source safe (vss) and now team foundation. Being git newbies does not make us newbies to the development process especially maintaining quality open source code. I use private git repos on github for my day jobs. I am not an expert, but neither am I am newbie.
The current openfire dev team is not large enough to practise the distributed development model you are proposing for fixing issues. I still insist that addressing issue OF-706 is not a branch development, but code maintainance which should be done on the main (trunk) branch.
For contributing developers outside of the dev team, your proposal makes perfect sense and has my acceptance and full support.
Being git newbies does not make us newbies to the development process
Again, I never claimed that.
The current openfire dev team is not large enough to practise the distributed development model you are proposing for fixing issues.
I don’t see how this process is related to the dev team size. Even if there are only two developers it’s “large” engouh to follow that process.
FWIW I enabled travis for Ignite’s openfire repository. All branches and pull requests are automatically build and the unit-tests are run. Failes are reported to the pull requests. Another argument why we should use pull requests for code review.
I don’t see how this process is related to the dev team size. Even if there are only two developers it’s “large” engouh to follow that process.
But a strict process is usually more beneficial if the team is larger. I think we have to weigh the complexity of a “best practice” process vs. the benefit it brings for a small team size and take care that complexity does not exceed benefit.
As I see it, there are many different workflows, which all have pros and cons (probably depending on the project and team):
There are also many opinions on the workflows, so it’s at least worth a discussion.
E.g. Git Workflow | Atlassian Git Tutorial describes the process, which would fit best for SVN oldies, but git newcomers. Even if it does not leverage the advantages of git, it might work best for us.
I think you two are simply overestimating the “complexity” involved.
E.g. https://www.atlassian.com/git/workflows#!workflow-centralized describes the process, which would fit best for SVN oldies, but git newcomers. Even if it does not leverage the advantages of git, it might work best for us.
And where to you put commits/branches for review when using this approach? Especially you should know that pushing commits that are not considered final to the offical master branch is fatal.