이 콘텐츠는 선택한 언어로 제공되지 않습니다.
13.5. Hibernate Services
13.5.1. About Hibernate Services 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
Services are classes that provide Hibernate with pluggable implementations of various types of functionality. Specifically they are implementations of certain service contract interfaces. The interface is known as the service role; the implementation class is know as the service implementation. Generally speaking, users can plug in alternate implementations of all standard service roles (overriding); they can also define additional services beyond the base set of service roles (extending).
13.5.2. About Service Contracts 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
The basic requirement for a service is to implement the marker interface
org.hibernate.service.Service
. Hibernate uses this internally for some basic type safety.
Optionally, the service can also implement the
org.hibernate.service.spi.Startable
and org.hibernate.service.spi.Stoppable
interfaces to receive notifications of being started and stopped. Another optional service contract is org.hibernate.service.spi.Manageable
which marks the service as manageable in JMX provided the JMX integration is enabled.
13.5.3. Types of Service Dependencies 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
Services are allowed to declare dependencies on other services using either of 2 approaches:
- @
org.hibernate.service.spi.InjectService
- Any method on the service implementation class accepting a single parameter and annotated with @
InjectService
is considered requesting injection of another service.By default the type of the method parameter is expected to be the service role to be injected. If the parameter type is different than the service role, theserviceRole
attribute of theInjectService
should be used to explicitly name the role.By default injected services are considered required, that is the start up will fail if a named dependent service is missing. If the service to be injected is optional, therequired
attribute of theInjectService
should be declared asfalse
(default istrue
). org.hibernate.service.spi.ServiceRegistryAwareService
- The second approach is a pull approach where the service implements the optional service interface
org.hibernate.service.spi.ServiceRegistryAwareService
which declares a singleinjectServices
method.During startup, Hibernate will inject theorg.hibernate.service.ServiceRegistry
itself into services which implement this interface. The service can then use theServiceRegistry
reference to locate any additional services it needs.
13.5.4. The ServiceRegistry 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
13.5.4.1. About the ServiceRegistry 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
The central service API, aside from the services themselves, is the
org.hibernate.service.ServiceRegistry
interface. The main purpose of a service registry is to hold, manage and provide access to services.
Service registries are hierarchical. Services in one registry can depend on and utilize services in that same registry as well as any parent registries.
Use
org.hibernate.service.ServiceRegistryBuilder
to build a org.hibernate.service.ServiceRegistry
instance.
Example 13.21. Use ServiceRegistryBuilder to create a ServiceRegistry
ServiceRegistryBuilder registryBuilder = new ServiceRegistryBuilder( bootstrapServiceRegistry ); ServiceRegistry serviceRegistry = registryBuilder.buildServiceRegistry();
ServiceRegistryBuilder registryBuilder = new ServiceRegistryBuilder( bootstrapServiceRegistry );
ServiceRegistry serviceRegistry = registryBuilder.buildServiceRegistry();
13.5.5. Custom Services 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
13.5.5.1. About Custom Services 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
Once a
org.hibernate.service.ServiceRegistry
is built it is considered immutable; the services themselves might accept re-configuration, but immutability here means adding/replacing services. So another role provided by the org.hibernate.service.ServiceRegistryBuilder
is to allow tweaking of the services that will be contained in the org.hibernate.service.ServiceRegistry
generated from it.
There are two means to tell a
org.hibernate.service.ServiceRegistryBuilder
about custom services.
- Implement a
org.hibernate.service.spi.BasicServiceInitiator
class to control on-demand construction of the service class and add it to theorg.hibernate.service.ServiceRegistryBuilder
via itsaddInitiator
method. - Just instantiate the service class and add it to the
org.hibernate.service.ServiceRegistryBuilder
via itsaddService
method.
Either approach the adding a service approach or the adding an initiator approach are valid for extending a registry (adding new service roles) and overriding services (replacing service implementations).
Example 13.22. Use ServiceRegistryBuilder to Replace an Existing Service with a Custom Service
13.5.6. The Bootstrap Registry 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
13.5.6.1. About the Boot-strap Registry 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
The boot-strap registry holds services that absolutely have to be available for most things to work. The main service here is the
ClassLoaderService
which is a perfect example. Even resolving configuration files needs access to class loading services (resource look ups). This is the root registry (no parent) in normal use.
Instances of boot-strap registries are built using the
org.hibernate.service.BootstrapServiceRegistryBuilder
class.
13.5.6.2. Using BootstrapServiceRegistryBuilder 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
Example 13.23. Using BootstrapServiceRegistryBuilder
13.5.6.3. BootstrapRegistry Services 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
org.hibernate.service.classloading.spi.ClassLoaderService
Hibernate needs to interact with class loaders. However, the manner in which Hibernate (or any library) should interact with class loaders varies based on the runtime environment which is hosting the application. Application servers, OSGi containers, and other modular class loading systems impose very specific class loading requirements. This service is provides Hibernate an abstraction from this environmental complexity. And just as importantly, it does so in a single-swappable-component manner.
In terms of interacting with a class loader, Hibernate needs the following capabilities:
- the ability to locate application classes
- the ability to locate integration classes
- the ability to locate resources (properties files, xml files, etc)
- the ability to load
java.util.ServiceLoader
Note
Currently, the ability to load application classes and the ability to load integration classes are combined into a single "load class" capability on the service. That may change in a later release.
org.hibernate.integrator.spi.IntegratorService
Applications, add-ons and other modules need to integrate with Hibernate. The previous approach required a component, usually an application, to coordinate the registration of each individual module. This registration was conducted on behalf of each module's integrator.
This service focuses on the discovery aspect. It leverages the standard Java
java.util.ServiceLoader
capability provided by the org.hibernate.service.classloading.spi.ClassLoaderService
in order to discover implementations of the org.hibernate.integrator.spi.Integrator
contract.
Integrators would simply define a file named
/META-INF/services/org.hibernate.integrator.spi.Integrator
and make it available on the classpath.
This file is used by the
java.util.ServiceLoader
mechanism. It lists, one per line, the fully qualified names of classes which implement the org.hibernate.integrator.spi.Integrator
interface.
13.5.7. The SessionFactory Registry 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
13.5.7.1. SessionFactory Registry 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
While it is best practice to treat instances of all the registry types as targeting a given
org.hibernate.SessionFactory
, the instances of services in this group explicitly belong to a single org.hibernate.SessionFactory
.
The difference is a matter of timing in when they need to be initiated. Generally they need access to the
org.hibernate.SessionFactory
to be initiated. This special registry is org.hibernate.service.spi.SessionFactoryServiceRegistry
13.5.7.2. SessionFactory Services 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
org.hibernate.event.service.spi.EventListenerRegistry
- Description
- Service for managing event listeners.
- Initiator
org.hibernate.event.service.internal.EventListenerServiceInitiator
- Implementations
org.hibernate.event.service.internal.EventListenerRegistryImpl
13.5.8. Integrators 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
13.5.8.1. Integrators 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
The
org.hibernate.integrator.spi.Integrator
is intended to provide a simple means for allowing developers to hook into the process of building a functioning SessionFactory. The org.hibernate.integrator.spi.Integrator
interface defines 2 methods of interest: integrate
allows us to hook into the building process; disintegrate
allows us to hook into a SessionFactory shutting down.
Note
There is a 3rd method defined on
org.hibernate.integrator.spi.Integrator
, an overloaded form of integrate
accepting a org.hibernate.metamodel.source.MetadataImplementor
instead of org.hibernate.cfg.Configuration
. This form is intended for use with the new metamodel code scheduled for completion in 5.0.
In addition to the discovery approach provided by the IntegratorService, applications can manually register Integrator implementations when building the BootstrapServiceRegistry.
13.5.8.2. Integrator use-cases 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
The main use cases for an
org.hibernate.integrator.spi.Integrator
right now are registering event listeners and providing services (see org.hibernate.integrator.spi.ServiceContributingIntegrator
). With 5.0 we plan on expanding that to allow altering the metamodel describing the mapping between object and relational models.
Example 13.24. Registering event listeners