[jira] [Created] (ISIS-1440) Use Fork/Join framework to load specifications in parallel? (speed up bootstrap time on multi-core machines)
Dan Haywood created ISIS-1440: - Summary: Use Fork/Join framework to load specifications in parallel? (speed up bootstrap time on multi-core machines) Key: ISIS-1440 URL: https://issues.apache.org/jira/browse/ISIS-1440 Project: Isis Issue Type: Improvement Components: Core Affects Versions: 1.12.2 Reporter: Dan Haywood Assignee: Dan Haywood Priority: Minor Fix For: 1.14.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ISIS-1439) Handle default methods defined in interfaces (JDK8)
Dan Haywood created ISIS-1439: - Summary: Handle default methods defined in interfaces (JDK8) Key: ISIS-1439 URL: https://issues.apache.org/jira/browse/ISIS-1439 Project: Isis Issue Type: Improvement Components: Core Affects Versions: 1.12.2 Reporter: Dan Haywood Assignee: Dan Haywood Priority: Minor Fix For: 1.14.0 For example, IsisConfigurationDefault service has spliterator() and forEach(), by virtue of implementing Iterator interface. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ISIS-1438) Set up JAXBContext for ChangesDtoUtils and the others in a background thread.
Dan Haywood created ISIS-1438: - Summary: Set up JAXBContext for ChangesDtoUtils and the others in a background thread. Key: ISIS-1438 URL: https://issues.apache.org/jira/browse/ISIS-1438 Project: Isis Issue Type: Improvement Components: Core Affects Versions: 1.12.2 Reporter: Dan Haywood Assignee: Dan Haywood Priority: Minor Fix For: 1.13.0 ... so that they are ready to use by the time required. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ISIS-1437) (If possible), configure slow-running Wicket bootstrapping in separate background threads.
Dan Haywood created ISIS-1437:
-
Summary: (If possible), configure slow-running Wicket
bootstrapping in separate background threads.
Key: ISIS-1437
URL: https://issues.apache.org/jira/browse/ISIS-1437
Project: Isis
Issue Type: Improvement
Components: Core
Affects Versions: 1.12.2
Reporter: Dan Haywood
Assignee: Dan Haywood
Priority: Minor
Fix For: 1.13.0
eg
{code}
configureWebJars();
configureWicketBootstrap();
configureWicketSelect2();
{code}
These methods are called during {{init()}}, same place that Isis itself is
initialized. So could do a fork/join and ensure complete before exiting the
init().
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ISIS-1401) NPE when wrapping call to FixtureScripts#runFixtureScript for a newly instantiated FixtureScript
[
https://issues.apache.org/jira/browse/ISIS-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15330488#comment-15330488
]
Dan Haywood commented on ISIS-1401:
---
To reproduce, I've added:
{code}
@Action(
restrictTo = RestrictTo.PROTOTYPING
)
@MemberOrder(sequence = "499.10.2")
public Object test() {
final BusRulesObjectsFixture fixtureScript = new
BusRulesObjectsFixture();
return wrapperFactory.wrap(this).runFixtureScript(fixtureScript, null);
}
@Inject
WrapperFactory wrapperFactory;
{code}
to {{KitchensinkFixturesService}} in the kitchensink app.
One solution is to manually inject services into the fixture script beforehand:
{code}
@Action(
restrictTo = RestrictTo.PROTOTYPING
)
@MemberOrder(sequence = "499.10.2")
public Object test() {
final BusRulesObjectsFixture fixtureScript = new
BusRulesObjectsFixture();
serviceRegistry2.injectServicesInto(fixtureScript);
return wrapperFactory.wrap(this).runFixtureScript(fixtureScript, null);
}
@Inject
WrapperFactory wrapperFactory;
@Inject
ServiceRegistry2 serviceRegistry2;
{code}
An alternative would be to refactor the FixtureScript superclass to use
@ViewModel or @XmlRootElement. However, this could, perhaps, have unexpected
side-effects, so I'd rather leave things as they are for now.
> NPE when wrapping call to FixtureScripts#runFixtureScript for a newly
> instantiated FixtureScript
> -
>
> Key: ISIS-1401
> URL: https://issues.apache.org/jira/browse/ISIS-1401
> Project: Isis
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.12.1
>Reporter: Oscar Bou
>Assignee: Dan Haywood
> Fix For: 1.13.0
>
>
> The FixtureScripts#runFixtureScript action is marked as "Prototyping", and
> basically there's no need to invoke it wrapped, but perhaps is relevant for
> other use cases.
> When executing something like:
> this.wrap(this.fixtureScripts).runFixtureScript(
> new MyFixtureScript(), null);
> A NullPointerException is thrown, as for the execution on
> DomainObjectInvokationHandler#handleActionMethod requires to create an
> adapter for the contributee (line 590):
> [java]
> contributeeAdapter = adapterFor(contributed);
> [/java]
> As the MyFixtureScript is a ViewModel, this will be delegated to
> FixtureScript#viewModelMemento() which in fact will contain:
> [java]
> @Programmatic
> @Override
> public String viewModelMemento() {
> return fixtureScripts.mementoFor(this);
> }
> [/java]
> Being "fixtureScripts" null.
> Not sure how to solve this, as basically the FixtureScript requires to be
> injected before executing it.
> As perhaps this will be the only method that can potentially been invoked
> before the FixtureScript being wrapped on the "FixtureScripts" service, an
> easy solution would be to check if the "fixtureScript" variable is null and,
> in that case, inject its own instance on this same method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ISIS-1401) NPE when wrapping call to FixtureScripts#runFixtureScript for a newly instantiated FixtureScript
[
https://issues.apache.org/jira/browse/ISIS-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Haywood resolved ISIS-1401.
---
Resolution: Won't Fix
> NPE when wrapping call to FixtureScripts#runFixtureScript for a newly
> instantiated FixtureScript
> -
>
> Key: ISIS-1401
> URL: https://issues.apache.org/jira/browse/ISIS-1401
> Project: Isis
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.12.1
>Reporter: Oscar Bou
>Assignee: Dan Haywood
> Fix For: 1.13.0
>
>
> The FixtureScripts#runFixtureScript action is marked as "Prototyping", and
> basically there's no need to invoke it wrapped, but perhaps is relevant for
> other use cases.
> When executing something like:
> this.wrap(this.fixtureScripts).runFixtureScript(
> new MyFixtureScript(), null);
> A NullPointerException is thrown, as for the execution on
> DomainObjectInvokationHandler#handleActionMethod requires to create an
> adapter for the contributee (line 590):
> [java]
> contributeeAdapter = adapterFor(contributed);
> [/java]
> As the MyFixtureScript is a ViewModel, this will be delegated to
> FixtureScript#viewModelMemento() which in fact will contain:
> [java]
> @Programmatic
> @Override
> public String viewModelMemento() {
> return fixtureScripts.mementoFor(this);
> }
> [/java]
> Being "fixtureScripts" null.
> Not sure how to solve this, as basically the FixtureScript requires to be
> injected before executing it.
> As perhaps this will be the only method that can potentially been invoked
> before the FixtureScript being wrapped on the "FixtureScripts" service, an
> easy solution would be to check if the "fixtureScript" variable is null and,
> in that case, inject its own instance on this same method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ISIS-1401) NPE when wrapping call to FixtureScripts#runFixtureScript for a newly instantiated FixtureScript
[
https://issues.apache.org/jira/browse/ISIS-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15330272#comment-15330272
]
Dan Haywood commented on ISIS-1401:
---
To reproduce, I've added:
{code}
@Action(
restrictTo = RestrictTo.PROTOTYPING
)
@MemberOrder(sequence = "499.10.2")
public Object test() {
final BusRulesObjectsFixture fixtureScript = new
BusRulesObjectsFixture();
return wrapperFactory.wrap(this).runFixtureScript(fixtureScript, null);
}
@Inject
WrapperFactory wrapperFactory;
{code}
to {{KitchensinkFixturesService}} in the kitchensink app.
One solution is to manually inject services into the fixture script beforehand:
{code}
@Action(
restrictTo = RestrictTo.PROTOTYPING
)
@MemberOrder(sequence = "499.10.2")
public Object test() {
final BusRulesObjectsFixture fixtureScript = new
BusRulesObjectsFixture();
serviceRegistry2.injectServicesInto(fixtureScript);
return wrapperFactory.wrap(this).runFixtureScript(fixtureScript, null);
}
@Inject
WrapperFactory wrapperFactory;
@Inject
ServiceRegistry2 serviceRegistry2;
{code}
An alternative would be to refactor the FixtureScript superclass to use
@ViewModel or @XmlRootElement. However, this could, perhaps, have unexpected
side-effects, so I'd rather leave things as they are for now.
> NPE when wrapping call to FixtureScripts#runFixtureScript for a newly
> instantiated FixtureScript
> -
>
> Key: ISIS-1401
> URL: https://issues.apache.org/jira/browse/ISIS-1401
> Project: Isis
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.12.1
>Reporter: Oscar Bou
>Assignee: Dan Haywood
> Fix For: 1.13.0
>
>
> The FixtureScripts#runFixtureScript action is marked as "Prototyping", and
> basically there's no need to invoke it wrapped, but perhaps is relevant for
> other use cases.
> When executing something like:
> this.wrap(this.fixtureScripts).runFixtureScript(
> new MyFixtureScript(), null);
> A NullPointerException is thrown, as for the execution on
> DomainObjectInvokationHandler#handleActionMethod requires to create an
> adapter for the contributee (line 590):
> [java]
> contributeeAdapter = adapterFor(contributed);
> [/java]
> As the MyFixtureScript is a ViewModel, this will be delegated to
> FixtureScript#viewModelMemento() which in fact will contain:
> [java]
> @Programmatic
> @Override
> public String viewModelMemento() {
> return fixtureScripts.mementoFor(this);
> }
> [/java]
> Being "fixtureScripts" null.
> Not sure how to solve this, as basically the FixtureScript requires to be
> injected before executing it.
> As perhaps this will be the only method that can potentially been invoked
> before the FixtureScript being wrapped on the "FixtureScripts" service, an
> easy solution would be to check if the "fixtureScript" variable is null and,
> in that case, inject its own instance on this same method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ISIS-1334) Create standalone JAR of an Isis app
[ https://issues.apache.org/jira/browse/ISIS-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15329425#comment-15329425 ] Jeroen van der Wal commented on ISIS-1334: -- Has anybody experience with Undertow [1]? [1] http://undertow.io/ > Create standalone JAR of an Isis app > > > Key: ISIS-1334 > URL: https://issues.apache.org/jira/browse/ISIS-1334 > Project: Isis > Issue Type: New Feature >Affects Versions: 1.11.1 >Reporter: Dan Haywood >Assignee: Dan Haywood >Priority: Minor > Fix For: 1.14.0 > > > Being able to have a standalone jar (eg java -jar xxx.jar), which I can see > would be useful for microservice type deployments. > using assembly plugin and our current org.apache.isis.WebServer does not > quite work, since our bootstrapping code assumes that config files can be > read as files rather than in the classpath. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ISIS-1436) When executing a bulk action on a paginated collection items, chosen items can be ignored unintentionally
[ https://issues.apache.org/jira/browse/ISIS-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Haywood updated ISIS-1436: -- Attachment: Screen Shot 2016-06-09 at 16.01.48.png Screen Shot 2016-06-09 at 16.02.02.png Screen Shot 2016-06-09 at 16.02.17.png > When executing a bulk action on a paginated collection items, chosen items > can be ignored unintentionally > - > > Key: ISIS-1436 > URL: https://issues.apache.org/jira/browse/ISIS-1436 > Project: Isis > Issue Type: Bug > Components: Core: Viewer: Wicket >Affects Versions: 1.12.2 >Reporter: Dan Haywood >Assignee: Dan Haywood > Fix For: 1.13.0 > > Attachments: Screen Shot 2016-06-09 at 16.01.48.png, Screen Shot > 2016-06-09 at 16.02.02.png, Screen Shot 2016-06-09 at 16.02.17.png > > > When executing a bulk action on paginated collection the action is not > executed on all items after choosing 'list all' (in order to undo pagination > in UI), 'select all' and then executing the action. > The issue can be reproduced using kitchensink - bulk. (In the attached > screenshots extra items in the fixturescript) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ISIS-1436) When executing a bulk action on a paginated collection items, chosen items can be ignored unintentionally
[ https://issues.apache.org/jira/browse/ISIS-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Haywood updated ISIS-1436: -- Summary: When executing a bulk action on a paginated collection items, chosen items can be ignored unintentionally (was: bulk actions don't work correctly for paged collections.) > When executing a bulk action on a paginated collection items, chosen items > can be ignored unintentionally > - > > Key: ISIS-1436 > URL: https://issues.apache.org/jira/browse/ISIS-1436 > Project: Isis > Issue Type: Bug > Components: Core: Viewer: Wicket >Affects Versions: 1.12.2 >Reporter: Dan Haywood >Assignee: Dan Haywood > Fix For: 1.13.0 > > > When executing a bulk action on paginated collection the action is not > executed on all items after choosing 'list all' (in order to undo pagination > in UI), 'select all' and then executing the action. > The issue can be reproduced using kitchensink - bulk. (In the attached > screenshots extra items in the fixturescript) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ISIS-1436) bulk actions don't work correctly for paged collections.
[ https://issues.apache.org/jira/browse/ISIS-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Haywood updated ISIS-1436: -- Description: When executing a bulk action on paginated collection the action is not executed on all items after choosing 'list all' (in order to undo pagination in UI), 'select all' and then executing the action. The issue can be reproduced using kitchensink - bulk. (In the attached screenshots extra items in the fixturescript) > bulk actions don't work correctly for paged collections. > > > Key: ISIS-1436 > URL: https://issues.apache.org/jira/browse/ISIS-1436 > Project: Isis > Issue Type: Bug > Components: Core: Viewer: Wicket >Affects Versions: 1.12.2 >Reporter: Dan Haywood >Assignee: Dan Haywood > Fix For: 1.13.0 > > > When executing a bulk action on paginated collection the action is not > executed on all items after choosing 'list all' (in order to undo pagination > in UI), 'select all' and then executing the action. > The issue can be reproduced using kitchensink - bulk. (In the attached > screenshots extra items in the fixturescript) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ISIS-1436) bulk actions don't work correctly for paged collections.
Dan Haywood created ISIS-1436: - Summary: bulk actions don't work correctly for paged collections. Key: ISIS-1436 URL: https://issues.apache.org/jira/browse/ISIS-1436 Project: Isis Issue Type: Bug Components: Core: Viewer: Wicket Affects Versions: 1.12.2 Reporter: Dan Haywood Assignee: Dan Haywood Fix For: 1.13.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
