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.
2 years, 7 months
Add pull request CI coverage of Galleon layers, drop Windows JDK 8
by Brian Stansberry
I'd like to add jobs to the automatic testing of PRs to run the testsuite
using slimmed installations provisioned by Galleon. But, we already run a
lot of jobs for each PR, enough so that our CI can overburdened during busy
times around deadlines. So I don't want to just add jobs. Instead I also
propose to drop the Windows + JDK 8 jobs.
Galleon Testing
During our work on WildFly 18 I added the ability to run portions of the
WildFly and WildFly Core testsuites with the tests executing against
slimmed server installations provisioned by Galleon instead of against the
complete installations normally used. The point of that was to get test
coverage of those slimmed installations.
Currently we have nightly jobs that run the testsuite this way.[1] As we
continue to evolve our set of Galleon layers, e.g. adding layers for
MicroProfile specs, I want to be sure we catch problems before PRs get
merged.
To run tests locally this way you pass -Dts.layers as an arg to maven.
Dropping Windows JDK 8 Jobs
If we'd drop something in order to free up resources for these Galleon
jobs, the Windows JDK 8 ones seem a good choice. We'd still run PRs against
Windows JDK 11, and we'd still run PRs against Linux JDK 8. I can't recall
any situation where CI found a regression that was specific to the
Windows + JDK 8 combination.
When CI gets overloaded during rush times, it's the Windows jobs that are
most problematic. The Windows jobs take longer because the storage drives
they use are slower. Plus we have fewer Windows agents. The effect is
during a rush, overall CI for PRs ends up taking hours longer while we wait
for Windows agents to come free and then run the job.
We'd still run nightly jobs with Windows + JDK 8 so in the off chance
there's a problem it would get noticed that way.
Specifics
For PRs against wildfly/wildfly I'd add a job equivalent to
https://ci.wildfly.org/viewType.html?buildTypeId=WF_GalleonLinuxJdk11 and
then drop
https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_PullRequestW...
For PRs against wildfly/wildfly-core I'd add jobs equivalent to
https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_GalleonLinux...
and https://ci.wildfly.org/viewType.html?buildTypeId=WF_GalleonLinuxJdk8
and then drop
https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_PullRequestW...
Any thoughts on this?
Best regards,
Brian
[1] See
https://ci.wildfly.org/viewType.html?buildTypeId=WF_GalleonLinuxJdk11
https://ci.wildfly.org/viewType.html?buildTypeId=WF_GalleonLinuxJdk8
https://ci.wildfly.org/viewType.html?buildTypeId=WF_GalleonWindowsJdk11
https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_GalleonLinux...
https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_GalleonLinux...
3 years, 10 months
Possible component upgrades report - Wildfly
by thofman＠redhat.com
Generated at 01:48:19 SGT 2019-10-27
Searched in following repositories:
* Central: https://repo1.maven.org/maven2/
* JBossPublic: https://repository.jboss.org/nexus/content/repositories/public/
Possible upgrades:
com.google.code.gson:gson:2.8.2 -> 2.8.6 (Central)
com.squareup.okhttp3:okhttp:3.9.0 -> 3.9.1 (Central)
com.sun.istack:istack-commons-runtime:3.0.7 -> 3.0.10 (Central)
com.sun.xml.bind.external:relaxng-datatype:2.3.1 -> 2.3.3-b01 (Central)
com.sun.xml.fastinfoset:FastInfoset:1.2.13 -> 1.2.17 (Central)
commons-beanutils:commons-beanutils:1.9.3 -> 1.9.4 (Central)
io.netty:netty-all:4.1.34.Final -> 4.1.43.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.rxjava2:rxjava:2.2.2 -> 2.2.13 (Central)
io.smallrye:smallrye-config:1.3.6 -> 1.3.9 (Central)
io.smallrye:smallrye-opentracing:1.3.0 -> 1.3.2 (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.3 -> 3.3.4 (Central)
org.apache.james:apache-mime4j:0.6 -> 0.6.1 (Central)
org.apache.myfaces.core:myfaces-api:2.3.1 -> 2.3.5 (Central)
org.apache.openjpa:openjpa-kernel:2.4.2 -> 2.4.3 (Central)
org.cryptacular:cryptacular:1.2.0 -> 1.2.3 (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.glassfish:jakarta.el:3.0.2 -> 3.0.3 (Central)
org.hibernate.validator:hibernate-validator:6.0.17.Final -> 6.0.18.Final (Central)
org.jasypt:jasypt:1.9.2 -> 1.9.3 (Central)
org.jboss:jboss-ejb-client:4.0.23.Final -> 4.0.25.Final (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.security:jbossxacml:2.0.8.Final -> 2.0.9.Final (JBossPublic)
org.opensaml:opensaml-core:3.3.0 -> 3.3.1 (Central)
org.reactivestreams:reactive-streams:1.0.2 -> 1.0.3 (Central)
xalan:serializer:2.7.1.jbossorg-4 -> 2.7.2 (Central)
34 items
3 years, 10 months
trouble ticketing system
by elizagaf＠gmail.com
Buenos días, tengo que desarrollar una aplicación de trouble ticketing y
necesito un colaborador que conozca bien BPM.
Algún candidato o alguien que tenga ya algo avanzado???
Preferiblemente de habla hispana pero no imprescindible.
Gracias.
3 years, 11 months
Possible component upgrades report - Wildfly Core
by thofman＠redhat.com
Generated at 16:49:31 SGT 2019-10-27
Searched in following repositories:
* Central: https://repo1.maven.org/maven2/
* JBossPublic: https://repository.jboss.org/nexus/content/repositories/public/
Possible upgrades:
com.jcraft:jsch:0.1.54 -> 0.1.55 (Central)
com.jcraft:jzlib:1.1.1 -> 1.1.3 (Central)
org.apache.httpcomponents:httpclient:4.5.4 -> 4.5.10 (Central)
org.apache.httpcomponents:httpcore:4.4.5 -> 4.4.12 (Central)
org.eclipse.jgit:org.eclipse.jgit:5.0.2.201807311906-r -> 5.0.3.201809091024-r (Central)
org.jboss.slf4j:slf4j-jboss-logmanager:1.0.3.GA -> 1.0.4.GA (Central)
org.slf4j:jcl-over-slf4j:1.7.22.jbossorg-1 -> 1.7.28 (Central)
org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.2.12.Final -> 1.2.13.Final (Central)
8 items
3 years, 11 months
Updating the WildFly archetypes
by Wolfgang Knauf
Hi,
the archetypes at https://github.com/wildfly/wildfly-archetypes
(e.g. "wildfly-javaee7-webapp-ear-blank-archetype") are for WildFly 8,
and when updating the WildFly version in pom.xmls, a lot of further
changes is required, see https://issues.jboss.org/browse/WFLY-9703
(which is only part of the changes).
I am interested in creating new archetypes for WildFly 15. What do you
think?
My plan is to name them e.g.
"wildfly15-javaee8-webapp-ear-blank-archetype" and to create a new
archetype version each time a new WildFly major version is released.
If you are OK with this, I will struggle with my first steps in Git, and
I probably will ask some more or less dumb questions about details ;-).
Best regards
Wolfgang
3 years, 11 months
