Plan a NoSQL System Resource

Choose the provider deployment, database, endpoint, authentication settings, targets, application binding, and allowed callers before configuration.

WebLogic Server includes a set of code examples that demonstrates the functionality of Jakarta Data and NoSQL within WebLogic Server. These examples are described in Sample Applications and Code Examples in Understanding Oracle WebLogic Server.

References to the code examples (which uses the Oracle NoSQL provider) appear throughout this book.

Supported NoSQL Providers

WebLogic Server supports the following NoSQL providers:

Provider Name Current WebLogic Server Managed Runtime
couchbase Document
couchdb Document
dynamodb Document
elasticsearch Document
mongodb Document
oracle-nosql Document
solr Document

Choose System Resource Names

You must specify a name for each NoSQL system resource.

The examples in the following table use the definitions in the WebLogic Server Jakarta Data/NoSQL sample. The application packages PersonRepository and Person in data-nosql.war.

The following table separates the sample’s resource names.

Name Example Purpose
Management resource personNoSqlResource Domain lookup and security policy identity
Descriptor JNDI binding nosql/personNoSqlResource Destination of the application mapping
Application-local alias nosql/person Repository selection and resource-reference name

Before a NoSQL system resource can be created, it must pass checks on its targeting controls placement, that its binding establishes the application’s approved destination, and policy controls current-subject access are verified.

Separate Placement and Security Controls

The following controls answer different questions. A successful check does not waive the others.

Control Purpose Configuration or Check
Targeting Where the resource is available Server or cluster targets
Application binding Which resource the deployer approved Effective same-scope declaration and JNDI mapping
Runtime authorization Whether the current subject may use the resource Resource-specific NoSQLResource access policy
Application ownership Which deployment may use a handle or derived capability Exact calling-application ownership checks
Database authentication How the provider authenticates to the NoSQL database Deployment-specific protected credentials
Management access Who may configure the resource WebLogic Server management permissions and protected connections

Configure Provider Properties

Property names differ by provider. For the specific names of the properties required by each supported NoSQL provider, see Eclipse JNoSQL databases GitHub repository.

For example, the following table lists the required properties and their non-secret development values for the Oracle NoSQL provider.

Property Purpose Development Value
jnosql.document.database Document database person_catalog
jnosql.oracle.nosql.deployment Oracle NoSQL deployment mode ON_PREMISES
jnosql.oracle.nosql.host Provider endpoint Value of WLS_NOSQL_ENDPOINT; for example, http://localhost:8080

The endpoint represents a local development service. Use deployment appropriate endpoint protection and authentication in the actual environment. Additional deployment-specific authentication and tuning properties follow the supported adapter contract.

Validation checks required and conflicting properties, supported provider/type combinations, numeric bounds where applicable, descriptor identity, and targeting. Activation validates configuration; it does not test live database connectivity. Provider construction is lazy.

Protect Provider Credentials

Use the supported protected property input for credential-bearing settings. The integration retains the existing WebLogic Server descriptor-encryption model.

Protect management access, domain configuration, and the platform security material needed to use protected values. Intended-property use must continue across restart. Keep secrets and raw encrypted value blobs out of ordinary property values, scripts, logs, and diagnostic reports.

The provider credential authenticates access to NoSQL databases. The WebLogic Server subject’s authorization is checked independently.