|
|||||||||||||||||||
Source file | Conditionals | Statements | Methods | TOTAL | |||||||||||||||
ConstructableServicePoint.java | - | - | - | - |
|
1 | // Copyright 2004, 2005 The Apache Software Foundation | |
2 | // | |
3 | // Licensed under the Apache License, Version 2.0 (the "License"); | |
4 | // you may not use this file except in compliance with the License. | |
5 | // You may obtain a copy of the License at | |
6 | // | |
7 | // http://www.apache.org/licenses/LICENSE-2.0 | |
8 | // | |
9 | // Unless required by applicable law or agreed to in writing, software | |
10 | // distributed under the License is distributed on an "AS IS" BASIS, | |
11 | // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | |
12 | // See the License for the specific language governing permissions and | |
13 | // limitations under the License. | |
14 | ||
15 | package org.apache.hivemind.impl; | |
16 | ||
17 | import java.util.List; | |
18 | ||
19 | import org.apache.hivemind.events.RegistryShutdownListener; | |
20 | import org.apache.hivemind.internal.ServiceImplementationConstructor; | |
21 | import org.apache.hivemind.internal.ServicePoint; | |
22 | ||
23 | /** | |
24 | * "Private" interface used by a {@link org.apache.hivemind.internal.ServiceModel}s to access non- | |
25 | * information about a {@link org.apache.hivemind.internal.ServicePoint}, such as its instance | |
26 | * builder and interceptors. | |
27 | * | |
28 | * @author Howard Lewis Ship | |
29 | */ | |
30 | public interface ConstructableServicePoint extends ServicePoint | |
31 | { | |
32 | /** | |
33 | * Returns the constructor that can create the core service implementation. Returns the service | |
34 | * constructor, if defined, or the default service constructor. The default service constructor | |
35 | * comes from the <service-point> itself; other modules can override this default using an | |
36 | * <implementation> element. | |
37 | */ | |
38 | ServiceImplementationConstructor getServiceConstructor(); | |
39 | ||
40 | /** | |
41 | * Returns a list of {@link org.apache.hivemind.internal.ServiceInterceptorContribution}s, | |
42 | * ordered according to their dependencies. May return null or an empty list. | |
43 | * <p> | |
44 | * Note that the order is tricky! To keep any error messages while ordering the interceptors | |
45 | * understandable, they are ordered according into runtime execution order. Example: If we want | |
46 | * a logging interceptor to operate before a security-check interceptor, we'll write the | |
47 | * following in the descriptor: | |
48 | * | |
49 | * <pre> | |
50 | * <interceptor service-id="hivemind.LoggingInterceptor" before="*"/> | |
51 | * <interceptor service-id="somepackage.SecurityInterceptor"/> | |
52 | * </pre> | |
53 | * | |
54 | * The <code>before</code> value for the first interceptor contribution will be assigned to | |
55 | * the contribution's | |
56 | * {@link org.apache.hivemind.internal.ServiceInterceptorContribution#getFollowingInterceptorIds() followingInterceptorIds} | |
57 | * property, because all other interceptors (including the security interceptor) should have | |
58 | * their behavior follow the logging interceptor. | |
59 | * <p> | |
60 | * To get this behavior, the logging interceptor will delegate to the security interceptor, and | |
61 | * the security interceptor will delegate to the core service implementation. | |
62 | * <p> | |
63 | * The trick is that interceptors are applied in reverse order: we start with core service | |
64 | * implementation, wrap it with the security interceptor, then wrap that with the logging | |
65 | * interceptor ... but that's an issue that applies when building the interceptor stack around | |
66 | * the core service implementation. | |
67 | */ | |
68 | List getOrderedInterceptorContributions(); | |
69 | ||
70 | /** | |
71 | * Invoked by the ServiceModel when constuction information (the builder and interceptors) is no | |
72 | * longer needed. | |
73 | */ | |
74 | void clearConstructorInformation(); | |
75 | ||
76 | /** | |
77 | * Adds a shutdown listener; HiveMind uses two coordinators; the first is the | |
78 | * hivemind.ShutdownCoordinator service, which is the coordinator used for service | |
79 | * implementations. The second coordinator is used by the HiveMind infrastructure directly; this | |
80 | * method adds a listener to that coordinator. Why two? It's about order of operations during | |
81 | * registry shutdown; the hivemind.ShutdownCoordinator service's listeners are all invoked | |
82 | * first, the the internal coordinator, to shutdown proxies and the like. This allows services | |
83 | * to communicate during shutdown. | |
84 | * | |
85 | * @param listener | |
86 | * the listener to be added to the infrastructure's shutdown coordinator | |
87 | * @since 1.1.1 | |
88 | */ | |
89 | ||
90 | void addRegistryShutdownListener(RegistryShutdownListener listener); | |
91 | } |
|