July 2015 - wildfly-dev - Jboss List Archives

WildFly 8.2.1.Final and 9.0.1.Final are now on OpenShift

by Farah Juma

Details for getting started can be found here: 8.2.1.Final: https://github.com/openshift-cartridges/openshift-wildfly-cartridge/tree/... 9.0.1.Final: https://github.com/openshift-cartridges/openshift-wildfly-cartridge/tree/...

11 years

1
0
0 / 0

Removing wildfly embedded

by Tomaž Cerar

Hi folks, I was wondering if we could remove wildfly-embedded (GAV: org.wildfly:wildfly-embedded) https://github.com/wildfly/wildfly/tree/master/embedded module given that we now have better embedded in WildFly-core (GAV: org.wildfly.core:wildfly-embedded) https://github.com/wildfly/wildfly-core/tree/master/embedded Only user we had (that I know of) was WildFly arquillian adapter but that was moved to wildfly-core's embedded already. So any objections to removing embedded from WldFly full codebase? any potential users should migrate can easily migrate to new API if they desire. -- tomaz

11 years

1
1
0 / 0

8.2.1.Final & 9.0.1.Final Released

by Jason T. Greene

Hello Everyone, As some of of have already seen, last night WildFly 9.0.1.Final and 8.2.1.Final were released. These releases include security updates and bug fixes. The issues addressed for 8.2.1 are: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12313721&versi... and include: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12312521&versi... https://github.com/jboss/xerces/pulls?q=is%3Apr+is%3Aclosed The issues addressed for 9.0.1 are: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12313721&versi... and include https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12312521&versi... Thanks!

11 years

1
0
0 / 0

New WildFly Naming Client library repository

by David M. Lloyd

I've published the new naming client library to GitHub under the WildFly org [1]. Features include: * ServiceLoader-based naming providers off of a common initial context * Implementation of the remote-naming protocol using new Remoting connection management * Support for wildfly-client-config configuration file * Proper support for federation * Useful base classes for easily implementing naming subtrees with or without federation support The new EJB client library is already using this support for its "ejb:" scheme, cutting down that project's naming code by an appreciable fraction. As part of the server integration, it is likely that this will be layered in to the server JNDI system. Still TODO: * Per-request security and transaction propagation for the remote naming protocol * Stabilized dependencies so I can tag a release [1] https://github.com/wildfly/wildfly-naming-client -- - DML

11 years

1
0
0 / 0

DOS causes logs with huge size

by Eduardo Sant'Ana da Silva

