Thanks again for all of your efforts on 8, the release appears to be well received. I know
some of you are already looking at 9, but as I mentioned before the release, I’m hoping we
can all focus on helping the community and fixing 8 issues.
Here is some things you can do to help WF8 be a success:
1. Help our users on the forums, and translate to JIRA as necessary - We have more
activity now that more people are kicking the tires. Let’s keep them engaged and make sure
they feel welcome!
2. Fix the popular bugs - It would be fantastic if we can clean up any discovered problems
in a short time frame, by getting those fixes into 8.0.1.
3. Blog - Helping our new users get familiar with some of the new capabilities is a great
way to build interest. If you like, we can also post your blog entry on WildFly.ORG
it takes a PR, but if you need help get the content written and ping me.
4. Docs/Wikis - If everyone could double check our current docs in their area of
expertise, and make sure they are helpful and up to date that would be awesome. If you see
frequent common questions on the forums, creating an informative wiki would be a great
5. JUG talks - A number of you have already done this, but in case some of you aren’t
aware, Arun is organizing WildFly overview talks with various JUGs that have expressed
interest. There is a presentation ready to go (that you can customize), and its all
virtual (over Google Hangout). Ping him if you are interested in this.
6. Encourage contributors - Sometimes our users are willing or interested in contributing,
but don’t really know how to do it, or maybe just need to know their expertise is desired.
If you see someone digging into things deeply, ask if they are interested in fixing it and
offer to help them through the process.
Here are some major things that we noticed after 8 that need looking into:
1. Our default configuration has some less optimal values. This is mostly because we
specify way too much up-front. One of our original yet not fully realized goals, is that
any parameter which varied according to system capacity would have an auto-set intelligent
default. Things like thread pool sizes should be a ratio of the number of available
processors. Memory based limits should be calculated based on available max memory. Also
we should avoid specifying things that we may later want to change. As an example we might
set an explicit path in our config file, and there really is no reason why we want to do
this other than to inform users the option exists. Ideally that should be a default, which
can be changed after a patch, and any specified value would actually be the intention of
2. Console needs slimming. The recent thread on that was a very useful discussion, and I
think 8.0.1 is a great place to introduce the slimmed console.
3. OpenShift. We should double check there are no open shift issues we need to address
before 8.0.1. There was a thread about JMS configuration issues, and I think we should
If anyone has any other items to raise, now is the time.
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat