[jira] [Closed] (ISIS-1976) Improve the metamodel cache management
[
https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andi Huber closed ISIS-1976.
Resolution: Fixed
We have made some progress on this issue, but it does not feel that the task is
finished yet.
However, I'm closing this issue. Work on IoC Container integration will provide
some improvements here anyway.
> Improve the metamodel cache management
> --
>
> Key: ISIS-1976
> URL: https://issues.apache.org/jira/browse/ISIS-1976
> Project: Isis
> Issue Type: Improvement
> Components: Core
>Reporter: Andi Huber
>Assignee: Andi Huber
>Priority: Major
> Fix For: 2.0.0-M2
>
>
> The cache management we have with ObjectAdapter, might be simplified such
> that we just work with java.lang.Object so far as possible. We would have a
> "disposable" ObjectAdapter that we instantiate around an Object whenever we
> need it - to access into the metamodel - and then throw it away after. Or
> perhaps eventually we might not need ObjectAdapter at all, just simply use
> #getClass() to look up the ObjectSpecification.
> ~~~
> The main objective is to get rid of these two maps:
> [https://github.com/apache/isis/blob/master/core/runtime/src/main/java/org/apache/isis/core/runtime/system/persistence/adaptermanager/OidAdapterHashMap.java]
> and
> [https://github.com/apache/isis/blob/master/core/runtime/src/main/java/org/apache/isis/core/runtime/system/persistence/adaptermanager/PojoAdapterHashMap.java]
> As their name suggests, these map:
> oid -> adapter (look up an adapter from an oid)
> pojo -> adapter (look up an adapter from a pojo)
> The adapter itself has a reference to its oid (getOid()) and to its pojo
> (getObject()).
> Most, though not all, objects have Oids. Certainly DN persistent objects do,
> in fact they do even if they are not yet persisted (prior to calling
> RepositoryService#persist(...). These will have a RootOid, which will
> indicate if the object is persistent or still transient.
> The same is true of view models, these also have a RootOid. They also have a
> RecreatableObjectFacet which is used to actually manufacture the Oid (because
> the oid for view models is basically a serialization of the state of the
> domain object). The RootOid for view models will indicate that they are view
> models.
> Values (ints, strings etc), do NOT have an oid. This also means that -
> obviously - they don't get saved in the OidAdapterHashMap; and they probably
> aren't saved in PojoAdapterHashMap. Value objects will have a ValueFacet.
> There's one other subtype of Oid (apart from RootOid), namely
> ParentedCollectionOid. That's because the Set or List that holds "child"
> objects is also managed as an adapter; ie:
> {code:java}
> public class Order {
>@Getter @Setter
>Set orderItems = Sets.newTreeSet();
>...
> }{code}
> Why is this done? Because a long time ago (before DN) the framework did its
> own persistence, so this was for lazy loading etc.
>
> The "ensureMapsConsistent" method in PersistenceSessionXxx is there to ensure
> that these are maintained correctly; it's rather paranoid because if these
> get out of sync, then bad things would happen; eg:
> [https://github.com/apache/isis/blob/master/core/plugins/jdo-datanucleus-4/src/main/java/org/apache/isis/core/runtime/system/persistence/PersistenceSession4.java#L1184]
>
> There's also some rather horrible "remapRecreatedPojo" methods that hack this
> stuff
> [https://github.com/apache/isis/blob/master/core/plugins/jdo-datanucleus-4/src/main/java/org/apache/isis/core/runtime/system/persistence/PersistenceSession4.java#L1739]
>
> All this stuff is a legacy from the original client/server architecture that
> the framework used to have; it was probably needed then but I really don't
> think it's needed now.
> ~~~
> At the moment the object adapters are created eagerly, typically using
> PersistenceSession#adapterFor(...). For domain services, we eagerly create
> an adapter around every service before each session, "just in case" it gets
> interacted with. This could be removed
> [https://github.com/apache/isis/blob/master/core/plugins/jdo-datanucleus-4/src/main/java/org/apache/isis/core/runtime/system/persistence/PersistenceSession4.java#L237]
>
>
> This also requires the ability to infer the Oid from the pojo, on the fly.
> There are two different ways this is done:
> * for DN entities, there is the JdoObjectIdSerlaizer
> * for view models, there's RecreatableObjectFacet, already mentioned.
> [https://github.com/apache/isis/blob/master/core/plugins/jdo-datanucleus-4/src/main/java/org/apache/isis/objectstore/jdo/datanucleus/persistence/spi/JdoObjectIdSerializer.java]
>
> Ideally the code to recreate/rehydrate the object should define a consistent
> API to
[jira] [Updated] (ISIS-1945) Tree View: allow tree-node icon decorators (overlay-icons)
[ https://issues.apache.org/jira/browse/ISIS-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andi Huber updated ISIS-1945: - Fix Version/s: (was: 2.0.0-M2) 2.0.0 > Tree View: allow tree-node icon decorators (overlay-icons) > -- > > Key: ISIS-1945 > URL: https://issues.apache.org/jira/browse/ISIS-1945 > Project: Isis > Issue Type: Improvement > Components: Core: Viewer: Wicket >Reporter: Andi Huber >Assignee: Andi Huber >Priority: Major > Fix For: 2.0.0 > > > Could be realized doing specific CSS class expression. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ISIS-1960) Action background execution: provide built-in default implementation
[
https://issues.apache.org/jira/browse/ISIS-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andi Huber updated ISIS-1960:
-
Fix Version/s: (was: 2.0.0-M2)
2.0.0
> Action background execution: provide built-in default implementation
>
>
> Key: ISIS-1960
> URL: https://issues.apache.org/jira/browse/ISIS-1960
> Project: Isis
> Issue Type: Improvement
> Components: Core
>Reporter: Andi Huber
>Assignee: Andi Huber
>Priority: Major
> Fix For: 2.0.0
>
>
> We want this code to run out-of the box (without the need for developers to
> provide their own implementation of *BackgroundCommandService*) ...
> {code:java}
> @Inject BackgroundService backgroundService;
> @Inject RepositoryService repositoryService;
> @Inject MessageService messageService;
> @Action
> public SimpleObject runInBackground(){
> backgroundService.execute(this).backgroundTask();
> return this;
> }
>
> @Programmatic
> public void backgroundTask(){
> messageService.informUser("backgroundTask started");
> try {
> Thread.sleep(8000); // wait 8s
> } catch (InterruptedException e) {
> e.printStackTrace();
> }
>
> val dummy = new SimpleObject();
> dummy.setName("Dummy");
>
> repositoryService.persist(dummy);
>
> messageService.informUser("backgroundTask finished");
> }
> {code}
> We solve this using a default ExecutorService to run Action invocations in
> the background.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ISIS-1599) "Set" interface does not work as an action parameter's collection type
[
https://issues.apache.org/jira/browse/ISIS-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andi Huber updated ISIS-1599:
-
Fix Version/s: (was: 2.0.0-M2)
2.0.0
> "Set" interface does not work as an action parameter's collection type
> ---
>
> Key: ISIS-1599
> URL: https://issues.apache.org/jira/browse/ISIS-1599
> Project: Isis
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.14.0
>Reporter: Tadas Giniotis
>Assignee: Andi Huber
>Priority: Minor
> Fix For: 2.0.0
>
>
> When using a Set as a parameter for an action -> it throws an
> exception when using that action. The same works correctly when using
> List.
> {quote}
> ...
> java.lang.IllegalArgumentException
> argument type mismatch
> sun.reflect.NativeMethodAccessorImpl#invoke0(null:-2)
> sun.reflect.NativeMethodAccessorImpl#invoke(null:-1)
> sun.reflect.DelegatingMethodAccessorImpl#invoke(null:-1)
> java.lang.reflect.Method#invoke(null:-1)
> org.apache.isis.core.metamodel.facets.actions.action.invocation.ActionInvocationFacetForDomainEventAbstract#invokeMethodElseFromCache(ActionInvocationFacetForDomainEventAbstract.java:408)
> org.apache.isis.core.metamodel.facets.actions.action.invocation.ActionInvocationFacetForDomainEventAbstract$2#execute(ActionInvocationFacetForDomainEventAbstract.java:262)
> org.apache.isis.core.metamodel.facets.actions.action.invocation.ActionInvocationFacetForDomainEventAbstract$2#execute(ActionInvocationFacetForDomainEventAbstract.java:223)
> org.apache.isis.applib.services.iactn.Interaction#executeInternal(Interaction.java:173)
> org.apache.isis.applib.services.iactn.Interaction#execute(Interaction.java:143)
>
> ...
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ISIS-2006) reimplementing a JAX-RS 2.0 restful client for Isis from scratch
[ https://issues.apache.org/jira/browse/ISIS-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andi Huber updated ISIS-2006: - Fix Version/s: (was: 2.0.0-M2) 2.0.0 > reimplementing a JAX-RS 2.0 restful client for Isis from scratch > > > Key: ISIS-2006 > URL: https://issues.apache.org/jira/browse/ISIS-2006 > Project: Isis > Issue Type: Improvement > Components: Core >Reporter: Andi Huber >Assignee: Andi Huber >Priority: Major > Fix For: 2.0.0 > > > Proposed to be a first class citizen living in core-applib, without > introducing any new maven dependencies by just conforming to the JAX-RS 2.0 > standard. > Also provides > - support for basic-auth > - support for async requests > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ISIS-2031) Using 'show all' on tables does take longer than expected
[ https://issues.apache.org/jira/browse/ISIS-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andi Huber updated ISIS-2031: - Issue Type: Improvement (was: Bug) > Using 'show all' on tables does take longer than expected > - > > Key: ISIS-2031 > URL: https://issues.apache.org/jira/browse/ISIS-2031 > Project: Isis > Issue Type: Improvement > Components: Core: Viewer: Wicket >Reporter: Andi Huber >Assignee: Andi Huber >Priority: Minor > Fix For: 2.0.0 > > > When fetching and displaying 25 objects (rendering a table) takes 1s, then > the same with 100 objects should take about 4s, but it takes way longer. > This is strange. I also noticed, that after having fetched all objects from > the DB, the viewer is still occupied with rendering, showing the long-running > indicator. > This needs some investigation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ISIS-2031) Using 'show all' on tables does take longer than expected
[ https://issues.apache.org/jira/browse/ISIS-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andi Huber updated ISIS-2031: - Fix Version/s: (was: 2.0.0-M2) 2.0.0 > Using 'show all' on tables does take longer than expected > - > > Key: ISIS-2031 > URL: https://issues.apache.org/jira/browse/ISIS-2031 > Project: Isis > Issue Type: Improvement > Components: Core: Viewer: Wicket >Reporter: Andi Huber >Assignee: Andi Huber >Priority: Minor > Fix For: 2.0.0 > > > When fetching and displaying 25 objects (rendering a table) takes 1s, then > the same with 100 objects should take about 4s, but it takes way longer. > This is strange. I also noticed, that after having fetched all objects from > the DB, the viewer is still occupied with rendering, showing the long-running > indicator. > This needs some investigation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