Anyone already saw this? I had, what I presume was a DOS attack in a virtual machine on the cloud, that consumes all space left. I saw single files log with more than 2.5G of information on my standalone log directory: 2015-07-20 06:53:46,024 SEVERE [javax.jmdns.impl.constants.DNSRecordType] (SocketListener(45-55-77-19.local.)) Could not find reco rd type for index: -1 2015-07-20 06:53:46,042 SEVERE [javax.jmdns.impl.DNSIncoming] (SocketListener(45-55-77-19.local.)) Could not find record type: dns [query,192.99.0.161:52050, length=184, id=0x5c78, flags=0x3030] 0: 5c7830305c783030 5c7830305c783030 5c7830305c783031 5c7830305c783030 \x00\x00 \x00\x00 \x00\x01 \x00\x00 20: 5c7830305c783030 5c7830305c783030 5c7830395c783546 5c7837335c783635 \x00\x00 \x00\x00 \x09\x5F \x73\x65 40: 5c7837325c783736 5c7836395c783633 5c7836355c783733 5c7830375c783546 \x72\x76 \x69\x63 \x65\x73 \x07\x5F 60: 5c7836345c783645 5c7837335c783244 5c7837335c783634 5c7830345c783546 \x64\x6E \x73\x2D \x73\x64 \x04\x5F 80: 5c7837355c783634 5c7837305c783035 5c7836435c783646 5c7836335c783631 \x75\x64 \x70\x05 \x6C\x6F \x63\x61 a0: 5c7836435c783030 5c7830305c783043 5c7830305c783031 \x6C\x00 \x00\x0C \x00\x01 2015-07-20 06:53:46,076 WARNING [javax.jmdns.impl.constants.DNSRecordClass] (SocketListener(45-55-77-19.local.)) Could not find re cord class for index: -1 2015-07-20 06:53:46,260 SEVERE [javax.jmdns.impl.DNSIncoming$MessageInputStream] (SocketListener(45-55-77-19.local.)) bad domain n ame: possible circular name detected. Bad offset: 0xffffffff at 0xb6 2015-07-20 06:53:46,270 SEVERE [javax.jmdns.impl.constants.DNSRecordType] (SocketListener(45-55-77-19.local.)) Could not find reco rd type for index: -1 2015-07-20 06:53:46,296 SEVERE [javax.jmdns.impl.DNSIncoming] (SocketListener(45-55-77-19.local.)) Could not find record type: dns [query,192.99.0.161:52050, length=184, id=0x5c78, flags=0x3030, questions=1 questions: [DNSQuestion@2024648779 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: 0\x00\x01\x00\x00\x00\x00\x00\x00\x 09\x5F\x73\x6.\x72\x76\x69\x63\x65\x73\x07\x5F\x64\x6E\x73\x2D\x73\.4\x04\x5F\x75\x64\x70\x05\x6C\x6F\x63\x61\x6C\x00\x00\.C\x00\x 01ϿϿϿϿϿϿϿϿϿϿϿϿϿϿϿϿϿϿϿϿ.]] question: [DNSQuestion@2024648779 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: 0\x00\x01\x00\x00\x0 0\x00\x00\x00\x09\x5F\x73\x6.\x72\x76\x69\x63\x65\x73\x07\x5F\x64\x6E\x73\x2D\x73\.4\x04\x5F\x75\x64\x70\x05\x6C\x6F\x63\x61\x6C\x 00\x00\.C\x00\x01ϿϿϿϿϿϿϿϿϿϿϿϿϿϿϿϿϿϿϿϿ.] 0: 5c7830305c783030 5c7830305c783030 5c7830305c783031 5c7830305c783030 \x00\x00 \x00\x00 \x00\x01 \x00\x00 20: 5c7830305c783030 5c7830305c783030 5c7830395c783546 5c7837335c783635 \x00\x00 \x00\x00 \x09\x5F \x73\x65 40: 5c7837325c783736 5c7836395c783633 5c7836355c783733 5c7830375c783546 \x72\x76 \x69\x63 \x65\x73 \x07\x5F 60: 5c7836345c783645 5c7837335c783244 5c7837335c783634 5c7830345c783546 \x64\x6E \x73\x2D \x73\x64 \x04\x5F 80: 5c7837355c783634 5c7837305c783035 5c7836435c783646 5c7836335c783631 \x75\x64 \x70\x05 \x6C\x6F \x63\x61 a0: 5c7836435c783030 5c7830305c783043 5c7830305c783031 \x6C\x00 \x00\x0C \x00\x01 Maybe this could give a hint: http://sourceforge.net/p/jmdns/bugs/130/ Is this an issue that wildfly should care about? Regards Eduardo Sant'Ana da Silva

11 years

2
3
0 / 0

How to contribute pull requests to WildFly

by David M. Lloyd

