Policies for merging PRs on master
by Alessio Soldano
As suggested by Brian, I'd like to draw attention to the discussion on
https://github.com/wildfly/wildfly/pull/10604 .
The PR is an upgrade of the webservices stack, including JBossWS, Apache
CXF, JAXB-RI and JAXB API. In particular, the JAXB upgrade is for EE8 and
better JDK 9 compatibility.
Now, due to the upgrade of the JAXB API spec jar, the PR is essentially
stalled since 20 days; the new spec is released as an alpha (as it's been
tested within JBossWS only) and that does not satisfy a rule that requires
any artifact being pulled to be Final.
We're talking about a spec jar, we could simply re-tag that as Final,
chances are we won't need changes any time soon there anyway, but as Tomaz
pointed out, in principle that would be dishonest.
While I see the point in requiring that only sufficiently stable upgrades
are applied to the codebase, I'm wondering whether, maybe, we're going a
bit too far with the rules. Brian wrote on this topic: "how to determine
that something is good enough to go in without using master as a test bed" ?
Opinions?
Cheers
Alessio
6 years, 9 months
Jirban board for WFLY feature requests/Jira cleanup
by Kabir Khan
I have set up a Jirban board for WFLY, which can be found at [1] (log into issues.jboss.org first). It effectively uses the following JQL:
project = WFLY and status != Closed and issuetype = "Feature Request" and (level is EMPTY and "Security Sensitive Issue" is EMPTY)
As you can see, it currently displays only feature requests.
However, if I organise this into swimlanes by fix version [2] it seems that there a lot of issues in the Resolved state for old releases.
I think these resolved issues should be closed. Firstly, I believe this is 'The Jira Way'. Secondly, it keeps the Jirban cache of issues on the server as small as possible, as the issues in the states configured to be 'done' in the Jirban config (i.e. Closed) are not cached. Also, the list of Fix Versions in the Jirban filters is populated from the issue data, so a nice side effect will be to keep that list more manageable. At the moment there are too many versions in there to make much sense out of it.
[3] contains a query for all issues in released versions. Here ' 10.x.x TBD' is a bit strange, but I assume these must have been released as part of something by now?
Then we have a few with Fix Version 'Awaiting Volunteers': [4]
There is a very mysterious Fix Version 'No Release': [5]
Then we have many resolved issues with no fix version but which have been done [6]
Finally we have a load of unresolved issues with no fix version which are rejected, duplicates, out of date etc. [7]
If my queries seem ok, I'd like to bulk close all of these. The ones from [4], [5] and [6] need a bit of care, but hopefully the date they were resolved can help figure out which release they went into. Or perhaps since they have been resolved with a strange fix version for so long, it doesn't matter if they are closed against that version either?
Thanks,
Kabir
[1] https://issues.jboss.org/jirban/index.html#/board?board=WFLY
[2] https://issues.jboss.org/jirban/index.html#/board?board=WFLY-fr&bl=true&s...
[3] https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20and%20status%...
[4] https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20and%20status%...
[5] https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20and%20status%...
[6] https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20AND%20status%...
[7] https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20AND%20status%...
6 years, 9 months
WildFly 11 and JDK9
by Tomaž Cerar
Hey guys,
during development of WF11 we have done lots of work on making it build &
run on JDK9.
as release nears I would like to summarize what the current state is and
how to move on.
Currently most of our core [1] & full [2] testsuite passes on latest builds
of JDK9.
Remaining failures are already addressed by [3] and [4]
**But** passing testsuite on JDK9 is not the same as using our binary
distribution under JDK9.
Currently as part of running build / testsuite we override version of
javassit to 3.22.0-CR2
which is currently the only version that works properly on JDK9.
As there is no .GA version of javassit that work on JDK9 avalible we
currently do not have it as default.
On top of that, hibernate as main user of javassit is not tested enough
with this version of javassist
unless hibernate / JPA team says otherwise.
That would in practice mean that users running WF11 on JDK9 would have
issues with JPA/Hibernate
based applications.
Currently I see two options how to address this:
- upgrade javassist to 3.22.x in server, preferably ask for .GA release.
- produce additional WildFly.x.x.x-jdk9 zip that would include the newer
javassist.
So question is do we even want to have working JDK9 build of WildFly 11
.Final
or should we postpone this for next update release.
--
tomaz
[1]
https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_MasterLinuxJdk9
[2] https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxJdk9ea
[3] https://github.com/wildfly/wildfly-core/pull/2738
[4] https://github.com/wildfly/wildfly-core/pull/2751
6 years, 9 months
Java 9, JBoss Modules, JAXP Redirection
by David Lloyd
JBoss Modules has a redirection mechanism for JAXP that allows us to
override the default provider with one from a module, while still
allowing TCCL-based selection to occur. Since Java 9, our
implementation violates the stricter reflection rules that are now in
place, meaning that JBoss Modules will probably stop working in a
future version. We had hoped that Java 9 would have some useful way
to establish the default implementation of various JAXP factories, but
that never happened. So I want to take the opportunity to review a
few mitigation options and get some feedback.
Option 1: Fix the redirection facility in Java 9
Java 9 offers a "newDefaultFactory()" method on most (maybe all) of
the JAXP factory classes, which always simply instantiates the system
provider of the given function. Using this method should allow us to
bypass the now-disallowed reflection by switching all of the cached
Constructor<? extends T> fields with cached Supplier<T> fields, whose
implementation would either be a call to the appropriate
newDefaultFactory() or a service loader-style public Constructor call.
Pros:
• Less change
• We can still override the default JAXP implementation
Cons:
• Continue carrying around the baggage of the __redirected code
until/unless the JAXP spec is modified to allow setting the default
factories
Option 2: Stop using redirection in Java 9, "cold turkey"
We could delete these classes completely. Instead of setting the
default JAXP implementation, we ensure that any modules using JAXP
have a services dependency on the implementation(s) corresponding to
those APIs, carefully monitoring TCCL setup and usage or ensuring that
the newFactory(xxx, getClass().getClassLoader()) form is always used,
depending on the situation.
Pros:
• No more dealing with redirection ever again
• While deployments generally use the newFactory() form, but
deployments also have TCCL set so that's not a problem
• One less source of bugs
Cons:
• It may be hard to be sure that we've done this 100% correctly in all
cases outside of deployments; the results could be weird mixed
implementations
Option 3: Use a dependency strategy
We could cause JBoss Modules to always include a "hidden" last
dependency on our chosen default JAXP implementation, which in turn
could be set up by a service loader configuration in the boot module.
Pros:
• Simpler than redirection
Cons:
• Due to the way JAXP works, we have to pollute the target module's
namespace with the implementation classes (though with redirection
we've already done that via __redirected classes)
So far Option 1 is (unfortunately) still looking the best to me,
overall. Does anyone have any differing opinions on this?
--
- DML
6 years, 9 months
Re: [wildfly-dev] Policies for merging PRs on master
by Brian Stansberry
Sorry, I dropped the list on my last post; see below...
On Tue, Dec 5, 2017 at 7:42 AM, Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
> On Mon, Dec 4, 2017 at 8:33 PM, Stuart Douglas <stuart.w.douglas(a)gmail.com
> > wrote:
>
>>
>>
>> On Tue, Dec 5, 2017 at 3:40 AM, Brian Stansberry <
>> brian.stansberry(a)redhat.com> wrote:
>>
>>> Great. :)
>>>
>>> One thing I think we need to do is figure out how to get custom TCK runs
>>> for PR branches. The TCK is a big part of our test coverage, and one way to
>>> not "use master as a test bed" is to get a check of a branch on the TCK
>>> before we merge it.
>>>
>>> I know we've gotten TCK runs of ad-hoc branches before, so by "figure
>>> out" I mean work out how to make that not overly painful, come to some sort
>>> of consensus on when it's worthwhile, etc.
>>>
>>
>> I think if we were going to do this it should probably be something
>> reviewers can ask for on specific PR. The TCK uses a *lot* more resources
>> than a standard CI run, so we need to make sure we limit it to cases where
>> it is required.
>>
>
> Yes, for sure we wouldn't want to do this broadly; submitters or reviewers
> should ask.
>
> I had in mind a fairly limited set of scenarios. Things like major/minor
> version bumps of the big EE components, or some large scale change with
> fairly clear TCK implications where we'd be reluctant to undo the change if
> it caused a problem. *Perhaps* core upgrades, as those somewhat amount to
> the latter. And then late in the cycle some last minute fixes where we
> sometimes ask for a custom run anyway.
>
> Doing custom runs doesn't buy much for small changes where if they fail
> TCK after merge we just revert them or we can spend a few days sorting the
> problem without stressing out.
>
>
>> Stuart
>>
>>
>>
>>>
>>> On Fri, Dec 1, 2017 at 10:04 AM, Alessio Soldano <asoldano(a)redhat.com>
>>> wrote:
>>>
>>>> There you go... PR updated to consume the same api jar now released as
>>>> final.
>>>>
>>>> Cheers
>>>> Alessio
>>>>
>>>> On Fri, Dec 1, 2017 at 3:30 PM, David Lloyd <david.lloyd(a)redhat.com>
>>>> wrote:
>>>>
>>>>> On Thu, Nov 30, 2017 at 5:50 PM, Alessio Soldano <asoldano(a)redhat.com>
>>>>> wrote:
>>>>> > As suggested by Brian, I'd like to draw attention to the discussion
>>>>> on
>>>>> > https://github.com/wildfly/wildfly/pull/10604 .
>>>>> > The PR is an upgrade of the webservices stack, including JBossWS,
>>>>> Apache
>>>>> > CXF, JAXB-RI and JAXB API. In particular, the JAXB upgrade is for
>>>>> EE8 and
>>>>> > better JDK 9 compatibility.
>>>>> > Now, due to the upgrade of the JAXB API spec jar, the PR is
>>>>> essentially
>>>>> > stalled since 20 days; the new spec is released as an alpha (as it's
>>>>> been
>>>>> > tested within JBossWS only) and that does not satisfy a rule that
>>>>> requires
>>>>> > any artifact being pulled to be Final.
>>>>> > We're talking about a spec jar, we could simply re-tag that as Final,
>>>>> > chances are we won't need changes any time soon there anyway, but as
>>>>> Tomaz
>>>>> > pointed out, in principle that would be dishonest.
>>>>>
>>>>> My opinion is that you should go ahead and make a .Final tag. In the
>>>>> (unlikely?) event that the spec has to be modified for some reason, I
>>>>> think you could make a 1.0.1.Final tag and call it a "bug fix".
>>>>>
>>>>> The alternative is to simply wait. I don't think there is any middle
>>>>> position.
>>>>>
>>>>> > While I see the point in requiring that only sufficiently stable
>>>>> upgrades
>>>>> > are applied to the codebase, I'm wondering whether, maybe, we're
>>>>> going a bit
>>>>> > too far with the rules. Brian wrote on this topic: "how to determine
>>>>> that
>>>>> > something is good enough to go in without using master as a test
>>>>> bed" ?
>>>>>
>>>>> I don't think we are; I agree with the policy as it stands. If you
>>>>> look at it in terms of being able to release at any time, then it
>>>>> follows that everything _must_ be stable.
>>>>>
>>>>> --
>>>>> - DML
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>
>>>
>>>
>>> --
>>> Brian Stansberry
>>> Manager, Senior Principal Software Engineer
>>> Red Hat
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
>
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
6 years, 9 months
Moving JBoss Modules towards Java 9 integration
by David Lloyd
Hi everyone, I want to outline a brief plan for the next couple steps
towards a better alignment between JBoss Modules and Java 9.
In Java 9, the platform classes are divided up into modules; the core set being:
java.base java.compiler java.datatransfer
java.desktop java.instrument java.jnlp
java.logging java.management java.management.rmi
java.naming java.prefs java.rmi
java.scripting java.security.jgss java.security.sasl
java.smartcardio java.sql java.sql.rowset
java.xml java.xml.crypto
In addition, the java.se module re-exports many of these.
As a first step towards alignment, it seems to me that we need to
introduce the ability for modules to create module dependencies on
these module names. However, unless we want to require Java 9 from
now on, the names must also work on Java 8.
So, I plan to follow this approximate plan:
• Introduce a new PlatformModuleLoader in to JBoss Modules JDK-specific code
◦ On Java 9+, this loader will create modules from the
corresponding JPMS platform module set
◦ On Java 8, this loader will create "system" modules from the
path sets which comprise the contents of these modules, possibly
including some "jdk.*" modules which are equivalent between Java 8 and
Java 9
• Update the LocalModuleLoader to pre-delegate module searches to
PlatformModuleLoader
• Remove "java" from the "system packages list"
• Bring these changes in to WildFly Core
• Deprecate the "javax.api", "sun.jdk", etc. modules, and also APIs
which use a different-than-standard name like "javax.sql.api", replace
their system dependency content with regular re-export dependencies on
platform modules
• Deprecate and replace other modules whose names are standardized but
different than ours, such as "java.corba", "java.transaction",
"java.xml.bind", etc., with delegations to modules with the standard
name
• Remove the "system" dependency type from the "urn:jboss:module:1.7" schema
One of the remaining unknowns is that there is only one Java 9
platform family in the wild right now, and it's OpenJDK-based. Other
vendors might introduce a different set of "jdk.*" modules, for
example, which might mean that the Java 8 emulation code for that
platform family may have to be updated. I consider this risk to be
mitigable.
It may also be necessary to have a compatibility mode or flag to
automatically add "java.se" as a module dependency, or perhaps to
re-add the "java" package prefix to the system package set, depending
on how compatibility shapes up in the end.
I hope to achieve this work in JBoss Modules 1.7; this would probably
be the last significant change before I start moving towards .Final.
So, if you have any feedback on this idea, please let me know here
ASAP. Thanks!
--
- DML
6 years, 9 months