Mixing org.jboss.as and org.wildfly packages
by Stuart Douglas
Hi,
So this is a minor issue, but it annoys me so I thought I would see what
other people think about it. In the test suite I have noticed that some new
code is being added under the org.wildfly package, even though all the
existing code is still under org.jboss.as.
I don't think this is a good idea, as it means there is two potential
places to look for something, with no real reason why something is in a
particular package other than the date it was added.
I propose that we move all the org.wildfly code into org.jboss.as to keep
everything consistent (moving everything to org.wildfly would also be an
option, but it has implications for backporting and has the potential to
create a lot more work).
Does anyone have any objections to this? If not I will prepare some PR's.
Stuart
7 years, 7 months
JDK 9 Developer Preview is now available on java.net
by Rory O'Donnell
Hi Jason/Tomaz,
*JDK 9 Developer Preview is now available on java.net [1]
*
Developer Preview milestone: - A reasonably stable build suitable for
broad testing by the developer community is available.
JDK 9 Builds 163 and higher include all planned features.
*Attention annotation processing users and authors - * Request for
feedback on annotation processing API changes made in JDK 9.
As has been done previously during Java SE 7 and Java SE 8, the JSR 269
annotation processing API is undergoing a maintenance review (MR) as
part of Java SE 9. Details of the changes in JDK 9 Early Access build
163 & build 164 available here [2]
Please report experiences running processors under JDK 9 and feedback on
the API changes to the compiler-dev mailing list.
(If you haven’t already subscribed to that list then please do so first,
otherwise your message will be discarded as spam.)
Rgds, Rory
[1] https://jdk9.java.net/download/
[2]
http://mail.openjdk.java.net/pipermail/compiler-dev/2017-April/010896.html
--
Rgds,Rory O'Donnell
Quality Engineering Manager
7 years, 7 months
Elytron Test Profiles and PRs
by Darran Lofthouse
Hello,
I have some PRs in the queue regarding additional Elytron testing in
custom test runs so I just wanted to double check we are happy with the
current strategy so I can continue merging.
Firstly as was discussed previously we have the new module in the
testsuite that has Elytron specific tests added to it, this is executed
as part of normal builds so regressions covered by these tests are
fairly easy to pick up.
Secondly we have an option to run the WildFly build with -Delytron, by
doing this some tests are automatically ignored but the testing now
switches the configuration of the server for existing tests to configure
the server to fully use an Elytron based configuration instead of the
default legacy configuration.
The PR process has also been updated so now when you submit PRs against
WildFly you don't just get an allTests run, in parallel you also get a
-Delytron run potentially picking up regressions that would not be
detected by the allTests run.
It probably is worth pointing out that although this additional testing
is not picked up in an allTests run engineers are also likely used to
skipping both the security manager tests locally and the tests for the
operating system they don't use for development.
Regards,
Darran Lofthouse.
7 years, 7 months
[JBEAP-10083][MODULES-282] blocking EAP migration testing
by Richard Opalka
Hi David & Peter,
MODULES-241 fix appeared in EAP these days
and it introduced new regression - see [JBEAP-10083] comments.
We have three possibilities at the moment:
* Option 1) Revert [MODULES-241] commit completely
* Option 2) Partially revert [MODULES-241] and bring in the hacky
solution I proposed some time ago
(see proposal branch:
https://github.com/ropalka/jboss-modules/commits/MODULES-282)
* Option 3) Provide a proper fix (we don't have it ATM)
I would guess Peter was working on the solution to solve some customer
problem, right?
If we don't come with Option 3) solution on tomorrow then
I'd propose to go with Option 2) for now (I just verified locally it
solves the migration problem
identified by QA and it fixes - although in an ugly way - the original
issue).
Let me know what do you think?
Richard
PS: I'm going to reason about Option 3) now ...
7 years, 7 months
Version notifications at library init
by David M. Lloyd
This is relatively minor but I've been sitting on it for a pretty long
time so I wanted to see if anyone had a strong opinion about it.
In the past few years, we've internationalized many of our projects, and
in the process assigned unique, searchable codes to exceptions and
INFO-and-higher log messages. In the meantime, as part of our existing
logging standards, we always log a version string for each library as it
is activated (this lets us quickly identify which versions of which
libraries are active, in order to aid in troubleshooting, etc.).
At present it is not part of our logging standard to assign a searchable
code to the version message. It has been suggested that we begin doing
so. If we did, I would recommend that the code be '0' for such messages
as most if not all of our projects use '1' as the lowest message ID.
The advantage of doing so is that it allows a given library's version
message to be quickly found in a log file, even if the language of the
log file is not known to the searcher. The disadvantage is that it
brings in additional noise to the log which makes it harder to read.
Does anyone have any strong feelings one way or the other, or better
yet, some pros or cons to add?
--
- DML
7 years, 7 months