Since migrating to git, and a review-oriented contribution structure, we've seen a massive improvement in the quality and quantity of community contribution in both WildFly itself and its affiliated projects. However, while we have lots of documents about how to get the WildFly code, hack on it, use git to make a branch, submit a pull request, etc., one thing rarely (if ever) talked about is any kind of standards as to how to actually build and structure your pull requests, so I'm going to establish that right now. I have a few reasons for doing this. First, the reviewers are stretched thin - very thin. This has several bad effects, including (but not limited to): * Pull requests sitting in the queue for extended periods of time * Giant pull requests getting less review than small pull requests * Pull requests receiving highly variable quality-of-review Secondly, we see problematic pull requests in a wide variety of shapes and sizes, from the single-unreviewable-mega-commit PR to the thousand-tiny-commit PR to the mixed-form-and-function-commit PR, as well as some stealthier cases like the build-is-broken-between-commits PR. Thirdly, the project has reached a size and scope where we really need to have more eyes on every change - as many as possible in fact. To that effect, and borrowing some concepts heavily from the Linux Kernel project's documentation [1], I offer this. You're welcome. (For background on how to get started with contribution, the hacking guide [2] is still the best place to start; after any initial discussion, I'll probably throw this up alongside that.) WildFly Contribution and Pull Request Standards ----------------------------------------------- While a complete git tutorial is far, far out of scope of this guide, there are a few important rules and guidelines to adhere to when creating a pull request for WildFly or one of its constituent or related sub-projects. 1) Describe the pull request adequately. The description *should* include a JIRA number directly from the project in question, whose corresponding JIRA issue will in turn have been linked to the pull request you are just now creating. The description *should* also include a decent, human-readable summary of what is changing. Proper spelling and grammar is a plus! 2) Make sure it builds and tests pass *first*. It is highly annoying to reviewers when they find they've spent a great deal of time reviewing some code only to discover that it doesn't even compile. In particular, it's common for a patch to trip CheckStyle if it hadn't been previously compile-tested at the least. While it is tempting to rely on the automated CI/GitHub integration to do our build and test for us (and I'm guilty of having done this too), it generally just causes trouble, so please don't do it! 3) Separate your changes - but not *too* much. This comes directly from [1], and I agree with it 100%: "Separate each _logical change_ into a separate patch. "For example, if your changes include both bug fixes and performance enhancements for a single driver, separate those changes into two or more patches. If your changes include an API update, and a new driver which uses that new API, separate those into two patches. "On the other hand, if you make a single change to numerous files, group those changes into a single patch. Thus a single logical change is contained within a single patch. "The point to remember is that each patch should make an easily understood change that can be verified by reviewers. Each patch should be justifiable on its own merits. "If one patch depends on another patch in order for a change to be complete, that is OK. Simply note "this patch depends on patch X" in your patch description. "When dividing your change into a series of patches, take special care to ensure that [WildFly] builds and runs properly after each patch in the series. Developers using "git bisect" to track down a problem can end up splitting your patch series at any point; they will not thank you if you introduce bugs in the middle. "If you cannot condense your patch set into a smaller set of patches, then only post say 15 or so at a time and wait for review and integration." I also want to emphasize how important it is to separate *functional* and *non-functional* changes. The latter category includes reformatting (which generally should *not* be done without a strong justification). 4) Avoid massive and/or "stream of consciousness" branches We all know that development can sometimes be an iterative process, and we learn as we go. Nonetheless, we do not need or want a complete record of all the highs and lows in the history of every change (for example, an "add foobar" commit followed later by a "remove foobar" commit in the same PR) - particularly for large changes or in large projects (like WildFly proper). It is good practice for such change authors to go back and rearrange and/or restructure the commits of a pull request such that they incrementally introduce the change in a logical manner, as one single conceptual change per PR. If a PR consists of dozens or hundreds of nontrivial commits, you will want to strongly consider dividing it up into multiple PRs, as PRs of this size simply cannot be effectively reviewed. They will either be merged without adequate review, or outright ignored or closed. Which one is worse, I leave to your imagination. 5) Pay attention and respond to review comments While in general it is my experience that WildFly contributors are good about this, I'm going to quote this passage from [1] regardless: "Your patch will almost certainly get comments from reviewers on ways in which the patch can be improved. You must respond to those comments; ignoring reviewers is a good way to get ignored in return. [...] "Be sure to tell the reviewers what changes you are making and to thank them for their time. Code review is a tiring and time-consuming process, and reviewers sometimes get grumpy. Even in that case, though, respond politely and address the problems they have pointed out." In addition, when something needs to be changed, the proper manner to do so is generally to modify the original commit, not to add more commits to the chain to fix issues as they're reported. See (4). 6) Don't get discouraged It may come to pass that you have to iterate on your pull request many times before it is considered acceptable. Don't be discouraged by this - instead, consider that to be a sign that the reviewers care highly about the quality of the code base. At the same time though, consider that it is frustrating for reviewers to have to say the same things over and over again, so please do take care to provide as high-quality submissions as possible, and see (5)! 7) You can review code too! You don't have to be an official reviewer in order to review a pull request. If you see a pull request dealing with an area you are familiar with, feel free to examine it and comment as needed. In addition, *all* pull requests need to be reviewed for basic (non-machine-verifiable) correctness, including noticing bad code, NPE risks, and anti-patterns as well as "boring stuff" like spelling and grammar and documentation. 8) On major refactorings When doing major and/or long-term refactors, while rare, it is possible that the above constraints become impractical, especially with regard to grouping changes. In this case, you can use a work branch on a (GitHub) fork of WildFly, applying the above rules in micro-scale to just that branch. In this case you could possibly ask a reviewer to also review some or all of the pull requests to that branch. Merge commits would then be used to periodically synchronize with upstream. In this way, when the long-term branch is ready to "come home" to the main branch, the reviewers may have a good idea that the (potentially quite numerous) changes in the work branch have been reviewed already. [1] https://www.kernel.org/doc/Documentation/SubmittingPatches [2] https://developer.jboss.org/wiki/HackingOnWildFly -- - DML

11 years

2
3
0 / 0

The CI Inquisition!

by Jason Greene

Hello Everyone! Over the last few years we have attempted to get a grip on the intermittent test failures we see in CI almost every run, and have attempted various policies which were poorly enforced. This was mainly due to an understanding of tight deadline, but also a concern that strict enforcement would damage our test coverage. I would find myself holding out in hope that over time we would see these issues decrease. Unfortunately that hope was misplaced, and the simple truth is that coverage is already harmed, because no one pays attention to the intermittent fails, since they are treated as noise and not a true defect. I think we have no other option but to @Ignore any and every intermittent test, no matter the number or area they appear in. So unless someone can propose another workable strategy, intermittent tests should be disabled immediately by anyone that is impacted by them (reviewers, contributors, whoever). To do this, a simple short independent PR should be sent in, and a note should be left in a comment to the component lead of the area tested (using github’s super cool @user syntax). The component lead can then act on the message and choose whether to open and assign a JIRA to have it fixed, to ignore it, to delete it, to rewrite, etc. The intention is that the process of disabling an intermittent test should be as minimal effort as possible. In order for a known intermittent test to be reenabled, it needs to be shown that it is no longer intermittent by completing many full testsuite runs successfully. Anyone that needs it can request a custom CI job run for this purpose. Finally, if you are a saint and decide to fix an intermittent failing test, but have trouble reproducing it, feel free to raise the topic in the WildFly HipChat and we can come up with a solution like custom debug test jobs that can get you the info you need. Thoughts? -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat

