[jira] [Commented] (UNOMI-180) Implement CXS GraphQL specification
[ https://issues.apache.org/jira/browse/UNOMI-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023022#comment-17023022 ] Jeroen van der Wal commented on UNOMI-180: -- The schema specification has moved to a different location: [|https://github.com/oasis-tcs/cxs-cdp/blob/master/server/index.js] [https://github.com/oasis-tcs/cxs-cdp/tree/master/server] > Implement CXS GraphQL specification > --- > > Key: UNOMI-180 > URL: https://issues.apache.org/jira/browse/UNOMI-180 > Project: Apache Unomi > Issue Type: Improvement > Components: core >Affects Versions: 1.3.0-incubating >Reporter: Serge Huber >Priority: Major > Fix For: 2.0.0 > > > We should implement the CXS specification, as we are supposed to. The > specification has now switched from REST API to GraphQL API, so the work will > begin on implementing GraphQL in a separate branch. > Basically we are implementing the specification that is tracked here : > [https://github.com/sergehuber/contextserver-graphql-api/blob/master/javascript/cxs-graphql-schema.js] > The idea is to implement this API on top of the existing data and structure > already inside Apache Unomi. Some model adjustements might be needed but the > goal is to keep the REST API compatible. Hopefully this will be possible :) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ISIS-1020) Dropdown window opens top left of the screen
[ https://issues.apache.org/jira/browse/ISIS-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal updated ISIS-1020: - Affects Version/s: 1.12.2 > Dropdown window opens top left of the screen > > > Key: ISIS-1020 > URL: https://issues.apache.org/jira/browse/ISIS-1020 > Project: Isis > Issue Type: Bug > Components: Core: Viewer: Wicket >Affects Versions: core-1.8.0, 1.12.2 >Reporter: Jeroen van der Wal > Fix For: 1.10.0 > > > The original issue reported here was that the select2 component sometimes > renders the drop-down top-left of the screen. > This ticket has been rescoped to just upgrade select2 to 3.5.2. This was > attempted as a fix, but does not address the issue. > We believe that select2 v4 will fix the issue, for this see ISIS-1224. Note > that this depends upon Wicket 7.x (ISIS-1223). > If select2 v4 does not fix the issue, then we have also raised a ticket to > rework using the selectize component (ISIS-1225). This is also our preferred > component to implement multi-select (ISIS-709). > ~ > Screencast to demonstrate the original issue in Estatio: > https://drive.google.com/file/d/0B2jd2Sl73mDBZ0lqYUhtVjVRamc/view?usp=sharing > This is reproducible in both IE11 and Chrome. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (ISIS-1020) upgrade select2 to v3.5.2 (was: Dropdown window opens top left of the screen)
[ https://issues.apache.org/jira/browse/ISIS-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal reopened ISIS-1020: -- This issue still needs some TLC > upgrade select2 to v3.5.2 (was: Dropdown window opens top left of the screen) > - > > Key: ISIS-1020 > URL: https://issues.apache.org/jira/browse/ISIS-1020 > Project: Isis > Issue Type: Bug > Components: Core: Viewer: Wicket >Affects Versions: core-1.8.0 >Reporter: Jeroen van der Wal > Fix For: 1.10.0 > > > The original issue reported here was that the select2 component sometimes > renders the drop-down top-left of the screen. > This ticket has been rescoped to just upgrade select2 to 3.5.2. This was > attempted as a fix, but does not address the issue. > We believe that select2 v4 will fix the issue, for this see ISIS-1224. Note > that this depends upon Wicket 7.x (ISIS-1223). > If select2 v4 does not fix the issue, then we have also raised a ticket to > rework using the selectize component (ISIS-1225). This is also our preferred > component to implement multi-select (ISIS-709). > ~ > Screencast to demonstrate the original issue in Estatio: > https://drive.google.com/file/d/0B2jd2Sl73mDBZ0lqYUhtVjVRamc/view?usp=sharing > This is reproducible in both IE11 and Chrome. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ISIS-1020) Dropdown window opens top left of the screen
[ https://issues.apache.org/jira/browse/ISIS-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal updated ISIS-1020: - Summary: Dropdown window opens top left of the screen (was: upgrade select2 to v3.5.2 (was: Dropdown window opens top left of the screen)) > Dropdown window opens top left of the screen > > > Key: ISIS-1020 > URL: https://issues.apache.org/jira/browse/ISIS-1020 > Project: Isis > Issue Type: Bug > Components: Core: Viewer: Wicket >Affects Versions: core-1.8.0 >Reporter: Jeroen van der Wal > Fix For: 1.10.0 > > > The original issue reported here was that the select2 component sometimes > renders the drop-down top-left of the screen. > This ticket has been rescoped to just upgrade select2 to 3.5.2. This was > attempted as a fix, but does not address the issue. > We believe that select2 v4 will fix the issue, for this see ISIS-1224. Note > that this depends upon Wicket 7.x (ISIS-1223). > If select2 v4 does not fix the issue, then we have also raised a ticket to > rework using the selectize component (ISIS-1225). This is also our preferred > component to implement multi-select (ISIS-709). > ~ > Screencast to demonstrate the original issue in Estatio: > https://drive.google.com/file/d/0B2jd2Sl73mDBZ0lqYUhtVjVRamc/view?usp=sharing > This is reproducible in both IE11 and Chrome. -- 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] [Commented] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15157167#comment-15157167 ] Jeroen van der Wal commented on ISIS-1303: -- When I pitch Apache Isis I always use phrases like "single layer application development", "layerless application development" or simply "no layers". > Rename the project to better describe its values and purpose > > > Key: ISIS-1303 > URL: https://issues.apache.org/jira/browse/ISIS-1303 > Project: Isis > Issue Type: Wish >Affects Versions: 1.11.1 >Reporter: Dan Haywood >Assignee: Dan Haywood > Fix For: 1.13.0 > > Attachments: ApacheFarthing.jpg, ApacheFarthing.jpg, > ApacheGestalt.jpg, Offset-curves-of-sinus-curve.svg > > > In the past there have been a couple of discussions regarding renaming the > project, the reason generally cited being the potential embarrassment of > sharing a name with the jihadist militant group [1] currently prominent in > the headlines. After due discussion on the mailing lists the prevailing view > has been to retain our name: "we were here first". > Until now I've concurred with that view also... after all, I originally came > up with the name "Isis", originally based on the name of the Thames as it > flows through Oxford [2] (many of the original authors of the framework live > within Oxfordshire, UK). > Separately to that discussion, we have the issue of marketing. Originally we > marketed ourselves as a framework implementing the "naked objects" pattern > [3]; the original name of the framework (prior to Apache) was of course the > Naked Objects Framework. However, this pattern is either not well-known or > is misunderstood (only a low proportion of developers that encounter the idea > immediately "get it"). The crudity of the original user interfaces didn't > help. And the name also, of course, can cause embarrassment in some cultures. > Then, when domain-driven design [4] came along as a movement, that seemed an > obvious platform upon which to position the framework: we obviously share the > core belief that the domain is the most important bit of the system. However > - and I still find this surprising - despite attempts otherwise we haven't > really made too much of an impression in that community. The fact that the > DDD community got massively sidetracked for a while by the CQRS pattern is > perhaps part of it. I also often detect the view that DDD should imply not > using a framework. The irony of course is that in rejecting framework such > developers actually have to write more infrastructure code vs business domain > code. > Also, the fit is perhaps not all that good after all. In the DDD community I > don't see anyone talking about modules... one of the named patterns, and a > major focus of our framework, but missing from DDD talks. Instead they get > side-tracked talking only about aggregate roots or bounded contexts; all well > and good, but over-emphasised). > [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in > person), and he agreed there was little emphasis. When I described our > framework's use of domain events to hook modules together (along with vetoing > behaviour we support) he admitted it was a new approach/pattern to him...] > Anyway, so DDD - which looked so promising - hasn't delivered. They might > come around to us one day, but it's probably time to define our own > individual space. Also, in the same way that everyone takes agile > development for granted as the "de facto", we ought to simply take DDD for > granted too... "of course you will be doing DDD, but are you doing it well?" > What we need to better market the framework is some other pattern or concept > or hook, and become known as the framework that best supports that idea. > There are several candidates: > - hexagonal architecture (also called ports and adapters, or the onion > architecture, and related to the clean architecture) > - don't repeat yourself principle > - aspect oriented programming (naked objects pattern is really the > recognition that UI presentation is a cross-cutting concern) > - the general concept of modularity > - DCI (data/context/interactions). > - "clean" "pure" "essential" pojo programming model > - agile, lean > - breaking down barriers between IT and business > Of these, I think that hexagonal architecture looks the best fit; it is well > regarded as a concept among the "cognoscenti", but there are surprisingly no > open source frameworks out there (at least in the Java space) that position > themselves as being the natural choice. > Therefore, I think a name - and appropriate short tag line - based around > this idea of hexagonal architecture should be considered. >
[jira] [Created] (ISIS-1310) DomainObjectContainter#titleOf(..) does not resolve @Title annotated on private field
Jeroen van der Wal created ISIS-1310: Summary: DomainObjectContainter#titleOf(..) does not resolve @Title annotated on private field Key: ISIS-1310 URL: https://issues.apache.org/jira/browse/ISIS-1310 Project: Isis Issue Type: Bug Components: Core Affects Versions: 1.11.1 Reporter: Jeroen van der Wal Assignee: Dan Haywood Priority: Minor DomainObjectContainter#titleOf(..) does not resolve @Title annotated on a private field. As a workaround you can use the title() method to provide a title. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ISIS-1306) Enable graph visualisation in Wicket Viewer
[ https://issues.apache.org/jira/browse/ISIS-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal updated ISIS-1306: - Priority: Minor (was: Major) > Enable graph visualisation in Wicket Viewer > --- > > Key: ISIS-1306 > URL: https://issues.apache.org/jira/browse/ISIS-1306 > Project: Isis > Issue Type: New Feature > Components: Core: Viewer: Wicket >Reporter: Vladimir Nisevic >Assignee: Dan Haywood >Priority: Minor > > Would be nice to have possibility to visualize graphs with. e.g > http://graphviz.org/ or maybe with http://visjs.org/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ISIS-1306) Enable graph visualisation in Wicket Viewer
[ https://issues.apache.org/jira/browse/ISIS-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal updated ISIS-1306: - Issue Type: Wish (was: Brainstorming) > Enable graph visualisation in Wicket Viewer > --- > > Key: ISIS-1306 > URL: https://issues.apache.org/jira/browse/ISIS-1306 > Project: Isis > Issue Type: Wish > Components: Core: Viewer: Wicket >Reporter: Vladimir Nisevic >Assignee: Dan Haywood >Priority: Minor > > Would be nice to have possibility to visualize graphs with. e.g > http://graphviz.org/ or maybe with http://visjs.org/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ISIS-1306) Enable graph visualisation in Wicket Viewer
[ https://issues.apache.org/jira/browse/ISIS-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15142849#comment-15142849 ] Jeroen van der Wal commented on ISIS-1306: -- This a rather vague requirement. Could you elaborate more? Perhaps spike a sample app? > Enable graph visualisation in Wicket Viewer > --- > > Key: ISIS-1306 > URL: https://issues.apache.org/jira/browse/ISIS-1306 > Project: Isis > Issue Type: Wish > Components: Core: Viewer: Wicket >Reporter: Vladimir Nisevic >Assignee: Dan Haywood >Priority: Minor > > Would be nice to have possibility to visualize graphs with. e.g > http://graphviz.org/ or maybe with http://visjs.org/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ISIS-1306) Enable graph visualisation in Wicket Viewer
[ https://issues.apache.org/jira/browse/ISIS-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal updated ISIS-1306: - Issue Type: Brainstorming (was: New Feature) > Enable graph visualisation in Wicket Viewer > --- > > Key: ISIS-1306 > URL: https://issues.apache.org/jira/browse/ISIS-1306 > Project: Isis > Issue Type: Brainstorming > Components: Core: Viewer: Wicket >Reporter: Vladimir Nisevic >Assignee: Dan Haywood >Priority: Minor > > Would be nice to have possibility to visualize graphs with. e.g > http://graphviz.org/ or maybe with http://visjs.org/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ISIS-1209) Perform static analysis of all event subscribers so that we suppress the submission of events if we know that there are no subscribers in that type of event.
[ https://issues.apache.org/jira/browse/ISIS-1209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15013194#comment-15013194 ] Jeroen van der Wal commented on ISIS-1209: -- If a developer creates events it might also be because he wants to allow other developers to override behaviour, like we do in the isisaddons. In practice this hooks are hardly ever used. > Perform static analysis of all event subscribers so that we suppress the > submission of events if we know that there are no subscribers in that type of > event. > - > > Key: ISIS-1209 > URL: https://issues.apache.org/jira/browse/ISIS-1209 > Project: Isis > Issue Type: Improvement > Components: Core >Affects Versions: 1.9.0 >Reporter: Dan Haywood >Assignee: Dan Haywood > Fix For: 2.0.0 > > > ... on the basis that - I think - raising so many events is what is causing > the framework to be slower than once it was. > Before doing this ticket we should test this theory first, though. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (ISIS-1209) Perform static analysis of all event subscribers so that we suppress the submission of events if we know that there are no subscribers in that type of event.
[ https://issues.apache.org/jira/browse/ISIS-1209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15013194#comment-15013194 ] Jeroen van der Wal edited comment on ISIS-1209 at 11/19/15 9:14 AM: If a developer creates events it might also be because he wants to allow other developers to override behaviour, like we do in the isisaddons. In practice these hooks are hardly ever used. was (Author: jcvanderwal): If a developer creates events it might also be because he wants to allow other developers to override behaviour, like we do in the isisaddons. In practice this hooks are hardly ever used. > Perform static analysis of all event subscribers so that we suppress the > submission of events if we know that there are no subscribers in that type of > event. > - > > Key: ISIS-1209 > URL: https://issues.apache.org/jira/browse/ISIS-1209 > Project: Isis > Issue Type: Improvement > Components: Core >Affects Versions: 1.9.0 >Reporter: Dan Haywood >Assignee: Dan Haywood > Fix For: 2.0.0 > > > ... on the basis that - I think - raising so many events is what is causing > the framework to be slower than once it was. > Before doing this ticket we should test this theory first, though. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ISIS-1221) JSON Format Layouts not recognized with i18n translations in Wicket Viewer
[ https://issues.apache.org/jira/browse/ISIS-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14990696#comment-14990696 ] Jeroen van der Wal commented on ISIS-1221: -- Ican reproduce the issue with your demo repo but haven't found time to look into it in more detail. Will try to squeeze it in tomorrow. > JSON Format Layouts not recognized with i18n translations in Wicket Viewer > -- > > Key: ISIS-1221 > URL: https://issues.apache.org/jira/browse/ISIS-1221 > Project: Isis > Issue Type: Bug > Components: Core: Viewer: Wicket >Affects Versions: 1.9.0 > Environment: Windows Server, HSQLDB >Reporter: Cesar Lugo >Assignee: Dan Haywood > > I am working with Apache Isis Wicket viewer 1.9.0, and I have some form > layout json files to define the layout for some domain objects. I also added > a translation file (i18n) with some translations. When running the > application in the browser, when I am in “writing translations” mode it shows > the object form with the layout defined in the json file (ok), but when I > switch to “reading translations”, it goes back to the “default” layout, > ignoring the layout defined in the json file. > In regards to those modes, I am referring to the Apache wicket viewer menu > which, in prototype mode, has a "Prototyping" menu, which has an option > "Switch to Reading Translations". When you select that option and keep using > the application is when it loses the layouts defined in the json layout files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ISIS-1240) Derive icon from service when not provided
Jeroen van der Wal created ISIS-1240: Summary: Derive icon from service when not provided Key: ISIS-1240 URL: https://issues.apache.org/jira/browse/ISIS-1240 Project: Isis Issue Type: Improvement Components: Core Affects Versions: 1.9.0 Reporter: Jeroen van der Wal Assignee: Dan Haywood Priority: Minor If no iconName method is provided for a service Isis searches for an icon equal to the service name. Additional to this behavior we could extend this search by stripping off know service suffixes like "Service, Menu and Repository". As an example: the "PersonMenu" service will use the "Person" icon if no icon has been specified. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ISIS-803) Replace lifecycle methods with additional EventBus events.
[ https://issues.apache.org/jira/browse/ISIS-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal updated ISIS-803: Priority: Minor (was: Major) > Replace lifecycle methods with additional EventBus events. > -- > > Key: ISIS-803 > URL: https://issues.apache.org/jira/browse/ISIS-803 > Project: Isis > Issue Type: Improvement > Components: Core >Affects Versions: core-1.5.0 >Reporter: Dan Haywood >Assignee: Dan Haywood >Priority: Minor > Fix For: 1.11.0 > > > This issue is to remove a feature that is only partly implemented in the JDO > objectstore, namely the lifecycle methods. > Jeroen and I were discussing this, and think they are possibly an > anti-pattern since they tend to lead to fragile code. > Rather than have the object "pushing" changes to others, it would be better > if an event were broadcast via the EventBus. That way a subscribing service > could pull appropriate changes and do whatever is necessary. > ~~~ > Possible implementation: > @DomainObject( > domainEventOnLoad = ..., > domainEventOnSave = ..., > domainEventOnUpdate = ..., > domainEventOnDelete = ..., > ) > By using the corresponding associated phases, ie EXECUTING and EXECUTED, the > subscriber can act BEFORE and/or AFTER the domain object is loaded / > initially saved-persisted / updated / deleted. > The "domainEventOnLoad" event would allow the user to "veto" a specific > domain entity instance (domain object) to be showed due to security or other > business reasons. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ISIS-1221) JSON Format Layouts not recognized with i18n translations in Wicket Viewer
[ https://issues.apache.org/jira/browse/ISIS-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14984409#comment-14984409 ] Jeroen van der Wal commented on ISIS-1221: -- Hi Cesar, thanks for setting up the repo. I will check it out later today. > JSON Format Layouts not recognized with i18n translations in Wicket Viewer > -- > > Key: ISIS-1221 > URL: https://issues.apache.org/jira/browse/ISIS-1221 > Project: Isis > Issue Type: Bug > Components: Core: Viewer: Wicket >Affects Versions: 1.9.0 > Environment: Windows Server, HSQLDB >Reporter: Cesar Lugo >Assignee: Dan Haywood > > I am working with Apache Isis Wicket viewer 1.9.0, and I have some form > layout json files to define the layout for some domain objects. I also added > a translation file (i18n) with some translations. When running the > application in the browser, when I am in “writing translations” mode it shows > the object form with the layout defined in the json file (ok), but when I > switch to “reading translations”, it goes back to the “default” layout, > ignoring the layout defined in the json file. > In regards to those modes, I am referring to the Apache wicket viewer menu > which, in prototype mode, has a "Prototyping" menu, which has an option > "Switch to Reading Translations". When you select that option and keep using > the application is when it loses the layouts defined in the json layout files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ISIS-1221) JSON Format Layouts not recognized with i18n translations in Wicket Viewer
[ https://issues.apache.org/jira/browse/ISIS-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14978646#comment-14978646 ] Jeroen van der Wal commented on ISIS-1221: -- I was not able to reproduce this with the kitchensink app [1], running on 1.9.0-SNAPSHOT (technically our 1.10.0 release candidate). [1] https://github.com/isisaddons/isis-app-kitchensink > JSON Format Layouts not recognized with i18n translations in Wicket Viewer > -- > > Key: ISIS-1221 > URL: https://issues.apache.org/jira/browse/ISIS-1221 > Project: Isis > Issue Type: Bug > Components: Core: Viewer: Wicket >Affects Versions: 1.9.0 > Environment: Windows Server, HSQLDB >Reporter: Cesar Lugo >Assignee: Dan Haywood > > I am working with Apache Isis Wicket viewer 1.9.0, and I have some form > layout json files to define the layout for some domain objects. I also added > a translation file (i18n) with some translations. When running the > application in the browser, when I am in “writing translations” mode it shows > the object form with the layout defined in the json file (ok), but when I > switch to “reading translations”, it goes back to the “default” layout, > ignoring the layout defined in the json file. > In regards to those modes, I am referring to the Apache wicket viewer menu > which, in prototype mode, has a "Prototyping" menu, which has an option > "Switch to Reading Translations". When you select that option and keep using > the application is when it loses the layouts defined in the json layout files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ISIS-542) Restrict which entities a service action is contributed to (as either a contributed action or contributed assocation).
[
https://issues.apache.org/jira/browse/ISIS-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14738919#comment-14738919
]
Jeroen van der Wal commented on ISIS-542:
-
+2 from Jeroen & Johan ;-)
Since we're using contributions more and more we like to start working on this
issue. We suggest extending @ParameterLayout with a contributed parameter.
Something like this:
public class PartyContributions{
public void moveFundsTo(
final Party fromParty,
final @ParameterLayout(contributed = Contributed.Never) Party toParty) {
}
}
> Restrict which entities a service action is contributed to (as either a
> contributed action or contributed assocation).
> --
>
> Key: ISIS-542
> URL: https://issues.apache.org/jira/browse/ISIS-542
> Project: Isis
> Issue Type: New Feature
> Components: Core
>Affects Versions: core-1.2.0
>Reporter: Dan Haywood
>Assignee: Dan Haywood
> Fix For: 1.12.0
>
>
> For example, an action
> void foo(A a, B b) { ... }
> will be contributed to both entities A and B. We might want to allow it to
> be contributed to one or the other.
> Suggestion is that @NotContributed annotation applies to action parameters
> (with current behaviour maintained for compatibility as the default for all
> parameters of the action):
> eg
> void foo(
> @NotContributed(As.Action) A,
> @NotContributed(As.Association) B) { ... }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ISIS-1193) void actions return 404 Not Found when called through restful viewer
Jeroen van der Wal created ISIS-1193:
Summary: void actions return 404 Not Found when called through
restful viewer
Key: ISIS-1193
URL: https://issues.apache.org/jira/browse/ISIS-1193
Project: Isis
Issue Type: Bug
Components: Core: Viewer: RestfulObjects
Affects Versions: 1.9.0
Reporter: Jeroen van der Wal
Assignee: Dan Haywood
We have method with this signature:
@Action(semantics = SemanticsOf.IDEMPOTENT)
public void putTax(
final String atPath,
final String reference,
final String name,
final String description,
final @Parameter(optionality = Optionality.OPTIONAL) String
externalReference,
final BigDecimal ratePercentage,
final LocalDate rateStartDate,
final @Parameter(optionality = Optionality.OPTIONAL) String
rateExternalReference) {
...
}
When putting a valid payload on the endpoint the viewer returns a 404 Not
Found. Since the payload is processed correctly expect a 200 OK.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JDO-746) Allow wildcard matching on StringExpression in typesafe queries (fluent API)
[ https://issues.apache.org/jira/browse/JDO-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709044#comment-14709044 ] Jeroen van der Wal commented on JDO-746: Many thanks. Allow wildcard matching on StringExpression in typesafe queries (fluent API) Key: JDO-746 URL: https://issues.apache.org/jira/browse/JDO-746 Project: JDO Issue Type: Improvement Components: api, specification, tck Affects Versions: JDO 3.2 Reporter: Jeroen van der Wal Fix For: JDO 3.2 Currently JDOQL 3.1 specifies the matches() function. We are using the fluent API in Datanucleus 4.2 however the 3.2 implementation of the StringExpression does not contain a matches() function. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JDO-746) Allow wildcard matching on StringExpression in typesafe queries (fluent API)
Jeroen van der Wal created JDO-746: -- Summary: Allow wildcard matching on StringExpression in typesafe queries (fluent API) Key: JDO-746 URL: https://issues.apache.org/jira/browse/JDO-746 Project: JDO Issue Type: Improvement Affects Versions: JDO 3.2 Reporter: Jeroen van der Wal Currently JDOQL 3.1 specifies the matches() function. We are using the fluent API in Datanucleus 4.2 however the 3.2 implementation of the StringExpression does not contain a matches() function. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ISIS-1070) Add header and handle double quotes in translations.pot file
Jeroen van der Wal created ISIS-1070:
Summary: Add header and handle double quotes in translations.pot
file
Key: ISIS-1070
URL: https://issues.apache.org/jira/browse/ISIS-1070
Project: Isis
Issue Type: Improvement
Components: Core
Affects Versions: core-1.8.0
Reporter: Jeroen van der Wal
Assignee: Dan Haywood
Priority: Minor
Fix For: core-1.9.0
Some translation services are more picky about the format of the .pot file than
others. I countered two issues when trying a different service:
1. Add compliant header
More about headers in this paper [1] and the gettext documentation [2]. I've
successfully managed to upload a .pot file to a translation service by adding
this header:
{code}
msgid
msgstr
Project-Id-Version: \n
POT-Creation-Date: 2015-03-04 12:52+0100\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n
Plural-Forms: nplurals=2; plural=n != 1;\n
{code}
2. Escape quotes
Some services can't deal with quotes in the translatable string:
{code}
msgid a href=#Accept using your data for research/a
{code}
One could argue that is this particular example the html should not be exposed
to the translator but it's imaginable that quotes are uses in string that are
presented to the user.
Escaping with a backslash allowed me to upload the .pot file:
{code}
msgid a href=\#\Accept using your data for research/a
{code}
[1] http://pology.nedohodnik.net/doc/user/en_US/ch-poformat.html
[2]
https://www.gnu.org/software/gettext/manual/html_node/Header-Entry.html#Header-Entry
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[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-tabpanelfocusedCommentId=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.init(ZipFile.java:215) at java.util.zip.ZipFile.init(ZipFile.java:145) at java.util.jar.JarFile.init(JarFile.java:154) at java.util.jar.JarFile.init(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.init(Reflections.java:128) at org.reflections.Reflections.init(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.init(Reflections.java:128) at org.reflections.Reflections.init(Reflections.java:169) at org.reflections.Reflections.init(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)
[jira] [Created] (ISIS-1042) Dropdown of Enums does not honour title() method
Jeroen van der Wal created ISIS-1042: Summary: Dropdown of Enums does not honour title() method Key: ISIS-1042 URL: https://issues.apache.org/jira/browse/ISIS-1042 Project: Isis Issue Type: Bug Components: Viewer: Wicket Affects Versions: viewer-wicket-1.8.0 Reporter: Jeroen van der Wal Assignee: Dan Haywood The dropdown of enums shows the name of the enum, not the result of the title() method when available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ISIS-1031) Filter and pagination on tables
[
https://issues.apache.org/jira/browse/ISIS-1031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14318412#comment-14318412
]
Jeroen van der Wal commented on ISIS-1031:
--
Pagination has always been available. It can be configured using the
CollectionLayout#paged annotation [1]. The defaults can be set in the
isis.properties file:
{code}
isis.viewers.paged.standalone=30
isis.viewers.paged.parented=10
{code}
[1]
http://isis.apache.org/reference/recognized-annotations/CollectionLayout.html
Filter and pagination on tables
---
Key: ISIS-1031
URL: https://issues.apache.org/jira/browse/ISIS-1031
Project: Isis
Issue Type: New Feature
Components: Core
Affects Versions: viewer-wicket-1.7.0, core-1.7.0
Reporter: Joshua Kamau
Assignee: Martin Grigorov
Priority: Minor
Labels: filter, grid, pagination
It should be possible to show pagination in the tables possibly with
configurable page size. It should also be nice to have ability to filter
entities in a table.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ISIS-1032) Contract test for bidirectional relationship can't handle overridden methods
Jeroen van der Wal created ISIS-1032: Summary: Contract test for bidirectional relationship can't handle overridden methods Key: ISIS-1032 URL: https://issues.apache.org/jira/browse/ISIS-1032 Project: Isis Issue Type: Improvement Components: Core Affects Versions: core-1.7.0 Reporter: Jeroen van der Wal Assignee: Jeroen van der Wal Priority: Minor Fix For: core-1.8.0 The contract tests search for methods with a specific name. It asserts to find one but when the method is overridden in a test it finds more then one. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ISIS-903) Improve i18n support (in NamedFacetDecorator etc) to honour client-side locale.
[ https://issues.apache.org/jira/browse/ISIS-903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301271#comment-14301271 ] Jeroen van der Wal commented on ISIS-903: - The argument that Java developers are more familiar with resource bundles is true. However, I have not encountered a single developer yet who liked working with it. Especially the fact that they have to maintain two code artefacts in a non-typesafe manner is laborious and error prone. My key principle is that a development team should *never* be bothered with the translation of an application. They develop in the language that is ubiquitous across the team, including the product owners. Translation is usually done separately by translators who don't even have to be on the team. A usual workflow could be: 1. Development team creates application in their own language. Additionally, strings in code that end up in the UI are wrapped. 2. A maven command is used to extract all visibile text. From the metamodel it will take it's name (eg. New Todo), the @Named override when applicable and the @DescribedAs. From the source code it will parse the wrapped strings. The result is a single .pot file for the translatable items. 3. The .pot file is translated into a localised .po file. This can be done trough various tools, including online. The .po files are placed in the WEBINF folder so they can be maintained independent from the application release cycle. Another big advantage I see in this approach is the fact that also includes Isis add-on modules will be included for translation without additional work. Except for wrapping strings in code of course. Introducing label identifiers would devaluate the power of developing in Isis and is merely cutting corners. From a technical point both approaches are the same. The additional component in the GNU gettext approach is the the maven task to extract the metamodel items. Here we could extend Dan's work on the metamodel exporter. Improve i18n support (in NamedFacetDecorator etc) to honour client-side locale. --- Key: ISIS-903 URL: https://issues.apache.org/jira/browse/ISIS-903 Project: Isis Issue Type: Improvement Components: Core Affects Versions: core-1.6.0 Reporter: Dan Haywood Assignee: Dan Haywood Priority: Minor Fix For: core-1.9.0 from the mailing list: http://markmail.org/message/wifsrte2p2q6tces ok, here's the scoop. It *is* possible to add i18n for Isis apps, but the implementation we have reflects the locale of the server, rather than the client. If client-side i18n is what you require then it ought to be possible to implement a different implementation of I18nFacetDecoratorInstaller. You can get hold of the user's locale using: AuthenticatedWebSessionForIsis.get().getLocale() -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ISIS-1020) Dropdown window opens top left of the screen
[ https://issues.apache.org/jira/browse/ISIS-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal updated ISIS-1020: - Description: This is reporducable in IE11, I have created a screencast to demonstrate https://drive.google.com/file/d/0B2jd2Sl73mDBZ0lqYUhtVjVRamc/view?usp=sharing Dropdown window opens top left of the screen Key: ISIS-1020 URL: https://issues.apache.org/jira/browse/ISIS-1020 Project: Isis Issue Type: Bug Components: Viewer: Wicket Reporter: Jeroen van der Wal Assignee: Dan Haywood This is reporducable in IE11, I have created a screencast to demonstrate https://drive.google.com/file/d/0B2jd2Sl73mDBZ0lqYUhtVjVRamc/view?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ISIS-1020) Dropdown window opens top left of the screen
[ https://issues.apache.org/jira/browse/ISIS-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal updated ISIS-1020: - Description: I have created a screencast to demonstrate in Estatio: https://drive.google.com/file/d/0B2jd2Sl73mDBZ0lqYUhtVjVRamc/view?usp=sharing This is reproducible in both IE11 and Chrome. was:This is reporducable in IE11, I have created a screencast to demonstrate https://drive.google.com/file/d/0B2jd2Sl73mDBZ0lqYUhtVjVRamc/view?usp=sharing Affects Version/s: viewer-wicket-1.8.0 Dropdown window opens top left of the screen Key: ISIS-1020 URL: https://issues.apache.org/jira/browse/ISIS-1020 Project: Isis Issue Type: Bug Components: Viewer: Wicket Affects Versions: viewer-wicket-1.8.0 Reporter: Jeroen van der Wal Assignee: Dan Haywood I have created a screencast to demonstrate in Estatio: https://drive.google.com/file/d/0B2jd2Sl73mDBZ0lqYUhtVjVRamc/view?usp=sharing This is reproducible in both IE11 and Chrome. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ISIS-1020) Dropdown window opens top left of the screen
Jeroen van der Wal created ISIS-1020: Summary: Dropdown window opens top left of the screen Key: ISIS-1020 URL: https://issues.apache.org/jira/browse/ISIS-1020 Project: Isis Issue Type: Bug Components: Viewer: Wicket Reporter: Jeroen van der Wal Assignee: Dan Haywood -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ISIS-1014) Modal window improvements
Jeroen van der Wal created ISIS-1014: Summary: Modal window improvements Key: ISIS-1014 URL: https://issues.apache.org/jira/browse/ISIS-1014 Project: Isis Issue Type: Improvement Components: Viewer: Wicket Affects Versions: viewer-wicket-1.8.0 Reporter: Jeroen van der Wal Assignee: Martin Grigorov Priority: Minor Fix For: viewer-wicket-1.8.0 1. Currently the modal window is located at the top of the screen. We would prefer putting it in the center of the screen. The animation time can be eliminated or reduced and could come out of the center. 2. We have a request that the user can move the modal window: she wants to be able to see underlying figures sometimes. 3. The user has to click twice on the OK button in order to invoke the modal window. 4. Make pressing the enter key invoke the OK action. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ISIS-1012) Use the same date and time format across tables and fields
[ https://issues.apache.org/jira/browse/ISIS-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal updated ISIS-1012: - Attachment: screenshot-1.png Use the same date and time format across tables and fields -- Key: ISIS-1012 URL: https://issues.apache.org/jira/browse/ISIS-1012 Project: Isis Issue Type: Improvement Components: Viewer: Wicket Affects Versions: viewer-wicket-1.7.0 Reporter: Jeroen van der Wal Assignee: Dan Haywood Attachments: screenshot-1.png -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ISIS-1012) Use the same date and time format across tables and fields
Jeroen van der Wal created ISIS-1012: Summary: Use the same date and time format across tables and fields Key: ISIS-1012 URL: https://issues.apache.org/jira/browse/ISIS-1012 Project: Isis Issue Type: Improvement Components: Viewer: Wicket Affects Versions: viewer-wicket-1.7.0 Reporter: Jeroen van der Wal Assignee: Dan Haywood Attachments: screenshot-1.png -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ISIS-982) Change the name of the Apache Isis project into something else
[ https://issues.apache.org/jira/browse/ISIS-982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal updated ISIS-982: Summary: Change the name of the Apache Isis project into something else (was: change the Name of the Project ISIS) Change the name of the Apache Isis project into something else Key: ISIS-982 URL: https://issues.apache.org/jira/browse/ISIS-982 Project: Isis Issue Type: Wish Reporter: Sushil Kumar Saini Assignee: Dan Haywood This name coincides with terrorist organisation. Its name can attract unwilling attention . Request you to rename the project. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ISIS-970) Introduce new annotations to collect together all non-UI (layout) hints, and deprecate old annotations
[
https://issues.apache.org/jira/browse/ISIS-970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14241869#comment-14241869
]
Jeroen van der Wal commented on ISIS-970:
-
Good stuff, this will make it much easier for newcomers. Personally the
remaining annotations could be removed for now and reinstated if they fit a
purpose in Isis again. One little thing: the objectType on @DomainObject
actually is the objectName.
Introduce new annotations to collect together all non-UI (layout) hints, and
deprecate old annotations
--
Key: ISIS-970
URL: https://issues.apache.org/jira/browse/ISIS-970
Project: Isis
Issue Type: Improvement
Components: Core
Affects Versions: core-1.7.0
Reporter: Dan Haywood
Assignee: Dan Haywood
Fix For: core-1.8.0
specifically:
{code}
@DomainObject(
audited = true|false
auditedDisabled = true|false // representing
@Audited(disabled=true)
published= SomePayloadFactory.class // probably factor out
PayloadFactory.Default so similar to interaction
autoComplete = SomeRepository.class
bookmarkable = BookmarkPolicy.ROOT // or CHILD
bounded = true|false// do not combine with
autoComplete
immutable= When.ALWAYS // or perhaps true|false;
defaults to ? perhaps true ?
objectType = CUS
viewModel= true|false// defaults to false
)
{code}
and
{code}
@Property(
interaction= ToDoItem.DueBy.class // or
PropertyInteractionEvent.Default.class for default
disabled = Where.OBJECT_FORMS etc. // (ignore the When enum)
disabledReason = ... // optional, representing
@Disabled(reason=...)
maxLength= 20
mustSatisfy = {SomeSpecification.class}
notPersisted = true|false // defaults to false
optional = true|false // defaults to false (ie
mandatory)
regex= abc.*def // ignore the validation and
caseSensitive attributes
)
{code}
and
{code}
@Collection(
interaction=
disabled = Where.OBJECT_FORMS etc. // (ignore the When enum)
disabledReason = ... // optional, representing
@Disabled(reason=...)
typeOf== OrderLine.class
)
{code}
and
{code}
@Action(
interaction= ToDoItem.Completed.class // or
ActionInteractionEvent.Default.class for default
disabled = Where.OBJECT_FORMS etc. // (ignore the When enum)
disabledReason = ... // optional, representing
@Disabled(reason=...)
semantics = Of.SAFE // or IDEMPOTENT,
NON_IDEMPOTENT
bulk = AppliesTo.BULK_ONLY // or BULK_AND_REGULAR
command= true|false
commandPersistence = Persistence.PERSISTED // representing
@Command(persistence=...)
commandExecuteIn = ExecuteIn.FOREGROUND // representing
@Command(executeIn=...)
commandDisabled= true|false// representing
@Command(disabled=true)
published = SomePayloadFactory.class // probably factor out
PayloadFactory.Default so similar to interaction
)
{code}
and
{code}
@Parameter(
minLength = 3
mustSatisfy = {SomeSpecification.class}
optional= true|false // defaults to false (ie
mandatory)
regex = abc.*def // ignore the validation and
caseSensitive attributes
)
{code}
This would result in the full complement of Isis annotations being:
- @DomainService and @DomainServiceLayout
- @DomainObject and @DomainObjectLayout
- @Property and @PropertyLayout
- @Collection and @CollectionLayout
- @Action and @ActionLayout
- @Parameter and @ParameterLayout
Also two further additional UI hints:
- @Title
- @MemberGroupLayout
All the above @XxxLayout annotations can instead be specified using a
.layout.json file.
The following 3rd-party annotations also supported:
- @javax.validation.constraints.Digits
- @javax.enterprise.context.RequestScoped
- @javax.jdo.annotations.*
~~~
Need to decide what to do with remaining annotations (mostly pertaining to
value types and other DDD ideas); remove or keep? They are:
- @Value
- @Defaulted
- @Encodeable
- @EqualByContent
- @Parseable
- @Aggregated
- @NotPersistable
- @Facets
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ISIS-960) The event bus swallows errors thrown in the subscribers
Jeroen van der Wal created ISIS-960: --- Summary: The event bus swallows errors thrown in the subscribers Key: ISIS-960 URL: https://issues.apache.org/jira/browse/ISIS-960 Project: Isis Issue Type: Improvement Components: Core Affects Versions: core-1.7.0 Reporter: Jeroen van der Wal Assignee: Jeroen van der Wal Fix For: core-1.8.0 The event bus swallows errors thrown in the subscribers so it's returning false positives on validate and other phases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (ISIS-960) The event bus swallows errors thrown in the subscribers
[ https://issues.apache.org/jira/browse/ISIS-960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal closed ISIS-960. --- Resolution: Fixed The event bus swallows errors thrown in the subscribers --- Key: ISIS-960 URL: https://issues.apache.org/jira/browse/ISIS-960 Project: Isis Issue Type: Improvement Components: Core Affects Versions: core-1.7.0 Reporter: Jeroen van der Wal Assignee: Jeroen van der Wal Fix For: core-1.8.0 The event bus swallows errors thrown in the subscribers so it's returning false positives on validate and other phases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ISIS-784) Change Wicket viewer to get rid of edit mode, instead allow individual fields to be edited by clicking on them (similar to the way that JIRA works).
[
https://issues.apache.org/jira/browse/ISIS-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14225245#comment-14225245
]
Jeroen van der Wal commented on ISIS-784:
-
I think that looks nice. We could make the changeXXX method be associated with
an getXXX if available. Something like this:
public class Something {
private String street;
private String city;
... setters + getters ...
public String getAddress() {
return getStreet() + , + getCity();
}
public void changeAddress() { final String street, final String city) {
setStreet(street);
setCity(city);
}
}
Currently this shows a modal window which is fine for now. Perhaps for Isis
3.0? ;-)
Change Wicket viewer to get rid of edit mode, instead allow individual fields
to be edited by clicking on them (similar to the way that JIRA works).
Key: ISIS-784
URL: https://issues.apache.org/jira/browse/ISIS-784
Project: Isis
Issue Type: New Feature
Components: Viewer: Wicket
Affects Versions: viewer-wicket-1.4.1
Reporter: Dan Haywood
Assignee: Dan Haywood
Priority: Minor
Fix For: viewer-wicket-2.0.0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ISIS-439) Wicket viewer should support mutable collections - ie with an implicit 'add' and 'remove' action.
[ https://issues.apache.org/jira/browse/ISIS-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14225261#comment-14225261 ] Jeroen van der Wal commented on ISIS-439: - Agree that it's better to remove mutable collections from the programming model since it's not compatible with decoupling using contributed collections. Wicket viewer should support mutable collections - ie with an implicit 'add' and 'remove' action. - Key: ISIS-439 URL: https://issues.apache.org/jira/browse/ISIS-439 Project: Isis Issue Type: Improvement Components: Viewer: Wicket Affects Versions: viewer-wicket-1.2.0 Reporter: Dan Haywood Assignee: Dan Haywood Fix For: viewer-wicket-2.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ISIS-946) Isis application won't run from Eclipse
Jeroen van der Wal created ISIS-946:
---
Summary: Isis application won't run from Eclipse
Key: ISIS-946
URL: https://issues.apache.org/jira/browse/ISIS-946
Project: Isis
Issue Type: Bug
Components: Viewer: Wicket
Affects Versions: viewer-wicket-1.8.0
Reporter: Jeroen van der Wal
Assignee: Dan Haywood
Priority: Critical
{code}
java.lang.Error: Unresolved compilation problem:
The type javax.servlet.http.Cookie cannot be resolved. It is indirectly
referenced from required .class files
at
org.apache.isis.viewer.wicket.ui.components.widgets.themepicker.ThemeChooser.init(ThemeChooser.java:96)
at
org.apache.isis.viewer.wicket.ui.pages.PageAbstract.addThemePicker(PageAbstract.java:211)
at
org.apache.isis.viewer.wicket.ui.pages.PageAbstract.init(PageAbstract.java:180)
at
org.apache.isis.viewer.wicket.ui.pages.error.ErrorPage.init(ErrorPage.java:40)
at
org.apache.isis.viewer.wicket.viewer.integration.wicket.WebRequestCycleForIsis.errorPageFor(WebRequestCycleForIsis.java:177)
at
org.apache.isis.viewer.wicket.viewer.integration.wicket.WebRequestCycleForIsis.errorPageProviderFor(WebRequestCycleForIsis.java:147)
at
org.apache.isis.viewer.wicket.viewer.integration.wicket.WebRequestCycleForIsis.onException(WebRequestCycleForIsis.java:138)
at
org.apache.wicket.request.cycle.RequestCycleListenerCollection$4.notify(RequestCycleListenerCollection.java:126)
at
org.apache.wicket.request.cycle.RequestCycleListenerCollection$4.notify(RequestCycleListenerCollection.java:122)
at
org.apache.wicket.util.listener.ListenerCollection.notify(ListenerCollection.java:80)
at
org.apache.wicket.request.cycle.RequestCycleListenerCollection.onException(RequestCycleListenerCollection.java:121)
at
org.apache.wicket.request.cycle.RequestCycleListenerCollection$4.notify(RequestCycleListenerCollection.java:126)
at
org.apache.wicket.request.cycle.RequestCycleListenerCollection$4.notify(RequestCycleListenerCollection.java:122)
at
org.apache.wicket.util.listener.ListenerCollection.notify(ListenerCollection.java:80)
at
org.apache.wicket.request.cycle.RequestCycleListenerCollection.onException(RequestCycleListenerCollection.java:121)
at
org.apache.wicket.request.cycle.RequestCycle.handleException(RequestCycle.java:347){code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ISIS-946) Isis application won't run from Eclipse
[
https://issues.apache.org/jira/browse/ISIS-946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14206340#comment-14206340
]
Jeroen van der Wal commented on ISIS-946:
-
That fixed it. Thanks Martin!
Isis application won't run from Eclipse
---
Key: ISIS-946
URL: https://issues.apache.org/jira/browse/ISIS-946
Project: Isis
Issue Type: Bug
Components: Viewer: Wicket
Affects Versions: viewer-wicket-1.8.0
Reporter: Jeroen van der Wal
Assignee: Martin Grigorov
Priority: Critical
{code}
java.lang.Error: Unresolved compilation problem:
The type javax.servlet.http.Cookie cannot be resolved. It is indirectly
referenced from required .class files
at
org.apache.isis.viewer.wicket.ui.components.widgets.themepicker.ThemeChooser.init(ThemeChooser.java:96)
at
org.apache.isis.viewer.wicket.ui.pages.PageAbstract.addThemePicker(PageAbstract.java:211)
at
org.apache.isis.viewer.wicket.ui.pages.PageAbstract.init(PageAbstract.java:180)
at
org.apache.isis.viewer.wicket.ui.pages.error.ErrorPage.init(ErrorPage.java:40)
at
org.apache.isis.viewer.wicket.viewer.integration.wicket.WebRequestCycleForIsis.errorPageFor(WebRequestCycleForIsis.java:177)
at
org.apache.isis.viewer.wicket.viewer.integration.wicket.WebRequestCycleForIsis.errorPageProviderFor(WebRequestCycleForIsis.java:147)
at
org.apache.isis.viewer.wicket.viewer.integration.wicket.WebRequestCycleForIsis.onException(WebRequestCycleForIsis.java:138)
at
org.apache.wicket.request.cycle.RequestCycleListenerCollection$4.notify(RequestCycleListenerCollection.java:126)
at
org.apache.wicket.request.cycle.RequestCycleListenerCollection$4.notify(RequestCycleListenerCollection.java:122)
at
org.apache.wicket.util.listener.ListenerCollection.notify(ListenerCollection.java:80)
at
org.apache.wicket.request.cycle.RequestCycleListenerCollection.onException(RequestCycleListenerCollection.java:121)
at
org.apache.wicket.request.cycle.RequestCycleListenerCollection$4.notify(RequestCycleListenerCollection.java:126)
at
org.apache.wicket.request.cycle.RequestCycleListenerCollection$4.notify(RequestCycleListenerCollection.java:122)
at
org.apache.wicket.util.listener.ListenerCollection.notify(ListenerCollection.java:80)
at
org.apache.wicket.request.cycle.RequestCycleListenerCollection.onException(RequestCycleListenerCollection.java:121)
at
org.apache.wicket.request.cycle.RequestCycle.handleException(RequestCycle.java:347){code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ISIS-912) Not possible to specify the fixtures to be loaded from the command line (ie --fixture flag is broken).
Jeroen van der Wal created ISIS-912: --- Summary: Not possible to specify the fixtures to be loaded from the command line (ie --fixture flag is broken). Key: ISIS-912 URL: https://issues.apache.org/jira/browse/ISIS-912 Project: Isis Issue Type: Bug Components: Core Affects Versions: core-1.6.0 Reporter: Jeroen van der Wal Assignee: Jeroen van der Wal Priority: Minor Fix For: core-1.7.0 In addition, need better documentation so that can see that it's also necessary to enable fixtures to be loaded using an additional system property isis.persistor.datanucleus.install-fixtures. eg: -D isis.persistor.datanucleus.install-fixtures=true \ --fixture org.estatio.fixture.EstatioDemoFixture \ --type PROTOTYPE \ --port 8080 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ISIS-899) Can't return a view model in Isis 1.6.0 over RO viewer.
[
https://issues.apache.org/jira/browse/ISIS-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14151022#comment-14151022
]
Jeroen van der Wal commented on ISIS-899:
-
Hi Vladimir,
I don't see any call to the mementoservice to generate a string respresentation
of the state of the objects, in Isis 1.6 you have to generate that first before
instantiating the viewmodel.
In Isis 1.7.0-SNAPSHOT you just have to annotate the pojo with @ViewModel and
the memento will be generated behind the curtains based on the setters:
{code}
@ViewModel
public class Address {
public String title() {
return Address lkmsId: + lkmsId;
}
private Street street;
@MemberOrder(sequence = 3)
public Street getStreet() {
return street;
}
public void setStreet(final Street street) {
this.street = street;
}
...
}
{code}
{code}
@ViewModel
public class Street {
}
{code}
{code}
public class AsePublicService {
@Render(Type.EAGERLY)
public Address getAddress(@Named(Source System) final String
sourceSystem, @Named(User) final String user, @Named(Agent) final String
agent, @Named(LKMS-ID) final String lkmsId, @Named(Valid Location) final
boolean validLocation) {
final Address address = new Address();
address.setHousenumber(12);
Street street = new Street();
street.setStreetname(5th Avenue);
address.setStreet(street);
return address;
}
...
{code}
The isPersistent=true looks like a bug.
Can't return a view model in Isis 1.6.0 over RO viewer.
---
Key: ISIS-899
URL: https://issues.apache.org/jira/browse/ISIS-899
Project: Isis
Issue Type: Bug
Components: Core: Viewer: RestfulObjects
Affects Versions: core-1.6.0
Reporter: Dan Haywood
Assignee: Dan Haywood
Fix For: core-1.7.0
Attachments: Address.java, AsePublicService.java, Street.java,
Wicket.png
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ISIS-905) Transaction handling fix, if throw exception on flush for no-arg action.
Jeroen van der Wal created ISIS-905: --- Summary: Transaction handling fix, if throw exception on flush for no-arg action. Key: ISIS-905 URL: https://issues.apache.org/jira/browse/ISIS-905 Project: Isis Issue Type: Bug Components: Core Affects Versions: core-1.6.0 Reporter: Jeroen van der Wal Assignee: Dan Haywood Priority: Minor Fix For: core-1.7.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ISIS-906) incorrectly attempts to render a veto exception (from a subscriber) to a non-existent action dialog panel when invoked for a no-arg action.
Jeroen van der Wal created ISIS-906:
---
Summary: incorrectly attempts to render a veto exception (from a
subscriber) to a non-existent action dialog panel when invoked for a no-arg
action.
Key: ISIS-906
URL: https://issues.apache.org/jira/browse/ISIS-906
Project: Isis
Issue Type: Bug
Components: Viewer: Wicket
Affects Versions: viewer-wicket-1.6.0
Reporter: Jeroen van der Wal
Assignee: Dan Haywood
Priority: Minor
Fix For: viewer-wicket-1.8.0
eg, with this code, the remove fails though the removeAndReplace works fine:
{code}
@ActionInteraction(Party.RemoveEvent.class)
public void remove() {
removeAndReplace(null);
}
@ActionInteraction(Party.RemoveEvent.class)
public void removeAndReplace(@Named(Replace with) @Optional Party
replacement) {
getContainer().remove(this);
getContainer().flush();
}
{code}
and the following stacktrace:
{code}
13:24:48,119 [MarkupContainer ] Unable to find component with id
'actionName' in [ActionPanel [Component id = content]]
Expected: 'theme:actionPromptModalWindow:content:actionName'.
Found with similar names: ''
13:24:48,119 [RequestCycleExtra ]
13:24:48,120 [RequestCycleExtra ] Handling the following exception
Unable to find component with id 'actionName' in [ActionPanel [Component id =
content]]
Expected: 'theme:actionPromptModalWindow:content:actionName'.
Found with similar names: ''
MarkupStream: [markup =
file:/C:/Users/jvanderwal/src/isis/component/viewer/wicket/ui/target-ide/classes/org/apache/isis/viewer/wicket/ui/components/actions/ActionPanel.html
wicket:panel
div class=actionPanel actionComponentType
div class=myBlockContainer
div class=iconAndTitle panel
actionPanelHeaderNew
span wicket:id=entityIconAndTitle[icon and
title]/span
p wicket:id=actionName
class=actionName[action name]/p
/div
span wicket:id=parameters
/span
/div
/div
/wicket:panel, index = 6, current = 'p
wicket:id=actionName class=actionName' (line 0, column 0)]
at
org.apache.wicket.markup.MarkupStream.throwMarkupException(MarkupStream.java:526)
at
org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1438)
at
org.apache.wicket.MarkupContainer.renderAll(MarkupContainer.java:1557)
at
org.apache.wicket.MarkupContainer.renderComponentTagBody(MarkupContainer.java:1532)
at
org.apache.wicket.MarkupContainer.renderAssociatedMarkup(MarkupContainer.java:689)
at
org.apache.wicket.markup.html.panel.AssociatedMarkupSourcingStrategy.renderAssociatedMarkup(AssociatedMarkupSourcingStrategy.java:76)
at
org.apache.wicket.markup.html.panel.PanelMarkupSourcingStrategy.onComponentTagBody(PanelMarkupSourcingStrategy.java:112)
at
org.apache.wicket.Component.internalRenderComponent(Component.java:2514)
at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1496)
at org.apache.wicket.Component.internalRender(Component.java:2344)
at org.apache.wicket.Component.render(Component.java:2272)
at
org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1392)
at
org.apache.wicket.MarkupContainer.renderAll(MarkupContainer.java:1557)
at
org.apache.wicket.MarkupContainer.renderComponentTagBody(MarkupContainer.java:1532)
at
org.apache.wicket.MarkupContainer.renderAssociatedMarkup(MarkupContainer.java:689)
at
org.apache.wicket.markup.html.panel.AssociatedMarkupSourcingStrategy.renderAssociatedMarkup(AssociatedMarkupSourcingStrategy.java:76)
at
org.apache.wicket.markup.html.panel.PanelMarkupSourcingStrategy.onComponentTagBody(PanelMarkupSourcingStrategy.java:112)
at
org.apache.wicket.Component.internalRenderComponent(Component.java:2514)
at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1496)
at org.apache.wicket.Component.internalRender(Component.java:2344)
at org.apache.wicket.Component.render(Component.java:2272)
at
org.apache.wicket.ajax.XmlAjaxResponse.writeComponent(XmlAjaxResponse.java:128)
at
org.apache.wicket.ajax.AbstractAjaxResponse.writeComponents(AbstractAjaxResponse.java:218)
at
org.apache.wicket.ajax.AbstractAjaxResponse.writeTo(AbstractAjaxResponse.java:150)
at
org.apache.wicket.ajax.AjaxRequestHandler.respond(AjaxRequestHandler.java:359)
at
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:862)
at
[jira] [Updated] (ISIS-890) Get rid of exploration mode, treat as synonym for prototype. Ditto with @Exploration annotation.
[ https://issues.apache.org/jira/browse/ISIS-890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal updated ISIS-890: Fix Version/s: (was: core-1.7.0) core-2.0.0 Get rid of exploration mode, treat as synonym for prototype. Ditto with @Exploration annotation. - Key: ISIS-890 URL: https://issues.apache.org/jira/browse/ISIS-890 Project: Isis Issue Type: Improvement Components: Core Affects Versions: core-1.6.0 Reporter: Dan Haywood Assignee: Dan Haywood Fix For: core-2.0.0 The main rationale here is to simplify and reduce number of concepts for developer to grapple with. Another part of the rationale is to make Isis consistent with Wicket, that only has two modes, not three (DEVELOPMENT and DEPLOYMENT). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ISIS-901) Use @DomainService(repositoryFor=...) as the basis for an implementation of the IconFacet.
[ https://issues.apache.org/jira/browse/ISIS-901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14149064#comment-14149064 ] Jeroen van der Wal commented on ISIS-901: - and similarly, this might be a replacement to using @AutoComplete annotation so that we can detect which service to use automatically. And, similarly, could use for the implementation of the PluralNameFacet, using the name of the repo as the basis. (Party = Parties etc). Use @DomainService(repositoryFor=...) as the basis for an implementation of the IconFacet. -- Key: ISIS-901 URL: https://issues.apache.org/jira/browse/ISIS-901 Project: Isis Issue Type: New Feature Components: Core Affects Versions: core-1.6.0 Reporter: Dan Haywood Assignee: Dan Haywood Priority: Minor Fix For: core-1.8.0 ... thus meaning no requirement to write an iconName method in the domain service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ISIS-901) Use @DomainService(repositoryFor=...) as the basis for an implementation of the IconFacet.
[ https://issues.apache.org/jira/browse/ISIS-901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal updated ISIS-901: Fix Version/s: (was: core-1.7.0) core-1.8.0 Use @DomainService(repositoryFor=...) as the basis for an implementation of the IconFacet. -- Key: ISIS-901 URL: https://issues.apache.org/jira/browse/ISIS-901 Project: Isis Issue Type: New Feature Components: Core Affects Versions: core-1.6.0 Reporter: Dan Haywood Assignee: Dan Haywood Priority: Minor Fix For: core-1.8.0 ... thus meaning no requirement to write an iconName method in the domain service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ISIS-893) (Cosmetics): If attempt to invoke non-existent action, get nasty error message
[ https://issues.apache.org/jira/browse/ISIS-893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal updated ISIS-893: Fix Version/s: (was: viewer-wicket-1.7.0) (was: core-1.7.0) core-1.8.0 viewer-wicket-1.8.0 (Cosmetics): If attempt to invoke non-existent action, get nasty error message -- Key: ISIS-893 URL: https://issues.apache.org/jira/browse/ISIS-893 Project: Isis Issue Type: Improvement Components: Core, Viewer: Wicket Affects Versions: viewer-wicket-1.6.0, core-1.6.0 Reporter: Dan Haywood Assignee: Dan Haywood Priority: Minor Fix For: viewer-wicket-1.8.0, core-1.8.0 see the actionId=fooBar diverted to error page with following stack trace: 15:59:41,112 [RequestCycleExtra577739874@qtp-1148559558-0 WARN ] Handling the following exception org.apache.wicket.WicketRuntimeException: Can't instantiate page using constructor 'public org.apache.isis.viewer.wicket.ui.pages.actionprompt.ActionPromptPage(org.apache.wicket.request.mapper.parameter.PageParameters)' and argument 'actionArgs=[abc], actionArgs=[Professional], actionArgs=[$nullArg$], actionArgs=[20140925], actionArgs=[$nullArg$], objectOid=[dom.todo.ToDoItems:1], actionOwningSpec=[dom.todo.ToDoItems], actionId=[fooBar(java.lang.String,dom.todo.ToDoItem$Category,dom.todo.ToDoItem$Subcategory,org.joda.time.LocalDate,java.math.BigDecimal)], actionType=[USER]'. An exception has been thrown during construction! at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:194) at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:99) at org.apache.wicket.DefaultMapperContext.newPageInstance(DefaultMapperContext.java:137) at org.apache.wicket.core.request.handler.PageProvider.resolvePageInstance(PageProvider.java:268) at org.apache.wicket.core.request.handler.PageProvider.getPageInstance(PageProvider.java:166) at org.apache.wicket.request.handler.render.PageRenderer.getPage(PageRenderer.java:78) at org.apache.wicket.request.handler.render.WebPageRenderer.renderPage(WebPageRenderer.java:100) at org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:221) at org.apache.wicket.core.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:175) at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:862) at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64) at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:261) at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:218) at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289) at org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:259) at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:282) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212) at org.apache.isis.core.webapp.diagnostics.IsisLogOnExceptionFilter.doFilter(IsisLogOnExceptionFilter.java:52) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212) at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449) at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365) at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90) at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83) at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383) at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362) at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
[jira] [Commented] (ISIS-886) Provide an API (perhaps in the WrapperFactory)to allow a programmer to determine whether the current user has view and/or modify access to a feature.
[
https://issues.apache.org/jira/browse/ISIS-886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14149065#comment-14149065
]
Jeroen van der Wal commented on ISIS-886:
-
Might be that this is not needed, could simply wrap the call to the sensitive
info:
{code}
public String title() {
StringBuilder buf = new StringBuilder();
try {
buf.append(wrap(this).getFirstName());
} catch(HiddenException ex) {
// ignore
}
{code}
Provide an API (perhaps in the WrapperFactory)to allow a programmer to
determine whether the current user has view and/or modify access to a feature.
-
Key: ISIS-886
URL: https://issues.apache.org/jira/browse/ISIS-886
Project: Isis
Issue Type: New Feature
Components: Core
Affects Versions: core-1.6.0
Reporter: Dan Haywood
Assignee: Dan Haywood
Priority: Minor
Fix For: core-1.7.0
The main use case being to allow a suitable title to be rendered (in title())
based on the users' permissions, eg:
public String title() {
StringBuilder buf = new StringBuilder();
if(wrapperFactory.isHidden(this, firstName)) {
buf.append(this.getFirstName());
}
return buf.toString();
}
and isDisabled(...) similarly
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (ISIS-886) Provide an API (perhaps in the WrapperFactory)to allow a programmer to determine whether the current user has view and/or modify access to a feature.
[
https://issues.apache.org/jira/browse/ISIS-886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14149065#comment-14149065
]
Jeroen van der Wal edited comment on ISIS-886 at 9/26/14 11:52 AM:
---
Might be that this is not needed, could simply wrap the call to the sensitive
info:
{code}
public String title() {
StringBuilder buf = new StringBuilder();
try {
buf.append(wrap(this).getFirstName());
} catch(HiddenException ex) {
// ignore
}
{code}
... in which case this can just be a documentation ticket.
was (Author: jcvanderwal):
Might be that this is not needed, could simply wrap the call to the sensitive
info:
{code}
public String title() {
StringBuilder buf = new StringBuilder();
try {
buf.append(wrap(this).getFirstName());
} catch(HiddenException ex) {
// ignore
}
{code}
Provide an API (perhaps in the WrapperFactory)to allow a programmer to
determine whether the current user has view and/or modify access to a feature.
-
Key: ISIS-886
URL: https://issues.apache.org/jira/browse/ISIS-886
Project: Isis
Issue Type: New Feature
Components: Core
Affects Versions: core-1.6.0
Reporter: Dan Haywood
Assignee: Dan Haywood
Priority: Minor
Fix For: core-1.7.0
The main use case being to allow a suitable title to be rendered (in title())
based on the users' permissions, eg:
{code}
public String title() {
StringBuilder buf = new StringBuilder();
if(wrapperFactory.isHidden(this, firstName)) {
buf.append(this.getFirstName());
}
return buf.toString();
}
{code}
and isDisabled(...) similarly
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ISIS-886) Provide an API (perhaps in the WrapperFactory)to allow a programmer to determine whether the current user has view and/or modify access to a feature.
[
https://issues.apache.org/jira/browse/ISIS-886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeroen van der Wal updated ISIS-886:
Description:
The main use case being to allow a suitable title to be rendered (in title())
based on the users' permissions, eg:
{code}
public String title() {
StringBuilder buf = new StringBuilder();
if(wrapperFactory.isHidden(this, firstName)) {
buf.append(this.getFirstName());
}
return buf.toString();
}
{code}
and isDisabled(...) similarly
was:
The main use case being to allow a suitable title to be rendered (in title())
based on the users' permissions, eg:
public String title() {
StringBuilder buf = new StringBuilder();
if(wrapperFactory.isHidden(this, firstName)) {
buf.append(this.getFirstName());
}
return buf.toString();
}
and isDisabled(...) similarly
Provide an API (perhaps in the WrapperFactory)to allow a programmer to
determine whether the current user has view and/or modify access to a feature.
-
Key: ISIS-886
URL: https://issues.apache.org/jira/browse/ISIS-886
Project: Isis
Issue Type: New Feature
Components: Core
Affects Versions: core-1.6.0
Reporter: Dan Haywood
Assignee: Dan Haywood
Priority: Minor
Fix For: core-1.7.0
The main use case being to allow a suitable title to be rendered (in title())
based on the users' permissions, eg:
{code}
public String title() {
StringBuilder buf = new StringBuilder();
if(wrapperFactory.isHidden(this, firstName)) {
buf.append(this.getFirstName());
}
return buf.toString();
}
{code}
and isDisabled(...) similarly
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ISIS-855) Allow contributed actions to be renamed in the contributee
[ https://issues.apache.org/jira/browse/ISIS-855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal updated ISIS-855: Fix Version/s: (was: core-1.7.0) core-1.8.0 Allow contributed actions to be renamed in the contributee -- Key: ISIS-855 URL: https://issues.apache.org/jira/browse/ISIS-855 Project: Isis Issue Type: New Feature Components: Core Affects Versions: core-1.6.0 Reporter: Dan Haywood Assignee: Dan Haywood Priority: Minor Fix For: core-1.8.0 eg for Lease#calculate(Property) - to appear as - Property#calculateLeases -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (ISIS-886) Provide an API (perhaps in the WrapperFactory)to allow a programmer to determine whether the current user has view and/or modify access to a feature.
[
https://issues.apache.org/jira/browse/ISIS-886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14149065#comment-14149065
]
Jeroen van der Wal edited comment on ISIS-886 at 9/26/14 11:53 AM:
---
Might be that this is not needed, could simply wrap the call to the sensitive
info:
{code}
public String title() {
StringBuilder buf = new StringBuilder();
try {
buf.append(wrap(this).getFirstName());
} catch(HiddenException ex) {
// ignore
}
}
{code}
... in which case this can just be a documentation ticket.
was (Author: jcvanderwal):
Might be that this is not needed, could simply wrap the call to the sensitive
info:
{code}
public String title() {
StringBuilder buf = new StringBuilder();
try {
buf.append(wrap(this).getFirstName());
} catch(HiddenException ex) {
// ignore
}
{code}
... in which case this can just be a documentation ticket.
Provide an API (perhaps in the WrapperFactory)to allow a programmer to
determine whether the current user has view and/or modify access to a feature.
-
Key: ISIS-886
URL: https://issues.apache.org/jira/browse/ISIS-886
Project: Isis
Issue Type: New Feature
Components: Core
Affects Versions: core-1.6.0
Reporter: Dan Haywood
Assignee: Dan Haywood
Priority: Minor
Fix For: core-1.7.0
The main use case being to allow a suitable title to be rendered (in title())
based on the users' permissions, eg:
{code}
public String title() {
StringBuilder buf = new StringBuilder();
if(wrapperFactory.isHidden(this, firstName)) {
buf.append(this.getFirstName());
}
return buf.toString();
}
{code}
and isDisabled(...) similarly
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ISIS-845) Hidden (Where.REFERENCES_PARENT) should take into account the instance that is the parent, not just its type.
[
https://issues.apache.org/jira/browse/ISIS-845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeroen van der Wal updated ISIS-845:
Description:
For example:
PartyRelationship {
fromParty;
toParty;
}
if rendered from the point of view of the from party, would want to show only
the toParty. But adding this annotation causes both properties to be
suppressed.
This can be seen in the code:
{code}
static FilterObjectAssociation associationDoesNotReferenceParent(final
ObjectSpecification parentSpec) {
if(parentSpec == null) {
return Filters.any();
}
return new FilterObjectAssociation() {
@Override
public boolean accept(ObjectAssociation association) {
final HiddenFacet facet =
association.getFacet(HiddenFacet.class);
if(facet == null) {
return true;
}
if (facet.where() != Where.REFERENCES_PARENT) {
return true;
}
final ObjectSpecification assocSpec =
association.getSpecification();
final boolean associationSpecIsOfParentSpec =
parentSpec.isOfType(assocSpec);
final boolean isVisible = !associationSpecIsOfParentSpec;
return isVisible;
}
};
}
{code}
Instead, the code should take into account the actual instance that is
referenced, not just the type (ie look at the object that the association
points back to).
was:
For example:
PartyRelationship {
fromParty;
toParty;
}
if rendered from the point of view of the from party, would want to show only
the toParty. But adding this annotation causes both properties to be
suppressed.
This can be seen in the code:
static FilterObjectAssociation associationDoesNotReferenceParent(final
ObjectSpecification parentSpec) {
if(parentSpec == null) {
return Filters.any();
}
return new FilterObjectAssociation() {
@Override
public boolean accept(ObjectAssociation association) {
final HiddenFacet facet =
association.getFacet(HiddenFacet.class);
if(facet == null) {
return true;
}
if (facet.where() != Where.REFERENCES_PARENT) {
return true;
}
final ObjectSpecification assocSpec =
association.getSpecification();
final boolean associationSpecIsOfParentSpec =
parentSpec.isOfType(assocSpec);
final boolean isVisible = !associationSpecIsOfParentSpec;
return isVisible;
}
};
}
Instead, the code should take into account the actual instance that is
referenced, not just the type (ie look at the object that the association
points back to).
Hidden (Where.REFERENCES_PARENT) should take into account the instance that
is the parent, not just its type.
-
Key: ISIS-845
URL: https://issues.apache.org/jira/browse/ISIS-845
Project: Isis
Issue Type: Improvement
Components: Core
Affects Versions: core-1.6.0
Reporter: Dan Haywood
Assignee: Dan Haywood
Fix For: core-1.8.0
For example:
PartyRelationship {
fromParty;
toParty;
}
if rendered from the point of view of the from party, would want to show only
the toParty. But adding this annotation causes both properties to be
suppressed.
This can be seen in the code:
{code}
static FilterObjectAssociation associationDoesNotReferenceParent(final
ObjectSpecification parentSpec) {
if(parentSpec == null) {
return Filters.any();
}
return new FilterObjectAssociation() {
@Override
public boolean accept(ObjectAssociation association) {
final HiddenFacet facet =
association.getFacet(HiddenFacet.class);
if(facet == null) {
return true;
}
if (facet.where() != Where.REFERENCES_PARENT) {
return true;
}
final ObjectSpecification assocSpec =
association.getSpecification();
final boolean associationSpecIsOfParentSpec =
parentSpec.isOfType(assocSpec);
final boolean isVisible = !associationSpecIsOfParentSpec;
return isVisible;
}
};
}
{code}
Instead, the code should take into account the actual instance that is
referenced, not just the type (ie look at the object that the association
points back to).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ISIS-834) Ensure that only a single implementation of a DomainService is registered.
[ https://issues.apache.org/jira/browse/ISIS-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal updated ISIS-834: Fix Version/s: (was: core-1.7.0) core-2.0.0 Ensure that only a single implementation of a DomainService is registered. -- Key: ISIS-834 URL: https://issues.apache.org/jira/browse/ISIS-834 Project: Isis Issue Type: Improvement Components: Core Affects Versions: core-1.5.0 Reporter: Dan Haywood Assignee: Dan Haywood Priority: Minor Fix For: core-2.0.0 Two complications: - ExceptionRecognizers require multiple implementations (are chained together) - for each implementation we identify all the types it implements, so the check isn't a simple 1:1 map (at the limit all implementations extend java.lang.Object). Therefore need to take into account the set of injection points that the services are injected into. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ISIS-845) Hidden (Where.REFERENCES_PARENT) should take into account the instance that is the parent, not just its type.
[
https://issues.apache.org/jira/browse/ISIS-845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeroen van der Wal updated ISIS-845:
Fix Version/s: (was: core-1.7.0)
core-1.8.0
Hidden (Where.REFERENCES_PARENT) should take into account the instance that
is the parent, not just its type.
-
Key: ISIS-845
URL: https://issues.apache.org/jira/browse/ISIS-845
Project: Isis
Issue Type: Improvement
Components: Core
Affects Versions: core-1.6.0
Reporter: Dan Haywood
Assignee: Dan Haywood
Fix For: core-1.8.0
For example:
PartyRelationship {
fromParty;
toParty;
}
if rendered from the point of view of the from party, would want to show only
the toParty. But adding this annotation causes both properties to be
suppressed.
This can be seen in the code:
static FilterObjectAssociation associationDoesNotReferenceParent(final
ObjectSpecification parentSpec) {
if(parentSpec == null) {
return Filters.any();
}
return new FilterObjectAssociation() {
@Override
public boolean accept(ObjectAssociation association) {
final HiddenFacet facet =
association.getFacet(HiddenFacet.class);
if(facet == null) {
return true;
}
if (facet.where() != Where.REFERENCES_PARENT) {
return true;
}
final ObjectSpecification assocSpec =
association.getSpecification();
final boolean associationSpecIsOfParentSpec =
parentSpec.isOfType(assocSpec);
final boolean isVisible = !associationSpecIsOfParentSpec;
return isVisible;
}
};
}
Instead, the code should take into account the actual instance that is
referenced, not just the type (ie look at the object that the association
points back to).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ISIS-830) Raise lifecycle events on EventBus.
[ https://issues.apache.org/jira/browse/ISIS-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal updated ISIS-830: Fix Version/s: (was: core-1.7.0) core-2.0.0 Raise lifecycle events on EventBus. --- Key: ISIS-830 URL: https://issues.apache.org/jira/browse/ISIS-830 Project: Isis Issue Type: Bug Components: Core Affects Versions: core-1.5.0 Reporter: Dan Haywood Assignee: Dan Haywood Fix For: core-2.0.0 Specifically: - ObjectPersistedEvent // postCreate in JDO terminology - ObjectUpdatingEvent // preStore in JDO terminology - ObjectUpdatedEvent// postStore in JDO terminology - ObjectRemovingEvent // preDelete in JDO terms This would be a more flexible solution for many use cases than implementing updating() etc can centralize logic. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ISIS-830) Wire up JDO events to publish onto our EventBus (rather than publish our own events).
[ https://issues.apache.org/jira/browse/ISIS-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal updated ISIS-830: Summary: Wire up JDO events to publish onto our EventBus (rather than publish our own events). (was: Raise lifecycle events on EventBus.) Wire up JDO events to publish onto our EventBus (rather than publish our own events). - Key: ISIS-830 URL: https://issues.apache.org/jira/browse/ISIS-830 Project: Isis Issue Type: Bug Components: Core Affects Versions: core-1.5.0 Reporter: Dan Haywood Assignee: Dan Haywood Fix For: core-2.0.0 Specifically: - ObjectPersistedEvent // postCreate in JDO terminology - ObjectUpdatingEvent // preStore in JDO terminology - ObjectUpdatedEvent// postStore in JDO terminology - ObjectRemovingEvent // preDelete in JDO terms This would be a more flexible solution for many use cases than implementing updating() etc can centralize logic. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ISIS-820) OidMarshaller - Identifier(PK) with special symbols should be allowed
[ https://issues.apache.org/jira/browse/ISIS-820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal updated ISIS-820: Fix Version/s: (was: core-1.7.0) core-2.0.0 OidMarshaller - Identifier(PK) with special symbols should be allowed - Key: ISIS-820 URL: https://issues.apache.org/jira/browse/ISIS-820 Project: Isis Issue Type: Improvement Components: Core Affects Versions: core-1.5.0 Reporter: Ranganath Chittari Assignee: Dan Haywood Fix For: core-2.0.0 Attachments: Identifier-#Symbol.log When a domain object has “#” symbol in its Primary key(of String type) and try to query it, java.lang.IllegalArgumentException (Identifier contains # symbol) exception is thrown: PFA Log file. This is presentation constraint and need to be enhanced by encoding and decodng the PK in ISIS OidMarshaller -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ISIS-805) (Mac and Linux) Class discovery service throws errors on startup
[
https://issues.apache.org/jira/browse/ISIS-805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeroen van der Wal updated ISIS-805:
Summary: (Mac and Linux) Class discovery service throws errors on startup
(was: Class discovery service throws errors on startup)
(Mac and Linux) Class discovery service throws errors on startup
Key: ISIS-805
URL: https://issues.apache.org/jira/browse/ISIS-805
Project: Isis
Issue Type: Bug
Components: Core
Affects Versions: core-1.5.0
Reporter: Jeroen van der Wal
Assignee: Dan Haywood
Priority: Minor
Fix For: core-1.7.0
These errors could be silently ignored:
{code}
2:58:45,672 [Reflections ] could not create Dir using
directory from url file:/System/Library/Java/Extensions/libJ3DAudio.jnilib.
skipping.
java.lang.RuntimeException: cannot use dir
/System/Library/Java/Extensions/libJ3DAudio.jnilib
at org.reflections.vfs.SystemDir.init(SystemDir.java:20)
at org.reflections.vfs.Vfs$DefaultUrlTypes$3.createDir(Vfs.java:229)
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:165)
at org.reflections.Reflections.init(Reflections.java:94)
at org.reflections.Reflections.init(Reflections.java:135)
at
org.apache.isis.applib.services.classdiscovery.ClassDiscoveryServiceUsingReflections.findSubTypesOfClasses(ClassDiscoveryServiceUsingReflections.java:37)
at
org.apache.isis.applib.fixturescripts.FixtureScripts.findAndInstantiateFixtureScripts(FixtureScripts.java:99)
at
org.apache.isis.applib.fixturescripts.FixtureScripts.init(FixtureScripts.java:95)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.isis.core.commons.lang.MethodExtensions.invoke(MethodExtensions.java:53)
at
org.apache.isis.core.commons.lang.MethodExtensions.invoke(MethodExtensions.java:47)
at
org.apache.isis.core.metamodel.specloader.ServiceInitializer.postConstruct(ServiceInitializer.java:126)
at
org.apache.isis.core.runtime.system.IsisSystemFixturesHookAbstract.initializeServices(IsisSystemFixturesHookAbstract.java:181)
at
org.apache.isis.core.runtime.system.IsisSystemFixturesHookAbstract.init(IsisSystemFixturesHookAbstract.java:141)
at
org.apache.isis.core.runtime.runner.IsisInjectModule.provideIsisSystem(IsisInjectModule.java:136)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
com.google.inject.internal.ProviderMethod.get(ProviderMethod.java:104)
at
com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40)
at
com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1031)
at
com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
at com.google.inject.Scopes$1$1.get(Scopes.java:65)
at
com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40)
at
com.google.inject.internal.SingleFieldInjector.inject(SingleFieldInjector.java:53)
at
com.google.inject.internal.MembersInjectorImpl.injectMembers(MembersInjectorImpl.java:110)
at
com.google.inject.internal.MembersInjectorImpl$1.call(MembersInjectorImpl.java:75)
at
com.google.inject.internal.MembersInjectorImpl$1.call(MembersInjectorImpl.java:73)
at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1024)
at
com.google.inject.internal.MembersInjectorImpl.injectAndNotify(MembersInjectorImpl.java:73)
at
com.google.inject.internal.MembersInjectorImpl.injectMembers(MembersInjectorImpl.java:60)
at
com.google.inject.internal.InjectorImpl.injectMembers(InjectorImpl.java:944)
at
org.apache.isis.viewer.wicket.viewer.IsisWicketApplication.init(IsisWicketApplication.java:210)
at org.apache.wicket.Application.initApplication(Application.java:819)
at
[jira] [Updated] (ISIS-803) Replace lifecycle methods with additional EventBus events.
[ https://issues.apache.org/jira/browse/ISIS-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal updated ISIS-803: Fix Version/s: (was: core-1.7.0) core-2.0.0 Replace lifecycle methods with additional EventBus events. -- Key: ISIS-803 URL: https://issues.apache.org/jira/browse/ISIS-803 Project: Isis Issue Type: Improvement Components: Core Affects Versions: core-1.5.0 Reporter: Dan Haywood Assignee: Dan Haywood Fix For: core-2.0.0 This issue is to remove a feature that is only partly implemented in the JDO objectstore, namely the lifecycle methods. Jeroen and I were discussing this, and think they are possibly an anti-pattern since they tend to lead to fragile code. Rather than have the object pushing changes to others, it would be better if an event were broadcast via the EventBus. That way a subscribing service could pull appropriate changes and do whatever is necessary. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ISIS-780) @Inject on field and @RequestScoped are incompatible - use a MetaModelValidator to detect
[ https://issues.apache.org/jira/browse/ISIS-780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal updated ISIS-780: Fix Version/s: (was: core-1.7.0) core-2.0.0 @Inject on field and @RequestScoped are incompatible - use a MetaModelValidator to detect - Key: ISIS-780 URL: https://issues.apache.org/jira/browse/ISIS-780 Project: Isis Issue Type: Improvement Components: Core Affects Versions: core-1.4.0 Reporter: Dan Haywood Assignee: Dan Haywood Fix For: core-2.0.0 Our support for @RequestScoped annotation is home-grown; we create a Javassist proxy for the service, which then delegates to dynamically created instances of the actual service bound on a thread-local. The Javassist proxy automatically forwards all method calls to the underlying service for the current thread. If the request-scoped service has other services injected into it via methods (ie setXxx(...) or injectXxx(...), then these method calls are forwarded just like any other, and everything works fine. However, if the request-scoped service has its other services injected via a field annotated with @RequestScoped, then the service will be injected into the Javassist proxy and the underlying service will get a null pointer. One day we might replace our home-grown injection with a more sophisticated third-party library (eg a CDI impl?) that can handle the above. But until such time, as a workaround we should fail-fast: detect the situation and through an exception on start-up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ISIS-802) Remove the ProfileStore component (in future, can raise a ProfileService as and when we identify a concrete reqt).
[ https://issues.apache.org/jira/browse/ISIS-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal updated ISIS-802: Summary: Remove the ProfileStore component (in future, can raise a ProfileService as and when we identify a concrete reqt). (was: Profile Service as a replacement for the ProfileStore component) Remove the ProfileStore component (in future, can raise a ProfileService as and when we identify a concrete reqt). -- Key: ISIS-802 URL: https://issues.apache.org/jira/browse/ISIS-802 Project: Isis Issue Type: New Feature Components: Core Affects Versions: core-1.5.0 Reporter: Dan Haywood Assignee: Dan Haywood Fix For: core-1.7.0 As a write-up from IsisCon2014, Dan said: 6. Profile Store The profile store is a component of the framework that is not supported by either the Wicket or Restful Objects viewers, but whose functionality is broadly superceded by the UserSettingsService. To which Kevin replied: When the UI becomes user-configurable (re-arranged, pallete change, etc) this should be demo'd. Where are user preferences (e.g. UI language, timezone, etc) currently stored? Do we have demo code? And so Dan said: There are two points here... where to store preferences, and how/what within Isis should consume them. For the former, we have the UserSettingsService (part of applib); in the JDO applib there is an entity-based implementation, For the latter, nothing in Isis particularly consumes these. For timezones we tend to use LocalDate which gets around the issue to some extent; but you are right that the UserProfile class (in the profilestore) does hold this Localization class; that needs surfacing out as a first-class concept somehow. So perhaps ProfileStore should live on, but not as a component, but instead as a separate service. In all, I see three related subdomains: [Shiro security] - [Isis user profile (i18n etc) service] - [Isis user settings service] I'll raise a ticket to capture this thinking so far. ~ ... which is what this ticket is... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ISIS-748) Improve the way we setup logging to vary between prod and test, and independent of viewer.
[ https://issues.apache.org/jira/browse/ISIS-748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal updated ISIS-748: Fix Version/s: (was: viewer-wicket-1.7.0) (was: core-1.7.0) core-2.0.0 Improve the way we setup logging to vary between prod and test, and independent of viewer. -- Key: ISIS-748 URL: https://issues.apache.org/jira/browse/ISIS-748 Project: Isis Issue Type: Improvement Components: Core, Viewer: Wicket Affects Versions: viewer-wicket-1.4.1, core-1.4.0 Reporter: Dan Haywood Assignee: Dan Haywood Priority: Minor Fix For: core-2.0.0 There is very similar code in both IsisWebAppBootstrapper and the IsisWicketApplication, using IsisLoggingConfigurer. This should be factored out into something reusable by both, as a context initlaizer (global webapp scope). Then, in both cases let the logging.properties be picked up from some other directory outside of WEB-INF. ~~~ UPDATE: it seems that specifying log4j.configuration seems to override this already??? /usr/lib/jvm/java-7-openjdk-amd64/bin/java -Djava.util.logging.config.file=/var/lib/tomcat7/conf/logging.properties -Djava.awt.headless=true -Dfile.encoding=UTF-8 -server -Xms128m -Xmx768m -XX:PermSize=64m -XX:MaxPermSize=256m -XX:+DisableExplicitGC -Dlog4j.configuration=/etc/tomcat7/estatio/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/usr/share/tomcat7/endorsed -classpath /usr/share/tomcat7/bin/bootstrap.jar:/usr/share/tomcat7/bin/tomcat-juli.jar -Dcatalina.base=/var/lib/tomcat7 -Dcatalina.home=/usr/share/tomcat7 -Djava.io.tmpdir=/tmp/tomcat7-tomcat7-tmp org.apache.catalina.startup.Bootstrap start -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ISIS-666) Provide hints so that the viewer can navigate to some other entity than that returned.
[ https://issues.apache.org/jira/browse/ISIS-666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal updated ISIS-666: Fix Version/s: (was: core-1.7.0) core-2.0.0 Provide hints so that the viewer can navigate to some other entity than that returned. -- Key: ISIS-666 URL: https://issues.apache.org/jira/browse/ISIS-666 Project: Isis Issue Type: New Feature Components: Core Affects Versions: core-1.3.0 Reporter: Dan Haywood Assignee: Dan Haywood Fix For: core-2.0.0 As per discussion in http://markmail.org/message/xhmeq62ywr2vqvje An @Navigate annotation, a @NotNavigate annotation, perhaps an @AggregateRoot annotation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ISIS-542) Restrict which entities a service action is contributed to (as either a contributed action or contributed assocation).
[
https://issues.apache.org/jira/browse/ISIS-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeroen van der Wal updated ISIS-542:
Fix Version/s: (was: core-1.7.0)
core-1.8.0
Restrict which entities a service action is contributed to (as either a
contributed action or contributed assocation).
--
Key: ISIS-542
URL: https://issues.apache.org/jira/browse/ISIS-542
Project: Isis
Issue Type: New Feature
Components: Core
Affects Versions: core-1.2.0
Reporter: Dan Haywood
Assignee: Dan Haywood
Fix For: core-1.8.0
For example, an action
void foo(A a, B b) { ... }
will be contributed to both entities A and B. We might want to allow it to
be contributed to one or the other.
Suggestion is that @NotContributed annotation applies to action parameters
(with current behaviour maintained for compatibility as the default for all
parameters of the action):
eg
void foo(
@NotContributed(As.Action) A,
@NotContributed(As.Association) B) { ... }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (ISIS-506) Stability: defaultXxx() not working for properties...
[ https://issues.apache.org/jira/browse/ISIS-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal closed ISIS-506. --- Resolution: Won't Fix Fix Version/s: (was: core-1.7.0) We are tending to move away from the container instantiating and initializing our pojos (eg the created() call), and this old feature is very much in the same spirit. Stability: defaultXxx() not working for properties... - Key: ISIS-506 URL: https://issues.apache.org/jira/browse/ISIS-506 Project: Isis Issue Type: Bug Components: Core Reporter: Dan Haywood Assignee: Dan Haywood Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ISIS-491) Integrate JSR-349 validation.
[
https://issues.apache.org/jira/browse/ISIS-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeroen van der Wal updated ISIS-491:
Fix Version/s: (was: core-1.7.0)
core-2.0.0
Integrate JSR-349 validation.
-
Key: ISIS-491
URL: https://issues.apache.org/jira/browse/ISIS-491
Project: Isis
Issue Type: New Feature
Components: Core
Affects Versions: core-1.2.0
Reporter: Dan Haywood
Assignee: Oscar Bou
Fix For: core-1.8.0
Original Estimate: 72h
Remaining Estimate: 72h
as per
http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/
The reference implementation (Hibernate Validator) is Apache licensed [1].
~~~
Implementation: should not be too difficult; mostly a matter of writing some
FacetFactories.
It may not make sense to use every feature of JSR-349...
* constructor parameters
* constraint groups
1. In Isis bootstrapping, get hold and cache the Validator. (This is
thread-safe, so could perhaps be global; maybe as a new top-level component
cf AuthorizationManager etc).
ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
validator = factory.getValidator();
and also
executableValidator = validator.forExecutables();
Validating a property change can be done using:
SetConstraintViolationCar constraintViolations = validator.validateValue(
Car.class,
manufacturer,
null
);
assertEquals( 1, constraintViolations.size() );
assertEquals( may not be null,
constraintViolations.iterator().next().getMessage() );
(nb: using validator.validateProperty(...) would mean that the value has been
applied already).
eg this would be a facet that implements ValidatingInteractionAdvisor and
acts on a ValidityContext of type PropertyModifyContext. (eg subclass
PropertyValidateFacetAbstract)
2. Validating a parameter of an action can be done using:
Car object = new Car( Morris );
Method method = Car.class.getMethod( drive, int.class );
Object[] parameterValues = { 80 };
SetConstraintViolationCar violations =
executableValidator.validateParameters(
object,
method,
parameterValues
);
assertEquals( 1, violations.size() );
Class? extends Annotation constraintType = violations.iterator()
.next()
.getConstraintDescriptor()
.getAnnotation()
.annotationType();
assertEquals( Max.class, constraintType );
This would be in a Facet that implements ValidatingInteractionAdvisor and
acts on a ValidityContext of type ActionInvocationContext (eg subclass
ActionValidationFacetAbstract)
~~~
There are also some new features that could be implemented:
3. validating the return value of an action:
Car object = new Car( Morris );
Method method = Car.class.getMethod( getPassengers );
Object returnValue = Collections.PassengeremptyList();
SetConstraintViolationCar violations =
executableValidator.validateReturnValue(
object,
method,
returnValue
);
assertEquals( 1, violations.size() );
Class? extends Annotation constraintType = violations.iterator()
.next()
.getConstraintDescriptor()
.getAnnotation()
.annotationType();
assertEquals( Size.class, constraintType );
This would need to be done after the action has been invoked; if the
constraint failed, then an exception would be thrown causing the transaction
to be aborted. This might require a new subclass of ValidityContext, eg
ActionReturnValueContext.
4. cf ISIS-479, all dirtied objects should be validated prior to commit.
a) we re-validate all properties (using the value of the property as the
proposed value). This would be done using InteractionUtils, called from
isAssociationValid with a ValidityContext of PropertyModifyContext.
b) we validate the object, ie InteractionUtils, with all with a
ValidityContext of ObjectValidityContext.
We would then have a new facet, implementing ValidatingInteractionAdvisor and
acting on an ObjectValidityContext (eg subclass ValidateObjectFacetAbstract);
which should perform:
SetConstraintViolationCar constraintViolations = validator.validate( car
);
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ISIS-491) Integrate JSR-349 validation.
[
https://issues.apache.org/jira/browse/ISIS-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeroen van der Wal updated ISIS-491:
Fix Version/s: (was: core-2.0.0)
core-1.8.0
Integrate JSR-349 validation.
-
Key: ISIS-491
URL: https://issues.apache.org/jira/browse/ISIS-491
Project: Isis
Issue Type: New Feature
Components: Core
Affects Versions: core-1.2.0
Reporter: Dan Haywood
Assignee: Oscar Bou
Fix For: core-1.8.0
Original Estimate: 72h
Remaining Estimate: 72h
as per
http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/
The reference implementation (Hibernate Validator) is Apache licensed [1].
~~~
Implementation: should not be too difficult; mostly a matter of writing some
FacetFactories.
It may not make sense to use every feature of JSR-349...
* constructor parameters
* constraint groups
1. In Isis bootstrapping, get hold and cache the Validator. (This is
thread-safe, so could perhaps be global; maybe as a new top-level component
cf AuthorizationManager etc).
ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
validator = factory.getValidator();
and also
executableValidator = validator.forExecutables();
Validating a property change can be done using:
SetConstraintViolationCar constraintViolations = validator.validateValue(
Car.class,
manufacturer,
null
);
assertEquals( 1, constraintViolations.size() );
assertEquals( may not be null,
constraintViolations.iterator().next().getMessage() );
(nb: using validator.validateProperty(...) would mean that the value has been
applied already).
eg this would be a facet that implements ValidatingInteractionAdvisor and
acts on a ValidityContext of type PropertyModifyContext. (eg subclass
PropertyValidateFacetAbstract)
2. Validating a parameter of an action can be done using:
Car object = new Car( Morris );
Method method = Car.class.getMethod( drive, int.class );
Object[] parameterValues = { 80 };
SetConstraintViolationCar violations =
executableValidator.validateParameters(
object,
method,
parameterValues
);
assertEquals( 1, violations.size() );
Class? extends Annotation constraintType = violations.iterator()
.next()
.getConstraintDescriptor()
.getAnnotation()
.annotationType();
assertEquals( Max.class, constraintType );
This would be in a Facet that implements ValidatingInteractionAdvisor and
acts on a ValidityContext of type ActionInvocationContext (eg subclass
ActionValidationFacetAbstract)
~~~
There are also some new features that could be implemented:
3. validating the return value of an action:
Car object = new Car( Morris );
Method method = Car.class.getMethod( getPassengers );
Object returnValue = Collections.PassengeremptyList();
SetConstraintViolationCar violations =
executableValidator.validateReturnValue(
object,
method,
returnValue
);
assertEquals( 1, violations.size() );
Class? extends Annotation constraintType = violations.iterator()
.next()
.getConstraintDescriptor()
.getAnnotation()
.annotationType();
assertEquals( Size.class, constraintType );
This would need to be done after the action has been invoked; if the
constraint failed, then an exception would be thrown causing the transaction
to be aborted. This might require a new subclass of ValidityContext, eg
ActionReturnValueContext.
4. cf ISIS-479, all dirtied objects should be validated prior to commit.
a) we re-validate all properties (using the value of the property as the
proposed value). This would be done using InteractionUtils, called from
isAssociationValid with a ValidityContext of PropertyModifyContext.
b) we validate the object, ie InteractionUtils, with all with a
ValidityContext of ObjectValidityContext.
We would then have a new facet, implementing ValidatingInteractionAdvisor and
acting on an ObjectValidityContext (eg subclass ValidateObjectFacetAbstract);
which should perform:
SetConstraintViolationCar constraintViolations = validator.validate( car
);
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ISIS-491) Integrate JSR-349 validation.
[
https://issues.apache.org/jira/browse/ISIS-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeroen van der Wal updated ISIS-491:
Description:
as per
http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/
The reference implementation (Hibernate Validator) is Apache licensed [1].
~~~
Implementation: should not be too difficult; mostly a matter of writing some
FacetFactories.
It may not make sense to use every feature of JSR-349...
* constructor parameters
* constraint groups
1. In Isis bootstrapping, get hold and cache the Validator. (This is
thread-safe, so could perhaps be global; maybe as a new top-level component cf
AuthorizationManager etc).
{code}
ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
validator = factory.getValidator();
{code}
and also
{code}
executableValidator = validator.forExecutables();
{code}
Validating a property change can be done using:
{code}
SetConstraintViolationCar constraintViolations = validator.validateValue(
Car.class,
manufacturer,
null
);
assertEquals( 1, constraintViolations.size() );
assertEquals( may not be null,
constraintViolations.iterator().next().getMessage() );
{code}
(nb: using validator.validateProperty(...) would mean that the value has been
applied already).
eg this would be a facet that implements ValidatingInteractionAdvisor and acts
on a ValidityContext of type PropertyModifyContext. (eg subclass
PropertyValidateFacetAbstract)
2. Validating a parameter of an action can be done using:
{code}
Car object = new Car( Morris );
Method method = Car.class.getMethod( drive, int.class );
Object[] parameterValues = { 80 };
SetConstraintViolationCar violations =
executableValidator.validateParameters(
object,
method,
parameterValues
);
assertEquals( 1, violations.size() );
Class? extends Annotation constraintType = violations.iterator()
.next()
.getConstraintDescriptor()
.getAnnotation()
.annotationType();
assertEquals( Max.class, constraintType );
{code}
This would be in a Facet that implements ValidatingInteractionAdvisor and acts
on a ValidityContext of type ActionInvocationContext (eg subclass
ActionValidationFacetAbstract)
~~~
There are also some new features that could be implemented:
3. validating the return value of an action:
{code}
Car object = new Car( Morris );
Method method = Car.class.getMethod( getPassengers );
Object returnValue = Collections.PassengeremptyList();
SetConstraintViolationCar violations =
executableValidator.validateReturnValue(
object,
method,
returnValue
);
assertEquals( 1, violations.size() );
Class? extends Annotation constraintType = violations.iterator()
.next()
.getConstraintDescriptor()
.getAnnotation()
.annotationType();
assertEquals( Size.class, constraintType );
{code}
This would need to be done after the action has been invoked; if the constraint
failed, then an exception would be thrown causing the transaction to be
aborted. This might require a new subclass of ValidityContext, eg
ActionReturnValueContext.
4. cf ISIS-479, all dirtied objects should be validated prior to commit.
a) we re-validate all properties (using the value of the property as the
proposed value). This would be done using InteractionUtils, called from
isAssociationValid with a ValidityContext of PropertyModifyContext.
b) we validate the object, ie InteractionUtils, with all with a
ValidityContext of ObjectValidityContext.
We would then have a new facet, implementing ValidatingInteractionAdvisor and
acting on an ObjectValidityContext (eg subclass ValidateObjectFacetAbstract);
which should perform:
{code}
SetConstraintViolationCar constraintViolations = validator.validate( car );
{code}
was:
as per
http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/
The reference implementation (Hibernate Validator) is Apache licensed [1].
~~~
Implementation: should not be too difficult; mostly a matter of writing some
FacetFactories.
It may not make sense to use every feature of JSR-349...
* constructor parameters
* constraint groups
1. In Isis bootstrapping, get hold and cache the Validator. (This is
thread-safe, so could perhaps be global; maybe as a new top-level component cf
AuthorizationManager etc).
ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
validator = factory.getValidator();
and also
executableValidator = validator.forExecutables();
Validating a property change can be done using:
SetConstraintViolationCar constraintViolations = validator.validateValue(
Car.class,
manufacturer,
null
);
assertEquals( 1, constraintViolations.size() );
assertEquals( may not be null,
constraintViolations.iterator().next().getMessage() );
(nb: using validator.validateProperty(...)
[jira] [Updated] (ISIS-487) Domain Object not validated by Isis before being sent to the database and RuntimeException handling on IsisTransactionManager
[
https://issues.apache.org/jira/browse/ISIS-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeroen van der Wal updated ISIS-487:
Fix Version/s: (was: core-1.7.0)
core-2.0.0
Domain Object not validated by Isis before being sent to the database and
RuntimeException handling on IsisTransactionManager
-
Key: ISIS-487
URL: https://issues.apache.org/jira/browse/ISIS-487
Project: Isis
Issue Type: Bug
Components: Core
Affects Versions: core-1.2.0
Reporter: Oscar Bou
Assignee: Dan Haywood
Fix For: core-2.0.0
Experiencing the following issues:
1. Domain Object not validated by Isis before being sent to the database
(executed within a BDD test; perhaps that's relevant).
2. Not sure if I could/should throw an exception on the onFailure() closure
(as the Isis transaction wouldn't be aborted).
3. I would expect to be able to know the Runtime Exception that has
originated the failure.
I'm executing this code from inside a BDD integration test.
I have a Domain Object that inherits from this class, which contains a
required name property:
public abstract class AbstractMultiTenantEntity extends
AbstractMultiTenantObject implements MultiTenantEntity {
/**
* Name of this Entity.
*/
private String name;
@Column(allowsNull = false)
@Override
@MemberOrder(sequence = 0.1)
public String getName() {
return this.name;
}
@Override
public void setName(final String name) {
this.name = name;
}
public String validateName(final String name) {
if (name == null) {
return Name cannot be an empty string;
} else {
return null;
}
}
...
}
The Domain Object class is declared simply as:
public class Risk extends AbstractMultiTenantEntity {
...
}
I have a factory method like this one:
public Risk addQuantitativeRiskToAsset(...) {
// Here the name field is null.
this.persist(risk);
return risk;
}
The point is that, due to a programming error, I was not initializing the
name field (it was null). But this could happen also on other use cases.
But the main problem is that, when the this.persist(risk) method is executed,
the INSERT SQL instruction appears in the log and a database CONSTRAINT
exception requiring the NAME database table field not to be NULL appears (so
Isis has not previously validated the domain object and detected that the
name property was null).
As the database persist is cached, the only line appearing at the log is:
10:44:16,317 [DataNucleusSimplePersistAlgorithm main INFO ] persist
PojoAdapter@6ac42aea[T~~:!com.xms.framework.risk.domain.model.Risk:461a09cf-c483-4779-ae58-a1840baf6a9c,specification=Risk,version=null,pojo-toString=com.xms.framework.risk.domain.model.Risk@6ee01906,pojo-hash=#6ee01906]
But on the first flush(), when the persistence manager tries to insert the
record the following exception is showed in the log:
-
11:12:30,643 [DataNucleusSimplePersistAlgorithm main INFO ] persist
PojoAdapter@6d70c116[T~~:!com.xms.framework.risk.domain.model.Risk:bff8097b-72d9-40e1-b6de-aab8f5743194,specification=Risk,version=null,pojo-toString=com.xms.framework.risk.domain.model.Risk@85f4d6e2,pojo-hash=#85f4d6e2]
11:12:30,894 [auditmain INFO ] 2.
PreparedStatement.new PreparedStatement returned
11:12:30,894 [auditmain INFO ] 2.
Connection.prepareStatement(INSERT INTO RISK
(ID,NAME,AUTOMATICNAMING,LIKELIHOOD,CODE,EVENT_EVENT_ID_OID,IMPACT,UPDATEDBYUSER,DESCRIPTION,CATEGORY_RISKCATEGORY_ID_OID,ASSET_ENTITY_ID_OID,EVENTDESCRIPTION,CONSEQUENCESDESCRIPTION,RISKREGISTER_RISKREGISTER_ID_OID,EVENTSOURCEDESCRIPTION,OWNER_BUSINESSACTOR_ID_OID,IMPACTLEVEL_IMPACTLEVEL_ID_OID,CREATEDBYUSER,TENANTID,EVENTSOURCE_EVENTSOURCE_ID_OID,LIKELIHOODLEVEL_LIKELIHOODLEVEL_ID_OID,DATECREATED,DATEUPDATED,RISKSLEADEDBYIT_VULNERABILITY_ID_OID,RISKSMODIFIED_CONTROL_ID_OID)
VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?), 1) returned
net.sf.log4jdbc.PreparedStatementSpy@afe1bc5
11:12:30,894 [auditmain INFO ] 2.
PreparedStatement.clearBatch() returned
11:12:30,894 [auditmain INFO ] 2.
PreparedStatement.setTimestamp(23, 2013-08-03 11:12:30.643,
[jira] [Updated] (ISIS-487) Domain Object not validated by Isis before being sent to the database and RuntimeException handling on IsisTransactionManager
[
https://issues.apache.org/jira/browse/ISIS-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeroen van der Wal updated ISIS-487:
Description:
Experiencing the following issues:
1. Domain Object not validated by Isis before being sent to the database
(executed within a BDD test; perhaps that's relevant).
2. Not sure if I could/should throw an exception on the onFailure() closure
(as the Isis transaction wouldn't be aborted).
3. I would expect to be able to know the Runtime Exception that has originated
the failure.
I'm executing this code from inside a BDD integration test.
I have a Domain Object that inherits from this class, which contains a required
name property:
{code}
public abstract class AbstractMultiTenantEntity extends
AbstractMultiTenantObject implements MultiTenantEntity {
/**
* Name of this Entity.
*/
private String name;
@Column(allowsNull = false)
@Override
@MemberOrder(sequence = 0.1)
public String getName() {
return this.name;
}
@Override
public void setName(final String name) {
this.name = name;
}
public String validateName(final String name) {
if (name == null) {
return Name cannot be an empty string;
} else {
return null;
}
}
...
}
{code}
The Domain Object class is declared simply as:
{code}
public class Risk extends AbstractMultiTenantEntity {
...
}
{code}
I have a factory method like this one:
{code}
public Risk addQuantitativeRiskToAsset(...) {
// Here the name field is null.
this.persist(risk);
return risk;
}
{code}
The point is that, due to a programming error, I was not initializing the
name field (it was null). But this could happen also on other use cases.
But the main problem is that, when the this.persist(risk) method is executed,
the INSERT SQL instruction appears in the log and a database CONSTRAINT
exception requiring the NAME database table field not to be NULL appears (so
Isis has not previously validated the domain object and detected that the
name property was null).
As the database persist is cached, the only line appearing at the log is:
10:44:16,317 [DataNucleusSimplePersistAlgorithm main INFO ] persist
PojoAdapter@6ac42aea[T~~:!com.xms.framework.risk.domain.model.Risk:461a09cf-c483-4779-ae58-a1840baf6a9c,specification=Risk,version=null,pojo-toString=com.xms.framework.risk.domain.model.Risk@6ee01906,pojo-hash=#6ee01906]
But on the first flush(), when the persistence manager tries to insert the
record the following exception is showed in the log:
-
{code}
11:12:30,643 [DataNucleusSimplePersistAlgorithm main INFO ] persist
PojoAdapter@6d70c116[T~~:!com.xms.framework.risk.domain.model.Risk:bff8097b-72d9-40e1-b6de-aab8f5743194,specification=Risk,version=null,pojo-toString=com.xms.framework.risk.domain.model.Risk@85f4d6e2,pojo-hash=#85f4d6e2]
11:12:30,894 [auditmain INFO ] 2. PreparedStatement.new
PreparedStatement returned
11:12:30,894 [auditmain INFO ] 2.
Connection.prepareStatement(INSERT INTO RISK
(ID,NAME,AUTOMATICNAMING,LIKELIHOOD,CODE,EVENT_EVENT_ID_OID,IMPACT,UPDATEDBYUSER,DESCRIPTION,CATEGORY_RISKCATEGORY_ID_OID,ASSET_ENTITY_ID_OID,EVENTDESCRIPTION,CONSEQUENCESDESCRIPTION,RISKREGISTER_RISKREGISTER_ID_OID,EVENTSOURCEDESCRIPTION,OWNER_BUSINESSACTOR_ID_OID,IMPACTLEVEL_IMPACTLEVEL_ID_OID,CREATEDBYUSER,TENANTID,EVENTSOURCE_EVENTSOURCE_ID_OID,LIKELIHOODLEVEL_LIKELIHOODLEVEL_ID_OID,DATECREATED,DATEUPDATED,RISKSLEADEDBYIT_VULNERABILITY_ID_OID,RISKSMODIFIED_CONTROL_ID_OID)
VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?), 1) returned
net.sf.log4jdbc.PreparedStatementSpy@afe1bc5
11:12:30,894 [auditmain INFO ] 2.
PreparedStatement.clearBatch() returned
11:12:30,894 [auditmain INFO ] 2.
PreparedStatement.setTimestamp(23, 2013-08-03 11:12:30.643,
java.util.GregorianCalendar[time=1375521135947,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id=Europe/Madrid,offset=360,dstSavings=360,useDaylight=true,transitions=165,lastRule=java.util.SimpleTimeZone[id=Europe/Madrid,offset=360,dstSavings=360,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=360,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=360,endTimeMode=2]],firstDayOfWeek=2,minimalDaysInFirstWeek=4,ERA=1,YEAR=2013,MONTH=7,WEEK_OF_YEAR=31,WEEK_OF_MONTH=1,DAY_OF_MONTH=3,DAY_OF_YEAR=215,DAY_OF_WEEK=7,DAY_OF_WEEK_IN_MONTH=1,AM_PM=0,HOUR=11,HOUR_OF_DAY=11,MINUTE=12,SECOND=15,MILLISECOND=947,ZONE_OFFSET=360,DST_OFFSET=360])
returned
11:12:30,895 [auditmain INFO ] 2.
PreparedStatement.setTimestamp(22, 2013-08-03 11:12:30.643,
[jira] [Updated] (ISIS-483) Not properly recognizing Collections of generics as Action return type
[
https://issues.apache.org/jira/browse/ISIS-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeroen van der Wal updated ISIS-483:
Fix Version/s: (was: core-1.7.0)
core-2.0.0
Not properly recognizing Collections of generics as Action return type
--
Key: ISIS-483
URL: https://issues.apache.org/jira/browse/ISIS-483
Project: Isis
Issue Type: Bug
Components: Core
Affects Versions: core-1.2.0
Reporter: Oscar Bou
Assignee: Oscar Bou
Fix For: core-2.0.0
Create a repository that inherits from a generic one, which implements a
generic function like this:
public abstract class MyAbstractDomainObjectRepositoryAndFactoryDO extends
MyAbstractDomainObject
extends AbstractFactoryAndRepository {
public ListDO listAll() {
return this.allInstances(this.domainObjectClass);
}
...
}
Create a concrete implementation of the previous repository like this one,
which introduces a new action/method:
public class DomainEntityClassCustomRepository extends
AbstractMultiTenantEntityRepositoryAndFactoryDomainEntityClass {
...
public ListRiskRegister listAllRiskRegisters() {
return this.listAll();
}
...
}
And DomainEntityClass inherits from MyAbstractDomainObject.
If the listAllRiskRegisters action is invoked from the Wicket viewer it
works perfectly, and a list of DomainEntityClass'es is shown.
And if the list only contains 1 element, the listAll action also shows that
element.
But if the listAll action is invoked and the list contains more than 1
element the following exception is thrown:
org.apache.wicket.WicketRuntimeException
Can't instantiate page using constructor 'public
org.apache.isis.viewer.wicket.ui.pages.action.ActionPage(org.apache.wicket.request.mapper.parameter.PageParameters)'
and argument 'pageType=[ACTION], actionSingleResultsMode=[REDIRECT],
objectOid=[com.company.DomainEntityClassCustomRepository:1],
actionType=[USER],
actionOwningSpec=[com.company.DomainEntityClassCustomRepository],
actionId=[listAll()], pageTitle=[List All], actionMode=[RESULTS]'. Might be
it doesn't exist, may be it is not visible (public).
org.apache.wicket.session.DefaultPageFactory#newPage(DefaultPageFactory.java:193)
org.apache.wicket.session.DefaultPageFactory#newPage(DefaultPageFactory.java:98)
org.apache.wicket.DefaultMapperContext#newPageInstance(DefaultMapperContext.java:137)
org.apache.wicket.core.request.handler.PageProvider#resolvePageInstance(PageProvider.java:268)
org.apache.wicket.core.request.handler.PageProvider#getPageInstance(PageProvider.java:166)
org.apache.wicket.request.handler.render.PageRenderer#getPage(PageRenderer.java:78)
org.apache.wicket.request.handler.render.WebPageRenderer#renderPage(WebPageRenderer.java:94)
org.apache.wicket.request.handler.render.WebPageRenderer#respond(WebPageRenderer.java:196)
org.apache.wicket.core.request.handler.RenderPageRequestHandler#respond(RenderPageRequestHandler.java:165)
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor#respond(RequestCycle.java:854)
org.apache.wicket.request.RequestHandlerStack#execute(RequestHandlerStack.java:64)
org.apache.wicket.request.cycle.RequestCycle#execute(RequestCycle.java:254)
org.apache.wicket.request.cycle.RequestCycle#processRequest(RequestCycle.java:211)
org.apache.wicket.request.cycle.RequestCycle#processRequestAndDetach(RequestCycle.java:282)
org.apache.wicket.protocol.http.WicketFilter#processRequestCycle(WicketFilter.java:259)
org.apache.wicket.protocol.http.WicketFilter#processRequest(WicketFilter.java:201)
org.apache.wicket.protocol.http.WicketFilter#doFilter(WicketFilter.java:282)
org.eclipse.jetty.servlet.ServletHandler$CachedChain#doFilter(ServletHandler.java:1326)
org.apache.shiro.web.servlet.AbstractShiroFilter#executeChain(AbstractShiroFilter.java:449)
org.apache.shiro.web.servlet.AbstractShiroFilter$1#call(AbstractShiroFilter.java:365)
org.apache.shiro.subject.support.SubjectCallable#doCall(SubjectCallable.java:90)
org.apache.shiro.subject.support.SubjectCallable#call(SubjectCallable.java:83)
org.apache.shiro.subject.support.DelegatingSubject#execute(DelegatingSubject.java:383)
org.apache.shiro.web.servlet.AbstractShiroFilter#doFilterInternal(AbstractShiroFilter.java:362)
org.apache.shiro.web.servlet.OncePerRequestFilter#doFilter(OncePerRequestFilter.java:125)
org.eclipse.jetty.servlet.ServletHandler$CachedChain#doFilter(ServletHandler.java:1326)
org.eclipse.jetty.servlet.ServletHandler#doHandle(ServletHandler.java:479)
org.eclipse.jetty.server.handler.ScopedHandler#handle(ScopedHandler.java:119)
org.eclipse.jetty.security.SecurityHandler#handle(SecurityHandler.java:520)
[jira] [Updated] (ISIS-483) Not properly recognizing Collections of generics as Action return type
[
https://issues.apache.org/jira/browse/ISIS-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeroen van der Wal updated ISIS-483:
Description:
Create a repository that inherits from a generic one, which implements a
generic function like this:
{code}
public abstract class MyAbstractDomainObjectRepositoryAndFactoryDO extends
MyAbstractDomainObject
extends AbstractFactoryAndRepository {
public ListDO listAll() {
return this.allInstances(this.domainObjectClass);
}
...
}
{code}
Create a concrete implementation of the previous repository like this one,
which introduces a new action/method:
{code}
public class DomainEntityClassCustomRepository extends
AbstractMultiTenantEntityRepositoryAndFactoryDomainEntityClass {
...
public ListRiskRegister listAllRiskRegisters() {
return this.listAll();
}
...
}
{code}
And:
DomainEntityClass inherits from MyAbstractDomainObject.
If the listAllRiskRegisters action is invoked from the Wicket viewer it works
perfectly, and a list of DomainEntityClass'es is shown.
And if the list only contains 1 element, the listAll action also shows that
element.
But if the listAll action is invoked and the list contains more than 1
element the following exception is thrown:
{code}
org.apache.wicket.WicketRuntimeException
Can't instantiate page using constructor 'public
org.apache.isis.viewer.wicket.ui.pages.action.ActionPage(org.apache.wicket.request.mapper.parameter.PageParameters)'
and argument 'pageType=[ACTION], actionSingleResultsMode=[REDIRECT],
objectOid=[com.company.DomainEntityClassCustomRepository:1], actionType=[USER],
actionOwningSpec=[com.company.DomainEntityClassCustomRepository],
actionId=[listAll()], pageTitle=[List All], actionMode=[RESULTS]'. Might be it
doesn't exist, may be it is not visible (public).
org.apache.wicket.session.DefaultPageFactory#newPage(DefaultPageFactory.java:193)
org.apache.wicket.session.DefaultPageFactory#newPage(DefaultPageFactory.java:98)
org.apache.wicket.DefaultMapperContext#newPageInstance(DefaultMapperContext.java:137)
org.apache.wicket.core.request.handler.PageProvider#resolvePageInstance(PageProvider.java:268)
org.apache.wicket.core.request.handler.PageProvider#getPageInstance(PageProvider.java:166)
org.apache.wicket.request.handler.render.PageRenderer#getPage(PageRenderer.java:78)
org.apache.wicket.request.handler.render.WebPageRenderer#renderPage(WebPageRenderer.java:94)
org.apache.wicket.request.handler.render.WebPageRenderer#respond(WebPageRenderer.java:196)
org.apache.wicket.core.request.handler.RenderPageRequestHandler#respond(RenderPageRequestHandler.java:165)
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor#respond(RequestCycle.java:854)
org.apache.wicket.request.RequestHandlerStack#execute(RequestHandlerStack.java:64)
org.apache.wicket.request.cycle.RequestCycle#execute(RequestCycle.java:254)
org.apache.wicket.request.cycle.RequestCycle#processRequest(RequestCycle.java:211)
org.apache.wicket.request.cycle.RequestCycle#processRequestAndDetach(RequestCycle.java:282)
org.apache.wicket.protocol.http.WicketFilter#processRequestCycle(WicketFilter.java:259)
org.apache.wicket.protocol.http.WicketFilter#processRequest(WicketFilter.java:201)
org.apache.wicket.protocol.http.WicketFilter#doFilter(WicketFilter.java:282)
org.eclipse.jetty.servlet.ServletHandler$CachedChain#doFilter(ServletHandler.java:1326)
org.apache.shiro.web.servlet.AbstractShiroFilter#executeChain(AbstractShiroFilter.java:449)
org.apache.shiro.web.servlet.AbstractShiroFilter$1#call(AbstractShiroFilter.java:365)
org.apache.shiro.subject.support.SubjectCallable#doCall(SubjectCallable.java:90)
org.apache.shiro.subject.support.SubjectCallable#call(SubjectCallable.java:83)
org.apache.shiro.subject.support.DelegatingSubject#execute(DelegatingSubject.java:383)
org.apache.shiro.web.servlet.AbstractShiroFilter#doFilterInternal(AbstractShiroFilter.java:362)
org.apache.shiro.web.servlet.OncePerRequestFilter#doFilter(OncePerRequestFilter.java:125)
org.eclipse.jetty.servlet.ServletHandler$CachedChain#doFilter(ServletHandler.java:1326)
org.eclipse.jetty.servlet.ServletHandler#doHandle(ServletHandler.java:479)
org.eclipse.jetty.server.handler.ScopedHandler#handle(ScopedHandler.java:119)
org.eclipse.jetty.security.SecurityHandler#handle(SecurityHandler.java:520)
org.eclipse.jetty.server.session.SessionHandler#doHandle(SessionHandler.java:227)
org.eclipse.jetty.server.handler.ContextHandler#doHandle(ContextHandler.java:940)
org.eclipse.jetty.servlet.ServletHandler#doScope(ServletHandler.java:409)
org.eclipse.jetty.server.session.SessionHandler#doScope(SessionHandler.java:186)
org.eclipse.jetty.server.handler.ContextHandler#doScope(ContextHandler.java:874)
org.eclipse.jetty.server.handler.ScopedHandler#handle(ScopedHandler.java:117)
[jira] [Updated] (ISIS-404) Testing if a wrapped Domain Object has been persisted fails
[ https://issues.apache.org/jira/browse/ISIS-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal updated ISIS-404: Assignee: Dan Haywood (was: Jeroen van der Wal) Testing if a wrapped Domain Object has been persisted fails - Key: ISIS-404 URL: https://issues.apache.org/jira/browse/ISIS-404 Project: Isis Issue Type: Bug Components: Core Affects Versions: core-1.1.0 Environment: Testing against current JUnit viewer snapshot over the 1.0.2 quickstart prototype. Reporter: Oscar Bou Assignee: Dan Haywood Labels: test Fix For: core-1.7.0 While doing tests over factory actions, one assert would be to verify the object has been persisted through the DomainObjectContainer.isPersistent(domainObject) method. If the evaluation is done over a wrapped object, it returns false. If it's done over the original object, it returns true. As an example: // Test if the Domain Object has been persisted. assertTrue(domainObjectContainer .isPersistent(communicationPathAssociatedWithNode)); // Node must be wrapped for the Apache Isis validators to be executed. communicationPathAssociatedWithNode = wrapped(communicationPathAssociatedWithNode); assertTrue(domainObjectContainer .isPersistent(communicationPathAssociatedWithNode)); The last assertion fails. The only difference I expected was the validation of the programming model. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (ISIS-404) Testing if a wrapped Domain Object has been persisted fails
[ https://issues.apache.org/jira/browse/ISIS-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal reassigned ISIS-404: --- Assignee: Jeroen van der Wal (was: Oscar Bou) Testing if a wrapped Domain Object has been persisted fails - Key: ISIS-404 URL: https://issues.apache.org/jira/browse/ISIS-404 Project: Isis Issue Type: Bug Components: Core Affects Versions: core-1.1.0 Environment: Testing against current JUnit viewer snapshot over the 1.0.2 quickstart prototype. Reporter: Oscar Bou Assignee: Jeroen van der Wal Labels: test Fix For: core-1.7.0 While doing tests over factory actions, one assert would be to verify the object has been persisted through the DomainObjectContainer.isPersistent(domainObject) method. If the evaluation is done over a wrapped object, it returns false. If it's done over the original object, it returns true. As an example: // Test if the Domain Object has been persisted. assertTrue(domainObjectContainer .isPersistent(communicationPathAssociatedWithNode)); // Node must be wrapped for the Apache Isis validators to be executed. communicationPathAssociatedWithNode = wrapped(communicationPathAssociatedWithNode); assertTrue(domainObjectContainer .isPersistent(communicationPathAssociatedWithNode)); The last assertion fails. The only difference I expected was the validation of the programming model. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (ISIS-88) Enhance I18nFacetDecorator to allow descriptions and help text to be looked up for action parameters.
[ https://issues.apache.org/jira/browse/ISIS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal closed ISIS-88. -- Resolution: Won't Fix Fix Version/s: (was: core-1.7.0) Let's fix this when someone asks for it. And in any case, we know that the current implementation only takes the server locale into account, not the client locale. Enhance I18nFacetDecorator to allow descriptions and help text to be looked up for action parameters. - Key: ISIS-88 URL: https://issues.apache.org/jira/browse/ISIS-88 Project: Isis Issue Type: New Feature Components: Core Affects Versions: 0.1.2-incubating, core-1.0.0 Reporter: Dan Haywood Priority: Minor The I18nFacetDecorator allows name, description and help text to be looked up for properties, collections and actions, but only supports names for parameters. It should be enhanced to support description and help text for action parameters also. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ISIS-86) I18n should be performed with respect to the user's Locale, not the location of the server.
[ https://issues.apache.org/jira/browse/ISIS-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal updated ISIS-86: --- Fix Version/s: (was: core-1.7.0) core-1.8.0 I18n should be performed with respect to the user's Locale, not the location of the server. --- Key: ISIS-86 URL: https://issues.apache.org/jira/browse/ISIS-86 Project: Isis Issue Type: Improvement Components: Core Affects Versions: 0.1.2-incubating, core-1.0.0 Reporter: Dan Haywood Priority: Minor Fix For: core-1.8.0 Looking through the I18nFacetDecorator, it seems to do its localization with respect to the locale of the server (for a webapp). Rob recently introduced the Localization interface in the applib, available in the default runtime's UserProfile interface, and so it would be better to have the i18n done with respect to that interface instead. At the same time, I think we ought to have Localization NOT be dependent on the default runtime, ie it ought to be available from the UserMemento, rather than in UserProfile. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (ISIS-86) I18n should be performed with respect to the user's Locale, not the location of the server.
[ https://issues.apache.org/jira/browse/ISIS-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal closed ISIS-86. -- Resolution: Duplicate Fix Version/s: (was: core-1.8.0) I18n should be performed with respect to the user's Locale, not the location of the server. --- Key: ISIS-86 URL: https://issues.apache.org/jira/browse/ISIS-86 Project: Isis Issue Type: Improvement Components: Core Affects Versions: 0.1.2-incubating, core-1.0.0 Reporter: Dan Haywood Priority: Minor Looking through the I18nFacetDecorator, it seems to do its localization with respect to the locale of the server (for a webapp). Rob recently introduced the Localization interface in the applib, available in the default runtime's UserProfile interface, and so it would be better to have the i18n done with respect to that interface instead. At the same time, I think we ought to have Localization NOT be dependent on the default runtime, ie it ought to be available from the UserMemento, rather than in UserProfile. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (ISIS-850) Target field in IsisCommand is to small to save actions on viewmodels
[ https://issues.apache.org/jira/browse/ISIS-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal closed ISIS-850. --- Resolution: Fixed Since the command module has moved to Isisaddons it's fixed there: https://github.com/isisaddons/isis-module-command/issues/1 Target field in IsisCommand is to small to save actions on viewmodels - Key: ISIS-850 URL: https://issues.apache.org/jira/browse/ISIS-850 Project: Isis Issue Type: Bug Components: Modules Affects Versions: core-1.6.0 Reporter: Jeroen van der Wal Assignee: Jeroen van der Wal When executing an action on a viewmodel the target contains the full memento so it will exceed the 255 characters of the column in the IsisCommand table. Need to investigate further what the maximum column length should be and decide to either extend or change to Clob/Text -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (ISIS-852) Derived property cannot be written properly
[
https://issues.apache.org/jira/browse/ISIS-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14095983#comment-14095983
]
Jeroen van der Wal commented on ISIS-852:
-
I don't know if this is a bug, Isis is just not designed to enable editing of
derived properties. The pattern we are using is disabling the edit button (by
adding @Immutable) and only allow changes through an action. In your case:
{code}
@javax.jdo.annotations.Persistent
private DateTime beginAt;
public DateTime getBeginAt() {
return beginAt;
}
public void setBeginAt(DateTime beginAt) {
this.beginAt = beginAt;
}
public AbstractDomainObject changeBeginDate(LocalDate beginDate) {
setBeginAt(getBeginAt().withDate(beginDate.getYear(),
beginDate.getMonthOfYear(), beginDate.getDayOfMonth()));
return this;
}
{code}
Derived property cannot be written properly
---
Key: ISIS-852
URL: https://issues.apache.org/jira/browse/ISIS-852
Project: Isis
Issue Type: Bug
Components: Core, Core: Objectstore: JDO
Affects Versions: objectstore-jdo-1.5.0, core-1.5.0
Reporter: Thomas Koren
Assignee: Dan Haywood
when using the proposed modifyXxx syntax to make a derived property writable,
it is rendered as disabled in wicket viewer.
{code:title=demo|borderStyle=solid}
public LocalDate getDerivedDate() { ... }
public void modifyDerivedDate(final LocalDate date) { ... }
{code}
when using the alternative setXxx syntax, the UI component is writable. but
in this case, the value of the derived property is not written to the
persisted property.
{code:title=demo|borderStyle=solid}
// {{ BeginAt (property)
@javax.jdo.annotations.Persistent
private DateTime beginAt;
@Disabled
@javax.jdo.annotations.Column(allowsNull = false)
public DateTime getBeginAt() {
return beginAt;
}
public void setBeginAt(final DateTime beginAt) {
this.beginAt = beginAt;
}
// }}
// {{ DerivedDate (property)
@NotPersisted
@NotPersistent
public LocalDate getDerivedDate() {
return getBeginAt().toLocalDate();
}
public void setDerivedDate(final LocalDate beginDate) {
setBeginAt(getBeginAt().withDate(beginDate.getYear(),
beginDate.getMonthOfYear(), beginDate.getDayOfMonth()));
}
// }}
{code}
it seems like the value set by the derived property gets overwritten by the
original/old value of the persisted property that is displayed in the wicket
component.
therefore it might only be an issue, if original and derived properties are
members of the same entity and displayed via wicket viewer.
some background:
i try to use 3 ui components (= derived properties: date, hour, minute) to
set a single persisted DateTime property.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (ISIS-853) joda DateTime properties loose time when persisted
[ https://issues.apache.org/jira/browse/ISIS-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal updated ISIS-853: Component/s: (was: Core: Objectstore: JDO) Viewer: Wicket joda DateTime properties loose time when persisted -- Key: ISIS-853 URL: https://issues.apache.org/jira/browse/ISIS-853 Project: Isis Issue Type: Bug Components: Viewer: Wicket Affects Versions: viewer-wicket-1.6.0 Reporter: Thomas Koren Assignee: Dan Haywood creating and persisting an entity just containing a DateTime and a String property via service action works just fine. when this entity is reopened and saved in wicket viewer without changing anything, the time component is set to 00:00. or, to be more precise: to 00:00 UTC which, in my case, is rendered as 02:00 (vienna: UTC+1 + daylight saving time) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (ISIS-853) joda DateTime properties loose time when persisted
[ https://issues.apache.org/jira/browse/ISIS-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal updated ISIS-853: Affects Version/s: (was: objectstore-jdo-1.5.0) viewer-wicket-1.6.0 joda DateTime properties loose time when persisted -- Key: ISIS-853 URL: https://issues.apache.org/jira/browse/ISIS-853 Project: Isis Issue Type: Bug Components: Viewer: Wicket Affects Versions: viewer-wicket-1.6.0 Reporter: Thomas Koren Assignee: Dan Haywood creating and persisting an entity just containing a DateTime and a String property via service action works just fine. when this entity is reopened and saved in wicket viewer without changing anything, the time component is set to 00:00. or, to be more precise: to 00:00 UTC which, in my case, is rendered as 02:00 (vienna: UTC+1 + daylight saving time) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (ISIS-852) Derived property cannot be written properly
[
https://issues.apache.org/jira/browse/ISIS-852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeroen van der Wal updated ISIS-852:
Affects Version/s: (was: objectstore-jdo-1.5.0)
(was: core-1.5.0)
viewer-wicket-1.6.0
Derived property cannot be written properly
---
Key: ISIS-852
URL: https://issues.apache.org/jira/browse/ISIS-852
Project: Isis
Issue Type: Bug
Components: Viewer: Wicket
Affects Versions: viewer-wicket-1.6.0
Reporter: Thomas Koren
Assignee: Dan Haywood
when using the proposed modifyXxx syntax to make a derived property writable,
it is rendered as disabled in wicket viewer.
{code:title=demo|borderStyle=solid}
public LocalDate getDerivedDate() { ... }
public void modifyDerivedDate(final LocalDate date) { ... }
{code}
when using the alternative setXxx syntax, the UI component is writable. but
in this case, the value of the derived property is not written to the
persisted property.
{code:title=demo|borderStyle=solid}
// {{ BeginAt (property)
@javax.jdo.annotations.Persistent
private DateTime beginAt;
@Disabled
@javax.jdo.annotations.Column(allowsNull = false)
public DateTime getBeginAt() {
return beginAt;
}
public void setBeginAt(final DateTime beginAt) {
this.beginAt = beginAt;
}
// }}
// {{ DerivedDate (property)
@NotPersisted
@NotPersistent
public LocalDate getDerivedDate() {
return getBeginAt().toLocalDate();
}
public void setDerivedDate(final LocalDate beginDate) {
setBeginAt(getBeginAt().withDate(beginDate.getYear(),
beginDate.getMonthOfYear(), beginDate.getDayOfMonth()));
}
// }}
{code}
it seems like the value set by the derived property gets overwritten by the
original/old value of the persisted property that is displayed in the wicket
component.
therefore it might only be an issue, if original and derived properties are
members of the same entity and displayed via wicket viewer.
some background:
i try to use 3 ui components (= derived properties: date, hour, minute) to
set a single persisted DateTime property.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (ISIS-852) Derived property cannot be written properly
[
https://issues.apache.org/jira/browse/ISIS-852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeroen van der Wal updated ISIS-852:
Component/s: (was: Core: Objectstore: JDO)
(was: Core)
Viewer: Wicket
Derived property cannot be written properly
---
Key: ISIS-852
URL: https://issues.apache.org/jira/browse/ISIS-852
Project: Isis
Issue Type: Bug
Components: Viewer: Wicket
Affects Versions: viewer-wicket-1.6.0
Reporter: Thomas Koren
Assignee: Dan Haywood
when using the proposed modifyXxx syntax to make a derived property writable,
it is rendered as disabled in wicket viewer.
{code:title=demo|borderStyle=solid}
public LocalDate getDerivedDate() { ... }
public void modifyDerivedDate(final LocalDate date) { ... }
{code}
when using the alternative setXxx syntax, the UI component is writable. but
in this case, the value of the derived property is not written to the
persisted property.
{code:title=demo|borderStyle=solid}
// {{ BeginAt (property)
@javax.jdo.annotations.Persistent
private DateTime beginAt;
@Disabled
@javax.jdo.annotations.Column(allowsNull = false)
public DateTime getBeginAt() {
return beginAt;
}
public void setBeginAt(final DateTime beginAt) {
this.beginAt = beginAt;
}
// }}
// {{ DerivedDate (property)
@NotPersisted
@NotPersistent
public LocalDate getDerivedDate() {
return getBeginAt().toLocalDate();
}
public void setDerivedDate(final LocalDate beginDate) {
setBeginAt(getBeginAt().withDate(beginDate.getYear(),
beginDate.getMonthOfYear(), beginDate.getDayOfMonth()));
}
// }}
{code}
it seems like the value set by the derived property gets overwritten by the
original/old value of the persisted property that is displayed in the wicket
component.
therefore it might only be an issue, if original and derived properties are
members of the same entity and displayed via wicket viewer.
some background:
i try to use 3 ui components (= derived properties: date, hour, minute) to
set a single persisted DateTime property.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (ISIS-852) Derived property cannot be written properly
[
https://issues.apache.org/jira/browse/ISIS-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14096150#comment-14096150
]
Jeroen van der Wal commented on ISIS-852:
-
You're right! According to the documentation it should be possible. In Estatio
we have never gone this route. Probably Dan can elaborate on this.
Derived property cannot be written properly
---
Key: ISIS-852
URL: https://issues.apache.org/jira/browse/ISIS-852
Project: Isis
Issue Type: Bug
Components: Viewer: Wicket
Affects Versions: viewer-wicket-1.6.0
Reporter: Thomas Koren
Assignee: Dan Haywood
when using the proposed modifyXxx syntax to make a derived property writable,
it is rendered as disabled in wicket viewer.
{code:title=demo|borderStyle=solid}
public LocalDate getDerivedDate() { ... }
public void modifyDerivedDate(final LocalDate date) { ... }
{code}
when using the alternative setXxx syntax, the UI component is writable. but
in this case, the value of the derived property is not written to the
persisted property.
{code:title=demo|borderStyle=solid}
// {{ BeginAt (property)
@javax.jdo.annotations.Persistent
private DateTime beginAt;
@Disabled
@javax.jdo.annotations.Column(allowsNull = false)
public DateTime getBeginAt() {
return beginAt;
}
public void setBeginAt(final DateTime beginAt) {
this.beginAt = beginAt;
}
// }}
// {{ DerivedDate (property)
@NotPersisted
@NotPersistent
public LocalDate getDerivedDate() {
return getBeginAt().toLocalDate();
}
public void setDerivedDate(final LocalDate beginDate) {
setBeginAt(getBeginAt().withDate(beginDate.getYear(),
beginDate.getMonthOfYear(), beginDate.getDayOfMonth()));
}
// }}
{code}
it seems like the value set by the derived property gets overwritten by the
original/old value of the persisted property that is displayed in the wicket
component.
therefore it might only be an issue, if original and derived properties are
members of the same entity and displayed via wicket viewer.
some background:
i try to use 3 ui components (= derived properties: date, hour, minute) to
set a single persisted DateTime property.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (ISIS-850) Target field in IsisCommand is to small to save actions on viewmodels
Jeroen van der Wal created ISIS-850: --- Summary: Target field in IsisCommand is to small to save actions on viewmodels Key: ISIS-850 URL: https://issues.apache.org/jira/browse/ISIS-850 Project: Isis Issue Type: Bug Components: Modules Affects Versions: core-1.6.0 Reporter: Jeroen van der Wal Assignee: Jeroen van der Wal When executing an action on a viewmodel the target contains the full memento so it will exceed the 255 characters of the column in the IsisCommand table. Need to investigate further what the maximum column length should be and decide to either extend or change to Clob/Text -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (ISIS-825) Wicket viewer, auto-focus on first field on action parameter not working
[
https://issues.apache.org/jira/browse/ISIS-825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeroen van der Wal reopened ISIS-825:
-
This fix breaks actions containing a BigDecimal resulting in this error:
java.lang.IllegalArgumentException cannot update component that does not have
setOutputMarkupId property set to true. Component: [BigDecimalTextField
[Component id = scalarIfCompact]]
Full stacktrace:
{code}
Stack trace:
org.apache.wicket.WicketRuntimeException
Method onRequest of interface org.apache.wicket.behavior.IBehaviorListener
targeted at org.apache.wicket.ajax.markup.html.AjaxLink$1@46a46a0b on component
[AjaxLink [Component id = additionalLink]] threw an exception
org.apache.wicket.RequestListenerInterface#internalInvoke(RequestListenerInterface.java:268)
org.apache.wicket.RequestListenerInterface#invoke(RequestListenerInterface.java:241)
org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler#invokeListener(ListenerInterfaceRequestHandler.java:250)
org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler#respond(ListenerInterfaceRequestHandler.java:236)
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor#respond(RequestCycle.java:862)
org.apache.wicket.request.RequestHandlerStack#execute(RequestHandlerStack.java:64)
org.apache.wicket.request.cycle.RequestCycle#execute(RequestCycle.java:261)
org.apache.wicket.request.cycle.RequestCycle#processRequest(RequestCycle.java:218)
org.apache.wicket.request.cycle.RequestCycle#processRequestAndDetach(RequestCycle.java:289)
org.apache.wicket.protocol.http.WicketFilter#processRequestCycle(WicketFilter.java:259)
org.apache.wicket.protocol.http.WicketFilter#processRequest(WicketFilter.java:201)
org.apache.wicket.protocol.http.WicketFilter#doFilter(WicketFilter.java:282)
org.apache.catalina.core.ApplicationFilterChain#internalDoFilter(ApplicationFilterChain.java:243)
org.apache.catalina.core.ApplicationFilterChain#doFilter(ApplicationFilterChain.java:210)
org.apache.shiro.web.servlet.AbstractShiroFilter#executeChain(AbstractShiroFilter.java:449)
org.apache.shiro.web.servlet.AbstractShiroFilter$1#call(AbstractShiroFilter.java:365)
org.apache.shiro.subject.support.SubjectCallable#doCall(SubjectCallable.java:90)
org.apache.shiro.subject.support.SubjectCallable#call(SubjectCallable.java:83)
org.apache.shiro.subject.support.DelegatingSubject#execute(DelegatingSubject.java:383)
org.apache.shiro.web.servlet.AbstractShiroFilter#doFilterInternal(AbstractShiroFilter.java:362)
org.apache.shiro.web.servlet.OncePerRequestFilter#doFilter(OncePerRequestFilter.java:125)
org.apache.catalina.core.ApplicationFilterChain#internalDoFilter(ApplicationFilterChain.java:243)
org.apache.catalina.core.ApplicationFilterChain#doFilter(ApplicationFilterChain.java:210)
org.apache.catalina.core.StandardWrapperValve#invoke(StandardWrapperValve.java:225)
org.apache.catalina.core.StandardContextValve#invoke(StandardContextValve.java:123)
org.apache.catalina.authenticator.AuthenticatorBase#invoke(AuthenticatorBase.java:472)
org.apache.catalina.core.StandardHostValve#invoke(StandardHostValve.java:168)
org.apache.catalina.valves.ErrorReportValve#invoke(ErrorReportValve.java:98)
org.apache.catalina.valves.AccessLogValve#invoke(AccessLogValve.java:927)
org.apache.catalina.core.StandardEngineValve#invoke(StandardEngineValve.java:118)
org.apache.catalina.connector.CoyoteAdapter#service(CoyoteAdapter.java:407)
org.apache.coyote.http11.AbstractHttp11Processor#process(AbstractHttp11Processor.java:1001)
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler#process(AbstractProtocol.java:579)
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor#run(JIoEndpoint.java:310)
java.util.concurrent.ThreadPoolExecutor#runWorker(ThreadPoolExecutor.java:1145)
java.util.concurrent.ThreadPoolExecutor$Worker#run(ThreadPoolExecutor.java:615)
java.lang.Thread#run(Thread.java:724)
java.lang.reflect.InvocationTargetException
sun.reflect.NativeMethodAccessorImpl#invoke0(NativeMethodAccessorImpl.java:-2)
sun.reflect.NativeMethodAccessorImpl#invoke(NativeMethodAccessorImpl.java:57)
sun.reflect.DelegatingMethodAccessorImpl#invoke(DelegatingMethodAccessorImpl.java:43)
java.lang.reflect.Method#invoke(Method.java:606)
org.apache.wicket.RequestListenerInterface#internalInvoke(RequestListenerInterface.java:258)
org.apache.wicket.RequestListenerInterface#invoke(RequestListenerInterface.java:241)
org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler#invokeListener(ListenerInterfaceRequestHandler.java:250)
org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler#respond(ListenerInterfaceRequestHandler.java:236)
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor#respond(RequestCycle.java:862)
org.apache.wicket.request.RequestHandlerStack#execute(RequestHandlerStack.java:64)
org.apache.wicket.request.cycle.RequestCycle#execute(RequestCycle.java:261)
[jira] [Commented] (ISIS-825) Wicket viewer, auto-focus on first field on action parameter not working
[ https://issues.apache.org/jira/browse/ISIS-825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14071671#comment-14071671 ] Jeroen van der Wal commented on ISIS-825: - I think we should not go forward with 1.6.0-RC2 since the improvement causes a bigger regression. Wicket viewer, auto-focus on first field on action parameter not working Key: ISIS-825 URL: https://issues.apache.org/jira/browse/ISIS-825 Project: Isis Issue Type: Improvement Components: Viewer: Wicket Affects Versions: viewer-wicket-1.5.0 Environment: Windows 8.1, Chrome/IE 11 Reporter: Markus Bozem Assignee: Dan Haywood Fix For: viewer-wicket-1.7.0 Autofocus ist not set on first field on action (modal dialog). See ISIS-527. Auto-focus is working on edit object. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (ISIS-573) To improve performance, set up caching of query results against any entities that are immutable (ie ref data, ie have ImmutableFacet on them).
[ https://issues.apache.org/jira/browse/ISIS-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14065625#comment-14065625 ] Jeroen van der Wal commented on ISIS-573: - We currently use (or misuse) @Immutable it disable all members of a class. Adding caching to the facet would harm the behavior of our applications. Implementing @Disabled on a class level would provide an alternative for us. See: ISIS-454 To improve performance, set up caching of query results against any entities that are immutable (ie ref data, ie have ImmutableFacet on them). -- Key: ISIS-573 URL: https://issues.apache.org/jira/browse/ISIS-573 Project: Isis Issue Type: New Feature Components: Core, Core: Objectstore: JDO Affects Versions: objectstore-jdo-1.1.0, core-1.2.0 Reporter: Dan Haywood Assignee: Dan Haywood Fix For: core-1.7.0 In DN, this is done using: query.addExtension(datanucleus.query.results.cached, true); query.addExtension(datanucleus.query.resultCache.validateObjects, false); So, need to figure out how to set up these properties on queries by repositories of immutable facets. But this could probably be done transparently. NB: for these cache results to hang around and not get garbage collected, would also need to set the global config parm: datanucleus.cache.queryResult.type=strong ... its default value is weak. Further info at: http://www.datanucleus.org/products/datanucleus/jdo/query_cache.html#datastoreCompilation -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (ISIS-573) To improve performance, set up caching of query results against any entities that are immutable (ie ref data, ie have ImmutableFacet on them).
[ https://issues.apache.org/jira/browse/ISIS-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14065625#comment-14065625 ] Jeroen van der Wal edited comment on ISIS-573 at 7/17/14 9:54 PM: -- We currently use (or misuse) @Immutable to disable all members of a class. Adding caching logic to the facet would harm the behavior of our applications. Implementing @Disabled on a class level would provide us with an option to abandon the current misuse of @Immutable. See also ISIS-454 was (Author: jcvanderwal): We currently use (or misuse) @Immutable it disable all members of a class. Adding caching to the facet would harm the behavior of our applications. Implementing @Disabled on a class level would provide an alternative for us. See: ISIS-454 To improve performance, set up caching of query results against any entities that are immutable (ie ref data, ie have ImmutableFacet on them). -- Key: ISIS-573 URL: https://issues.apache.org/jira/browse/ISIS-573 Project: Isis Issue Type: New Feature Components: Core, Core: Objectstore: JDO Affects Versions: objectstore-jdo-1.1.0, core-1.2.0 Reporter: Dan Haywood Assignee: Dan Haywood Fix For: core-1.7.0 In DN, this is done using: query.addExtension(datanucleus.query.results.cached, true); query.addExtension(datanucleus.query.resultCache.validateObjects, false); So, need to figure out how to set up these properties on queries by repositories of immutable facets. But this could probably be done transparently. NB: for these cache results to hang around and not get garbage collected, would also need to set the global config parm: datanucleus.cache.queryResult.type=strong ... its default value is weak. Further info at: http://www.datanucleus.org/products/datanucleus/jdo/query_cache.html#datastoreCompilation -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (ISIS-821) Precision gets lost when double values are use in BigDecimal attributes
[ https://issues.apache.org/jira/browse/ISIS-821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal resolved ISIS-821. - Resolution: Fixed Precision gets lost when double values are use in BigDecimal attributes --- Key: ISIS-821 URL: https://issues.apache.org/jira/browse/ISIS-821 Project: Isis Issue Type: Bug Components: Viewer: RestfulObjects Affects Versions: viewer-restfulobjects-2.3.0 Reporter: Jeroen van der Wal Assignee: Jeroen van der Wal Fix For: viewer-restfulobjects-2.4.0 The restful spec requires BigDecimal values to surrounded by quotes. When doubles are being used the conversion to BigDecimal is incorrect. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (ISIS-801) Action method taking domain object paramater gets triggered automatically whenever instances of that object type is accessed
[
https://issues.apache.org/jira/browse/ISIS-801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14027744#comment-14027744
]
Jeroen van der Wal commented on ISIS-801:
-
Have you put a breakpoint on the line with the persist, run in debug mode and
confirmed that this line is called unexpectedly? If so, could you attach the
stacktrace?
Action method taking domain object paramater gets triggered automatically
whenever instances of that object type is accessed
Key: ISIS-801
URL: https://issues.apache.org/jira/browse/ISIS-801
Project: Isis
Issue Type: Bug
Reporter: Ranganath Chittari
Assignee: Dan Haywood
Priority: Critical
I have application security service which creates permission to manage
particular entity(OmSite). Its action method is:
@Bookmarkable
@MemberOrder(sequence = 9)
@Named(Create Site Permission)
public OmPermission createSitePermission(final @Named(Choose a site)
OmSite site) {
final OmPermission obj = newTransientInstance(OmPermission.class);
obj.setPermission(SecurityUtil.formatSitePermission(site.getOrgId(),
site.getSiteId()));
obj.setSite(site);
persistIfNotAlready(obj);
return obj;
}
As you can see this method takes OmSite instance to create a permission to
that instance. And OmPermission has foreign key to OmSite. This action is
displayed in service menu and its working fine.
But the problem I am facing is when I access the list of OmSite objects in
other UI pages. This action method is getting triggered automatically and
inserts bulk OmPermissions for all those ListOmSite objects.
This action method createSitePermission should be invoked only if it is
clicked manually, but it gets triggered automatically whenever OmSite is
accesed in some other places.
For ex:
an action that returns a list of these OmSite,
when OmSite is in a collection of some other entity,
When new OmSite is created.
Workaround for this issue is annotate @NotContributed to that action method,
it will prevent from invoking this method whenever its parameter instance is
accessed.
BR
Ranganath Varma
Could you please look into this issue.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (ISIS-765) Allow UserMemento#hasRole to match on wildcards
Jeroen van der Wal created ISIS-765: --- Summary: Allow UserMemento#hasRole to match on wildcards Key: ISIS-765 URL: https://issues.apache.org/jira/browse/ISIS-765 Project: Isis Issue Type: Improvement Components: Core Affects Versions: core-1.4.0 Reporter: Jeroen van der Wal Assignee: Jeroen van der Wal Priority: Minor Fix For: core-1.4.2 The roles the user has are prefixed by the realm they they were defined in. In orderer to make role matching across realms easier I suggest to use regex matching. Example: *user_role matches both ldapRealm:user_role and localRealm:user_role -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (ISIS-765) Allow UserMemento#hasRole to match on wildcards
[ https://issues.apache.org/jira/browse/ISIS-765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal resolved ISIS-765. - Resolution: Fixed Allow UserMemento#hasRole to match on wildcards --- Key: ISIS-765 URL: https://issues.apache.org/jira/browse/ISIS-765 Project: Isis Issue Type: Improvement Components: Core Affects Versions: core-1.4.0 Reporter: Jeroen van der Wal Assignee: Jeroen van der Wal Priority: Minor Fix For: core-1.4.2 The roles the user has are prefixed by the realm they they were defined in. In orderer to make role matching across realms easier I suggest to use regex matching. Example: *user_role matches both ldapRealm:user_role and localRealm:user_role -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (ISIS-758) Auditing should be able to cope with a change to a property where the referenced object has been deleted.
Jeroen van der Wal created ISIS-758: --- Summary: Auditing should be able to cope with a change to a property where the referenced object has been deleted. Key: ISIS-758 URL: https://issues.apache.org/jira/browse/ISIS-758 Project: Isis Issue Type: Bug Components: Core Affects Versions: core-1.4.0 Reporter: Jeroen van der Wal Assignee: Dan Haywood Fix For: core-1.4.2 For example, doing a cascade delete of Parent -* Child. Here, the Parent and each of the Children will be audited, and in the case of Child, its parent reference is changing from (parent) to null. However, as the parent itself is deleted, trying to generate its toString() (when using JDO object store) is causing an exception. The fix is to grab the toString of the object when the objects are enlisted into the transaction, before they are deleted. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (ISIS-760) IllegalStateException when commands/audit enabled in Estatio and failing to persist the Oid of a view model.
Jeroen van der Wal created ISIS-760:
---
Summary: IllegalStateException when commands/audit enabled in
Estatio and failing to persist the Oid of a view model.
Key: ISIS-760
URL: https://issues.apache.org/jira/browse/ISIS-760
Project: Isis
Issue Type: Bug
Reporter: Jeroen van der Wal
Assignee: Dan Haywood
Priority: Critical
There are two separate issues here:
- first is that the auditing service's column for storing OIDs isn't long
enough for view models.
- the second is that, given this then causes the xactn to be aborted, that it
throws an IllegalStateException for any subsequent interaction with the system.
The only fix is to restart the server. See details below
The reason for the second issue is that the previous session does not close
correctly. This is because of an exception being thrown in
PersistenceSession#close:
PersistenceSession.completeCommandIfConfigured() line: 418
PersistenceSession.closeServices() line: 399
PersistenceSession.close() line: 372
IsisSessionDefault.close() line: 119
IsisContextThreadLocal(IsisContext).closeSessionInstance() line: 219
WebRequestCycleForIsis.onEndRequest(RequestCycle) line: 134
This in turn is because of an attempt to complete any pending command (per the
CommandJdo service) on a xactn that has already been aborted.
The fix, I think, is simple enough; add a guard...
private void completeCommandIfConfigured() {
// NEW CODE START
if(getTransactionManager().getTransaction().getState().isComplete()) {
// can't do anything, since already complete (possibly aborted)
return;
}
// NEW CODE END
final CommandContext commandContext =
getServiceOrNull(CommandContext.class);
if(commandContext != null) {
final CommandService commandService =
getServiceOrNull(CommandService.class);
if(commandService != null) {
final Command command = commandContext.getCommand();
commandService.complete(command);
}
}
}
~~
to reproduce:
with estatio demo data
find invoices for status new
choose oxford
approve all.
A server restart was required.
{code}
java.lang.IllegalStateException
Session already open and context not configured for autoclose
org.apache.isis.core.runtime.system.context.IsisContext#applySessionClosePolicy(IsisContext.java:186)
org.apache.isis.core.runtime.system.context.IsisContextThreadLocal#openSessionInstance(IsisContextThreadLocal.java:148)
org.apache.isis.viewer.wicket.viewer.integration.wicket.WebRequestCycleForIsis#onBeginRequest(WebRequestCycleForIsis.java:81)
org.apache.wicket.request.cycle.RequestCycleListenerCollection$1#notify(RequestCycleListenerCollection.java:65)
org.apache.wicket.request.cycle.RequestCycleListenerCollection$1#notify(RequestCycleListenerCollection.java:61)
org.apache.wicket.util.listener.ListenerCollection#notify(ListenerCollection.java:80)
org.apache.wicket.request.cycle.RequestCycleListenerCollection#onBeginRequest(RequestCycleListenerCollection.java:60)
org.apache.wicket.request.cycle.RequestCycleListenerCollection$1#notify(RequestCycleListenerCollection.java:65)
org.apache.wicket.request.cycle.RequestCycleListenerCollection$1#notify(RequestCycleListenerCollection.java:61)
org.apache.wicket.util.listener.ListenerCollection#notify(ListenerCollection.java:80)
org.apache.wicket.request.cycle.RequestCycleListenerCollection#onBeginRequest(RequestCycleListenerCollection.java:60)
org.apache.wicket.request.cycle.RequestCycle#processRequest(RequestCycle.java:213)
org.apache.wicket.request.cycle.RequestCycle#processRequestAndDetach(RequestCycle.java:289)
org.apache.wicket.protocol.http.WicketFilter#processRequestCycle(WicketFilter.java:259)
org.apache.wicket.protocol.http.WicketFilter#processRequest(WicketFilter.java:201)
org.apache.wicket.protocol.http.WicketFilter#doFilter(WicketFilter.java:282)
org.apache.catalina.core.ApplicationFilterChain#internalDoFilter(ApplicationFilterChain.java:243)
org.apache.catalina.core.ApplicationFilterChain#doFilter(ApplicationFilterChain.java:210)
org.apache.shiro.web.servlet.AbstractShiroFilter#executeChain(AbstractShiroFilter.java:449)
org.apache.shiro.web.servlet.AbstractShiroFilter$1#call(AbstractShiroFilter.java:365)
org.apache.shiro.subject.support.SubjectCallable#doCall(SubjectCallable.java:90)
org.apache.shiro.subject.support.SubjectCallable#call(SubjectCallable.java:83)
org.apache.shiro.subject.support.DelegatingSubject#execute(DelegatingSubject.java:383)
org.apache.shiro.web.servlet.AbstractShiroFilter#doFilterInternal(AbstractShiroFilter.java:362)
org.apache.shiro.web.servlet.OncePerRequestFilter#doFilter(OncePerRequestFilter.java:125)
[jira] [Updated] (ISIS-760) IllegalStateException when commands/audit enabled in Estatio and failing to persist the Oid of a view model.
[
https://issues.apache.org/jira/browse/ISIS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeroen van der Wal updated ISIS-760:
Description:
There are two separate issues here:
- first is that the auditing service's column for storing OIDs isn't long
enough for view models.
- the second is that, given this then causes the xactn to be aborted, that it
throws an IllegalStateException for any subsequent interaction with the system.
The only fix is to restart the server. See details below
The reason for the second issue is that the previous session does not close
correctly. This is because of an exception being thrown in
PersistenceSession#close:
PersistenceSession.completeCommandIfConfigured() line: 418
PersistenceSession.closeServices() line: 399
PersistenceSession.close() line: 372
IsisSessionDefault.close() line: 119
IsisContextThreadLocal(IsisContext).closeSessionInstance() line: 219
WebRequestCycleForIsis.onEndRequest(RequestCycle) line: 134
This in turn is because of an attempt to complete any pending command (per the
CommandJdo service) on a xactn that has already been aborted
private void completeCommandIfConfigured() {
final CommandContext commandContext =
getServiceOrNull(CommandContext.class);
if(commandContext != null) {
final CommandService commandService =
getServiceOrNull(CommandService.class);
if(commandService != null) {
final Command command = commandContext.getCommand();
commandService.complete(command);
}
}
}
So, when closing the session, need to take this into account. Should propogate
exception if any arises, but still ensure that the persistence session is
closed for next-time around.
~~
to reproduce:
with estatio demo data
find invoices for status new
choose oxford
approve all.
A server restart was required.
{code}
java.lang.IllegalStateException
Session already open and context not configured for autoclose
org.apache.isis.core.runtime.system.context.IsisContext#applySessionClosePolicy(IsisContext.java:186)
org.apache.isis.core.runtime.system.context.IsisContextThreadLocal#openSessionInstance(IsisContextThreadLocal.java:148)
org.apache.isis.viewer.wicket.viewer.integration.wicket.WebRequestCycleForIsis#onBeginRequest(WebRequestCycleForIsis.java:81)
org.apache.wicket.request.cycle.RequestCycleListenerCollection$1#notify(RequestCycleListenerCollection.java:65)
org.apache.wicket.request.cycle.RequestCycleListenerCollection$1#notify(RequestCycleListenerCollection.java:61)
org.apache.wicket.util.listener.ListenerCollection#notify(ListenerCollection.java:80)
org.apache.wicket.request.cycle.RequestCycleListenerCollection#onBeginRequest(RequestCycleListenerCollection.java:60)
org.apache.wicket.request.cycle.RequestCycleListenerCollection$1#notify(RequestCycleListenerCollection.java:65)
org.apache.wicket.request.cycle.RequestCycleListenerCollection$1#notify(RequestCycleListenerCollection.java:61)
org.apache.wicket.util.listener.ListenerCollection#notify(ListenerCollection.java:80)
org.apache.wicket.request.cycle.RequestCycleListenerCollection#onBeginRequest(RequestCycleListenerCollection.java:60)
org.apache.wicket.request.cycle.RequestCycle#processRequest(RequestCycle.java:213)
org.apache.wicket.request.cycle.RequestCycle#processRequestAndDetach(RequestCycle.java:289)
org.apache.wicket.protocol.http.WicketFilter#processRequestCycle(WicketFilter.java:259)
org.apache.wicket.protocol.http.WicketFilter#processRequest(WicketFilter.java:201)
org.apache.wicket.protocol.http.WicketFilter#doFilter(WicketFilter.java:282)
org.apache.catalina.core.ApplicationFilterChain#internalDoFilter(ApplicationFilterChain.java:243)
org.apache.catalina.core.ApplicationFilterChain#doFilter(ApplicationFilterChain.java:210)
org.apache.shiro.web.servlet.AbstractShiroFilter#executeChain(AbstractShiroFilter.java:449)
org.apache.shiro.web.servlet.AbstractShiroFilter$1#call(AbstractShiroFilter.java:365)
org.apache.shiro.subject.support.SubjectCallable#doCall(SubjectCallable.java:90)
org.apache.shiro.subject.support.SubjectCallable#call(SubjectCallable.java:83)
org.apache.shiro.subject.support.DelegatingSubject#execute(DelegatingSubject.java:383)
org.apache.shiro.web.servlet.AbstractShiroFilter#doFilterInternal(AbstractShiroFilter.java:362)
org.apache.shiro.web.servlet.OncePerRequestFilter#doFilter(OncePerRequestFilter.java:125)
org.apache.catalina.core.ApplicationFilterChain#internalDoFilter(ApplicationFilterChain.java:243)
org.apache.catalina.core.ApplicationFilterChain#doFilter(ApplicationFilterChain.java:210)
org.apache.catalina.core.StandardWrapperValve#invoke(StandardWrapperValve.java:225)
org.apache.catalina.core.StandardContextValve#invoke(StandardContextValve.java:123)
