Re: [RESULT] [VOTE] Apache Isis Core release 1.8.0
Hi all. My testimonial +1. I've not been able to test the released artifacts but we've been working in production with this release the last weeks with success. Great job to all. > El 23/2/2015, a las 22:42, Dan Haywood > escribió: > > The vote has completed with the following result : > > +4 (binding): Kevin Meyer, Martin Grigorov, Dan Haywood, Jeroen van der > Wal > +1 (non binding): Vladimir Nisevic > > The vote is SUCCESSFUL. > > Thanks to all who voted.
[jira] [Resolved] (ISIS-928) Isis 1.8.0 release tasks
[ https://issues.apache.org/jira/browse/ISIS-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Haywood resolved ISIS-928. -- Resolution: Fixed > Isis 1.8.0 release tasks > > > Key: ISIS-928 > URL: https://issues.apache.org/jira/browse/ISIS-928 > Project: Isis > Issue Type: Task > Components: Core, Core: Viewer: Wicket >Affects Versions: archetype-todoapp-1.7.0, archetype-simpleapp-1.7.0, > viewer-wicket-1.7.0, core-1.7.0 >Reporter: Dan Haywood >Assignee: Dan Haywood >Priority: Minor > Fix For: archetype-1.8.0, core-1.8.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[RESULT] [VOTE] Apache Isis Core release 1.8.0
The vote has completed with the following result : +4 (binding): Kevin Meyer, Martin Grigorov, Dan Haywood, Jeroen van der Wal +1 (non binding): Vladimir Nisevic The vote is SUCCESSFUL. Thanks to all who voted.
Re: [VOTE] Apache Isis Core release 1.8.0 RC1
ok, 72 hours have passed so I'm closing this vote. I'll post the result on a separate thread. Thanks all Dan On 23 February 2015 at 11:44, Vladimir Nišević wrote: > +1 > > Best regards > Vladimir > > > > Am 23.02.2015 um 08:15 schrieb Dan Haywood >: > > > > My own +1 > > > >> On 22 February 2015 at 21:38, Martin Grigorov > wrote: > >> > >> +1 to release > >> > >> Tested building Isis from source (+ verifying signatures) and with > >> downloading from the Maven repo. > >> Everything looks fine with the application I'm working on. > >> > >> Martin Grigorov > >> Wicket Training and Consulting > >> https://twitter.com/mtgrigorov > >> > >> On Fri, Feb 20, 2015 at 11:09 PM, Dan Haywood < > >> d...@haywood-associates.co.uk> > >> wrote: > >> > >>> Hi folks, > >>> > >>> I've cut a release for Apache Isis Core and the simpleapp archetype: > >>> * Core 1.8.0 > >>> * SimpleApp Archetype 1.8.0 > >>> > >>> Note that the Wicket viewer is now part of Core, and that the ToDoApp > >>> archetype has been retired (replaced by an example app on Isis addons, > >>> outside of ASF). > >>> > >>> The source code artifacts have been uploaded to a staging repository on > >>> repository.apache.org: > >> > http://repository.apache.org/content/repositories/orgapacheisis-1032/org/apache/isis/core/isis/1.8.0/isis-1.8.0-source-release.zip > >> > http://repository.apache.org/content/repositories/orgapacheisis-1032/org/apache/isis/archetype/simpleapp-archetype/1.8.0/simpleapp-archetype-1.8.0-source-release.zip > >>> > >>> For each zip there is a corresponding signature file (append .asc to > the > >>> zip's url). > >>> > >>> In the source code repo the code has been tagged as isis-1.8.0-RC1 and > >>> simpleapp-archetype-1.8.0-RC1. > >>> > >>> For instructions on how to verify the release (build from binaries > and/or > >>> use in Maven directly), see > >>> http://isis.apache.org/contributors/verifying-releases.html > >>> > >>> Please verify the release and cast your vote. The vote will be open > for > >> a > >>> minimum of 72 hours. > >>> > >>> [ ] +1 > >>> [ ] 0 > >>> [ ] -1 > >>> > >>> Thanks > >>> Dan > >> >
[jira] [Comment Edited] (ISIS-1050) Reflection VFS related issues in jetty-console
[ https://issues.apache.org/jira/browse/ISIS-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14333227#comment-14333227 ] Dan Haywood edited comment on ISIS-1050 at 2/23/15 12:31 PM: - My suspicion is the latter. It's a bit annoying, cos we had, for a while there at least, got rid of these stacktraces. Perhaps a 1.8.1 release might be in order... was (Author: danhaywood): My suspicion is the latter. It's a bit annoying, cos we have, for a while there at least, got rid of these stacktraces. Perhaps a 1.8.1 release might be in order... > Reflection VFS related issues in jetty-console > -- > > Key: ISIS-1050 > URL: https://issues.apache.org/jira/browse/ISIS-1050 > Project: Isis > Issue Type: Bug > Components: Core >Affects Versions: core-1.8.0 >Reporter: Martin Grigorov >Assignee: Dan Haywood >Priority: Minor > > Just tried java -jar .../simpleapp-...-jetty-console.jar and it logs several > VFS related stacktraces: > java.io.FileNotFoundException: > /tmp/simpleapp-webapp-1.8.0-SNAPSHOT-jetty-console.jar_8080/webapp/WEB-INF/classes > (Is a directory) > at java.util.zip.ZipFile.open(Native Method) > at java.util.zip.ZipFile.(ZipFile.java:215) > at java.util.zip.ZipFile.(ZipFile.java:145) > at java.util.jar.JarFile.(JarFile.java:154) > at java.util.jar.JarFile.(JarFile.java:118) > at org.reflections.vfs.Vfs$DefaultUrlTypes$1.createDir(Vfs.java:207) > at org.reflections.vfs.Vfs.fromURL(Vfs.java:98) > at org.reflections.vfs.Vfs.fromURL(Vfs.java:90) > at org.reflections.Reflections.scan(Reflections.java:236) > at org.reflections.Reflections.scan(Reflections.java:203) > at org.reflections.Reflections.(Reflections.java:128) > at org.reflections.Reflections.(Reflections.java:169) > at > org.apache.isis.applib.services.classdiscovery.ClassDiscoveryServiceUsingReflections.findSubTypesOfClasses(ClassDiscoveryServiceUsingReflections.java:76) > at > org.apache.isis.applib.fixturescripts.FixtureScripts.findSubTypesOfClasses(FixtureScripts.java:226) > > and > ava.lang.NoClassDefFoundError: org/apache/commons/vfs2/VFS > at org.reflections.vfs.Vfs$DefaultUrlTypes$7.matches(Vfs.java:281) > at org.reflections.vfs.Vfs.fromURL(Vfs.java:97) > at org.reflections.vfs.Vfs.fromURL(Vfs.java:90) > at org.reflections.Reflections.scan(Reflections.java:236) > at org.reflections.Reflections.scan(Reflections.java:203) > at org.reflections.Reflections.(Reflections.java:128) > at org.reflections.Reflections.(Reflections.java:169) > at org.reflections.Reflections.(Reflections.java:142) > at > org.apache.isis.objectstore.jdo.service.RegisterEntities.registerAllPersistenceCapables(RegisterEntities.java:67) > It seems they are harmless. The application seems to run fine. > The problem could be related to the recent upgrade of Reflections to 0.9.9 > and/or jetty-console-maven-plugin to 1.56. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Apache Isis Core release 1.8.0 RC1
+1 Best regards Vladimir > Am 23.02.2015 um 08:15 schrieb Dan Haywood : > > My own +1 > >> On 22 February 2015 at 21:38, Martin Grigorov wrote: >> >> +1 to release >> >> Tested building Isis from source (+ verifying signatures) and with >> downloading from the Maven repo. >> Everything looks fine with the application I'm working on. >> >> Martin Grigorov >> Wicket Training and Consulting >> https://twitter.com/mtgrigorov >> >> On Fri, Feb 20, 2015 at 11:09 PM, Dan Haywood < >> d...@haywood-associates.co.uk> >> wrote: >> >>> Hi folks, >>> >>> I've cut a release for Apache Isis Core and the simpleapp archetype: >>> * Core 1.8.0 >>> * SimpleApp Archetype 1.8.0 >>> >>> Note that the Wicket viewer is now part of Core, and that the ToDoApp >>> archetype has been retired (replaced by an example app on Isis addons, >>> outside of ASF). >>> >>> The source code artifacts have been uploaded to a staging repository on >>> repository.apache.org: >> http://repository.apache.org/content/repositories/orgapacheisis-1032/org/apache/isis/core/isis/1.8.0/isis-1.8.0-source-release.zip >> http://repository.apache.org/content/repositories/orgapacheisis-1032/org/apache/isis/archetype/simpleapp-archetype/1.8.0/simpleapp-archetype-1.8.0-source-release.zip >>> >>> For each zip there is a corresponding signature file (append .asc to the >>> zip's url). >>> >>> In the source code repo the code has been tagged as isis-1.8.0-RC1 and >>> simpleapp-archetype-1.8.0-RC1. >>> >>> For instructions on how to verify the release (build from binaries and/or >>> use in Maven directly), see >>> http://isis.apache.org/contributors/verifying-releases.html >>> >>> Please verify the release and cast your vote. The vote will be open for >> a >>> minimum of 72 hours. >>> >>> [ ] +1 >>> [ ] 0 >>> [ ] -1 >>> >>> Thanks >>> Dan >>
[jira] [Commented] (ISIS-1050) Reflection VFS related issues in jetty-console
[ https://issues.apache.org/jira/browse/ISIS-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14333239#comment-14333239 ] Jeroen van der Wal commented on ISIS-1050: -- I'm not sure if the Jetty console has ever been free from these stacktraces, I only use it when testing a release. Anyway, the harmless nature doesn't justify cutting a release just for this. > Reflection VFS related issues in jetty-console > -- > > Key: ISIS-1050 > URL: https://issues.apache.org/jira/browse/ISIS-1050 > Project: Isis > Issue Type: Bug > Components: Core >Affects Versions: core-1.8.0 >Reporter: Martin Grigorov >Assignee: Dan Haywood >Priority: Minor > > Just tried java -jar .../simpleapp-...-jetty-console.jar and it logs several > VFS related stacktraces: > java.io.FileNotFoundException: > /tmp/simpleapp-webapp-1.8.0-SNAPSHOT-jetty-console.jar_8080/webapp/WEB-INF/classes > (Is a directory) > at java.util.zip.ZipFile.open(Native Method) > at java.util.zip.ZipFile.(ZipFile.java:215) > at java.util.zip.ZipFile.(ZipFile.java:145) > at java.util.jar.JarFile.(JarFile.java:154) > at java.util.jar.JarFile.(JarFile.java:118) > at org.reflections.vfs.Vfs$DefaultUrlTypes$1.createDir(Vfs.java:207) > at org.reflections.vfs.Vfs.fromURL(Vfs.java:98) > at org.reflections.vfs.Vfs.fromURL(Vfs.java:90) > at org.reflections.Reflections.scan(Reflections.java:236) > at org.reflections.Reflections.scan(Reflections.java:203) > at org.reflections.Reflections.(Reflections.java:128) > at org.reflections.Reflections.(Reflections.java:169) > at > org.apache.isis.applib.services.classdiscovery.ClassDiscoveryServiceUsingReflections.findSubTypesOfClasses(ClassDiscoveryServiceUsingReflections.java:76) > at > org.apache.isis.applib.fixturescripts.FixtureScripts.findSubTypesOfClasses(FixtureScripts.java:226) > > and > ava.lang.NoClassDefFoundError: org/apache/commons/vfs2/VFS > at org.reflections.vfs.Vfs$DefaultUrlTypes$7.matches(Vfs.java:281) > at org.reflections.vfs.Vfs.fromURL(Vfs.java:97) > at org.reflections.vfs.Vfs.fromURL(Vfs.java:90) > at org.reflections.Reflections.scan(Reflections.java:236) > at org.reflections.Reflections.scan(Reflections.java:203) > at org.reflections.Reflections.(Reflections.java:128) > at org.reflections.Reflections.(Reflections.java:169) > at org.reflections.Reflections.(Reflections.java:142) > at > org.apache.isis.objectstore.jdo.service.RegisterEntities.registerAllPersistenceCapables(RegisterEntities.java:67) > It seems they are harmless. The application seems to run fine. > The problem could be related to the recent upgrade of Reflections to 0.9.9 > and/or jetty-console-maven-plugin to 1.56. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Experience with upgrade our application to 1.8.0-SNAPSHOT
OK, cool, good to hear. Feel free to vote on the 1.8.0 release if you wish; it's always nice to have participation in votes from the wider community than just the committers. Cheers Dan On 23 February 2015 at 11:26, Vladimir Nišević wrote: > Hi Dan, thank you for your answer and hint. After I made cleanup of my > local maven repository, it all works fine! > > Seems not to be any show-stopper at the moment. > > Regs,Vladimir > > 2015-02-20 18:14 GMT+01:00 Dan Haywood : > > > Hi Vladimir, > > > > Thanks for this feedback. > > > > We did have an issue with this a few days ago, I had made a silly error > and > > was corrupting the list of packages to go searching for services. So you > > might just have picked up this bad version. > > > > Otherwise, I'm actually cutting the 1.8.0 release right now. Given > there's > > been so much work done in it, I'm sure that there will be a few bugs > still > > lurking; but for ourselves we're in production right now on a cut from > > 1.8.0-SNAPSHOT, so we think it's reasonably stable. > > > > Let us know if you know of anything you consider a show-stopper, however. > > > > Thx > > Dan > > > > ~ > > > > On 20 February 2015 at 10:37, Vladimir Nišević > wrote: > > > > > Hi guys, first of all, great work in the upcoming version! > > > > > > We are currently using 1.7.0 in production and planning to upgrade to > > > 1.8.0 - since it solves some othes our issues . > > > > > > Here some first experience we've made with 1.8.0-SNAPSHOT. My approach > is > > > usually to checkout the latest simpleapp, run it locally based on that > > > experience adapt e.g. maven dependencies, new settings in our > application > > > that works with 1.7.0 > > > We also use simpleapp when trying to reproduce our issues. > > > > > > First experience I've made when launching the naked simpleapp-webapp > > using > > > eclipse IDE with provided .launch config, is that isis does not > recognize > > > any persistent classes and I get next error > > > > > > > > > ISIS METAMODEL > > VALIDATION > > > ERRORS > > > > > > No @PersistenceCapable entities found. (Are the entities referenced by > > the > > > registered services? are all services registered? did the DataNucleus > > > enhancer run?) > > > > > > Please inspect the above messages and correct your domain model. > > > > > > ISIS METAMODEL > > VALIDATION > > > ERRORS > > > > > > Datanucleus enhancer seems to work see attached log > > > > > > > > > We found a workaround, when adapting isis.properties and putting > > > explicitly the > > > > > > isis.services = dom.simple.SimpleObjects,\ > > > > > > then it works. > > > > > > Trying out with IDEA (the latest one), it works fine without any > > > adaptations, but my team is currently using eclipse. > > > > > > I have some more issues, would come with them if we stuck... > > > > > > Regs,Vladimir > > > > > >
[jira] [Commented] (ISIS-1050) Reflection VFS related issues in jetty-console
[ https://issues.apache.org/jira/browse/ISIS-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14333227#comment-14333227 ] Dan Haywood commented on ISIS-1050: --- My suspicion is the latter. It's a bit annoying, cos we have, for a while there at least, got rid of these stacktraces. Perhaps a 1.8.1 release might be in order... > Reflection VFS related issues in jetty-console > -- > > Key: ISIS-1050 > URL: https://issues.apache.org/jira/browse/ISIS-1050 > Project: Isis > Issue Type: Bug > Components: Core >Affects Versions: core-1.8.0 >Reporter: Martin Grigorov >Assignee: Dan Haywood >Priority: Minor > > Just tried java -jar .../simpleapp-...-jetty-console.jar and it logs several > VFS related stacktraces: > java.io.FileNotFoundException: > /tmp/simpleapp-webapp-1.8.0-SNAPSHOT-jetty-console.jar_8080/webapp/WEB-INF/classes > (Is a directory) > at java.util.zip.ZipFile.open(Native Method) > at java.util.zip.ZipFile.(ZipFile.java:215) > at java.util.zip.ZipFile.(ZipFile.java:145) > at java.util.jar.JarFile.(JarFile.java:154) > at java.util.jar.JarFile.(JarFile.java:118) > at org.reflections.vfs.Vfs$DefaultUrlTypes$1.createDir(Vfs.java:207) > at org.reflections.vfs.Vfs.fromURL(Vfs.java:98) > at org.reflections.vfs.Vfs.fromURL(Vfs.java:90) > at org.reflections.Reflections.scan(Reflections.java:236) > at org.reflections.Reflections.scan(Reflections.java:203) > at org.reflections.Reflections.(Reflections.java:128) > at org.reflections.Reflections.(Reflections.java:169) > at > org.apache.isis.applib.services.classdiscovery.ClassDiscoveryServiceUsingReflections.findSubTypesOfClasses(ClassDiscoveryServiceUsingReflections.java:76) > at > org.apache.isis.applib.fixturescripts.FixtureScripts.findSubTypesOfClasses(FixtureScripts.java:226) > > and > ava.lang.NoClassDefFoundError: org/apache/commons/vfs2/VFS > at org.reflections.vfs.Vfs$DefaultUrlTypes$7.matches(Vfs.java:281) > at org.reflections.vfs.Vfs.fromURL(Vfs.java:97) > at org.reflections.vfs.Vfs.fromURL(Vfs.java:90) > at org.reflections.Reflections.scan(Reflections.java:236) > at org.reflections.Reflections.scan(Reflections.java:203) > at org.reflections.Reflections.(Reflections.java:128) > at org.reflections.Reflections.(Reflections.java:169) > at org.reflections.Reflections.(Reflections.java:142) > at > org.apache.isis.objectstore.jdo.service.RegisterEntities.registerAllPersistenceCapables(RegisterEntities.java:67) > It seems they are harmless. The application seems to run fine. > The problem could be related to the recent upgrade of Reflections to 0.9.9 > and/or jetty-console-maven-plugin to 1.56. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Experience with upgrade our application to 1.8.0-SNAPSHOT
Hi Dan, thank you for your answer and hint. After I made cleanup of my local maven repository, it all works fine! Seems not to be any show-stopper at the moment. Regs,Vladimir 2015-02-20 18:14 GMT+01:00 Dan Haywood : > Hi Vladimir, > > Thanks for this feedback. > > We did have an issue with this a few days ago, I had made a silly error and > was corrupting the list of packages to go searching for services. So you > might just have picked up this bad version. > > Otherwise, I'm actually cutting the 1.8.0 release right now. Given there's > been so much work done in it, I'm sure that there will be a few bugs still > lurking; but for ourselves we're in production right now on a cut from > 1.8.0-SNAPSHOT, so we think it's reasonably stable. > > Let us know if you know of anything you consider a show-stopper, however. > > Thx > Dan > > ~ > > On 20 February 2015 at 10:37, Vladimir Nišević wrote: > > > Hi guys, first of all, great work in the upcoming version! > > > > We are currently using 1.7.0 in production and planning to upgrade to > > 1.8.0 - since it solves some othes our issues . > > > > Here some first experience we've made with 1.8.0-SNAPSHOT. My approach is > > usually to checkout the latest simpleapp, run it locally based on that > > experience adapt e.g. maven dependencies, new settings in our application > > that works with 1.7.0 > > We also use simpleapp when trying to reproduce our issues. > > > > First experience I've made when launching the naked simpleapp-webapp > using > > eclipse IDE with provided .launch config, is that isis does not recognize > > any persistent classes and I get next error > > > > > > ISIS METAMODEL > VALIDATION > > ERRORS > > > > No @PersistenceCapable entities found. (Are the entities referenced by > the > > registered services? are all services registered? did the DataNucleus > > enhancer run?) > > > > Please inspect the above messages and correct your domain model. > > > > ISIS METAMODEL > VALIDATION > > ERRORS > > > > Datanucleus enhancer seems to work see attached log > > > > > > We found a workaround, when adapting isis.properties and putting > > explicitly the > > > > isis.services = dom.simple.SimpleObjects,\ > > > > then it works. > > > > Trying out with IDEA (the latest one), it works fine without any > > adaptations, but my team is currently using eclipse. > > > > I have some more issues, would come with them if we stuck... > > > > Regs,Vladimir > > >
Re: [VOTE] Apache Isis Core release 1.8.0 RC1
Here's my +1 One side note: the archetype shows some (harmless) reflection errors in the Jetty console, already documented in ISIS-1050 [1] [1] https://issues.apache.org/jira/browse/ISIS-1050
[jira] [Commented] (ISIS-1045) New domain events are created for each phase for properties, but not for collections nor actions. The current design doesn't support use of the wrapper factory.
[ https://issues.apache.org/jira/browse/ISIS-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14333153#comment-14333153 ] Oscar Bou commented on ISIS-1045: - COMMENTS FOR GUAVA EVENT BUS The per-thread queueing behavior is irrespective of using the EventBus or the AsyncEventBus implementation. Notice on [1] the definition of the queue. And on [2] the logic of the "dispatch" method, that originates the problem, as it will introduce different behavior depending on its internal state when a new Event is posted to be dispatched: - If it's currently dispatching a previously posted Event, it will queue it, so its event handlers will be invoked after previously invoking all event handlers of this previous event. - If it's not currently dispatching any other Event, it will instead invoke all its event handlers immediately. I've just noticed on [3] the availability of an "immediate" Service Bus, whose comment is that it will not queue Events. So perhaps this could be a simpler solution. But not sure if the ServiceBus can be configured to use this Dispatcher instead of the "queue" one ... Perhaps simply creating a custom EventBus inheriting from the current one, which overrides the Dispatcher configured at [4]? Look there how it currently instantiates the "queuePerThread" dispatcher ... [1] https://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/eventbus/Dispatcher.java#87 [2] https://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/eventbus/Dispatcher.java#96 [3] https://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/eventbus/Dispatcher.java#63 [4] https://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/eventbus/EventBus.java#119 > New domain events are created for each phase for properties, but not for > collections nor actions. The current design doesn't support use of the > wrapper factory. > - > > Key: ISIS-1045 > URL: https://issues.apache.org/jira/browse/ISIS-1045 > Project: Isis > Issue Type: Improvement > Components: Core >Affects Versions: core-1.7.0 >Reporter: Dan Haywood >Assignee: Dan Haywood >Priority: Minor > Fix For: core-1.9.0 > > > In the domain events design we have 5 phases: > hide/disable/validate/pre-execute/post-execute. The framework attempts to > reuse the same event where possible > for actions: > - for hide, always creates new event > - for disable, always creates new event > - for validate, always creates new event, puts onto thread-local > - for pre-execute, uses the event from validate (obtain from thread-local) > - for post-execute, uses the event from pre-execute (passed as local var). > for collections: > - ditto > but for properties, although we originally had the same algorithm, this was > changed (patch from Oscar) to: > - for hide, always creates new event > - for disable, always creates new event > - for validate, always creates new event, puts onto thread-local > - for pre-execute, always creates a new event (ignores that on thread-local) > - for post-execute, uses the event from pre-execute (passed as local var). > The reason that Oscar needed this change was because the framework does not > anticipate there being more than one "pending" interaction. However, if the > wrapper factory is used, then this assumption isn't true, because validateX() > -> wrap -> validateY(). > This use case actually needs a stack of pending interaction events to support > this change. > As things stand: > * the getUserData() functionality is broken for property domain events > * the underlying problem remains for actions -> actions using the wrapper > factory during the validate phase. > There is also a suggestion that the Guava event bus might be an issue in that > it buffers changes; I'm not exactly sure what this means (we don't use the > async guava bus), and I don't know if its behaviour is significant or not. > But in any case, the above design defect is an issue irrespective and which > needs addressing; once that's fixed then we can look at the Guava event bus > to decide if it is also a problem for us or not. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (ISIS-1045) New domain events are created for each phase for properties, but not for collections nor actions. The current design doesn't support use of the wrapper factory.
[ https://issues.apache.org/jira/browse/ISIS-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14333136#comment-14333136 ] Oscar Bou edited comment on ISIS-1045 at 2/23/15 9:29 AM: -- I agree this is irrespective of Guava's queueing behavior. But please don't revert patch for having access to user data without supporting multiple actions executed through the wrapper factory. My production system works ok because we are not using the Isis provided Guava Event Bus for dispatching "nested" events. We've implemented another Event Bus based on Axon (simpler implementation than the one provided on the patch, as we only needed to support our own dispatched Events). Basically we currently use the Isis Event Bus for Isis infra. supported domain events, but the Axon based one for our own domain events. That way, for example, in response to an element removed from a collection (notified via Apache Isis Guava-based Event Bus) we dispatch a new Event over our custom Axon-based Event Bus that invokes immediately all Event Handlers, without queueing their calls. was (Author: obou): I agree this is irrespective of Guava's queueing behavior (Commented in another ticket). But please don't revert patch for having access to user data without supporting multiple actions executed through the wrapper factory. > New domain events are created for each phase for properties, but not for > collections nor actions. The current design doesn't support use of the > wrapper factory. > - > > Key: ISIS-1045 > URL: https://issues.apache.org/jira/browse/ISIS-1045 > Project: Isis > Issue Type: Improvement > Components: Core >Affects Versions: core-1.7.0 >Reporter: Dan Haywood >Assignee: Dan Haywood >Priority: Minor > Fix For: core-1.9.0 > > > In the domain events design we have 5 phases: > hide/disable/validate/pre-execute/post-execute. The framework attempts to > reuse the same event where possible > for actions: > - for hide, always creates new event > - for disable, always creates new event > - for validate, always creates new event, puts onto thread-local > - for pre-execute, uses the event from validate (obtain from thread-local) > - for post-execute, uses the event from pre-execute (passed as local var). > for collections: > - ditto > but for properties, although we originally had the same algorithm, this was > changed (patch from Oscar) to: > - for hide, always creates new event > - for disable, always creates new event > - for validate, always creates new event, puts onto thread-local > - for pre-execute, always creates a new event (ignores that on thread-local) > - for post-execute, uses the event from pre-execute (passed as local var). > The reason that Oscar needed this change was because the framework does not > anticipate there being more than one "pending" interaction. However, if the > wrapper factory is used, then this assumption isn't true, because validateX() > -> wrap -> validateY(). > This use case actually needs a stack of pending interaction events to support > this change. > As things stand: > * the getUserData() functionality is broken for property domain events > * the underlying problem remains for actions -> actions using the wrapper > factory during the validate phase. > There is also a suggestion that the Guava event bus might be an issue in that > it buffers changes; I'm not exactly sure what this means (we don't use the > async guava bus), and I don't know if its behaviour is significant or not. > But in any case, the above design defect is an issue irrespective and which > needs addressing; once that's fixed then we can look at the Guava event bus > to decide if it is also a problem for us or not. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ISIS-1045) New domain events are created for each phase for properties, but not for collections nor actions. The current design doesn't support use of the wrapper factory.
[ https://issues.apache.org/jira/browse/ISIS-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14333136#comment-14333136 ] Oscar Bou commented on ISIS-1045: - I agree this is irrespective of Guava's queueing behavior (Commented in another ticket). But please don't revert patch for having access to user data without supporting multiple actions executed through the wrapper factory. > New domain events are created for each phase for properties, but not for > collections nor actions. The current design doesn't support use of the > wrapper factory. > - > > Key: ISIS-1045 > URL: https://issues.apache.org/jira/browse/ISIS-1045 > Project: Isis > Issue Type: Improvement > Components: Core >Affects Versions: core-1.7.0 >Reporter: Dan Haywood >Assignee: Dan Haywood >Priority: Minor > Fix For: core-1.9.0 > > > In the domain events design we have 5 phases: > hide/disable/validate/pre-execute/post-execute. The framework attempts to > reuse the same event where possible > for actions: > - for hide, always creates new event > - for disable, always creates new event > - for validate, always creates new event, puts onto thread-local > - for pre-execute, uses the event from validate (obtain from thread-local) > - for post-execute, uses the event from pre-execute (passed as local var). > for collections: > - ditto > but for properties, although we originally had the same algorithm, this was > changed (patch from Oscar) to: > - for hide, always creates new event > - for disable, always creates new event > - for validate, always creates new event, puts onto thread-local > - for pre-execute, always creates a new event (ignores that on thread-local) > - for post-execute, uses the event from pre-execute (passed as local var). > The reason that Oscar needed this change was because the framework does not > anticipate there being more than one "pending" interaction. However, if the > wrapper factory is used, then this assumption isn't true, because validateX() > -> wrap -> validateY(). > This use case actually needs a stack of pending interaction events to support > this change. > As things stand: > * the getUserData() functionality is broken for property domain events > * the underlying problem remains for actions -> actions using the wrapper > factory during the validate phase. > There is also a suggestion that the Guava event bus might be an issue in that > it buffers changes; I'm not exactly sure what this means (we don't use the > async guava bus), and I don't know if its behaviour is significant or not. > But in any case, the above design defect is an issue irrespective and which > needs addressing; once that's fixed then we can look at the Guava event bus > to decide if it is also a problem for us or not. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
