The lazy provider is intended to defer Gmbal API calls until there is a JMX connection. The provider is scope
(environment) aware and behaves accordingly to actual scope. The default behaviour does not defers Gmbal API calls.
There are two kind of method allowing registration of an object as a listener. One is for
WSEndpointImpl
instances (implementing
WSEndpointScopeChangeListener) and the other is for arbitrary objects
(implementing
DefaultScopeChangeListener) that want to be notified about scope changes. The distinction is made
because of the fact that endpoints should be registered first and other objects (e.g. dependants on endpoints) must
be registered after all the endpoints are processed so no inconsistency is present.
Glassfish:
WebServicesContainer is one of two classes for which a
ManagedObjectManager instance (see Gmbal API)
is created when a webservice application is deployed into the Glassfish. For the purpose of postponing Gmbal API calls
the
WebServicesContainer extends
MBeanListener.CallbackImpl so it can register itself as a listener of
AMXGlassfish and receive a notification about a connection of a JMX client to the Glassfish server (see
WebServicesContainer#postConstruct for registration details). The moment the JMX client is connected a notification
is sent to the listeners of
AMXGlassfish. When this event is received by
WebServiceContainer (see the
callback method
mbeanRegistered) a
ManagedObjectManager instance is created and no further deferring
of Gmbal API calls is needed.
Metro/JAX-WS:
The situation in Metro/JAX-WS is slightly different from the one described above. Metro/JAX-WS can be used as standalone
libraries (outside of Glassfish) so no notification from the Glassfish server can be expected in this case. This leads
to a situation when Metro/JAX-WS has to be aware of context in which it is used and acts appropriately. There are 3
scopes an application using Metro/JAX-WS can be in:
STANDALONE,
GLASSFISH_NO_JMX,
GLASSFISH_JMX
(
scope). The default scope is
STANDALONE and all Gmbal API calls are invoked as they
are requested. The other two scopes are applied only when an application is deployed into a Glassfish server. The
GLASSFISH_NO_JMX is set at the moment the application is deployed (see below) and its purpose is to defer Gmbal
API calls for as long as possible. For some classes e.g.
ManagedObjectManager proxy classes were introduced to
avoid the necessity of creating the real Gmbal objects but if a method is invoked on these proxies the creation of real
Gmbal objects is forced even in this scope. The
GLASSFISH_JMX scope is set when a JMX client is connected to
the Glassfish server and it processes Gmbal API calls without deferring (as if the application was in the
STANDALONE scope). The entry point for postponing the Gmbal API calls / creating Gmbal objects in Metro/JAX-WS
is
LazyMOMProvider. This class is capable of receiving notifications from the Glassfish server
(
LazyMOMProvider.initMOMForScope) about the scope change and it also spread this information to its listeners.
The listeners of
LazyMOMProvider are of two kinds:
LazyMOMProvider.WSEndpointScopeChangeListener and
LazyMOMProvider.DefaultScopeChangeListener. Extensions of
WSEndpoint (e.g.
WSEndpointImpl)
should implement the
LazyMOMProvider.WSEndpointScopeChangeListener and register themselves as endpoint listeners
of
LazyMOMProvider. Other classes should implement the latter mentioned interface and register themselves as
a non-endpoint listener. The differences between these two kind of listeners are described in
LazyMOMProvider
class comment. An implementation of
LazyMOMProvider.DefaultScopeChangeListener is provided in Metro
(
WSEndpointCollectionBasedMOMListener). As mentioned above this listener register itself as a non-endpoint
listener of
LazyMOMProvider (
WSEndpointCollectionBasedMOMListener.init). An instance of this class is
used in these factories:
SessionManager,
NonceManager and
SequenceManagerFactory.
SessionManager,
NonceManager,
PersistentSequenceManager and
InVmSequenceManager also
(indirectly) implement
MOMRegistrationAware for providing information whether a manager is registered at
ManagedObjectManager or not. Registration of a manager at
ManagedObjectManager can be processed directly
(if
WSEndpointCollectionBasedMOMListener.canRegisterAtMOM returns
true) via
WSEndpointCollectionBasedMOMListener.registerAtMOM or is deferred by putting the manager into
WSEndpointCollectionBasedMOMListener.registrationAwareMap. Managers stored in for deferred registration are
processed at the moment the
LazyMOMProvider notifies the
WSEndpointCollectionBasedMOMListener about
the scope change.
The mentioned postponing of Gmbal API calls applies only to the server side of the webservice application.