Plugging in Credential Store backed ExpressionResolver
by Darran Lofthouse
Presently working on WFCORE-4360 adding support for expression resolution
backed by a credential store - the main barrier is going to be the solution
to bridge expression resolution with a subsystem provided component.
I am wondering if the following is going to be viable to support a
configurable expression resolver from a subsystem.
I see the RuntimeExpressionResolver is created very early in the boot
process, however at the time it is created the CapabilityRegistry is also
available. This is making me think if the CapabilityRegistry can be passed
in to the RuntimeExpressionResolver.
I would then imagine the resource handling expression resolution would
register a non-dynamic capability which exposes an expression resolver
runtime API. This in turn may also need to cross reference a credential
store which would also need to be accessible using the runtime API of a
capability.
At the time of expression resolution the RuntimeExpressionResolver would
then check the CapabilityRegistry to see if an expression resolver has been
registered and attempt to use it falling back to vault then default
ModelNode resolution if it does not resolve the expression.
Using a runtime API I suspect I would likely need to trigger the
initialisation of these APIs at the start of Stage.RUNTIME - that looks
feasible by adding a stage to Stage.RUNTIME with addFirst test to true -
maybe to be safe these should also start on demand based on first access.
Regards,
Darran Lofthouse.
3 years, 9 months
WildFly CI builds on ARM64
by Martin Grigorov
Hello WildFly team,
I work for one of the bigger ARM64 hardware providers.
My client is willing to donate a build server that could be used as a
TeamCity agent to execute the WildFly test suites on ARM64 Linux.
The aim is to make sure that WildFly is running fine on ARM64 architecture
in the long run.
I've ran 'mvn install' on one of our systems and it is passing
successfully.
If a problem arises in the future on ARM64 then me and my colleagues would
be glad to help with any ARM related issues!
Is this something you would be interested to have ?
Kind regards,
Martin Grigorov
4 years, 8 months
Wildscribe Documentation
by James Perkins
Hello All,
I assume everyone is aware of what Wildscribe [1] is. I've had a thought
that instead of having this massive site that will keep growing with each
version of WildFly released that we start adding this model documentation
on the WildFly Documentation site [2]. The idea is to just add a link on
each releases index page with a link to the model descriptions.
This would be automated as well with the docs project within WildFly. It
means that as part of the release process when building the docs the
Wildscribe model pages would be generated automatically.
My proposal would be for WildFly 19+ we would no longer update the
Wildscribe website. As you can see on the site if you click on versions
it's getting quite long :). All new Wildsribe pages would be present on the
main documentation for that version. The Wildscribe site would have a note
about where the documentation would now be for newer releases.
Any thoughts or concerns about this? If not objections I'll file a JIRA and
do some work on this as it shouldn't take all that long.
[1]: https://wildscribe.github.io/
[2]: https://docs.wildfly.org
--
James R. Perkins
JBoss by Red Hat
4 years, 9 months
Merge com.sum.xml.bind module's dependencies into itself
by Lin Gao
Hi folks,
There are 2 Eclipse JAXB related projects[1] that produce 10 artifacts with
3 groupIds that are spread over 5 JBoss modules:
Project
groupId
artifactId
JBoss module
dependencies
eclipse-ee4j/jaxb-ri <https://github.com/eclipse-ee4j/jaxb-ri>
org.glassfish.jaxb
jaxb-runtime
com.sun.xml.bind
-
com.github.relaxng
-
com.sun.istack
-
com.sun.xml.txw2
-
com.sun.xsom
-
javax.api
-
javax.xml.bind.api
-
javax.xml.stream.api
jaxb-xjc
jaxb-jxc
codemodel
txw2
com.sun.xml.txw2
-
javax.api
xsom
com.sun.xsom
-
com.github.relaxng
-
javax.api
com.sun.xml.bind.external
rngom
com.sun.xml.bind
See above
relaxng-datatype
com.github.relaxng
N/A
eclipse-ee4j/jaxb-istack-commons
<https://github.com/eclipse-ee4j/jaxb-istack-commons>
com.sun.istack
istack-commons-runtime
com.sun.istack
-
javax.activation.api
-
javax.api
istack-commons-tools
All these JBoss modules are private and do not depend on other modules
except *com.sun.xml.bind*, we want to know if it is possible to simplify it
by living with only 1 JBoss module: com.sun.xml.bind[2].
So if any projects that are built based on WildFly depend on the following
4 JBoss modules, please comment if it is OK to do the merge(by updating
your dependencies to com.sun.xml.bind instead):
com.github.relaxng
com.sun.istack
com.sun.xml.txw2
com.sun.xsom
Thank you :)
[1] https://github.com/eclipse-ee4j/jaxb-ri
https://github.com/eclipse-ee4j/jaxb-istack-commons
[2] https://issues.redhat.com/browse/WFLY-12913
Best Regards
--
Lin Gao
Senior Software Engineer
JBoss Sustaining Engineering Team
4 years, 9 months
WildFly Elytron - Module Structure
by Darran Lofthouse
At some point in the future we are going to need to consider a migration to
Jakarta EE 9 so I just wanted to raise some ideas as to how we may choose
to structure the project.
As it stands today our 1.x releases are being used for WildFly and in each
release we are maintaining compatibility of the public API against the
previous releases. We have also started with our 2.0.x releases where some
compatibility has been broken to clean up inter package dependencies, we
were planning to tag this as .Final for Quarkus.
If we are going to switch to Jakarta EE 9 which means new packages for the
specifications that feels like we should handle that with a major version
bump. My first idea was we move master to 3.x and insert a new 2.0.x
release which maintains compatibility with 1.x other than the Jakarta
changes but considering other requirements on us that would lead us to: -
* Elytron 1.x - Jakarta EE 8
* Elytron 2.x - Jakarta EE 9
* Elytron 3.x - Jakarta EE 8
* Elytron 4.x - Jakarta EE 9
So instead to simplify our versioning I was going to consider we pull the
spec related modules out into their own projects: -
wildfly-elytron-ee and wildfly-elytron-mp
This would mean our Elytron release streams would become: -
* Elytron 1.x - Jakarta EE 8
* Elytron 2.x - No Jakarta modules, compatible with 1.x.
* Elytron 3.x - No Jakarta modules, some breaking changes.
The new modules would then align with Elytron 2.x and handle the move to
Jakarta EE 9 within their own version ranges.
Regards,
Darran Lofthouse.
4 years, 9 months
WildFly Community Space Replacement
by James Perkins
Hello All,
We are in a position where we need to change the community space for
WildFly, currently located at https://developer.jboss.org/en/wildfly/. On
2020-03-1 this community space will become read-only.
We've got 3 areas we need to move.
1. Forums/Q&A
2. Wiki/FAQ
3. Articles
1. Forums/Q&A
My preference here is we would use Stack Overflow, specifically the wildfly
tag <https://stackoverflow.com/questions/tagged/wildfly>. It seems the
forums is really more Q&A than anything.
If we want to keep the forum and Q&A separate we could use Stack Overflow
for the Q&A and Google Groups for the forum. Though I don't really see much
difference between the forum and Q&A.
2. Wiki/FAQ
For this we could use GitHub Wiki here. For details see
https://help.github.com/en/github/building-a-strong-community/about-wikis.
3. Articles
I don't know how often articles get created, but it doesn't look like
often. My suggestion would be that we just use wildfly.org for this. These
seem to be akin to blog posts.
Another option could be better as without knowing the structure of how
wildfly.org is a bit of ask for the community to write an article/blog post.
Any other options or suggestions on any of these points are welcome.
Not required but I would also like to open for discussion moving the
wildfly-dev mailing list to Google Groups. What are others opinions on
this? It seems to get fairly low traffic as of now.
--
James R. Perkins
JBoss by Red Hat
4 years, 9 months
Shift in WildFly 19 schedule, alignment with MicroProfile 3.3
by Brian Stansberry
In my announcement of the WildFly 19 Beta1 release I said that we'd likely
delay the Final release a bit to evaluate the possibility of supporting
MicroProfile 3.3, which is due out in February. Our investigations of that
are looking favorable, so I'd like to propose the following:
1) Delay the WildFly 19 Final release until shortly after the approximately
Feb 18 MicroProfile 3.3 release in order to bring it in.
2) We make next Fri Feb 7 the cutoff for having other changes for 19 merged
into master. For changes going into WildFly Core the cutoff would be next
Tue Feb 4.
3) On Feb 7 create a 19.x branch that we will use for the MicroProfile 3.3
work. WildFly 19 would be released from this branch.
4) This means from that point the master branch would be open for work on
WildFly 20.
5) Any very high priority bug fixes we identify before 19 Final we would
also port to 19.x. But the goal should be to have anything we know of now
in before we create the branch.
6) If we hit some issue that makes it look like getting 3.3 in would go
past Feb we can reset and release WF 19 with MicroProfile 3.2.
Best regards,
Brian
4 years, 9 months
Possible component upgrades report - Wildfly
by thofman＠redhat.com
Generated at 01:49:20 SGT 2020-01-26
Searched in following repositories:
* Central: https://repo1.maven.org/maven2/
* JBossPublic: https://repository.jboss.org/nexus/content/repositories/public/
Possible upgrades:
com.fasterxml.jackson.core:jackson-annotations:2.10.1 -> 2.10.2 (Central)
com.google.code.gson:gson:2.8.2 -> 2.8.6 (Central)
com.netflix.hystrix:hystrix-core:1.5.12 -> 1.5.18 (Central)
com.squareup.okhttp3:okhttp:3.9.0 -> 3.9.1 (Central)
com.sun.xml.fastinfoset:FastInfoset:1.2.13 -> 1.2.17 (Central)
io.jaegertracing:jaeger-client:0.34.1 -> 0.34.2 (Central)
io.netty:netty-all:4.1.42.Final -> 4.1.45.Final (Central)
io.opentracing.contrib:opentracing-interceptors:0.0.4 -> 0.0.5 (Central)
io.opentracing.contrib:opentracing-tracerresolver:0.1.5 -> 0.1.8 (Central)
io.reactivex:rxjava:1.2.0 -> 1.2.10 (Central)
io.reactivex.rxjava2:rxjava:2.2.5 -> 2.2.17 (Central)
io.smallrye:smallrye-metrics:2.3.2 -> 2.3.3 (Central)
io.smallrye:smallrye-opentracing:1.3.0 -> 1.3.3 (Central)
io.undertow.js:undertow-js:1.0.2.Final -> 1.0.3.Final (Central)
joda-time:joda-time:2.9.7 -> 2.9.9 (Central)
net.bytebuddy:byte-buddy:1.9.11 -> 1.9.16 (Central)
org.apache.activemq:activemq-artemis-native:1.0.0 -> 1.0.1 (Central)
org.apache.avro:avro:1.7.6 -> 1.7.7 (Central)
org.apache.cxf:cxf-core:3.3.4 -> 3.3.5 (Central)
org.apache.cxf.xjc-utils:cxf-xjc-runtime:3.3.0 -> 3.3.1 (Central)
org.apache.james:apache-mime4j:0.6 -> 0.6.1 (Central)
org.apache.myfaces.core:myfaces-api:2.3.1 -> 2.3.6 (Central)
org.apache.openjpa:openjpa-kernel:2.4.2 -> 2.4.3 (Central)
org.apache.qpid:proton-j:0.33.2 -> 0.33.3 (Central)
org.apache.ws.xmlschema:xmlschema-core:2.2.4 -> 2.2.5 (Central)
org.cryptacular:cryptacular:1.2.0 -> 1.2.3 (Central)
org.eclipse:yasson:1.0.5 -> 1.0.6 (Central)
org.eclipse.microprofile.opentracing:microprofile-opentracing-api:1.3.1 -> 1.3.2 (Central)
org.eclipse.microprofile.rest.client:microprofile-rest-client-api:1.3.2 -> 1.3.4 (Central)
org.eclipse.persistence:eclipselink:2.7.3 -> 2.7.5 (Central)
org.hdrhistogram:HdrHistogram:2.1.9 -> 2.1.12 (Central)
org.hibernate:hibernate-search-backend-jms:5.10.7.Final -> 5.10.8.Final (Central)
org.jasypt:jasypt:1.9.2 -> 1.9.3 (Central)
org.jboss.activemq.artemis.integration:artemis-wildfly-integration:1.0.2 -> 1.0.2-wildfly-1 (JBossPublic)
org.jboss.arquillian.container:arquillian-container-test-spi:1.4.0.Final -> 1.4.1.Final (Central)
org.jboss.narayana:jbosstxbridge:5.10.1.Final -> 5.10.3.Final (Central)
org.jboss.security:jbossxacml:2.0.8.Final -> 2.0.9.Final (JBossPublic)
org.jboss.spec.javax.faces:jboss-jsf-api_2.3_spec:3.0.0.SP01 -> 3.0.0.SP1 (Central)
org.jgroups.kubernetes:jgroups-kubernetes:1.0.13.Final -> 1.0.14.Final (Central)
org.opensaml:opensaml-core:3.3.0 -> 3.3.1 (Central)
org.reactivestreams:reactive-streams:1.0.2 -> 1.0.3 (Central)
org.wildfly.galleon-plugins:wildfly-config-gen:4.2.3.Final -> 4.2.4.Final (Central)
xalan:serializer:2.7.1.jbossorg-4 -> 2.7.2 (Central)
43 items
Report generated by Maven Dependency Updater
https://github.com/jboss-set/maven-dependency-updater
4 years, 10 months
