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.
4 years, 8 months
Wildfly and moving from JDK8 to JDK11
by Andrew Marlow
Hello everyone,
I am moving from JDK8 to JDK11 and am running into some wildfly issues. I
am using the ancient version 9.0.1. Please don't laugh.
Am I being unreasonable to hope that it might work with JDK11. If so then I
think the best thing to do might be to move to the latest (20.0.1). I am
reluctant to do this because I have moved versions before (not often) and I
find the configuration changes to be, ahem, challenging.
I have already removed some stuff that I wasn't using anyway and that is no
longer present in JDK11, i.e. IIOP related stuff since CORBA is no more. It
only helped in that it removed clutter from the log and enabled me to see
more clearly the error I am getting now.
The error I am getting is: failed to start service
jboxx.txn.ArjunaObjectStoreEnvironment. It seems to be failing to find a
class by reflection. I am getting:
ClassNotFoundException: jdk.internal.reflect.ConstructorAccessorImpl from
[Module "org.jboss.jts:main" from local module loader
I can't help wondering if this might be to do with certain modules/classes
becoming inaccessible with the move to modules that was made in JDK9. This
is just a suspicion, I could easily be wrong and without further
information that theory doesn't really get me anywhere.
Can anybody help me out please?
--
Regards,
Andrew Marlow
http://www.andrewpetermarlow.co.uk
5 years, 1 month
Mailing List issues
by Brian Stansberry
We had some problems with delivery to this list last week and into this
week, but they seem to be resolved now. If you posted something and it
didn't get delivered, please do post again!
Best regards,
Brian
5 years, 1 month
Re: A catalog.xml file for our config schemas
by Brian Stansberry
There were problems recently with the mail list and this didn't go through,
so resending now...
On Thu, Aug 20, 2020 at 9:49 PM Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
> Does anyone have any ideas on how we could generate a catalog.xml file[1]
> that we could ship in docs/schema along with all our xsds? This would
> provide a mapping between our xml namespace URNs and the associated xsd
> file in that same dir.
>
> For simplicity's sake this could be limited to the server / subsystem
> configuration schemas.
>
> I think this would need to be handled by the WildFly galleon plugin. Such
> a catalog would need to combine data from the various maven modules that
> provide schemas. It's the WF galleon plugin feature pack generation or
> provisioning functions that pull together data from all the various
> modules.
>
> A not particular elegant possibility is to stick property files in the
> various 'schema' dirs in the source, e.g.
> https://github.com/wildfly/wildfly/tree/master/jaxrs/src/main/resources/s....
> The properties map the urns to the xsd file names. Something in the galleon
> plugin knows to look for those and aggregates the contents and generates
> the catalog.
>
> This question was sparked by a question from Fred Bricon on twitter:
> https://twitter.com/fbricon/status/1293911221771485185
>
> [1] https://www.oasis-open.org/committees/entity/spec-2001-08-06.html
>
> Best regards,
> Brian
>
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
5 years, 1 month
Refactoring the WildFly OpenSSL project
by Farah Juma
As it stands today, the WildFly OpenSSL project contains both Java code and
native code. This means that each time we need to do a release, we need to
build the natives, regardless of whether or not there have actually been
changes made to the native code. The process of building the natives on
various platforms takes time and has caused delays in the past that could
have been avoided if we were able to handle changes to the Java code only
as a separate release. We have actually found that there have been many
times where a release has involved changes to only the Java code. To
simplify the release process, we're going to be splitting out the native
code from the WildFly OpenSSL project into a separate project. That
way, changes to the Java code only will be able to be handled as a separate
release, without needing to rebuild the natives. The proposed changes can
be found in our incubator:
https://github.com/wildfly-security-incubator/wildfly-openssl-natives
https://github.com/wildfly-security-incubator/wildfly-openssl/tree/2.x
The native modules that have been split out are going to retain the same
group and artifact ID as they had when contained in the wildfly-openssl
project.
Regards,
Farah
5 years, 1 month
error wflyjca0042 failed to match pool Check JndiName: java:jboss/de xsDS
by nagraj
wildfly 19 - error wflyjca0042 failed to match pool Check JndiName:
java:jboss/de xsDS
i getting above error while connecting jdbc
please help i am trying to upgrade wildfly version 10 to 9.1.0
I have added below in standalone and also kept ojdbc7.jar file in module
folder
<driver name="h2" module="com.h2database.h2">
<xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
</driver>
<driver name="mysql" module="com.mysql">
<driver-class>com.mysql.jdbc.Driver</driver-class>
<xa-datasource-class>com.mysql.jdbc.MysqlXADataSource</xa-datasource-class>
</driver>
--
Sent from: http://wildfly-development.1055759.n5.nabble.com/
5 years, 2 months
Activemq with wildfly 18
by Naresh V
Hi team
I have gone though documentation for wildfly 18 jms and understodo that standalone-full.xml ahve configuration for activemq.
I downloaded activemq and configured queue.
I have written servlet to send message,after running servlet, message is not visible in activemq.
can anyone suggest me link or method to integrate activemq with wildfly18
5 years, 2 months
