WildFly/JBoss Datasource definition for Derby fails - wildfly

I'm hoping this is just a stupid question, but after googling around and browsing the WildFly docs, I can't seem to link things up.
I have an EJB application which has been working since forever, but with JPA backed by the H2 database. The entity database has grown so large that the H2 implementation now has extreme performance problems and I need to migrate to a Derby backstore.
The problem is that the H2 DS is sort of "baked into" WF as ExampleDS, but Derby is not, and I can't seem to get Derby defined as a datasource. My first try was to define it with a module.xml, but I wasn't having much luck, so as I don't need domain, I opted to just drop derbyclient.jar into standalone/deployments, which seemed to work fine.
With the client JAR deployed, my attempt to define the DVDDerbyDS datasource gets this:
[jboss#ftgme2 ~/wildfly-23.0.0.Final/bin]$ ./jboss-cli.sh -c
[standalone#localhost:9990 /] /subsystem=datasources/data-source=DVDDerbyDS:add(
\
> jndi-name=java:jboss/datasources/DVDDerbyDS,\
> driver-name=derbyclient,\
> connection-url=jdbc:derby://localhost:1527/DVD\
> )
{
"outcome" => "failed",
"failure-description" => {
"WFLYCTL0412: Required services that are not installed:" => ["jboss.jdbc
-driver.derbyclient"],
"WFLYCTL0180: Services with missing/unavailable dependencies" => [
"org.wildfly.data-source.DVDDerbyDS is missing [jboss.jdbc-driver.de
rbyclient]",
"jboss.driver-demander.java:jboss/datasources/DVDDerbyDS is missing
[jboss.jdbc-driver.derbyclient]"
]
},
"rolled-back" => true
}
I'm guessing that this is a simple case of two operands that need to match not matching, probably the derbyclient info. But deploying derbyclient gives no hint of how to reference it, and every permutation I've tried has failed.
Any ideas ?
In the management console deployments, derbyclient.jar appears as deployed and enabled and is referred to only as derbyclient.jar. Modifying the CLI above still fails: –
[standalone#localhost:9990 /] /subsystem=datasources/data-source=DVDDerbyDS:add( jndi-name=java:jboss/datasources/DVDDerbyDS, driver-name=derbyclient.jar, connection-url=jdbc:derby://localhost:1527/DVD) –
{ "outcome" => "failed", "failure-description" => { "WFLYCTL0412: Required services that are not installed:" => ["jboss.jdbc -driver.derbyclient_jar"], "WFLYCTL0180: Services with missing/unavailable dependencies" => [ "org.wildfly.data-source.DVDDerbyDS is missing [jboss.jdbc-driver.de rbyclient_jar]", "jboss.driver-demander.java:jboss/datasources/DVDDerbyDS is missing [jboss.jdbc-driver.derbyclient_jar]" ] }, "rolled-back" => true } –
The same using derbyclient_jar. –
[standalone#localhost:9990 /] /subsystem=datasources:installed-drivers-list
{
"outcome" => "success",
"result" => [{
"driver-name" => "h2",
"deployment-name" => undefined,
"driver-module-name" => "com.h2database.h2",
"module-slot" => "main",
"driver-datasource-class-name" => "",
"driver-xa-datasource-class-name" => "org.h2.jdbcx.JdbcDataSource",
"datasource-class-info" => [{"org.h2.jdbcx.JdbcDataSource" => {
"URL" => "java.lang.String",
"description" => "java.lang.String",
"loginTimeout" => "int",
"password" => "java.lang.String",
"url" => "java.lang.String",
"user" => "java.lang.String"
}}],
"driver-class-name" => "org.h2.Driver",
"driver-major-version" => 1,
"driver-minor-version" => 4,
"jdbc-compliant" => true
}]
}
[standalone#localhost:9990 /]
but
[jboss#ftgme2 ~/wildfly-23.0.0.Final/standalone/deployments]$ cat derbyclient.jar.deployed
derbyclient.jar
[standalone#localhost:9990 /] /deployment=derbyclient.jar:browse-content(path=META-INF/services/)
{
"outcome" => "success",
"result" => [{
"path" => "java.sql.Driver",
"directory" => false,
"file-size" => 47L
}]
}

It looks like the derbyclient.jar does not contain everything you need. It worked for me with the following.
First you need to install the driver as a module:
# Set the path to Derby and add a module for the driver
set DERBY_HOME=/path/to/db-derby-10.15.2.0-bin
module add --name=org.apache.derby --resources=$DERBY_HOME/lib/derbyclient.jar,$DERBY_HOME/lib/derbytools.jar,$DERBY_HOME/lib/derbyshared.jar --dependencies=javax.api,javax.transaction.api --resource-delimiter=,
# Add the JDBC driver
/subsystem=datasources/jdbc-driver=derby:add(driver-module-name=org.apache.derby, driver-name=derby, driver-class-name=org.apache.derby.jdbc.ClientDriver)
Then you can add your data source:
/subsystem=datasources/data-source=DVDDerbyDS:add(jndi-name=java:jboss/datasources/DVDDerbyDS, driver-name=derby, connection-url=jdbc:derby://localhost:1527/DVD)

Related

Wildfly Management API : What is URL for list Servergroups?

How to fetch server group details using Wildfly Management API
https://wildfly.prod.idntegrator.cosng.net/management?operation=attribute&name=server-group
{
"outcome" : "failed",
"failure-description" : "WFLYCTL0201: Unknown attribute 'servergroup'",
"rolled-back" : true
}
I am not able to find much information here:
https://docs.jboss.org/author/display/WFLY10/The%20HTTP%20management%20API.html
I tried from Jboss CLI but it has no attribute like servergroup but has /server-group=generic type notation not sure how to put in rest call
As far as I know there is no way to read just the server groups from the HTTP Management API. The best you could do is something like:
http://localhost:9990/management/?operation=resource
This would include an array of the server groups.
"server-group": {
"main-server-group": null,
"other-server-group": null
}
From CLI however you can use the read-children-names operation.
/:read-children-names(child-type=server-group)
Example output:
[domain#localhost:9990 /] /:read-children-names(child-type=server-group)
{
"outcome" => "success",
"result" => [
"main-server-group",
"other-server-group"
]
}

jboss cli command to get datasource connection pool details in json format

using jboss cli to get connection pool details, gets output like this
{
"outcome" => "success",
"result" => {
"ActiveCount" => 1,
"AvailableCount" => 20L
}
}
is there a way to get the same in json format?
You could use the --output-json argument. Something like:
$JBOSS_HOME/bin/jboss-cli.sh -c --output-json "/subsystem=datasources/data-source=ExampleDS/statistics=pool:read-resource(include-runtime=true)"

Error in connection with PostgreSQL 12 by creating a datasource

I'm getting an exception while connecting to PostgreSQL 12 by creating a data source via wildfly admin console.
It works fine on my another machine which has PostgreSQL 9.5. and it seems to work fine when I connect without data-source.
try (Connection conn = DriverManager.getConnection(
"jdbc:postgresql://127.0.0.1:5432/registrar", "postgres", "postgres")) {
if (conn != null) {
System.out.println("Connected to the database!");
Statement statement = conn.createStatement();
ResultSet rs = statement.executeQuery("Select * FROM public.user LIMIT 10");
while(rs.next())
System.out.println(rs.getString(2));
} else {
System.out.println("Failed to make connection!");
}
But when I create a data-source like this:
and this the exception that I get when I try to test the connection from UI.
Request
{
"address" => [
("subsystem" => "datasources"),
("data-source" => "RegistrarDS")
],
"operation" => "test-connection-in-pool"
}
Response
Internal Server Error
{
"outcome" => "failed",
"failure-description" => "WFLYJCA0040: failed to invoke operation: WFLYJCA0047: Connection is not valid",
"rolled-back" => true,
"response-headers" => {"process-state" => "reload-required"}
}
Has anything changed in PostgreSQL 12? What could be the issue?
Could be an issue with the datasource-class defined in your driver as described here on issues.redhat.com
If a datasource-class is defined then it takes precedence to create the datasource and as such it can only use connection-properties.
Since there is not a single connection-url property for all drivers, you have to use connection-properties if you are defining the datasource-class.
Another thing you could try is to set "Connection Properties" instead of "Connection URL" and make sure you are using the correct/latest driver jar file.
Also check your Postgresql logs for further info on the exception..
-> https://www.postgresql.org/about/news/2000/

Configuring security to access EJB through WS -- WFLYEJB0364 Connection rejected

I have followed this tutorial to configure an user ejbuser with password 12345678 and role appCitas. The instructions that I followed are:
C:\wildfly-14.0.1.Final\bin>jboss-cli.bat
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /] connect
[standalone#localhost:9990 /] /subsystem=elytron/filesystem-realm=proxyRealm:add(path=proxy-realm-users,relative-to=jboss.server.config.dir)
{"outcome" => "success"}
[standalone#localhost:9990 /] /subsystem=elytron/filesystem-realm=proxyRealm:add-identity(identity=ejbuser)
{"outcome" => "success"}
[standalone#localhost:9990 /] /subsystem=elytron/filesystem-realm=proxyRealm:set-password(identity=ejbuser,clear={password=12345678})
{"outcome" => "success"}
[standalone#localhost:9990 /] /subsystem=elytron/filesystem-realm=proxyRealm:add-identity-attribute(identity=ejbuser,name=Roles,value=["guest", "appCitas"])
{"outcome" => "success"}
[standalone#localhost:9990 /] /subsystem=elytron/simple-role-decoder=from-roles-attribute:add(attribute=Roles)
{"outcome" => "success"}
[standalone#localhost:9990 /] /subsystem=elytron/security-domain=proxySD:add(default-realm=proxyRealm,permission-mapper=default-permission-mapper,realms=[{realm=proxyRealm,role-decoder=from-roles-attribute},{realm=local}])
{"outcome" => "success"}
[standalone#localhost:9990 /] /subsystem=elytron/sasl-authentication-factory=proxy-application-sasl-autentication:add(mechanism-configurations=[{mechanism-name=JBOSS-LOCAL-USER,realm-mapper=local},{mechanism-name=DIGEST-MD5,mechanism-realm-configurations=[{realm-name=proxyRealm}]},{mechanism-name=BASIC,mechanism-realm-configurations=[{realm-name=proxyRealm}]}],sasl-server-factory=configured,security-domain=proxySD)
{"outcome" => "success"}
[standalone#localhost:9990 /] /subsystem=ejb3/application-security-domain=other:add(security-domain=proxySD)
{"outcome" => "success"}
[standalone#localhost:9990 /] /subsystem=remoting/http-connector=http-remoting-connector:write-attribute(name=sasl-authentication-factory,value=proxy-application-sasl-autentication)
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
In mi EJB, I have
#WebService(
endpointInterface = "es.ssib.otic.test.prototipoEjbCitas.ApiCitasPublico",
name = "ApiCitasEjb")
#RolesAllowed("apiCitas")
#Stateless
public class ApiCitasPublicoImpl
implements ApiCitasPublico {
#Override
public #XmlElement(name = "pacienteCitaResponse", required = true) PacienteCitaResponse getPacienteCita(
#WebParam(name = "datosSolicitante") #XmlElement(required = true) IdPeticion idPaciente) {
...
}
And my jboss-app.xml is
<?xml version="1.0" encoding="UTF-8"?>
<jboss-app>
<security-domain>other</security-domain>
</jboss-app>
The ear deploys correctly and it does not show any log problem, yet I try to access a method from SoapUI and I add a Basic Authentication, with:
username: ejbuser
password: 12345678
Domain: I have tried with other, proxySD, proxyRealm and leaving it blank
Pre-emptive auth: I have combined all of the above values of "Domain" with both "Use-global-preference" and "Authenticate pre-emptively".
In all cases, I get a
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<soap:Fault>
<faultcode>soap:Server</faultcode>
<faultstring>WFLYEJB0364: Invocation on method: public es.ssib.otic.test.prototipoEjbCitas.beans.PacienteCitaResponse es.ssib.otic.test.prototipoEjbCitas.impl.ApiCitasPublicoImpl.getPacienteCita(es.ssib.otic.test.prototipoEjbCitas.beans.IdPeticion) of bean: ApiCitasPublicoImpl is not allowed</faultstring>
</soap:Fault>
</soap:Body>
</soap:Envelope>
If I remove the security configuration, I can access through SoapUI with no problems.
Working with WildFly 14.0.0.1 Final.
Note: This question is somewhat related to my previous one, but since I have reinstalled the wildfly and I have followed step by step the above mentioned tutorial, I think it is better to post it as a separate question.
Update
Following the lead of #fjuma's answer, I have configured the following:
[standalone#localhost:9990 /] /subsystem=elytron/http-authentication-factory=proxy-application-http-authentication:add(http-server-mechanism-factory=global,security-domain=proxySD,mechanism-configurations=[{mechanism-name=BASIC,mechanims-realm-configuration=[{realm-name=proxyAD}]}])
{"outcome" => "success"}
[standalone#localhost:9990 /] /subsystem=undertow/application-security-domain=proxyAD:add(http-authentication-factory=proxy-application-http-authentication)
{"outcome" => "success"}
And changed the value of security-domain in jboss-app.xml to proxyAD, I get an error deploying the ear:
{
"WFLYCTL0412: Required services that are not installed:" => ["jboss.security.security-domain.proxyAD"],
"WFLYCTL0180: Services with missing/unavailable dependencies" => [
"jboss.deployment.subunit.\"prototipoEarCitas-0.0.1-SNAPSHOT.ear\".\"prototipoEjbCitas-0.0.1-SNAPSHOT.jar\".component.ApiCitasPublicoImpl.CREATE is missing [jboss.security.security-domain.proxyAD]",
"jboss.ws.endpoint.\"prototipoEarCitas-0.0.1-SNAPSHOT.ear\".\"prototipoEjbCitas-0.0.1-SNAPSHOT.jar\".ApiCitasPublicoImpl is missing [jboss.security.security-domain.proxyAD]"
]
}
A couple things to note:
To make use of HTTP Basic authentication, an Elytron http-authentication-factory is needed. Documentation on how to configure this can be found here.
When using HTTP Basic authentication, an application-security-domain mapping also needs to be added in the Undertow subsystem. See https://developer.jboss.org/thread/276445 for more details related to this when using webservices.
###Update by the OP:
This is the final minimal set of commands to configure EJBs access through WS (tested on a clean, brand new Wildfly 14.0.1. Final):
C:\wildfly-14.0.1.Final\bin>jboss-cli.bat
You are disconnected at the moment. Type 'connect' to connect to the server or '
help' for the list of supported commands.
[disconnected /] connect
[standalone#localhost:9990 /] /subsystem=elytron/properties-realm=proxyRealm:add(groups-attribute=groups,groups-properties={path=proxy-roles.properties,relative-to=jboss.server.config.dir},users-properties={path=proxy-users.properties,relative-to=jboss.server.config.dir,plain-text=true})
{"outcome" => "success"}
[standalone#localhost:9990 /] /subsystem=elytron/security-domain=proxySD:add(realms=[{realm=proxyRealm,role-decoder=groups-to-roles}],default-realm=proxyRealm,permission-mapper=default-permission-mapper)
{"outcome" => "success"}
[standalone#localhost:9990 /] /subsystem=elytron/http-authentication-factory=proxy-http-auth:add(http-server-mechanism-factory=global,security-domain=proxySD,mechanism-configurations=[{mechanism-name=BASIC,mechanism-realm-configurations=[{realm-name=proxyRealm}]}]
{"outcome" => "success"}
[standalone#localhost:9990 /] /subsystem=undertow/application-security-domain=proxySD:add(http-authentication-factory=proxy-http-auth)
{"outcome" => "success"}
[standalone#localhost:9990 /] /subsystem=elytron/sasl-authentication-factory=proxy-app-sasl-auth:add(mechanism-configurations=[{mechanism-name=JBOSS-LOCAL-USER,realm-mapper=local},{mechanism-name=BASIC,mechanism-realm-configurations=[{realm-name=proxyRealm}]}],sasl-server-factory=configured,security-domain=proxySD)
{"outcome" => "success"}
[standalone#localhost:9990 /] /subsystem=ejb3/application-security-domain=proxySD:add(security-domain=proxySD)
{"outcome" => "success"}
Notes:
As you may have noticed, I switched from a FileSystem realm to a Properties realm. This is not related to the issue, it is just that it made easier to debug.
Elytron's security domain (defined at the 3rd command), Undertow's application security domain (defined at the 4th command) and EJB's application-security-domain (defined at the 6th command) have all the same name proxySD. That the name is the same in all three subsystems is important, and bad things can happen if they have different names (I have not tried out all the combinations).
WS based on EJBs must be invoked with "authenticate pre-emptively", sending the authentication data in the first request without being prompted by the server. WS based on POJOs in a war use the authentication system for web pages, so there is no need to authentica pre-emptively.

Puppet PostgresQL management

I am trying to provision an EC2 instance using puppet. In the process I have downloaded the puppetlabs-postgresql module from puppetlabs. Since I'm fairly new to puppet, i do not want to manage my database by creating classes in my site.pp file located in /etc/puppet/manifests/site.pp. Rather I want to have a module call database in /etc/puppet/modules/database.
What I have done so far is create an init.pp file in /etc/puppet/modules/database. Below is the content of my init.pp file :
class database {
# resources
postgresql::globals{'globals':
version => '9.3',
manage_package_repo => true,
encoding => 'UTF8',
locale => 'it_IT.utf8',
}
postgresql::server{'server':
ensure => 'present',
listen_addresses => '*',
manage_firewall => true,
}
postgresql::server::contrib{'contrib':
package_ensure => 'present',
}
}
And then in my /etc/puppet/manifests/site.pp file i have included the database class as below :
node default {
include localusers
include database
}
However i keep getting an error :
Error: Puppet::Parser::AST::Resource failed with error ArgumentError: Invalid resource type postgresql::globals at /etc/puppet.manifests/init.pp:12
Please what is the correct way to make use of the postgresql classes and resources in my own module and create a database in the module as well ?
You're on the right track, but there are a few issues with how you're using the postgresql module. The reason you're getting the Invalid resource type error is that you're trying to use postgresql::globals as a defined type when it's actually a class. You have the same issue with the other two classes you're using. Try this...
class database {
# set global defaults before creating server
class { 'postgresql::globals':
version => '9.3',
manage_package_repo => true,
encoding => 'UTF8',
locale => 'it_IT.utf8',
}->
class { 'postgresql::server':
listen_addresses => '*',
manage_firewall => true,
}
# install the postgresql contrib package
class { 'postgresql::server::contrib':
package_ensure => 'present',
}
# create database with user and default permissions
postgresql::server::db { 'my_awesome_db':
user => 'my_db_user',
password => 'puppetRocks',
}
}
In the reference section of the module documentation, there's a breakdown of the classes and resources (a.k.a. defined types). The postgresql::server::db type that I used is the simplest way to create a database, user, and permissions all at once. There are separate types available for each of those to provide more fine-grained control.