[jira] [Commented] (ISIS-3175) Cheatsheet: Verify documented Parameter as Tuple Example works
[ https://issues.apache.org/jira/browse/ISIS-3175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17584934#comment-17584934 ] Brian Kalbfus commented on ISIS-3175: - I reproduced issue with `autoCompleteXxx(Parameters params, String search)` at [https://github.com/bkalbfus/isis-app-helloworld/tree/release-2.0.0-M8-RC1-jdo] > Cheatsheet: Verify documented Parameter as Tuple Example works > -- > > Key: ISIS-3175 > URL: https://issues.apache.org/jira/browse/ISIS-3175 > Project: Isis > Issue Type: Documentation > Components: Isis Docs Website >Reporter: Andi Huber >Assignee: Andi Huber >Priority: Major > Fix For: 2.0.0-M8 > > > Brian: > Meanwhile, I was following the M7 cheat sheet for contributed actions with > static Parameters class. The choicesXxx() method works but not the > autoCompleteXxx() one. [...] it'd be good to ensure that code that follows > the last page of the cheat sheet is intact. For one thing, I needed to add > @Programmatic to the Parameters class to get past metamodel validation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ISIS-2990) Clean build and run displays ClassNotFoundException: com.sun.xml.bind.v2.ContextFactory
[ https://issues.apache.org/jira/browse/ISIS-2990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Kalbfus updated ISIS-2990: Description: I cloned the isis-app-simpleapp repository, switched to JDO branch, built project, and ran via the 'target/simpleapp-jdo-webapp-2.0.0-M7-exec.jar' command. Same result for JPA branch. Error on console: ``` java.lang.RuntimeException: unrecoverable error: 'Error obtaining JAXBContext for class; object class is 'org.apache.isis.schema.cmd.v2.CommandDto'' with cause ... at org.apache.isis.commons.internal.exceptions._Exceptions.unrecoverable(_Exceptions.java:144) ~[isis-commons-2.0.0-M7.jar!/:2.0.0-M7] at org.apache.isis.commons.internal.resources._Xml.verboseException(_Xml.java:201) ~[isis-commons-2.0.0-M7.jar!/:2.0.0-M7] at org.apache.isis.commons.internal.resources._Xml.contextOf(_Xml.java:226) ~[isis-commons-2.0.0-M7.jar!/:2.0.0-M7] at java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1705) ~[?:?] at org.apache.isis.commons.internal.resources._Xml.jaxbContextFor(_Xml.java:217) ~[isis-commons-2.0.0-M7.jar!/:2.0.0-M7] at org.apache.isis.applib.util.JaxbUtil.jaxbContextFor(JaxbUtil.java:111) ~[isis-applib-2.0.0-M7.jar!/:2.0.0-M7] at org.apache.isis.applib.util.schema.CommandDtoUtils.getJaxbContext(CommandDtoUtils.java:57) ~[isis-applib-2.0.0-M7.jar!/:2.0.0-M7] at org.apache.isis.applib.util.schema.CommandDtoUtils.init(CommandDtoUtils.java:50) ~[isis-applib-2.0.0-M7.jar!/:2.0.0-M7] at org.apache.isis.commons.internal.concurrent._ConcurrentTask$3.innerCall(_ConcurrentTask.java:150) ~[isis-commons-2.0.0-M7.jar!/:2.0.0-M7] at org.apache.isis.commons.internal.concurrent._ConcurrentTask$3.innerCall(_ConcurrentTask.java:146) ~[isis-commons-2.0.0-M7.jar!/:2.0.0-M7] at org.apache.isis.commons.internal.concurrent._ConcurrentTask$1.innerCall(_ConcurrentTask.java:109) ~[isis-commons-2.0.0-M7.jar!/:2.0.0-M7] at org.apache.isis.commons.internal.concurrent._ConcurrentTask.run(_ConcurrentTask.java:86) ~[isis-commons-2.0.0-M7.jar!/:2.0.0-M7] at java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec(ForkJoinTask.java:1406) ~[?:?] at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290) ~[?:?] at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1016) ~[?:?] at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1665) ~[?:?] at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1598) ~[?:?] at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177) ~[?:?] Caused by: javax.xml.bind.JAXBException: Implementation of JAXB-API has not been found on module path or classpath. at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:232) ~[jakarta.xml.bind-api-2.3.3.jar!/:2.3.3] at javax.xml.bind.ContextFinder.find(ContextFinder.java:375) ~[jakarta.xml.bind-api-2.3.3.jar!/:2.3.3] at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:691) ~[jakarta.xml.bind-api-2.3.3.jar!/:2.3.3] at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:632) ~[jakarta.xml.bind-api-2.3.3.jar!/:2.3.3] at org.apache.isis.commons.internal.resources._Xml.contextOf(_Xml.java:224) ~[isis-commons-2.0.0-M7.jar!/:2.0.0-M7] ... 15 more Caused by: java.lang.ClassNotFoundException: com.sun.xml.bind.v2.ContextFactory at jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:602) ~[?:?] at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) ~[?:?] at java.lang.ClassLoader.loadClass(ClassLoader.java:521) ~[?:?] at javax.xml.bind.ServiceLoaderUtil.nullSafeLoadClass(ServiceLoaderUtil.java:92) ~[jakarta.xml.bind-api-2.3.3.jar!/:2.3.3] at javax.xml.bind.ServiceLoaderUtil.safeLoadClass(ServiceLoaderUtil.java:125) ~[jakarta.xml.bind-api-2.3.3.jar!/:2.3.3] at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:230) ~[jakarta.xml.bind-api-2.3.3.jar!/:2.3.3] at javax.xml.bind.ContextFinder.find(ContextFinder.java:375) ~[jakarta.xml.bind-api-2.3.3.jar!/:2.3.3] at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:691) ~[jakarta.xml.bind-api-2.3.3.jar!/:2.3.3] at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:632) ~[jakarta.xml.bind-api-2.3.3.jar!/:2.3.3] at org.apache.isis.commons.internal.resources._Xml.contextOf(_Xml.java:224) ~[isis-commons-2.0.0-M7.jar!/:2.0.0-M7] ... 15 more ``` was: I cloned the isis-app-simpleapp repository, switched to JDO branch, built project, and ran via the `java -jar` command. Same result for JPA branch. Error on console: ``` java.lang.RuntimeException: unrecoverable error: 'Error obtaining JAXBContext for
[jira] [Updated] (ISIS-2990) Clean build and run displays ClassNotFoundException: com.sun.xml.bind.v2.ContextFactory
[ https://issues.apache.org/jira/browse/ISIS-2990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Kalbfus updated ISIS-2990: Description: I cloned the isis-app-simpleapp repository, switched to JDO branch, built project, and ran via the 'java -jar target/simpleapp-jdo-webapp-2.0.0-M7-exec.jar' command. Same result for JPA branch. Error on console: ``` java.lang.RuntimeException: unrecoverable error: 'Error obtaining JAXBContext for class; object class is 'org.apache.isis.schema.cmd.v2.CommandDto'' with cause ... at org.apache.isis.commons.internal.exceptions._Exceptions.unrecoverable(_Exceptions.java:144) ~[isis-commons-2.0.0-M7.jar!/:2.0.0-M7] at org.apache.isis.commons.internal.resources._Xml.verboseException(_Xml.java:201) ~[isis-commons-2.0.0-M7.jar!/:2.0.0-M7] at org.apache.isis.commons.internal.resources._Xml.contextOf(_Xml.java:226) ~[isis-commons-2.0.0-M7.jar!/:2.0.0-M7] at java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1705) ~[?:?] at org.apache.isis.commons.internal.resources._Xml.jaxbContextFor(_Xml.java:217) ~[isis-commons-2.0.0-M7.jar!/:2.0.0-M7] at org.apache.isis.applib.util.JaxbUtil.jaxbContextFor(JaxbUtil.java:111) ~[isis-applib-2.0.0-M7.jar!/:2.0.0-M7] at org.apache.isis.applib.util.schema.CommandDtoUtils.getJaxbContext(CommandDtoUtils.java:57) ~[isis-applib-2.0.0-M7.jar!/:2.0.0-M7] at org.apache.isis.applib.util.schema.CommandDtoUtils.init(CommandDtoUtils.java:50) ~[isis-applib-2.0.0-M7.jar!/:2.0.0-M7] at org.apache.isis.commons.internal.concurrent._ConcurrentTask$3.innerCall(_ConcurrentTask.java:150) ~[isis-commons-2.0.0-M7.jar!/:2.0.0-M7] at org.apache.isis.commons.internal.concurrent._ConcurrentTask$3.innerCall(_ConcurrentTask.java:146) ~[isis-commons-2.0.0-M7.jar!/:2.0.0-M7] at org.apache.isis.commons.internal.concurrent._ConcurrentTask$1.innerCall(_ConcurrentTask.java:109) ~[isis-commons-2.0.0-M7.jar!/:2.0.0-M7] at org.apache.isis.commons.internal.concurrent._ConcurrentTask.run(_ConcurrentTask.java:86) ~[isis-commons-2.0.0-M7.jar!/:2.0.0-M7] at java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec(ForkJoinTask.java:1406) ~[?:?] at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290) ~[?:?] at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1016) ~[?:?] at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1665) ~[?:?] at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1598) ~[?:?] at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177) ~[?:?] Caused by: javax.xml.bind.JAXBException: Implementation of JAXB-API has not been found on module path or classpath. at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:232) ~[jakarta.xml.bind-api-2.3.3.jar!/:2.3.3] at javax.xml.bind.ContextFinder.find(ContextFinder.java:375) ~[jakarta.xml.bind-api-2.3.3.jar!/:2.3.3] at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:691) ~[jakarta.xml.bind-api-2.3.3.jar!/:2.3.3] at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:632) ~[jakarta.xml.bind-api-2.3.3.jar!/:2.3.3] at org.apache.isis.commons.internal.resources._Xml.contextOf(_Xml.java:224) ~[isis-commons-2.0.0-M7.jar!/:2.0.0-M7] ... 15 more Caused by: java.lang.ClassNotFoundException: com.sun.xml.bind.v2.ContextFactory at jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:602) ~[?:?] at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) ~[?:?] at java.lang.ClassLoader.loadClass(ClassLoader.java:521) ~[?:?] at javax.xml.bind.ServiceLoaderUtil.nullSafeLoadClass(ServiceLoaderUtil.java:92) ~[jakarta.xml.bind-api-2.3.3.jar!/:2.3.3] at javax.xml.bind.ServiceLoaderUtil.safeLoadClass(ServiceLoaderUtil.java:125) ~[jakarta.xml.bind-api-2.3.3.jar!/:2.3.3] at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:230) ~[jakarta.xml.bind-api-2.3.3.jar!/:2.3.3] at javax.xml.bind.ContextFinder.find(ContextFinder.java:375) ~[jakarta.xml.bind-api-2.3.3.jar!/:2.3.3] at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:691) ~[jakarta.xml.bind-api-2.3.3.jar!/:2.3.3] at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:632) ~[jakarta.xml.bind-api-2.3.3.jar!/:2.3.3] at org.apache.isis.commons.internal.resources._Xml.contextOf(_Xml.java:224) ~[isis-commons-2.0.0-M7.jar!/:2.0.0-M7] ... 15 more ``` was: I cloned the isis-app-simpleapp repository, switched to JDO branch, built project, and ran via the 'target/simpleapp-jdo-webapp-2.0.0-M7-exec.jar' command. Same result for JPA branch. Error on console: ``` java.lang.RuntimeException:
[jira] [Created] (ISIS-2990) Clean build and run displays ClassNotFoundException: com.sun.xml.bind.v2.ContextFactory
Brian Kalbfus created ISIS-2990: --- Summary: Clean build and run displays ClassNotFoundException: com.sun.xml.bind.v2.ContextFactory Key: ISIS-2990 URL: https://issues.apache.org/jira/browse/ISIS-2990 Project: Isis Issue Type: Bug Components: Isis Starters Mavendeps Affects Versions: 2.0.0-M7 Environment: Apache Maven 3.6.3 Java version: 13.0.2, vendor: Oracle Corporation Default locale: en_US, platform encoding: Cp1252 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" Reporter: Brian Kalbfus I cloned the isis-app-simpleapp repository, switched to JDO branch, built project, and ran via the `java -jar` command. Same result for JPA branch. Error on console: ``` java.lang.RuntimeException: unrecoverable error: 'Error obtaining JAXBContext for class; object class is 'org.apache.isis.schema.cmd.v2.CommandDto'' with cause ... at org.apache.isis.commons.internal.exceptions._Exceptions.unrecoverable(_Exceptions.java:144) ~[isis-commons-2.0.0-M7.jar!/:2.0.0-M7] at org.apache.isis.commons.internal.resources._Xml.verboseException(_Xml.java:201) ~[isis-commons-2.0.0-M7.jar!/:2.0.0-M7] at org.apache.isis.commons.internal.resources._Xml.contextOf(_Xml.java:226) ~[isis-commons-2.0.0-M7.jar!/:2.0.0-M7] at java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1705) ~[?:?] at org.apache.isis.commons.internal.resources._Xml.jaxbContextFor(_Xml.java:217) ~[isis-commons-2.0.0-M7.jar!/:2.0.0-M7] at org.apache.isis.applib.util.JaxbUtil.jaxbContextFor(JaxbUtil.java:111) ~[isis-applib-2.0.0-M7.jar!/:2.0.0-M7] at org.apache.isis.applib.util.schema.CommandDtoUtils.getJaxbContext(CommandDtoUtils.java:57) ~[isis-applib-2.0.0-M7.jar!/:2.0.0-M7] at org.apache.isis.applib.util.schema.CommandDtoUtils.init(CommandDtoUtils.java:50) ~[isis-applib-2.0.0-M7.jar!/:2.0.0-M7] at org.apache.isis.commons.internal.concurrent._ConcurrentTask$3.innerCall(_ConcurrentTask.java:150) ~[isis-commons-2.0.0-M7.jar!/:2.0.0-M7] at org.apache.isis.commons.internal.concurrent._ConcurrentTask$3.innerCall(_ConcurrentTask.java:146) ~[isis-commons-2.0.0-M7.jar!/:2.0.0-M7] at org.apache.isis.commons.internal.concurrent._ConcurrentTask$1.innerCall(_ConcurrentTask.java:109) ~[isis-commons-2.0.0-M7.jar!/:2.0.0-M7] at org.apache.isis.commons.internal.concurrent._ConcurrentTask.run(_ConcurrentTask.java:86) ~[isis-commons-2.0.0-M7.jar!/:2.0.0-M7] at java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec(ForkJoinTask.java:1406) ~[?:?] at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290) ~[?:?] at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1016) ~[?:?] at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1665) ~[?:?] at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1598) ~[?:?] at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177) ~[?:?] Caused by: javax.xml.bind.JAXBException: Implementation of JAXB-API has not been found on module path or classpath. at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:232) ~[jakarta.xml.bind-api-2.3.3.jar!/:2.3.3] at javax.xml.bind.ContextFinder.find(ContextFinder.java:375) ~[jakarta.xml.bind-api-2.3.3.jar!/:2.3.3] at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:691) ~[jakarta.xml.bind-api-2.3.3.jar!/:2.3.3] at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:632) ~[jakarta.xml.bind-api-2.3.3.jar!/:2.3.3] at org.apache.isis.commons.internal.resources._Xml.contextOf(_Xml.java:224) ~[isis-commons-2.0.0-M7.jar!/:2.0.0-M7] ... 15 more Caused by: java.lang.ClassNotFoundException: com.sun.xml.bind.v2.ContextFactory at jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:602) ~[?:?] at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) ~[?:?] at java.lang.ClassLoader.loadClass(ClassLoader.java:521) ~[?:?] at javax.xml.bind.ServiceLoaderUtil.nullSafeLoadClass(ServiceLoaderUtil.java:92) ~[jakarta.xml.bind-api-2.3.3.jar!/:2.3.3] at javax.xml.bind.ServiceLoaderUtil.safeLoadClass(ServiceLoaderUtil.java:125) ~[jakarta.xml.bind-api-2.3.3.jar!/:2.3.3] at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:230) ~[jakarta.xml.bind-api-2.3.3.jar!/:2.3.3] at javax.xml.bind.ContextFinder.find(ContextFinder.java:375) ~[jakarta.xml.bind-api-2.3.3.jar!/:2.3.3] at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:691) ~[jakarta.xml.bind-api-2.3.3.jar!/:2.3.3] at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:632) ~[jakarta.xml.bind-api-2.3.3.jar!/:2.3.3]
[jira] [Commented] (ISIS-2946) Allow option to have Boolean scalar values toggle
[ https://issues.apache.org/jira/browse/ISIS-2946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17479507#comment-17479507 ] Brian Kalbfus commented on ISIS-2946: - Good to change this to a wish; I know this involved unwinding or short-circuiting the edit mode. I had a boolean one-click component working with M4. As I recall, I had to copy over implementations from the abstract scalar, at least, to have the checkbox not disabled and the click event to enter edit mode and toggle. When M5 was released, it did not work any more. I am thinking that the solution to this would be an alternative abstract scalar panel that does not have an edit mode, so it would add functionality for other scalars as a bonus (Like many web pages that save without a "Save" button). I thought I saw an old ticket where it solved a problem of updating the database without a user-triggered confirmation step by adding an edit mode, so this would be an undo of sorts. > Allow option to have Boolean scalar values toggle > - > > Key: ISIS-2946 > URL: https://issues.apache.org/jira/browse/ISIS-2946 > Project: Isis > Issue Type: Wish > Components: Isis Viewer Wicket >Affects Versions: 2.0.0-M6 >Reporter: Brian Kalbfus >Priority: Minor > > For a Boolean value to be toggled, it takes the following user actions: > 1. Click on the "Yes/no" text next to the checkbox > 2. Since the page just refreshed, scroll down to where the property was > 3. Click on the checkbox > 4. Click on the "OK" button > 5. Since the page just refreshed again, scroll down to see that your > change took > > It seems to me that a user usually expects to be able to update a checkbox > with a single action and the current behavior is the result of building in a > confirmation feature into the Wicket module. For those who would prefer skip > the confirmation step, we can have updates occur automatically. This would > make the checkbox intuitive and allow updates of other scalars without a > submit button. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (ISIS-2946) Allow option to have Boolean scalar values toggle
Brian Kalbfus created ISIS-2946: --- Summary: Allow option to have Boolean scalar values toggle Key: ISIS-2946 URL: https://issues.apache.org/jira/browse/ISIS-2946 Project: Isis Issue Type: Improvement Components: Isis Viewer Wicket Affects Versions: 2.0.0-M6 Reporter: Brian Kalbfus For a Boolean value to be toggled, it takes the following user actions: 1. Click on the "Yes/no" text next to the checkbox 2. Since the page just refreshed, scroll down to where the property was 3. Click on the checkbox 4. Click on the "OK" button 5. Since the page just refreshed again, scroll down to see that your change took It seems to me that a user usually expects to be able to update a checkbox with a single action and the current behavior is the result of building in a confirmation feature into the Wicket module. For those who would prefer skip the confirmation step, we can have updates occur automatically. This would make the checkbox intuitive and allow updates of other scalars without a submit button. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (ISIS-2420) Testing fails when certain beans are injected
[ https://issues.apache.org/jira/browse/ISIS-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17187896#comment-17187896 ] Brian Kalbfus commented on ISIS-2420: - I think I have a conclusion to this. * Case #2 is inappropriate for SimpleModule. It should use UserService. * Case #1 is solved by changing WebApp module's domainapp.webapp.integtests.ApplicationIntegTestAbstract to import domainapp.webapp.AppManifest and not import IsisModuleSecurityBypass. > Testing fails when certain beans are injected > - > > Key: ISIS-2420 > URL: https://issues.apache.org/jira/browse/ISIS-2420 > Project: Isis > Issue Type: Bug > Components: Isis Starters Mavendeps >Affects Versions: 2.0.0-M3 >Reporter: Brian Kalbfus >Priority: Major > > see [https://github.com/bkalbfus/isis-app-simpleapp] > Spring cannot find a bean to inject when running integration or BDD tests. > Skipping test allows SimpleModule to build and then WebApp module can run > with spring-boot:run. Wicket app works perfectly. > > Cases documented in referenced repo: > # Spring Event listener does not get domain service injected for BDD tests. > Launching in Wicket viewer is functioning as expected. This is shown in > NewUserService in WebApp module. > # SimpleObjects injects ApplicationUserRepository. Tests fail the same way. > Spring cannot find a bean to inject. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ISIS-2420) Testing fails when certain beans are injected
[ https://issues.apache.org/jira/browse/ISIS-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Kalbfus updated ISIS-2420: Description: see [https://github.com/bkalbfus/isis-app-simpleapp] Spring cannot find a bean to inject when running integration or BDD tests. Skipping test allows SimpleModule to build and then WebApp module can run with spring-boot:run. Wicket app works perfectly. Cases documented in referenced repo: # Spring Event listener does not get domain service injected for BDD tests. Launching in Wicket viewer is functioning as expected. This is shown in NewUserService in WebApp module. # SimpleObjects injects ApplicationUserRepository. Tests fail the same way. Spring cannot find a bean to inject. was: see [https://github.com/bkalbfus/isis-app-simpleapp] Spring Event listener does not get domain service injected for BDD tests. Launching in Wicket viewer is functioning as expected. Summary: Testing fails when certain beans are injected (was: BDD fails when there is a Spring event listener that injects a domain service) > Testing fails when certain beans are injected > - > > Key: ISIS-2420 > URL: https://issues.apache.org/jira/browse/ISIS-2420 > Project: Isis > Issue Type: Bug > Components: Isis Starters Mavendeps >Affects Versions: 2.0.0-M3 >Reporter: Brian Kalbfus >Priority: Major > > see [https://github.com/bkalbfus/isis-app-simpleapp] > Spring cannot find a bean to inject when running integration or BDD tests. > Skipping test allows SimpleModule to build and then WebApp module can run > with spring-boot:run. Wicket app works perfectly. > > Cases documented in referenced repo: > # Spring Event listener does not get domain service injected for BDD tests. > Launching in Wicket viewer is functioning as expected. This is shown in > NewUserService in WebApp module. > # SimpleObjects injects ApplicationUserRepository. Tests fail the same way. > Spring cannot find a bean to inject. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ISIS-2420) BDD fails when there is a Spring event listener that injects a domain service
[ https://issues.apache.org/jira/browse/ISIS-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186235#comment-17186235 ] Brian Kalbfus commented on ISIS-2420: - This also occurs in standard integration tests. I made a commit to my fork to simply inject ApplicationUserRepository to SimpleObjects. This breaks the build. > BDD fails when there is a Spring event listener that injects a domain service > - > > Key: ISIS-2420 > URL: https://issues.apache.org/jira/browse/ISIS-2420 > Project: Isis > Issue Type: Bug > Components: Isis Starters Mavendeps >Affects Versions: 2.0.0-M3 >Reporter: Brian Kalbfus >Priority: Major > > see [https://github.com/bkalbfus/isis-app-simpleapp] > > Spring Event listener does not get domain service injected for BDD tests. > Launching in Wicket viewer is functioning as expected. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ISIS-2421) Demo fat jar fails to launch - could not find asciidoctor jruby file
Brian Kalbfus created ISIS-2421: --- Summary: Demo fat jar fails to launch - could not find asciidoctor jruby file Key: ISIS-2421 URL: https://issues.apache.org/jira/browse/ISIS-2421 Project: Isis Issue Type: Bug Components: Isis Examples Affects Versions: 2.0.0-M3 Reporter: Brian Kalbfus running the generated demo wicket jar with java -jar fails on startup. Need to add the requiresUnpack configuration to the spring boot repackage process. org.asciidoctor asciidoctorj -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ISIS-2420) BDD fails when there is a Spring event listener that injects a domain service
Brian Kalbfus created ISIS-2420: --- Summary: BDD fails when there is a Spring event listener that injects a domain service Key: ISIS-2420 URL: https://issues.apache.org/jira/browse/ISIS-2420 Project: Isis Issue Type: Bug Components: Isis Starters Mavendeps Affects Versions: 2.0.0-M3 Reporter: Brian Kalbfus see [https://github.com/bkalbfus/isis-app-simpleapp] Spring Event listener does not get domain service injected for BDD tests. Launching in Wicket viewer is functioning as expected. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ISIS-2384) Action that takes a List of view models fails to gather them when object has been viewed already
Brian Kalbfus created ISIS-2384:
---
Summary: Action that takes a List of view models fails to gather
them when object has been viewed already
Key: ISIS-2384
URL: https://issues.apache.org/jira/browse/ISIS-2384
Project: Isis
Issue Type: Bug
Components: Isis Examples
Affects Versions: 2.0.0-M3
Reporter: Brian Kalbfus
>From demo in master, apply this patch:
{code:java}
diff --git
a/examples/demo/domain/src/main/java/demoapp/dom/viewmodels/jaxbrefentity/StatefulViewModelJaxbRefsEntity.java
b/examples/demo/domain/src/main/java/demoapp/dom/viewmodels/jaxbrefentity/StatefulViewModelJaxbRefsEntity.java
index 92a26bc..476ca60 100644
---
a/examples/demo/domain/src/main/java/demoapp/dom/viewmodels/jaxbrefentity/StatefulViewModelJaxbRefsEntity.java
+++
b/examples/demo/domain/src/main/java/demoapp/dom/viewmodels/jaxbrefentity/StatefulViewModelJaxbRefsEntity.java
@@ -37,11 +37,10 @@
import org.apache.isis.applib.annotation.Property;
import org.apache.isis.applib.annotation.SemanticsOf;
+import demoapp.dom._infra.asciidocdesc.HasAsciiDocDescription;
import lombok.Getter;
import lombok.Setter;
-import demoapp.dom._infra.asciidocdesc.HasAsciiDocDescription;
-
//tag::class[]
@XmlRootElement(name = "demo.StatefulViewModelJaxbRefsEntity")
@XmlType(
@@ -103,6 +102,14 @@
@XmlElement(name = "child")
private List children = new ArrayList<>();
+@Action(associateWith = "children")
+public StatefulViewModelJaxbRefsEntity suffixChildren(List
children) {
+ for(ChildJdoEntity child : children) {
+ child.setName(child.getName() + ", Jr");
+ }
+ return this;
+}
+
@Action(associateWith = "children", associateWithSequence = "1", semantics
= SemanticsOf.NON_IDEMPOTENT)
public StatefulViewModelJaxbRefsEntity addChild(final ChildJdoEntity
child) {
children.add(child);
{code}
Then, on the demo wicket page, go to the view models refs entity. Add all
children. Then view all children individually (I used ctrl-click).
Then, select all the children and run the "Suffix Children" action. Before
being prompted to affirm the selected children, an NPE occurs:
{noformat}
java.lang.NullPointerException
java.util.Objects#requireNonNull(Objects.java:222)
org.apache.isis.viewer.wicket.ui.components.widgets.linkandlabel.LinkAndLabelFactoryAbstract$1#doOnClick(LinkAndLabelFactoryAbstract.java:112)
org.apache.isis.viewer.wicket.ui.components.widgets.linkandlabel.ActionLink#onClick(ActionLink.java:100)
org.apache.wicket.ajax.markup.html.AjaxLink$1#onEvent(AjaxLink.java:85)
org.apache.wicket.ajax.AjaxEventBehavior#respond(AjaxEventBehavior.java:127)
org.apache.wicket.ajax.AbstractDefaultAjaxBehavior#onRequest(AbstractDefaultAjaxBehavior.java:598)
org.apache.wicket.core.request.handler.ListenerRequestHandler#internalInvoke(ListenerRequestHandler.java:306)
org.apache.wicket.core.request.handler.ListenerRequestHandler#invoke(ListenerRequestHandler.java:280)
org.apache.wicket.core.request.handler.ListenerRequestHandler#invokeListener(ListenerRequestHandler.java:222)
org.apache.wicket.core.request.handler.ListenerRequestHandler#respond(ListenerRequestHandler.java:208)
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor#respond(RequestCycle.java:914)
org.apache.wicket.request.RequestHandlerExecutor#execute(RequestHandlerExecutor.java:65)
org.apache.wicket.request.cycle.RequestCycle#execute(RequestCycle.java:282)
org.apache.wicket.request.cycle.RequestCycle#processRequest(RequestCycle.java:253)
[jira] [Created] (ISIS-2363) Recently removed ServiceRegistry.injectServicesInto() is still recommended in docs
Brian Kalbfus created ISIS-2363:
---
Summary: Recently removed ServiceRegistry.injectServicesInto() is
still recommended in docs
Key: ISIS-2363
URL: https://issues.apache.org/jira/browse/ISIS-2363
Project: Isis
Issue Type: Bug
Components: Isis Applib (programming model), Isis Docs Website
Affects Versions: 2.0.0-M3
Reporter: Brian Kalbfus
The docs [1] have this text:
Alternatively the object can be instantiated simply using {{new}}, then
services injected using
[{{ServiceRegistry}}|https://isis.apache.org/refguide/2.0.0-M3/applib-svc/ServiceRegistry.html]'s
{{injectServicesInto(…)}} method.
This method is missing in 2.0.0-M3. I found from Slack[2] that a replacement
might be serviceInjector.injectServicesInto()
[1]:
[https://isis.apache.org/refguide/2.0.0-M3/applib-svc/about.html#using-the-services]
[2]:
[https://the-asf.slack.com/archives/CFC42LWBV/p1579553230202600?thread_ts=1579553230.202600=CFC42LWBV]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ISIS-2104) AuditerService not being called
[ https://issues.apache.org/jira/browse/ISIS-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16831869#comment-16831869 ] Brian Kalbfus commented on ISIS-2104: - Regarding #1: The way I tested the MessageService in my application was to have an implementation of it with `menuOrder = 1` in the test classpath that keeps a copy of the messages sent to it so that test classes can query it. This was an acceptance test that was run as a cucumber feature. Would this approach work for the module unit tests? > AuditerService not being called > --- > > Key: ISIS-2104 > URL: https://issues.apache.org/jira/browse/ISIS-2104 > Project: Isis > Issue Type: Bug > Components: Core >Affects Versions: 2.0.0-M2 > Environment: C:\Users\bkalbfus\workspace>mvn -v > Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; > 2018-10-24T10:41:47-08:00) > Maven home: C:\ProgramData\chocolatey\lib\maven\apache-maven-3.6.0\bin\.. > Java version: 1.8.0_152, vendor: Oracle Corporation, runtime: C:\Program > Files\Java\jdk1.8.0_152\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Brian Kalbfus >Assignee: Andi Huber >Priority: Critical > Fix For: 2.0.0 > > Attachments: AuditDatabaseLogger.java > > > A simple implementation of AuditerService (see attached) works in v1.17 > helloworld archetype but not in v2.0.0-M2 helloworld archetype. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ISIS-2020) Experimental Support for DataNucleus Federated Datastore
[ https://issues.apache.org/jira/browse/ISIS-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16829651#comment-16829651 ] Brian Kalbfus commented on ISIS-2020: - Yes, this was my concern. Will the 'v2' release have all the features in 'v1' like auditing, event bus (I identified earlier) and quickstart archetype? I think it is a good idea to put spring overhaul in 'v3' . > Experimental Support for DataNucleus Federated Datastore > > > Key: ISIS-2020 > URL: https://issues.apache.org/jira/browse/ISIS-2020 > Project: Isis > Issue Type: New Feature > Components: Core: Objectstore: JDO >Affects Versions: 1.16.2, 2.0.0-M1 >Reporter: Brian Kalbfus >Assignee: Andi Huber >Priority: Minor > Fix For: 2.0.0 > > Attachments: datanucleus-api-jdo.patch > > > Insert and Update operations work as expected, but query operations operate > on the primary datastore. I see from stepping through the M1 code that > Insert and Update operations use a transaction that accesses a > FederatedDataStore. I guess that is where the difference occurs in that the > query operations get a data store another way, failing to get the > FederatedDataStore that is configured. > example code created from helloworld-archetype is at > [https://github.com/bkalbfus/isis-federatedDS-2_0_0-M1] > Mailing list: > [https://lists.apache.org/thread.html/2edea2f8d802532c3672eddc83b484bbc2e31d1cac16f2759feeb95f@%3Cusers.isis.apache.org%3E] > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ISIS-2020) Experimental Support for DataNucleus Federated Datastore
[ https://issues.apache.org/jira/browse/ISIS-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16829589#comment-16829589 ] Brian Kalbfus commented on ISIS-2020: - Hi Andi, This answers my question! I guess this is one of the reasons for the 'v2' branch, then. Thanks! > Experimental Support for DataNucleus Federated Datastore > > > Key: ISIS-2020 > URL: https://issues.apache.org/jira/browse/ISIS-2020 > Project: Isis > Issue Type: New Feature > Components: Core: Objectstore: JDO >Affects Versions: 1.16.2, 2.0.0-M1 >Reporter: Brian Kalbfus >Assignee: Andi Huber >Priority: Minor > Fix For: 2.0.0 > > Attachments: datanucleus-api-jdo.patch > > > Insert and Update operations work as expected, but query operations operate > on the primary datastore. I see from stepping through the M1 code that > Insert and Update operations use a transaction that accesses a > FederatedDataStore. I guess that is where the difference occurs in that the > query operations get a data store another way, failing to get the > FederatedDataStore that is configured. > example code created from helloworld-archetype is at > [https://github.com/bkalbfus/isis-federatedDS-2_0_0-M1] > Mailing list: > [https://lists.apache.org/thread.html/2edea2f8d802532c3672eddc83b484bbc2e31d1cac16f2759feeb95f@%3Cusers.isis.apache.org%3E] > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ISIS-2020) Experimental Support for DataNucleus Federated Datastore
[ https://issues.apache.org/jira/browse/ISIS-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16829553#comment-16829553 ] Brian Kalbfus commented on ISIS-2020: - Can we apply these fixes to the 'v1' branch? Thanks! > Experimental Support for DataNucleus Federated Datastore > > > Key: ISIS-2020 > URL: https://issues.apache.org/jira/browse/ISIS-2020 > Project: Isis > Issue Type: New Feature > Components: Core: Objectstore: JDO >Affects Versions: 1.16.2, 2.0.0-M1 >Reporter: Brian Kalbfus >Assignee: Andi Huber >Priority: Minor > Fix For: 2.0.0 > > Attachments: datanucleus-api-jdo.patch > > > Insert and Update operations work as expected, but query operations operate > on the primary datastore. I see from stepping through the M1 code that > Insert and Update operations use a transaction that accesses a > FederatedDataStore. I guess that is where the difference occurs in that the > query operations get a data store another way, failing to get the > FederatedDataStore that is configured. > example code created from helloworld-archetype is at > [https://github.com/bkalbfus/isis-federatedDS-2_0_0-M1] > Mailing list: > [https://lists.apache.org/thread.html/2edea2f8d802532c3672eddc83b484bbc2e31d1cac16f2759feeb95f@%3Cusers.isis.apache.org%3E] > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ISIS-2104) AuditerService not being called
[ https://issues.apache.org/jira/browse/ISIS-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818316#comment-16818316 ] Brian Kalbfus commented on ISIS-2104: - [https://github.com/apache/isis/blob/a494f564103769976083e2a5c0ed5142d475b230/core/plugins/jdo-datanucleus-5/src/main/java/org/apache/isis/core/runtime/system/persistence/PersistenceSession5.java#L841] is missing the code that existed in v1 to enlist updating to changedObjectsServiceInternal at [https://github.com/apache/isis/blob/af58faef7dbf2e9f635ec46c72affd3a830a6946/core/runtime/src/main/java/org/apache/isis/core/runtime/system/persistence/PersistenceSession.java#L2381] When I added it (I skipped the EventBus code for this test), auditing seemed to work. Is this module going away in favor of Spring Persistence? > AuditerService not being called > --- > > Key: ISIS-2104 > URL: https://issues.apache.org/jira/browse/ISIS-2104 > Project: Isis > Issue Type: Bug > Components: Core >Affects Versions: 2.0.0-M2 > Environment: C:\Users\bkalbfus\workspace>mvn -v > Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; > 2018-10-24T10:41:47-08:00) > Maven home: C:\ProgramData\chocolatey\lib\maven\apache-maven-3.6.0\bin\.. > Java version: 1.8.0_152, vendor: Oracle Corporation, runtime: C:\Program > Files\Java\jdk1.8.0_152\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Brian Kalbfus >Priority: Major > Attachments: AuditDatabaseLogger.java > > > A simple implementation of AuditerService (see attached) works in v1.17 > helloworld archetype but not in v2.0.0-M2 helloworld archetype. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ISIS-2029) Using Application Identity (e.g. settings module) with .orm file leads to Webui exception
[
https://issues.apache.org/jira/browse/ISIS-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16768622#comment-16768622
]
Brian Kalbfus commented on ISIS-2029:
-
This is the same error I came upon last year with application identity. Where
I thought the issue might have been resolved in 2.0.0-M1 and I was doing
something wrong, I now believe it is still an issue.
I created a github repository to demonstrate this error[1], from the SimpleApp
archetype in version 2.0.0-M2.
[1]https://github.com/bkalbfus/apache-isis-appidentity
> Using Application Identity (e.g. settings module) with .orm file leads to
> Webui exception
> -
>
> Key: ISIS-2029
> URL: https://issues.apache.org/jira/browse/ISIS-2029
> Project: Isis
> Issue Type: Bug
> Components: Core, Core: Viewer: Wicket
>Affects Versions: 1.16.2
>Reporter: Vladimir Nisevic
>Priority: Major
> Fix For: 1.19.0
>
> Attachments: stacktrace.txt
>
>
> h2.Problem description
> I want to use settings module (incode or previous isis-addons) so that the
> tables are persisted in custom database schema (different than isissettings).
> In order to achieve this I have created a custom .orm file e.g.
>
> package-custom.orm
> {code:java}
>
> http://xmlns.jcp.org/xml/ns/jdo/orm;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/jdo/orm
> http://xmlns.jcp.org/xml/ns/jdo/orm_3_0.xsd;>
>
> table="IsisAppSetting"/>
>
>
>
> {code}
> and refer the file in persistor_datanucleus.properties
> {code:java}
> # schema name override
> isis.persistor.datanucleus.impl.datanucleus.Mapping=custom{code}
>
> I can create single ApplicationSetting thru WebUI but if I have more than one
> persisted, here the WebUI exception I get in WebUI
> {code:java}
> Caused by:
> org.datanucleus.exceptions.NucleusUserException
> Identity
> "interface.MQTT.activated[OID]org.incode.example.settings.dom.jdo.ApplicationSettingJdo"
> is assigned to class
> "org.incode.example.settings.dom.jdo.ApplicationSettingJdo", but its not the
> correct object-id type for this class.
> org.datanucleus.store.AbstractStoreManager#manageClassForIdentity(AbstractStoreManager.java:937)
> org.datanucleus.ExecutionContextImpl#getClassDetailsForId(ExecutionContextImpl.java:3385)
> org.datanucleus.ExecutionContextImpl#findObjects(ExecutionContextImpl.java:3251){code}
>
> I believe the root cause is that Datanucleus thinks somehow that the
> ApplicationSetting has not Application Identity which it has since field key
> is primary key - but only in the case when retreiving more then one entity
> from database.
>
> All works fine when creating new instance ApplicationSetting or reading it
> from database by key. The command "Settings --> listAll" fails.
>
> I tried also to adapt the .orm file e.g. but it didn't helped.
> {code:java}
>
> schema="myschema" table="IsisAppSetting">
>
>
> table="IsisUserSetting"/>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ISIS-2020) Experimental Support for DataNucleus Federated Datastore
[ https://issues.apache.org/jira/browse/ISIS-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16737594#comment-16737594 ] Brian Kalbfus commented on ISIS-2020: - Hi Andi, The FederatedDataStore has been working as required in my project so far. Fixture scripts don't work with this configuration because in org.apache.isis.applib.services.jdosupport.IsisJdoSupportDN5.executeUpdate(String), the code executes an update SQL directly on the JdoConnection's primary data store. deleteFrom() called on a entity persisted to a different database causes an error because it cannot find that table in the primary datastore. * A work-around is to comment out the tear-down fixture lines that delete from entities persisted to a non-primary datastore for WebApp prototyping and uncomment them to run Integration testing. * A fix might be to use the JDO batch update or delete via query instead of native SQL on the database connection. > Experimental Support for DataNucleus Federated Datastore > > > Key: ISIS-2020 > URL: https://issues.apache.org/jira/browse/ISIS-2020 > Project: Isis > Issue Type: New Feature > Components: Core: Objectstore: JDO >Affects Versions: 1.16.2, 2.0.0-M1 >Reporter: Brian Kalbfus >Assignee: Andi Huber >Priority: Minor > Fix For: 2.0.0 > > Attachments: datanucleus-api-jdo.patch > > > Insert and Update operations work as expected, but query operations operate > on the primary datastore. I see from stepping through the M1 code that > Insert and Update operations use a transaction that accesses a > FederatedDataStore. I guess that is where the difference occurs in that the > query operations get a data store another way, failing to get the > FederatedDataStore that is configured. > example code created from helloworld-archetype is at > [https://github.com/bkalbfus/isis-federatedDS-2_0_0-M1] > Mailing list: > [https://lists.apache.org/thread.html/2edea2f8d802532c3672eddc83b484bbc2e31d1cac16f2759feeb95f@%3Cusers.isis.apache.org%3E] > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ISIS-2034) REST operations return empty response
[ https://issues.apache.org/jira/browse/ISIS-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16692407#comment-16692407 ] Brian Kalbfus commented on ISIS-2034: - OK, that did it. I see you are using cookie authentication now. The curl command displayed isn't accurate if you have to include a cookie in the process. Maybe modifying the api specification document (/restful/swagger/private) will work better with Swagger-UI and generated clients. You can add a security scheme like is described in [https://swagger.io/docs/specification/authentication/cookie-authentication/] . Thanks! Brian > REST operations return empty response > - > > Key: ISIS-2034 > URL: https://issues.apache.org/jira/browse/ISIS-2034 > Project: Isis > Issue Type: Bug > Components: Core: Viewer: RestfulObjects >Affects Versions: 2.0.0-M2 > Environment: Windows 7 >Reporter: Brian Kalbfus >Assignee: Andi Huber >Priority: Minor > Labels: not-an-issue > Fix For: 2.0.0-M2 > > Attachments: simpleappswaggerui.png > > > to reproduce: > # checkout HEAD of v2 branch > # mvn clean install > # cd to isis/example/application/simpleapp/webapp > # set PROTOTYPING=true > # mvn jetty:run > # open web browser to localhost:8080/wicket, sign in as sven/pass > # from prototyping menu, open swagger-ui > # reload private spec > # select simple - /service/simple.SimpleObjectMenu/actions/listAll/invoke > # click "Try it out" > expected: Response body should have some output - some json with metadata or > something > actual: Reponse body says "no content" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (ISIS-2034) REST operations return empty response
[ https://issues.apache.org/jira/browse/ISIS-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16692159#comment-16692159 ] Brian Kalbfus edited comment on ISIS-2034 at 11/19/18 7:42 PM: --- Hi Andi, It gives me the same result if I create SimpleObject instances. See attached screenshot. If there are no instances, I'd expect there would be returned an empty list. I just did 'git pull' and rebuilt the simpleapp; I have the same result. The HTTP status code (missing from screenshot) is 401. Thanks, Brian was (Author: bkalbfus): Hi Andi, It gives me the same result if I create SimpleObject instances. See attached screenshot. If there are no instances, I'd expect there would be returned an empty list. I just did 'git pull' and rebuilt the simpleapp; I have the same result. Thanks, Brian > REST operations return empty response > - > > Key: ISIS-2034 > URL: https://issues.apache.org/jira/browse/ISIS-2034 > Project: Isis > Issue Type: Bug > Components: Core: Viewer: RestfulObjects >Affects Versions: 2.0.0-M2 > Environment: Windows 7 >Reporter: Brian Kalbfus >Assignee: Andi Huber >Priority: Minor > Labels: not-an-issue > Fix For: 2.0.0-M2 > > Attachments: simpleappswaggerui.png > > > to reproduce: > # checkout HEAD of v2 branch > # mvn clean install > # cd to isis/example/application/simpleapp/webapp > # set PROTOTYPING=true > # mvn jetty:run > # open web browser to localhost:8080/wicket, sign in as sven/pass > # from prototyping menu, open swagger-ui > # reload private spec > # select simple - /service/simple.SimpleObjectMenu/actions/listAll/invoke > # click "Try it out" > expected: Response body should have some output - some json with metadata or > something > actual: Reponse body says "no content" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ISIS-2034) REST operations return empty response
[ https://issues.apache.org/jira/browse/ISIS-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16692159#comment-16692159 ] Brian Kalbfus commented on ISIS-2034: - Hi Andi, It gives me the same result if I create SimpleObject instances. See attached screenshot. If there are no instances, I'd expect there would be returned an empty list. I just did 'git pull' and rebuilt the simpleapp; I have the same result. Thanks, Brian > REST operations return empty response > - > > Key: ISIS-2034 > URL: https://issues.apache.org/jira/browse/ISIS-2034 > Project: Isis > Issue Type: Bug > Components: Core: Viewer: RestfulObjects >Affects Versions: 2.0.0-M2 > Environment: Windows 7 >Reporter: Brian Kalbfus >Assignee: Andi Huber >Priority: Minor > Labels: not-an-issue > Fix For: 2.0.0-M2 > > Attachments: simpleappswaggerui.png > > > to reproduce: > # checkout HEAD of v2 branch > # mvn clean install > # cd to isis/example/application/simpleapp/webapp > # set PROTOTYPING=true > # mvn jetty:run > # open web browser to localhost:8080/wicket, sign in as sven/pass > # from prototyping menu, open swagger-ui > # reload private spec > # select simple - /service/simple.SimpleObjectMenu/actions/listAll/invoke > # click "Try it out" > expected: Response body should have some output - some json with metadata or > something > actual: Reponse body says "no content" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ISIS-2034) REST operations return empty response
[ https://issues.apache.org/jira/browse/ISIS-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Kalbfus updated ISIS-2034: Attachment: simpleappswaggerui.png > REST operations return empty response > - > > Key: ISIS-2034 > URL: https://issues.apache.org/jira/browse/ISIS-2034 > Project: Isis > Issue Type: Bug > Components: Core: Viewer: RestfulObjects >Affects Versions: 2.0.0-M2 > Environment: Windows 7 >Reporter: Brian Kalbfus >Assignee: Andi Huber >Priority: Minor > Labels: not-an-issue > Fix For: 2.0.0-M2 > > Attachments: simpleappswaggerui.png > > > to reproduce: > # checkout HEAD of v2 branch > # mvn clean install > # cd to isis/example/application/simpleapp/webapp > # set PROTOTYPING=true > # mvn jetty:run > # open web browser to localhost:8080/wicket, sign in as sven/pass > # from prototyping menu, open swagger-ui > # reload private spec > # select simple - /service/simple.SimpleObjectMenu/actions/listAll/invoke > # click "Try it out" > expected: Response body should have some output - some json with metadata or > something > actual: Reponse body says "no content" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ISIS-2034) REST operations return empty response
Brian Kalbfus created ISIS-2034: --- Summary: REST operations return empty response Key: ISIS-2034 URL: https://issues.apache.org/jira/browse/ISIS-2034 Project: Isis Issue Type: Bug Components: Core: Viewer: RestfulObjects Affects Versions: 2.0.0-M2 Environment: Windows 7 Reporter: Brian Kalbfus to reproduce: # checkout HEAD of v2 branch # mvn clean install # cd to isis/example/application/simpleapp/webapp # set PROTOTYPING=true # mvn jetty:run # open web browser to localhost:8080/wicket, sign in as sven/pass # from prototyping menu, open swagger-ui # reload private spec # select simple - /service/simple.SimpleObjectMenu/actions/listAll/invoke # click "Try it out" expected: Response body should have some output - some json with metadata or something actual: Reponse body says "no content" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ISIS-2020) DataNucleus Federated Datastore functionality not used in query
[ https://issues.apache.org/jira/browse/ISIS-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16680647#comment-16680647 ] Brian Kalbfus commented on ISIS-2020: - I have SimpleApp working with a federated data store. I am working from the v2 branch. I had to make one change in the isis-core-plugins-jdo-datanucleus-5 module: [https://github.com/apache/isis/blob/2f8f57c32e3a85c54c35c9d73062e8212bb4c8e5/core/plugins/jdo-datanucleus-5/src/main/java/org/apache/isis/core/runtime/system/persistence/DataNucleusApplicationComponents5.java#L124] (from the v2 branch) The isSchemaAwareStoreManager method assumes that hsqldb and sqlserver urls would render a SchemaAwareStoreManager. This is not the case if there is a secondary store defined - you get a Federated data store manager. I suppose you could test for the presence of a "isis.persistor.datanucleus.impl.datanucleus.datastore.*" property to immediately return false. I commented out this code so that the probePmf test is used. Also, I had to change the entity listAll methods like I describe in my prior comment and "ignore" the unit test that calls this method. I now understand why the build and tests succeeded but the web app failed to start: the federated data store is declared in the webapp module. What is the downside of not having a SchemaAwareStoreManager in Apache Isis? Thanks, Brian > DataNucleus Federated Datastore functionality not used in query > --- > > Key: ISIS-2020 > URL: https://issues.apache.org/jira/browse/ISIS-2020 > Project: Isis > Issue Type: Bug > Components: Core: Objectstore: JDO >Affects Versions: 1.16.2, 2.0.0-M1 >Reporter: Brian Kalbfus >Assignee: Andi Huber >Priority: Major > Fix For: 2.0.0 > > Attachments: datanucleus-api-jdo.patch > > > Insert and Update operations work as expected, but query operations operate > on the primary datastore. I see from stepping through the M1 code that > Insert and Update operations use a transaction that accesses a > FederatedDataStore. I guess that is where the difference occurs in that the > query operations get a data store another way, failing to get the > FederatedDataStore that is configured. > example code created from helloworld-archetype is at > [https://github.com/bkalbfus/isis-federatedDS-2_0_0-M1] > Mailing list: > [https://lists.apache.org/thread.html/2edea2f8d802532c3672eddc83b484bbc2e31d1cac16f2759feeb95f@%3Cusers.isis.apache.org%3E] > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ISIS-2020) DataNucleus Federated Datastore functionality not used in query
[
https://issues.apache.org/jira/browse/ISIS-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678672#comment-16678672
]
Brian Kalbfus commented on ISIS-2020:
-
When I change
{code:java}
return repositoryService.allInstances(HelloOtherWorldObject.class);{code}
to
{code:java}
return isisJdoSupport.executeQuery(HelloOtherWorldObject.class, null);{code}
then the result looks good to me. Is there a good reason to prefer
repositoryService#allInstances over doing a query like this?
> DataNucleus Federated Datastore functionality not used in query
> ---
>
> Key: ISIS-2020
> URL: https://issues.apache.org/jira/browse/ISIS-2020
> Project: Isis
> Issue Type: Bug
> Components: Core: Objectstore: JDO
>Affects Versions: 1.16.2, 2.0.0-M1
>Reporter: Brian Kalbfus
>Assignee: Andi Huber
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: datanucleus-api-jdo.patch
>
>
> Insert and Update operations work as expected, but query operations operate
> on the primary datastore. I see from stepping through the M1 code that
> Insert and Update operations use a transaction that accesses a
> FederatedDataStore. I guess that is where the difference occurs in that the
> query operations get a data store another way, failing to get the
> FederatedDataStore that is configured.
> example code created from helloworld-archetype is at
> [https://github.com/bkalbfus/isis-federatedDS-2_0_0-M1]
> Mailing list:
> [https://lists.apache.org/thread.html/2edea2f8d802532c3672eddc83b484bbc2e31d1cac16f2759feeb95f@%3Cusers.isis.apache.org%3E]
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ISIS-2020) DataNucleus Federated Datastore functionality not used in query
[ https://issues.apache.org/jira/browse/ISIS-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16677341#comment-16677341 ] Brian Kalbfus commented on ISIS-2020: - I updated [https://github.com/bkalbfus/isis-federatedDS-2_0_0-M1] with substituting the latest datanucleus-core 5.2 jar. It makes use of a dependency exception and redeclaring the datanucleus maven plugin in the child pom. The findByName action works, but listAll does not work with this code - Please advise on how to get listAll to work. > DataNucleus Federated Datastore functionality not used in query > --- > > Key: ISIS-2020 > URL: https://issues.apache.org/jira/browse/ISIS-2020 > Project: Isis > Issue Type: Bug > Components: Core: Objectstore: JDO >Affects Versions: 1.16.2, 2.0.0-M1 >Reporter: Brian Kalbfus >Priority: Major > Fix For: 1.16.3 > > Attachments: datanucleus-api-jdo.patch > > > Insert and Update operations work as expected, but query operations operate > on the primary datastore. I see from stepping through the M1 code that > Insert and Update operations use a transaction that accesses a > FederatedDataStore. I guess that is where the difference occurs in that the > query operations get a data store another way, failing to get the > FederatedDataStore that is configured. > example code created from helloworld-archetype is at > [https://github.com/bkalbfus/isis-federatedDS-2_0_0-M1] > Mailing list: > [https://lists.apache.org/thread.html/2edea2f8d802532c3672eddc83b484bbc2e31d1cac16f2759feeb95f@%3Cusers.isis.apache.org%3E] > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (ISIS-2020) DataNucleus Federated Datastore functionality not used in query
[ https://issues.apache.org/jira/browse/ISIS-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16677251#comment-16677251 ] Brian Kalbfus edited comment on ISIS-2020 at 11/6/18 9:32 PM: -- This issue is apparently fixed in datanucleus-core 5.2.0-m2 as of 3 days ago. Andy patched datanucleus-core because it makes more sense there than my one-off fix of datanucleus-api-jdo. My datanucleus test passes now. To fix the test project using Isis, I can't simply reference 5.2.0-m2 from the test project because it is part of isis-core-plugins-jdo-datanucleus-5. Maybe there is a maven override that allows me to do this. Is there a newer version of isis-core-plugins-jdo-datanucleus-5 that references the later datanucleus build? -Brian was (Author: bkalbfus): This issue is apparently fixed in datanucleus-core 5.2.0-m2 as of 3 days ago. Andy patched datanucleus-core because it makes more sense there than my one-off fix of datanucleus-api-jdo. My datanucleus test passes now. The fix the test project using Isis, I can't simply reference 5.2.0-m2 from the test project because it is part of isis-core-plugins-jdo-datanucleus-5. Maybe there is a maven override that allows me to do this. Is there a newer version of isis-core-plugins-jdo-datanucleus-5 that references the later datanucleus build? -Brian > DataNucleus Federated Datastore functionality not used in query > --- > > Key: ISIS-2020 > URL: https://issues.apache.org/jira/browse/ISIS-2020 > Project: Isis > Issue Type: Bug > Components: Core: Objectstore: JDO >Affects Versions: 1.16.2, 2.0.0-M1 >Reporter: Brian Kalbfus >Priority: Major > Fix For: 1.16.3 > > Attachments: datanucleus-api-jdo.patch > > > Insert and Update operations work as expected, but query operations operate > on the primary datastore. I see from stepping through the M1 code that > Insert and Update operations use a transaction that accesses a > FederatedDataStore. I guess that is where the difference occurs in that the > query operations get a data store another way, failing to get the > FederatedDataStore that is configured. > example code created from helloworld-archetype is at > [https://github.com/bkalbfus/isis-federatedDS-2_0_0-M1] > Mailing list: > [https://lists.apache.org/thread.html/2edea2f8d802532c3672eddc83b484bbc2e31d1cac16f2759feeb95f@%3Cusers.isis.apache.org%3E] > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ISIS-2020) DataNucleus Federated Datastore functionality not used in query
[ https://issues.apache.org/jira/browse/ISIS-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16677251#comment-16677251 ] Brian Kalbfus commented on ISIS-2020: - This issue is apparently fixed in datanucleus-core 5.2.0-m2 as of 3 days ago. Andy patched datanucleus-core because it makes more sense there than my one-off fix of datanucleus-api-jdo. My datanucleus test passes now. The fix the test project using Isis, I can't simply reference 5.2.0-m2 from the test project because it is part of isis-core-plugins-jdo-datanucleus-5. Maybe there is a maven override that allows me to do this. Is there a newer version of isis-core-plugins-jdo-datanucleus-5 that references the later datanucleus build? -Brian > DataNucleus Federated Datastore functionality not used in query > --- > > Key: ISIS-2020 > URL: https://issues.apache.org/jira/browse/ISIS-2020 > Project: Isis > Issue Type: Bug > Components: Core: Objectstore: JDO >Affects Versions: 1.16.2, 2.0.0-M1 >Reporter: Brian Kalbfus >Priority: Major > Fix For: 1.16.3 > > Attachments: datanucleus-api-jdo.patch > > > Insert and Update operations work as expected, but query operations operate > on the primary datastore. I see from stepping through the M1 code that > Insert and Update operations use a transaction that accesses a > FederatedDataStore. I guess that is where the difference occurs in that the > query operations get a data store another way, failing to get the > FederatedDataStore that is configured. > example code created from helloworld-archetype is at > [https://github.com/bkalbfus/isis-federatedDS-2_0_0-M1] > Mailing list: > [https://lists.apache.org/thread.html/2edea2f8d802532c3672eddc83b484bbc2e31d1cac16f2759feeb95f@%3Cusers.isis.apache.org%3E] > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ISIS-2020) DataNucleus Federated Datastore functionality not used in query
[ https://issues.apache.org/jira/browse/ISIS-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16662499#comment-16662499 ] Brian Kalbfus commented on ISIS-2020: - Hi Andi, I will look at a PR for datanucleus for the query by name sub-issue. -Brian > DataNucleus Federated Datastore functionality not used in query > --- > > Key: ISIS-2020 > URL: https://issues.apache.org/jira/browse/ISIS-2020 > Project: Isis > Issue Type: Bug > Components: Core: Objectstore: JDO >Affects Versions: 1.16.2, 2.0.0-M1 >Reporter: Brian Kalbfus >Priority: Major > Attachments: datanucleus-api-jdo.patch > > > Insert and Update operations work as expected, but query operations operate > on the primary datastore. I see from stepping through the M1 code that > Insert and Update operations use a transaction that accesses a > FederatedDataStore. I guess that is where the difference occurs in that the > query operations get a data store another way, failing to get the > FederatedDataStore that is configured. > example code created from helloworld-archetype is at > [https://github.com/bkalbfus/isis-federatedDS-2_0_0-M1] > Mailing list: > [https://lists.apache.org/thread.html/2edea2f8d802532c3672eddc83b484bbc2e31d1cac16f2759feeb95f@%3Cusers.isis.apache.org%3E] > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (ISIS-2020) DataNucleus Federated Datastore functionality not used in query
[ https://issues.apache.org/jira/browse/ISIS-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16661428#comment-16661428 ] Brian Kalbfus edited comment on ISIS-2020 at 10/23/18 11:01 PM: I am solving this by patching datanucleus-api-jdo. JDOQLTypedQueryImpl is getting a query from the primaryStoreMgr instead of finding the correct StoreManager for the class. The attached patch fixes the "Find by Name" operation, not the "List All" operation. was (Author: bkalbfus): I am solving this by patching datanucleus-api-jdo. JDOQLTypedQueryImpl is getting a query from the primaryStoreMgr instead of finding the correct StoreManager for the class. > DataNucleus Federated Datastore functionality not used in query > --- > > Key: ISIS-2020 > URL: https://issues.apache.org/jira/browse/ISIS-2020 > Project: Isis > Issue Type: Bug > Components: Core: Objectstore: JDO >Affects Versions: 1.16.2, 2.0.0-M1 >Reporter: Brian Kalbfus >Priority: Major > Attachments: datanucleus-api-jdo.patch > > > Insert and Update operations work as expected, but query operations operate > on the primary datastore. I see from stepping through the M1 code that > Insert and Update operations use a transaction that accesses a > FederatedDataStore. I guess that is where the difference occurs in that the > query operations get a data store another way, failing to get the > FederatedDataStore that is configured. > example code created from helloworld-archetype is at > [https://github.com/bkalbfus/isis-federatedDS-2_0_0-M1] > Mailing list: > [https://lists.apache.org/thread.html/2edea2f8d802532c3672eddc83b484bbc2e31d1cac16f2759feeb95f@%3Cusers.isis.apache.org%3E] > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ISIS-2020) DataNucleus Federated Datastore functionality not used in query
[ https://issues.apache.org/jira/browse/ISIS-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Kalbfus updated ISIS-2020: Attachment: datanucleus-api-jdo.patch > DataNucleus Federated Datastore functionality not used in query > --- > > Key: ISIS-2020 > URL: https://issues.apache.org/jira/browse/ISIS-2020 > Project: Isis > Issue Type: Bug > Components: Core: Objectstore: JDO >Affects Versions: 1.16.2, 2.0.0-M1 >Reporter: Brian Kalbfus >Priority: Major > Attachments: datanucleus-api-jdo.patch > > > Insert and Update operations work as expected, but query operations operate > on the primary datastore. I see from stepping through the M1 code that > Insert and Update operations use a transaction that accesses a > FederatedDataStore. I guess that is where the difference occurs in that the > query operations get a data store another way, failing to get the > FederatedDataStore that is configured. > example code created from helloworld-archetype is at > [https://github.com/bkalbfus/isis-federatedDS-2_0_0-M1] > Mailing list: > [https://lists.apache.org/thread.html/2edea2f8d802532c3672eddc83b484bbc2e31d1cac16f2759feeb95f@%3Cusers.isis.apache.org%3E] > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ISIS-2020) DataNucleus Federated Datastore functionality not used in query
Brian Kalbfus created ISIS-2020: --- Summary: DataNucleus Federated Datastore functionality not used in query Key: ISIS-2020 URL: https://issues.apache.org/jira/browse/ISIS-2020 Project: Isis Issue Type: Bug Components: Core: Objectstore: JDO Affects Versions: 1.16.2, 2.0.0-M1 Reporter: Brian Kalbfus Insert and Update operations work as expected, but query operations operate on the primary datastore. I see from stepping through the M1 code that Insert and Update operations use a transaction that accesses a FederatedDataStore. I guess that is where the difference occurs in that the query operations get a data store another way, failing to get the FederatedDataStore that is configured. example code created from helloworld-archetype is at [https://github.com/bkalbfus/isis-federatedDS-2_0_0-M1] Mailing list: [https://lists.apache.org/thread.html/2edea2f8d802532c3672eddc83b484bbc2e31d1cac16f2759feeb95f@%3Cusers.isis.apache.org%3E] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
