Is there a single maven BOM artifact I can use to get/build the entire wildfly ee server?
by Eric B
I'm trying to debug some code, and I am often hitting classes in
Wildfly/Undertow/etc in my stack that I don't have the source code for.
I'd love to be able to add a dependency in my pom.xml so that Eclipse will
automatically d/l the sources from maven central for me and add them to my
debugger. I'm looking for an artifact that I'd be able to list something
like:
<dependency>
<artifactId>wildfly</artifactId>
<groupId>org.wildfly</groupId>
<version>10.1.0</version>
<scope>provided</scope>
<type>pom</type>
</dependency>
That would then download all the sources for me, and I'd be in business.
Is there something like this BOM available for wildfly?
Thanks,
Eric
6 years
HAL.next / replace console in WildFly 13
by Harald Pehl
The development of HAL.next [1] has reached a point where we can replace the
existing console with HAL.next. We'd like to make this transition for
WildFly 13.
HAL.next ships with everything which is available in the current console.
In addition there are plenty new and enhanced features. I'm currently
preparing a website which will include basic user documentation and a list
of new and enhanced features.
Although we believe the new console is stable enough, we could add an
additional endpoint in WildFly 13 for the old console. This would enable
users to switch back and forth between the new and old console.
What do you think?
.: Harald
[1] https://github.com/hal/hal.next
6 years
JIRA: Proposal to make default assignee "Unassigned" for all areas
by David Lloyd
This is something we've talked about before. I think we should move
forward on this for the WFLY and WFCORE projects.
Ideally we'd also have a "responsible person" field which would be
populated by the component lead by default. But I don't think this is
necessary as long as our component leads are triaging issues in their
areas (which they should be).
I think we should just do it. WDYT?
--
- DML
6 years, 1 month
Re: [wildfly-dev] problems with the Elytron permission-mapping config model
by Alexey Loubyansky
On Tue, Mar 27, 2018 at 12:34 PM, Darran Lofthouse <
darran.lofthouse(a)redhat.com> wrote:
> Ok so lets switch this another way.
>
> If the addition from other subsystems was to be eliminated is there still
> a provisioning issue?
>
The provisioning issue is related to the structure of the configuration
model (to be more precise the representation of the resource in the domain
management model since this is what is being manipulated). There are other
examples of subsystems requiring configuration of other features, e.g. some
subsystems may require specific socket-bindings. There is no problem with
that from the provisioning perspective because the model allows to check
whether the required socket-binding is already present in the config,
whether its parameters need any adjustments and if the socket-binding is
missing from the config it can be added.
Thanks,
Alexey
>
> On Fri, 23 Mar 2018 at 20:52 Brian Stansberry <brian.stansberry(a)redhat.com>
> wrote:
>
>> On Fri, Mar 23, 2018 at 12:56 PM, Darran Lofthouse <
>> darran.lofthouse(a)jboss.com> wrote:
>>
>>> On Fri, 23 Mar 2018 at 17:50 Alexey Loubyansky <
>>> alexey.loubyansky(a)redhat.com> wrote:
>>>
>>>> On Fri, Mar 23, 2018 at 6:20 PM, Farah Juma <fjuma(a)redhat.com> wrote:
>>>>
>>>>> A solution to part of the problem mentioned in WFCORE-3596 that was
>>>>> discussed is to introduce the concept of named permission sets. In
>>>>> particular, instead of having a permission-mapping reference permissions,
>>>>> it would instead reference named permission-sets. This would allow the
>>>>> provisioning tool to be able to add/remove permissions to/from a default
>>>>> permission-set based on the presence/absence of a specific subsystem when
>>>>> generating the default configuration. However, as Alexey pointed out, this
>>>>> doesn't solve the problem of knowing which permission-mapping a
>>>>> permission-set should be added to when attempting to preserve user
>>>>> configuration changes for patching, version updates, etc.
>>>>>
>>>>
>>>> Right. It does not change the permission-mappings, they remain to be a
>>>> list of items with no identity. Which is the fundamental problem.
>>>>
>>>
>>> But why is that a problem? I think that is the piece still missing.
>>>
>>> By moving the list of the permissions into a single named resource the
>>> tooling no longer has a need to be performing the manipulation within the
>>> simple permission mapper so that can be left to the administrator to look
>>> after independently.
>>>
>>
>> Is your question why is it a problem to give these things an identity? If
>> so, I have the same question, although I don't think Alexey's the one to
>> come up with the identity.
>>
>> Or is your question why is not having an identity a problem? If so, is it
>> correct to say that getting rid of this bit of wrongness is the problem:
>>
>> https://github.com/wildfly/wildfly-core/blob/master/
>> elytron/src/main/resources/subsystem-templates/elytron.xml#L125
>>
>> Basically right there elytron is speculatively providing configuration
>> rightly owned by other subsystems. To do this correctly, each of those
>> permissions should be part of the config established by other parts of the
>> system. The provisioning tool is expected to do it correctly. And doing
>> that requires some sort of identity for each item in the set. . Installing
>> a feature should involve adding independent, identifiable chunks of config,
>> not manipulating an attribute of some chunk of config owned by a different
>> feature. Manipulating an attribute is not feasible and isn't correct.
>>
>>
>>>
>>>>
>>>> Thanks,
>>>> Alexey
>>>>
>>>> Thanks,
>>>>> Farah
>>>>>
>>>>> On Fri, Mar 23, 2018 at 11:55 AM, Alexey Loubyansky <
>>>>> alexey.loubyansky(a)redhat.com> wrote:
>>>>>
>>>>>> While this is addressed mainly to the Elytron team, it seems like we
>>>>>> would appreciate opinions from other colleagues since we are basically
>>>>>> stuck discussing possible ways to resolve https://issues.jboss.org/
>>>>>> browse/WFCORE-3596
>>>>>>
>>>>>> The description in the jira is pretty brief assuming people know what
>>>>>> that is about, since it's been raised before multiple times. Here is what
>>>>>> it is about fundamentally.
>>>>>>
>>>>>> If a configuration model (of a subsystem or any other component)
>>>>>> includes a list of configurable units (let's assume XML elements for
>>>>>> simplicity) that don't have any identity (unique id/name/path/etc) this is
>>>>>> a big problem for supporting patching and version updates preserving user
>>>>>> configuration changes. Or simply customizing the default config model using
>>>>>> a tool. By a big problem I mean it's simply not going to work reliably.
>>>>>>
>>>>>> As a simple exercise that demonstrates the issue, imagine you have
>>>>>> two configs each of which includes a list of these configurable units that
>>>>>> have no identity. Now try to identify the difference between the two lists.
>>>>>> Or merge them with one overwriting the other. Basically components w/o an
>>>>>> identity can not be manipulated. You can only add them but not modify or
>>>>>> even remove (unless their index in the list is a constant value of course).
>>>>>>
>>>>>> I don't think I've seen any issue of this kind in our (WF/EAP)
>>>>>> configs except for the Elytron's permission-mapping's. (If somebody knows
>>>>>> such components please let me know).
>>>>>> If I misunderstand the Elytron config model or approaching this from
>>>>>> a wrong angle, please let me know.
>>>>>>
>>>>>> Question for the Elytron team: is the problem I am describing clear?
>>>>>> Do you admit it as a problem?
>>>>>>
>>>>>> Thanks,
>>>>>> Alexey
>>>>>>
>>>>>
>>>>>
>>> _______________________________________________
>>> 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
>>
>
6 years, 1 month
Hibernate Validator/Bean Validation status
by Guillaume Smet
Hi,
The Apache BVal folks are working on their Bean Validation 2.0
implementation and, by doing so, they opened a few TCK appeals against the
Bean Validation TCK - including for tests already present in the 1.1 TCK.
We fixed a few tests in the TCK and we had to also make changes to the
reference implementation as it was conforming to incorrect tests.
So, basically, we will have to release a new version of the TCK and a
conforming version of Hibernate Validator and upgrade them in WildFly at
some point. These versions will be respectively 2.0.3.Final and
6.0.10.Final.
This is still a work in progress and I'm not really sure of when the Apache
BVal folks will be done with the appeals.
Thus I will push an upgrade to 6.0.9.Final to WildFly today as we recently
discovered a 5.x -> 6.0.x regression and I think it's better to be sure the
fix is in WildFly 13.
If we get to finish the TCK work before the WF 13 freeze, I'll push the
updated version and we will also have to upgrade the TCK we use for testing
the EE8 conformance.
--
Guillaume
6 years, 1 month
problems with the Elytron permission-mapping config model
by Alexey Loubyansky
While this is addressed mainly to the Elytron team, it seems like we would
appreciate opinions from other colleagues since we are basically stuck
discussing possible ways to resolve
https://issues.jboss.org/browse/WFCORE-3596
The description in the jira is pretty brief assuming people know what that
is about, since it's been raised before multiple times. Here is what it is
about fundamentally.
If a configuration model (of a subsystem or any other component) includes a
list of configurable units (let's assume XML elements for simplicity) that
don't have any identity (unique id/name/path/etc) this is a big problem for
supporting patching and version updates preserving user configuration
changes. Or simply customizing the default config model using a tool. By a
big problem I mean it's simply not going to work reliably.
As a simple exercise that demonstrates the issue, imagine you have two
configs each of which includes a list of these configurable units that have
no identity. Now try to identify the difference between the two lists. Or
merge them with one overwriting the other. Basically components w/o an
identity can not be manipulated. You can only add them but not modify or
even remove (unless their index in the list is a constant value of course).
I don't think I've seen any issue of this kind in our (WF/EAP) configs
except for the Elytron's permission-mapping's. (If somebody knows such
components please let me know).
If I misunderstand the Elytron config model or approaching this from a
wrong angle, please let me know.
Question for the Elytron team: is the problem I am describing clear? Do you
admit it as a problem?
Thanks,
Alexey
6 years, 1 month
Elytron role mapping
by Zoltán Kukk
Hi all,
I'd like to create a role mapping to convert role received from a
realm to another role
eg. role name is SOME_ROLE and I'd like to convert it to SOMETHING_ELSE.
Is it possible with Elytron?
6 years, 1 month
Release Announcement: General Availability of JDK 10
by Rory O'Donnell
Hi Jason/Tomaz,
A number of items to share with you today :
*1) JDK 10 General Availability *
JDK 10, the first release produced under the six-month rapid-cadence
release model [1][2], is now Generally Available.
We've identified no P1 bugs since we promoted build 46 almost two weeks
ago, so that is the official GA release, ready for production use.
GPL'd binaries from Oracle are available here: http://jdk.java.net/10
This release includes twelve features:
* 286: Local-Variable Type Inference <http://openjdk.java.net/jeps/286>
* 296: Consolidate the JDK Forest into a Single Repository
<http://openjdk.java.net/jeps/296>
* 304: Garbage-Collector Interface <http://openjdk.java.net/jeps/304>
* 307: Parallel Full GC for G1 <http://openjdk.java.net/jeps/307>
* 310: Application Class-Data Sharing <http://openjdk.java.net/jeps/310>
* 312: Thread-Local Handshakes <http://openjdk.java.net/jeps/312>
* 313: Remove the Native-Header Generation Tool (javah)
<http://openjdk.java.net/jeps/313>
* 314: Additional Unicode Language-Tag Extensions
<http://openjdk.java.net/jeps/314>
* 316: Heap Allocation on Alternative Memory Devices
<http://openjdk.java.net/jeps/316>
* 317: Experimental Java-Based JIT Compiler
<http://openjdk.java.net/jeps/317>
* 319: Root Certificates <http://openjdk.java.net/jeps/319>
* 322: Time-Based Release Versioning <http://openjdk.java.net/jeps/322>
*2) JDK 11 EA build 5, under both the GPL and Oracle EA licenses, are
now available at **http://jdk.java.net/11**.*
* Schedule, status & features
o http://openjdk.java.net/projects/jdk/11/
* Release Notes:
o http://jdk.java.net/11/release-notes
* Summary of changes
o https://download.java.net/java/early_access/jdk11/5/jdk-11+5.html
*3) The Z Garbage Collector Project, early access builds available : *
The first EA binary from from The Z Garbage Collector Project, also
known as ZGC, is now available. ZGC is a scalable low latency garbage
collector. For information on how to enable and use ZGC, please see the
project wiki.
* Project page: http://openjdk.java.net/projects/zgc/
* Wiki: https://wiki.openjdk.java.net/display/zgc/Main
*4) Quality Outreach Report for **March 2018 **is available
*
* https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+Mar...
*5) **Java Client Roadmap Update
*
* We posted a blog [3] and related white paper [4] detailing our plans
for the Java Client.
Rgds,Rory
[1] https://mreinhold.org/blog/forward-faster
[2]
http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html
[3] Blog:
https://blogs.oracle.com/java-platform-group/the-future-of-javafx-and-oth...
[4] Whitepaper:
http://www.oracle.com/technetwork/java/javase/javaclientroadmapupdate2018...
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
6 years, 1 month
WildFly Java 9 support & CI job
by Jaikiran Pai
It appears that the recent release of WildFly 12.0.0.Final has a major
issue with Java 9 support for deployments. More specifically, if the
application being deployed is compiled using Java 9 JDK then the
annotation processing (through Jandex) causes such classes to skip the
annotation indexing, effectively missing any annotation information
present on them. There's a JIRA for it here[1] and I /think/ another
user here in the forum thread[2] is affected by the same issue. I see
that Stuart is already upgrading Jandex which includes a fix, so this
mail isn't really about fixing this issue.
Given the ease with which this got reproduced and the fact that we
missed it in our regular integration job for Java 9 [3], I looked around
to see why we couldn't catch this earlier. It looks like the WildFly
pom.xml uses org.jboss:jboss-parent:25 [4] which fixes the target class
version of the compilation to 1.8. As a result, even though the CI job
uses Java 9 to compile the application sources (in test cases) it ends
up with a class version to Java 8 and that explains why these issues
weren't caught earlier.
So would it be possible to have another variant of this CI job which
passes Java 9 as the target version for compiled sources, as a system
property value (the pom.xml of jboss-parent allows the value to be
configured through properties)?
[1] https://issues.jboss.org/browse/WFLY-9961
[2] https://developer.jboss.org/thread/277401
[3]
https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxJdk9&branc...
[4]
http://repo1.maven.org/maven2/org/jboss/jboss-parent/25/jboss-parent-25.pom
-Jaikiran
6 years, 1 month
