[
https://issues.apache.org/jira/browse/ISIS-833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Haywood updated ISIS-833:
-----------------------------
Description:
... so that in future these can be released independently of core; and to
reduce configuration (isis.properties file).
Some principles:
* minimize the amount of configuration required; by exploiting @DomainService
annotation, in many cases it should be sufficient to simply add the appropriate
module to the classpath, and let the service be auto-reigstered.
* "on the other hand", don't (without some safety checks) want to start
automatically registering services that might substantially change behaviour of
the system. For example, the JDO services - audit, command, publishing - all
require explicit configuration in isis.properties. Automatically registering
these might be "too much, too soon".
Thus:
* In services containing only programmatic or hidden services ("system
services, repos") then these should be annotated with @DomainService; thus they
are configured and registered automatically if added to the classpath.
* In services containing only "contributions" can (probably safely enough) be
annotated with @DomainService; thus they are configured and registered
automatically if added to the classpath.
* any menu UI services should NOT be annotated with @DomainService, because the
developer may want to have more fine-grained control on how the UI appears.
~~~~~~
No change for the following services:
core request-scoped services; already annotated with @DomainService, and so
always available
- CommandContext (no UI; applib implementation; populated by
runtime if available) - UPDATED JAVADOC
- Bulk.InteractionContext (no UI; applib implementation; not used by
runtime) - UPDATED JAVADOC
- Scratchpad (no UI; applib implementation; not used by
runtime) - UPDATED JAVADOC
- QueryResultsCache (no UI; applib implementation; not used by
runtime) - UPDATED JAVADOC
core singleton services; already annotated with @DomainService, and so always
available
- MementoServiceDefault (no UI; runtime implementation; used
implicitly by runtime for commands) - UPDATED JAVADOC
- BookmarkServiceDefault (no UI; runtime implementation; used
implicitly by runtime for commands) - UPDATED JAVADOC, now non UI, separated
out out contributions
- XmlSnapshotServiceDefault (no UI; runtime implementation; not
used by runtime) - UPDATED JAVADOC
- ClassDiscoveryServiceUsingReflections (no UI; applib implementation; not
used by runtime) - UPDATED JAVADOC
- ClockService (no UI; applib implementation; not used by
runtime) - UPDATED JAVADOC
~~~
These services should changed to be annotated annotated with @DomainService
(because JDO is now core):
- IsisJdoSupportImpl (no UI; not used by runtime) - NOW
ANNOTATED; UPDATED EXAMPLE APPS (isis.properties, *SystemInitializer for integ
tests
- EventBusServiceJdo (no UI, used by runtime if available) - NOW
ANNOTATED; UPDATED EXAMPLE APPS (isis.properties, *SystemInitializer for integ
tests
~~~
IsisJdoSupport API should move from the jdo-applib to applib; - DONE.
~~~~~~
The following are new (Maven) modules.
Some notes:
* If a service can be used by runtime, then its API is defined in applib; the
module therefore contains only the impl. Most of the modules below fall into
this category.
* If a service is completely standalone from the framework, then it defines its
own API (in an "applib" submodule) and its own impl. An example of this is
isis-module-settings, which defines AppSettings and UserSettings.
isis-module-wrapper (used by integtestsupport)
- WrapperFactoryDefault (no UI; already @DomainService; rename
core-wrapper implementation); DONE, UPDATED pom.xml in example apps;
isis-module-command-jdo - MOVED, UPDATED.
- CommandServiceJdo (used by runtime if available, so API in
applib) - DECIDED NOT TO MAKE INTO @DomainService FOR NOW.
- CommandServiceJdoContributions (UI, not used by runtime)
- CommandServiceJdoRepository (no UI, supporting service for
...Contributions); - NOW ANNOTATED AS @DomainService; UPDATED EXAMPLES
- BackgroundCommandServiceJdo (UI visible, not used by runtime
but prereq for background service) - NOW ANNOTATED AS @DomainService; UPDATED
EXAMPLES
- BackgroundCommandServiceJdoContributions (UI visible, not used by runtime)
- BackgroundCommandServiceJdoRepository (not visible, supporting service
for ...Contributions); - NOW ANNOTATED AS @DomainService; UPDATED EXAMPLES
isis-module-audit-jdo - MOVED, UPDATED.
- AuditingServiceJdo (used by runtime if available, so API in
applib) - DECIDED NOT TO MAKE INTO @DomainService FOR NOW
- AuditingServiceJdoContributions (UI, not used by runtime)
- AuditingServiceJdoRepository (not visible, supporting service for
...Contributions); - NOW ANNOTATED AS @DomainService; UPDATED EXAMPLES
isis-module-background
- BackgroundServiceDefault (used by runtime if available, so API in
applib; requires BackgroundCommandService); CAN'T SAFELY BE A @DomainService
BECAUSE OF DEPENDENCY ON impl. of BackgroundCommandService
isis-module-publishing-jdo
- PublishingServiceJdo (used by runtime if available, so API in
applib)
- PublishingServiceJdoContributions (UI, not used by runtime)
- PublishingServiceJdoRepository (not visible, supporting service for
...Contributions); - NOW ANNOTATED AS @DomainService; UPDATED EXAMPLES
isis-module-publishingeventserializer-ro
- RestfulObjectsSpecEventSerializer (not visible, used by publishing service);
- NOW ANNOTED AS @DomainService; UPDATED EXAMPLES
isis-module-devutils (not used by runtime, standalone)
- applib
> DeveloperUtilitiesService
- impl
> DeveloperUtilitiesServiceDefault (metamodel impl)
isis-module-settings (not used by runtime, standalone)
- applib
> ApplicationSettingsServiceRW
> UserSettingsServiceRW
- impl-jdo
> ApplicationSettingsServiceJdo (UI, not used by runtime)
> ApplicationSettingsServiceHidden (not UI, not used by runtime)
> UserSettingsServiceJdo (UI, not used by runtime)
> UserSettingsServiceHidden (not UI, not used by runtime)
in addition:
* move IsisJdoSupport APi into core-applib *; DONE; HAVE REMOVED jdo-applib
completely... updated pom.xml for example apps.
* EventBusServiceDefault can be deprecated, since its subclass
EventBusServiceJdo is always available
- have decided to leave ExceptionRecognizerCompositeForJdoObjectStore to be
explicitly registered; likelihood that this will require customisation in some
cases. (used by runtime if available)
was:
... so that in future these can be released independently of core; and to
reduce configuration (isis.properties file).
Some principles:
* minimize the amount of configuration required; by exploiting @DomainService
annotation, in many cases it should be sufficient to simply add the appropriate
module to the classpath, and let the service be auto-reigstered.
* "on the other hand", don't (without some safety checks) want to start
automatically registering services that might substantially change behaviour of
the system. For example, the JDO services - audit, command, publishing - all
require explicit configuration in isis.properties. Automatically registering
these might be "too much, too soon".
Thus:
* In services containing only programmatic or hidden services ("system
services, repos") then these should be annotated with @DomainService; thus they
are configured and registered automatically if added to the classpath.
* In services containing only "contributions" can (probably safely enough) be
annotated with @DomainService; thus they are configured and registered
automatically if added to the classpath.
* any menu UI services should NOT be annotated with @DomainService, because the
developer may want to have more fine-grained control on how the UI appears.
~~~~~~
No change for the following services:
core request-scoped services; already annotated with @DomainService, and so
always available
- CommandContext (no UI; applib implementation; populated by
runtime if available) - UPDATED JAVADOC
- Bulk.InteractionContext (no UI; applib implementation; not used by
runtime) - UPDATED JAVADOC
- Scratchpad (no UI; applib implementation; not used by
runtime) - UPDATED JAVADOC
- QueryResultsCache (no UI; applib implementation; not used by
runtime) - UPDATED JAVADOC
core singleton services; already annotated with @DomainService, and so always
available
- MementoServiceDefault (no UI; runtime implementation; used
implicitly by runtime for commands) - UPDATED JAVADOC
- BookmarkServiceDefault (no UI; runtime implementation; used
implicitly by runtime for commands) - UPDATED JAVADOC, now non UI, separated
out out contributions
- XmlSnapshotServiceDefault (no UI; runtime implementation; not
used by runtime) - UPDATED JAVADOC
- ClassDiscoveryServiceUsingReflections (no UI; applib implementation; not
used by runtime) - UPDATED JAVADOC
- ClockService (no UI; applib implementation; not used by
runtime) - UPDATED JAVADOC
~~~
These services should changed to be annotated annotated with @DomainService
(because JDO is now core):
- IsisJdoSupportImpl (no UI; not used by runtime) - NOW
ANNOTATED; UPDATED EXAMPLE APPS (isis.properties, *SystemInitializer for integ
tests
- EventBusServiceJdo (no UI, used by runtime if available) - NOW
ANNOTATED; UPDATED EXAMPLE APPS (isis.properties, *SystemInitializer for integ
tests
~~~
IsisJdoSupport API should move from the jdo-applib to applib; - DONE.
~~~~~~
The following are new (Maven) modules.
Some notes:
* If a service can be used by runtime, then its API is defined in applib; the
module therefore contains only the impl. Most of the modules below fall into
this category.
* If a service is completely standalone from the framework, then it defines its
own API (in an "applib" submodule) and its own impl. An example of this is
isis-module-settings, which defines AppSettings and UserSettings.
isis-module-wrapper (used by integtestsupport)
- WrapperFactoryDefault (no UI; already @DomainService; rename
core-wrapper implementation); DONE, UPDATED pom.xml in example apps;
isis-module-command-jdo - MOVED, UPDATED.
- CommandServiceJdo (used by runtime if available, so API in
applib) - DECIDED NOT TO MAKE INTO @DomainService FOR NOW.
- CommandServiceJdoContributions (UI, not used by runtime)
- CommandServiceJdoRepository (no UI, supporting service for
...Contributions); - NOW ANNOTATED AS @DomainService; UPDATED EXAMPLES
- BackgroundCommandServiceJdo (UI visible, not used by runtime
but prereq for background service) - NOW ANNOTATED AS @DomainService; UPDATED
EXAMPLES
- BackgroundCommandServiceJdoContributions (UI visible, not used by runtime)
- BackgroundCommandServiceJdoRepository (not visible, supporting service
for ...Contributions); - NOW ANNOTATED AS @DomainService; UPDATED EXAMPLES
isis-module-audit-jdo - MOVED, UPDATED.
- AuditingServiceJdo (used by runtime if available, so API in
applib) - DECIDED NOT TO MAKE INTO @DomainService FOR NOW
- AuditingServiceJdoContributions (UI, not used by runtime)
- AuditingServiceJdoRepository (not visible, supporting service for
...Contributions); - NOW ANNOTATED AS @DomainService; UPDATED EXAMPLES
isis-module-background
- BackgroundServiceDefault (used by runtime if available, so API in
applib; requires BackgroundCommandService); CAN'T SAFELY BE A @DomainService
BECAUSE OF DEPENDENCY ON impl. of BackgroundCommandService
isis-module-publishing-jdo
- PublishingServiceJdo (used by runtime if available, so API in
applib)
- PublishingServiceJdoContributions (UI, not used by runtime)
- PublishingServiceJdoRepository (not visible, supporting service for
...Contributions); - NOW ANNOTATED AS @DomainService; UPDATED EXAMPLES
isis-module-devutils (not used by runtime, standalone)
- applib
> DeveloperUtilitiesService
- impl
> DeveloperUtilitiesServiceDefault (metamodel impl)
isis-module-settings (not used by runtime, standalone)
- applib
> ApplicationSettingsServiceRW
> UserSettingsServiceRW
- impl-jdo
> ApplicationSettingsServiceJdo (UI, not used by runtime)
> ApplicationSettingsServiceHidden (not UI, not used by runtime)
> UserSettingsServiceJdo (UI, not used by runtime)
> UserSettingsServiceHidden (not UI, not used by runtime)
in addition:
* move IsisJdoSupport APi into core-applib *; DONE; HAVE REMOVED jdo-applib
completely... updated pom.xml for example apps.
* EventBusServiceDefault can be deprecated, since its subclass
EventBusServiceJdo is always available
- have decided to leave ExceptionRecognizerCompositeForJdoObjectStore to be
explicitly registered; likelihood that this will require customisation in some
cases. (used by runtime if available)
> Break out applib and JDO services into modules
> ----------------------------------------------
>
> Key: ISIS-833
> URL: https://issues.apache.org/jira/browse/ISIS-833
> Project: Isis
> Issue Type: Improvement
> Affects Versions: objectstore-jdo-1.5.0, core-1.5.0
> Reporter: Dan Haywood
> Assignee: Dan Haywood
> Fix For: objectstore-jdo-1.6.0, core-1.6.0
>
>
> ... so that in future these can be released independently of core; and to
> reduce configuration (isis.properties file).
> Some principles:
> * minimize the amount of configuration required; by exploiting
> @DomainService annotation, in many cases it should be sufficient to simply
> add the appropriate module to the classpath, and let the service be
> auto-reigstered.
> * "on the other hand", don't (without some safety checks) want to start
> automatically registering services that might substantially change behaviour
> of the system. For example, the JDO services - audit, command, publishing -
> all require explicit configuration in isis.properties. Automatically
> registering these might be "too much, too soon".
> Thus:
> * In services containing only programmatic or hidden services ("system
> services, repos") then these should be annotated with @DomainService; thus
> they are configured and registered automatically if added to the classpath.
> * In services containing only "contributions" can (probably safely enough) be
> annotated with @DomainService; thus they are configured and registered
> automatically if added to the classpath.
> * any menu UI services should NOT be annotated with @DomainService, because
> the developer may want to have more fine-grained control on how the UI
> appears.
> ~~~~~~
> No change for the following services:
> core request-scoped services; already annotated with @DomainService, and so
> always available
> - CommandContext (no UI; applib implementation; populated
> by runtime if available) - UPDATED JAVADOC
> - Bulk.InteractionContext (no UI; applib implementation; not used by
> runtime) - UPDATED JAVADOC
> - Scratchpad (no UI; applib implementation; not used by
> runtime) - UPDATED JAVADOC
> - QueryResultsCache (no UI; applib implementation; not used by
> runtime) - UPDATED JAVADOC
> core singleton services; already annotated with @DomainService, and so always
> available
> - MementoServiceDefault (no UI; runtime implementation; used
> implicitly by runtime for commands) - UPDATED JAVADOC
> - BookmarkServiceDefault (no UI; runtime implementation; used
> implicitly by runtime for commands) - UPDATED JAVADOC, now non UI, separated
> out out contributions
> - XmlSnapshotServiceDefault (no UI; runtime implementation; not
> used by runtime) - UPDATED JAVADOC
> - ClassDiscoveryServiceUsingReflections (no UI; applib implementation; not
> used by runtime) - UPDATED JAVADOC
> - ClockService (no UI; applib implementation; not used by
> runtime) - UPDATED JAVADOC
> ~~~
> These services should changed to be annotated annotated with @DomainService
> (because JDO is now core):
> - IsisJdoSupportImpl (no UI; not used by runtime) - NOW
> ANNOTATED; UPDATED EXAMPLE APPS (isis.properties, *SystemInitializer for
> integ tests
> - EventBusServiceJdo (no UI, used by runtime if available) - NOW
> ANNOTATED; UPDATED EXAMPLE APPS (isis.properties, *SystemInitializer for
> integ tests
> ~~~
> IsisJdoSupport API should move from the jdo-applib to applib; - DONE.
> ~~~~~~
> The following are new (Maven) modules.
> Some notes:
> * If a service can be used by runtime, then its API is defined in applib; the
> module therefore contains only the impl. Most of the modules below fall into
> this category.
> * If a service is completely standalone from the framework, then it defines
> its own API (in an "applib" submodule) and its own impl. An example of this
> is isis-module-settings, which defines AppSettings and UserSettings.
> isis-module-wrapper (used by integtestsupport)
> - WrapperFactoryDefault (no UI; already @DomainService; rename
> core-wrapper implementation); DONE, UPDATED pom.xml in example apps;
> isis-module-command-jdo - MOVED, UPDATED.
> - CommandServiceJdo (used by runtime if available, so API in
> applib) - DECIDED NOT TO MAKE INTO @DomainService FOR NOW.
> - CommandServiceJdoContributions (UI, not used by runtime)
> - CommandServiceJdoRepository (no UI, supporting service for
> ...Contributions); - NOW ANNOTATED AS @DomainService; UPDATED EXAMPLES
> - BackgroundCommandServiceJdo (UI visible, not used by runtime
> but prereq for background service) - NOW ANNOTATED AS @DomainService; UPDATED
> EXAMPLES
> - BackgroundCommandServiceJdoContributions (UI visible, not used by runtime)
> - BackgroundCommandServiceJdoRepository (not visible, supporting service
> for ...Contributions); - NOW ANNOTATED AS @DomainService; UPDATED EXAMPLES
> isis-module-audit-jdo - MOVED, UPDATED.
> - AuditingServiceJdo (used by runtime if available, so API in
> applib) - DECIDED NOT TO MAKE INTO @DomainService FOR NOW
> - AuditingServiceJdoContributions (UI, not used by runtime)
> - AuditingServiceJdoRepository (not visible, supporting service for
> ...Contributions); - NOW ANNOTATED AS @DomainService; UPDATED EXAMPLES
> isis-module-background
> - BackgroundServiceDefault (used by runtime if available, so API in
> applib; requires BackgroundCommandService); CAN'T SAFELY BE A @DomainService
> BECAUSE OF DEPENDENCY ON impl. of BackgroundCommandService
> isis-module-publishing-jdo
> - PublishingServiceJdo (used by runtime if available, so API in
> applib)
> - PublishingServiceJdoContributions (UI, not used by runtime)
> - PublishingServiceJdoRepository (not visible, supporting service for
> ...Contributions); - NOW ANNOTATED AS @DomainService; UPDATED EXAMPLES
> isis-module-publishingeventserializer-ro
> - RestfulObjectsSpecEventSerializer (not visible, used by publishing
> service); - NOW ANNOTED AS @DomainService; UPDATED EXAMPLES
> isis-module-devutils (not used by runtime, standalone)
> - applib
> > DeveloperUtilitiesService
> - impl
> > DeveloperUtilitiesServiceDefault (metamodel impl)
> isis-module-settings (not used by runtime, standalone)
> - applib
> > ApplicationSettingsServiceRW
> > UserSettingsServiceRW
> - impl-jdo
> > ApplicationSettingsServiceJdo (UI, not used by runtime)
> > ApplicationSettingsServiceHidden (not UI, not used by runtime)
> > UserSettingsServiceJdo (UI, not used by runtime)
> > UserSettingsServiceHidden (not UI, not used by runtime)
> in addition:
> * move IsisJdoSupport APi into core-applib *; DONE; HAVE REMOVED jdo-applib
> completely... updated pom.xml for example apps.
> * EventBusServiceDefault can be deprecated, since its subclass
> EventBusServiceJdo is always available
> - have decided to leave ExceptionRecognizerCompositeForJdoObjectStore to be
> explicitly registered; likelihood that this will require customisation in
> some cases. (used by runtime if available)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
