[
https://issues.apache.org/jira/browse/JENA-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14803371#comment-14803371
]
A. Soroka commented on JENA-1029:
---------------------------------
No, the other way around-- in other words, given (say) the OSGi environment, it
would be nice for Jena to be able to rely on OSGi for its lifecycle management.
Of course there would need to be a J2SE impl and it would be the default. The
proposal above seems mostly fine, except that I would hope to find the registry
be an interface and not a class, to indicate that it could be implemented with
different "backends". The other thing is that we would want to define "system
init" in terms of guarantees instead of implementation. The J2SE default
registry might get populated via {{ServiceLoader}} as you describe, but an OSGi
registry impl might look in the OSGi service registry for services with a
particular type or piece of metadata, or a CDI registry impl might use the bean
registry, etc.
> Add a Jena-wide subsystem lifecycle
> -----------------------------------
>
> Key: JENA-1029
> URL: https://issues.apache.org/jira/browse/JENA-1029
> Project: Apache Jena
> Issue Type: Improvement
> Affects Versions: Jena 3.0.0
> Reporter: Andy Seaborne
>
> A subsystem lifecyclefor Jena would provide the hook for:
> * basic wiring together e.g. wiring RIOT into Jena core
> * initialization e.g. {{TDB.init()}} becomes redundant
> * starting and stopping in large systems, e.g. starting and stopping Fuseki2
> when in a Tomcat server
> This proposal is as simple as possible. It is for system bootstrap and basic
> lifecycle. It is not intended to work for a mixture of jars from different
> Jena releases.
> *Sub-system Interface*
> {code:title=JenaSubsystemLifecycle|borderStyle=solid}
> public interface JenaSubsystemLifecycle {
> public void start() ;
> public void stop() ;
> }
> {code}
> {{stop}} would not be called normally as part of JVM exit (code can do that
> itself anyway). It is in support of start-stop-(re)start and only called if
> there is a hook for such a cycle. {{stop}} is more of a placeholder for the
> moment.
> *Registry*
> There is a single registry:
> {code:title=JenaSubsystemRegistry|borderStyle=solid}
> public class JenaSubsystemRegistry {
> public static void add(JenaSubsystemLifecycle module) ;
> public static boolean isRegistered(JenaSubsystemLifecycle module) ;
> public static void remove(JenaSubsystemLifecycle module) ;
> public static int size() ;
> public static boolean isEmpty() ;
> public static void forEach(Consumer<JenaSubsystemLifecycle> action) ;
> }
> {code}
> *Ensuring initialization*
> Jena core provides a "system init" that is cheap to call if initialization
> has already occurred. It should attempt the first call as early as possible.
> When initializing, it runs a {{ServiceLoader}} cycle to discover any
> {{JenaSubsystemLifecycle}} implementations described in a
> {{META-INF/services/...}} file and populates the registry. Then the registry
> is
> used to call {{start()}} in some unspecified order.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
