Q on JenaSubsystemRegistry. The load() method. Is is to be called after
adding a series of JenaSubsystemLifecycle objects? I guess I am asking if
the standard use is:
{code}
JenaSubsystemRegistry reg = // some method to get registry here
reg.add( module1 )
reg.add( module2 )
reg.add( module3 )
reg.load();
{code}
The Registry indicates that the collection of modules is a set, but the
Lifecycle documentation makes no mention of equality or comparator
requirements. How is the set in the Registry to be determined?
I will assume for the moment that it is based on level and that only one
Lifecycle element may be present for a specified level. If a second module
is added with the level of a previous entry which is expected to be used
(first or last?)
Seems like JenaSubsystemRegistry might be a good candidate for a contract
test.
Claude
On Fri, Sep 18, 2015 at 11:30 PM, ASF subversion and git services (JIRA) <
j...@apache.org> wrote:
>
> [
> https://issues.apache.org/jira/browse/JENA-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14876594#comment-14876594
> ]
>
> ASF subversion and git services commented on JENA-1029:
> -------------------------------------------------------
>
> Commit 8cbde67e6b58e75ddb528c432f3876ec8aabd85a in jena's branch
> refs/heads/Jena-1029_subsystem from [~andy.seaborne]
> [ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=8cbde67 ]
>
> JENA-1029: TDB.init or RIOT.init becomes JenaSystem.init where needed.
>
> > 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)
>
--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