11 years

4
3
0 / 0

WildFly 10.0.0.Alpha5 is now on OpenShift

by Farah Juma

As usual, see https://github.com/openshift-cartridges/openshift-wildfly-cartridge/tree/... to get started.

11 years

1
0
0 / 0

Early Access builds for JDK 8u60 b24 and JDK 9 b72 are available on java.net

by Rory O'Donnell

Hi Jason/Tomaz, Early Access build for JDK 8u60 b24 <http://jdk8.java.net/download.html> is available on java.net, summary of changes are listed here. <http://www.java.net/download/jdk8u60/changes/jdk8u60-b24.html> As we enter the later phases of development for JDK 8u60, please log any show stoppers as soon as possible. Early Access build for JDK 9 b72 <https://jdk9.java.net/download/> is available on java.net, summary of changes are listed here <http://www.java.net/download/jdk9/changes/jdk9-b72.html>. Note: b72 includes 8081708 <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8081607> - Change default GC for server configurations to G1 As described in JEP 248 <http://openjdk.java.net/jeps/248>, switching to a low-pause collector in JDK 9 such as G1 should provide a better overall experience, for most users, than a throughput-oriented collector such as the Parallel GC, which is currently the default. A call for feedback and data points <http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-June/019221.html> regarding this change went out on the hotspot-dev <http://mail.openjdk.java.net/mailman/listinfo/hotspot-dev> mailing list, where such input should be provided. Rgds,Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

11 years

1
0
0 / 0

Using feature packs for custom distributions

by Marko Strukelj

For Keycloak we’ve been trying to create a trimmed down distribution of Keycloak server, basing it on servlet-feature-pack rather than full-feature-pack, since we don’t need many of the subsystems. We’ve encountered some issues though that made us step back and stick to using full-feature-pack as a basis for Keycloak server distribution. If we find a way to address these issues in the future we’ll reconsider, but for now we don’t see much sense in basing our Keycloak distribution on servlet-feature-pack. There are two big isues for us: 1) Big module dependency trees Our goal was to reduce the distribution size by reducing the number of subsystems, and modules shipped. We guessed that since we don’t use EJB, JMS, WS - but basically just JAX-RS and datasources, the resulting distribution based on servlet-feature-pack wouldn’t get a lot bigger than OOTB servlet-feature-pack. But it turns out that enabling virtually any additional subsystem - in our case we want to use datasources, which are provided by org.jboss.as.connector - that pulls in around 90Mb of non-optional dependencies. That’s a lot just to get datasources support. What’s interesting is that adding a different subsystem support e.g. org.jboss.as.jaxrs pulls in the same dependency tree - i.e. adding JAXRS support pulls in the same dependency tree as adding Datasources support - that’s how intertwined the dependencies currently are. Using servlet-feature-pack for distributions that require some additional subsystems from full-feature-set is thus not very effective to significantly reduce custom distribution’s disk footprint. There is a tool I wrote as part of my analysis that I used to analyze the size of dependency trees: https://github.com/mstruk/keycloak-moduletool 2) Staying in-sync with changes in full-feature-pack Creating a custom feature pack that is a subset of full-feature-pack requires copying module.xml files from wildfly/feature-pack source tree into custom feature pack source tree. Adding org.jboss.as.connector means copying over hundreds of modules (186 to be precise). As Wildfly development moves on, any changes to module.xml files have to be synced into the custom feature pack. That has the potential to be a huge maintenance burden, and a source of errors. One way to address this would be extended syntax somewhere in feature pack definition project to say something like: <module id=”org.jboss.as.connector” from=”full-feature-pack” include-dependencies=”true” skip-optional=”true”/> And that would replace copying over module directories, and module.xml files. And guarantee that things remain in-sync. For our use-case this would also be addressed by wildfly providing a feature-pack definition that’s somewhere between servlet-feature-pack and full-feature-pack - as long as it contains datasources support, and jaxrs support ... Another thing is provisioning of feature packs, which I address in another email. - marko

11 years

6
8
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

wildfly-dev July 2015