* Simple CRUD operations are available at: <base>/{unit-name}/entity/{type}. Reads are GETs, and writes use PUT/POST/DELETE.

* Simple CRUD operations are available at: <base>/{unit-name}/entity/{type}. Reads are GETs, and writes use PUT/POST/DELETE.

* Queries can also Read, Update and Delete: <base>/{unit-name}/query/<queryName>. You will likely want similar restrictions on queries as other CRUD operations. Reads are GETs and writing queries are POST

* Queries can also Read, Update and Delete: <base>/{unit-name}/query/<queryName>. You will likely want similar restrictions on queries as other CRUD operations. Reads are GETs and writing queries are POST

−

** Single result read queries are at: GET /persistence/{unit-name}/querySingleResult/{name} and should likely be treated like other Read queries

+

** Single result read queries are at: GET /persistence/{unit-name}/singleResultQuery/{name} and should likely be treated like other Read queries

* Bootstrapping operations should likely be secured as they allow dynamic addition of mappings and persistence units. PUT/DELETE /persistence/{unit-name}

* Bootstrapping operations should likely be secured as they allow dynamic addition of mappings and persistence units. PUT/DELETE /persistence/{unit-name}

* Metadata is available by Rest and may need securing: GET /persistence and GET /persistence/unitName

* Metadata is available by Rest and may need securing: GET /persistence and GET /persistence/unitName

Line 71:

Line 71:

== Logging Configuration ==

== Logging Configuration ==

−

=== WebLogic Server ===

+

=== WebLogic Server ===

+

+

*Create a logging.properties file (see the sample below).

+

*Point WLS at logging.properties file with -Djava.util.logging.config.file=path/to/logging.properties, when starting server<br>

EclipseLink JPA-RS

bug 362900
The EclipseLink 2.4.0 release will include an easy to use RESTful interface for interacting with JPA persistence units and EJB session bean methods. The intent is to provide an easy to use solution for exposing these Java EE capabilities through REST.

Features

Simple Enablement: The JPA-RS capability can be easily added to any Java EE application being deployed to any compliant Java EE server by simply adding JPA-RS components to an application.

Zero configuration: When enabled the exposed JAX-RS service will allow any persistence unit or related EJB to be accessed using simple REST calls. Optional configuration will be supported for developers who want to limit what capabilities are exposed or wish to customize the resources used in any REST operation.

Dynamic JPA-RS: Enable the deployment of a generic JPA-RS application into a compliant Java EE server without requiring any included persistence units. This dynamic service will support provisioning of persistence units on the fly by passing in or providing reference to dynamic JPA configuration XML (persistence.xml and eclipselink-orm.xml using virtual entities).

Requirements

RESTFul API

When enabled JPA-RS will expose the complete capabilities of the persistence units defined within the application.

Persistence Unit Access

In order for JPA-RS to access a persistence unit it must be made available through one of the following mechanisms:

Available on classpath of running JPA-RS instance so standard JPA bootstrapping can find it

Provisioned: This requires a PUT call to the service to inform it of a PU

Pass in all of the configuration

Pass in minimal information with information about where to retrieve additional config from

Using JPA-RS with static PU

The goal is to make enabling of JPA-RS as easy to do as possible.

JAX-RS

In order to function in standard JAX-RS solution there must be annotated classes in the deployed WAR.

Jersey

The JAX-RS reference implementation is Jersey (jersey.java.net). Additional support will be added to leverage Jersey's (add version) planned support for defining JAX-RS applications and resources using their API. The goal here is to allow JPA-RS to be declaratively configured without requiring any additional code to be included in a user's WAR/EAR.

Dynamic JPA-RS

Dynamic JPA-RS refers to the notion of a JPA-RS application deployment where persistence unit definitions are installed/provisioned on the fly.

Security

Security in JPA-RS should be implemented through standard RESTful application security practices.

The REST URLs described in the document linked above give an idea of which URLs could be restricted using a standard user/role based system. Some things to consider:

Simple CRUD operations are available at: <base>/{unit-name}/entity/{type}. Reads are GETs, and writes use PUT/POST/DELETE.

Queries can also Read, Update and Delete: <base>/{unit-name}/query/<queryName>. You will likely want similar restrictions on queries as other CRUD operations. Reads are GETs and writing queries are POST

Single result read queries are at: GET /persistence/{unit-name}/singleResultQuery/{name} and should likely be treated like other Read queries

Bootstrapping operations should likely be secured as they allow dynamic addition of mappings and persistence units. PUT/DELETE /persistence/{unit-name}

Metadata is available by Rest and may need securing: GET /persistence and GET /persistence/unitName

Configurable Content

By default all entity types CRUD operations and named queries will be exposed by JPA-RS. Configuration of which URLs are available is through the security policy described above.

Additional URIs

In addition to the URI's for all defined named queries and entity types there should be support in JPA-RS to access server side application logic within EJB session beans.

Configurable Content

By default all entity types CRUD operations and named queries will be exposed by JPA-RS. Configuration of which URLs are available is through the security policy described above.

Logging Configuration

WebLogic Server

Create a logging.properties file (see the sample below).

Point WLS at logging.properties file with -Djava.util.logging.config.file=path/to/logging.properties, when starting server

Sample logging.properties file

# Add handlers to the root logger.
# These are inherited by all other loggers.
handlers=java.util.logging.ConsoleHandler, java.util.logging.FileHandler
#Set the default logging level for new ServerLoggingHandler instances
weblogic.logging.ServerLoggingHandler.level = ALL
# Set the logging level of the root logger.
# Levels from lowest to highest are
# FINEST, FINER, FINE, CONFIG, INFO, WARNING and SEVERE.
# The default level for all loggers and handlers is INFO.
.level=SEVERE
# Specify logging levels for specific namespaces.
org.eclipse.persistence.jpars.level=FINEST
# Configure the ConsoleHandler.
# ConsoleHandler uses java.util.logging.SimpleFormatter by default.
# Even though the root logger has the same level as this,
# the next line is still needed because we're configuring a handler,
# not a logger, and handlers don't inherit properties from the root logger.
java.util.logging.ConsoleHandler.level=FINEST
# Configure the FileHandler.
# FileHandler uses java.util.logging.XMLFormatter by default.
java.util.logging.FileHandler.formatter=java.util.logging.SimpleFormatter
java.util.logging.FileHandler.level=FINEST
# The following special tokens can be used in the pattern property
# which specifies the location and name of the log file.
# / - standard path separator
# %t - system temporary directory
# %h - value of the user.home system property
# %g - generation number for rotating logs
# %u - unique number to avoid conflicts
# FileHandler writes to %h/demo0.log by default.
java.util.logging.FileHandler.pattern=./jpa-rs.log

Glassfish Server

Using Glassfish Admin Console, add JPA-RS logger. The name of the JPA-RS logger is "org.eclipse.persistence.jpars".