On 19/09/15 14:33, Claude Warren wrote:
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:
Two step process: load(=initialize) then execute .start.
load() != run
load() and add(..) can be mixed.
{code}
JenaSubsystemRegistry reg = // some method to get registry here
reg.add( module1 )
reg.add( module2 )
reg.add( module3 )
reg.load();
{code}
See the code in JenaSystem
and
http://jena.staging.apache.org/documentation/notes/system-initialization.html
In fact, the code ATM loads, then adds the level zero handler (so it is
always present).
Then sorts them into level order and calls .start() in a .forEach loop.
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?
Equality determined by the initialization code type. The "set" of
objects (object equality) is really more a helper than a requirement
because it might be hard to sort out externally.
If some weird setup want multiple instances of the same class (different
arguments presumably), it can.
ServiceLoader will only create one of each object anyway.
All the system initializers ones are very simply classes that have no
state. Look for classes called "Init..." e.g. "InitARQ"
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?)
javadoc on JenaSystem.forEach
"Calls are made sequentially and in increasing level order. The exact
order within a level is not specified; it is not registration order."
Seems like JenaSubsystemRegistry might be a good candidate for a contract
test.
Claude
The real test is "does Jena initialize?". The hard part is
order-dependent initialization of classes even within one artifact.
This has always been a problem - it's a general Java thing. Order
inside class of statics matters as do loops of class1.<init> ->
class2.<init> ... -> class1 and running into uninitialized statics
(final does not matter - that only affects only primitive data types
during <init>).
The new level stuff gives us a way to control things if necessary. I
did simply the initialization of ARQ for example, by assuming jena core
is ready.
Andy
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)
