You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com> on 2013/05/10 12:56:46 UTC
Suggestion: More helpful messages on validation exceptions for easier debugging
Hi to all.
First of all, it's recommended to evaluate Apache Isis over the current snapshot's "quickstart_wicket_restful_jdo-archetype" or using the current released version? It's quite stable for evaluation purposes? I can understand the opposite, as all bugs I can found are well known. But if there has been enough improvements to easier the evaluation, I would change.
A suggestion that can help debugger's life.
While debugging using the Junit viewer, an exception is raised for a mandatory field (I assumed) that has not been entered. As all fields that have no annotation are by default mandatory (@Optional must be written explicitely), any non-Apache Isis migrated project will have plenty of them. Also, if a programmer's forget to annotate a field, it will be a commonly found exception. Same will happen for non-mandatory parameters on actions placed on Entities or Services.
A more clear message could be something similar to this:
"A Mandatory field (%s) has not been entered for an instance of Class: %s."
Also, in my case I finally noticed that it was an Action parameter what was required, as Apache Isis also will assume that all parameters not annotated with "@Optional" are also mandatory.
In such a case, a message like this one would be expected:
"A mandatory parameter (%s) has not been entered while executing action '%s' on an instance of Class '%s'"
I think all previous information is available on the Object Specification and Listerners, so it could be possible to include it relatively "easily".
The following exception was raised instead:
org.apache.isis.progmodel.wrapper.applib.InvalidException: Mandatory
at org.apache.isis.progmodel.wrapper.metamodel.internal.DomainObjectInvocationHandler.toException(DomainObjectInvocationHandler.java:561)
at org.apache.isis.progmodel.wrapper.metamodel.internal.DomainObjectInvocationHandler.notifyListenersAndVetoIfRequired(DomainObjectInvocationHandler.java:533)
at org.apache.isis.progmodel.wrapper.metamodel.internal.DomainObjectInvocationHandler.handleActionMethod(DomainObjectInvocationHandler.java:483)
at org.apache.isis.progmodel.wrapper.metamodel.internal.DomainObjectInvocationHandler.invoke(DomainObjectInvocationHandler.java:225)
at org.apache.isis.progmodel.wrapper.metamodel.internal.InvocationHandlerMethodInterceptor.intercept(InvocationHandlerMethodInterceptor.java:37)
at com.xms.framework.architecture.domain.model.technology.NodeFactory$$EnhancerByCGLIB$$17e4a172.createNode(<generated>)
at com.xms.framework.architecture.domain.model.technology.NodeTest.testCreateCommunicationPathAssociatedWithNode(NodeTest.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:68)
at org.apache.isis.viewer.junit.IsisTestRunner$1.invoke(IsisTestRunner.java:160)
at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:107)
at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:88)
at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:96)
at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:86)
at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:49)
at org.apache.isis.viewer.junit.IsisTestRunner.invokeTestMethod(IsisTestRunner.java:124)
at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:61)
at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:54)
at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:33)
at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:45)
at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:52)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Re: Suggestion: More helpful messages on validation exceptions for easier debugging
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
The "E" from Real Estate ... sorry.
We are trying to evaluate Isis by fully implementing a subset of a SubDomain without making changes to the framework, as we are not quite confident about its internals. We are descovering some interesting things while debugging, but have not made any changes to source code.
Be sure that if we make any local changes to Apache Isis code we will release it or at least comment with you as the project's leader.
Our "core business" is risk management and compliance, so we understand the concept of risk and the mitigation activity you are proposing. We would "commit" to it :-) Thanks for giving the option.
We have not explored the bookmarks functionality. It's really interesting, an option we don't have on our own framework.
The fact is that we are currently centered on exploring the framework and the migration costs.
Our current focus is on evaluating the Domain ease of implementation, validation, testing, integrated security (we are using CAS as Single Sign-On; seems to be supported by Apache Shiro. And also Spring Security through Wavemaker, but we are quite confident we can integrate all authentication and authorization).
We are also seeing a lot of value on the REST generated "API" (despite we have not focus our proof-of-concept there yet).
It's not as centered on the Wickets or other presentation viewer, as we had something similar over Wavemaker (less powerful but enough for our current needs; we are also evaluating if it's worth the effort to extend it to support the Apache Isis programming model characteristics we are considering to use) . But thanks to the Wickets viewer the time needed from coding to showing the app to a business expert is REALLY shorter than the one we have with Wavemaker. So, at least, for prototyping we are planning to use it. Let's see what happens for production...
I will create now the "Jira" tickets.
El 14/05/2013, a las 08:34, Dan Haywood <da...@haywood-associates.co.uk> escribió:
> On 13 May 2013 14:06, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:
>
>>
>> Nice to see there's going to be an official release this month. I
>> understand they are not more often, if you were doing a lot of improvements
>> due to the Statio project development.
>>
>>
> s/Statio/Estatio..
>
> Do you like the way that bookmarks now work. I should post about it, but
> briefly:
>
> @Bookmarkable - bookmarked, in hidden panel to the left
> @Bookmarkable(AS_CHILD) - will be bookmarked, but only if (one of) its
> parent references is also bookmarked.
>
>
>
>> By now we will continue to prioritize to implement on Apache Isis a BC of
>> our current solution in order to test it with our Domain, but those
>> contributions are "annotated" :-)
>>
>> I couldn't quite parse what you are saying here. But if you are making
> some local fixes to Isis, then please do consider raising tickets and
> attaching patches. Then I can fold those changes back into Isis.
>
> Also, it seems that you now doing a lot of work on Isis, and that there's a
> chance it may become a key dependency of your system. Any dependency
> implies a risk. To offset that risk, it might make sense for you to look
> to being a committer (and having a more direct influence on the framework)
> in the future. If that appeals, then the first step down that road is to
> start providing some contributions.
>
> cheers
> Dan
Re: Suggestion: More helpful messages on validation exceptions for
easier debugging
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 13 May 2013 14:06, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:
>
> Nice to see there's going to be an official release this month. I
> understand they are not more often, if you were doing a lot of improvements
> due to the Statio project development.
>
>
s/Statio/Estatio..
Do you like the way that bookmarks now work. I should post about it, but
briefly:
@Bookmarkable - bookmarked, in hidden panel to the left
@Bookmarkable(AS_CHILD) - will be bookmarked, but only if (one of) its
parent references is also bookmarked.
> By now we will continue to prioritize to implement on Apache Isis a BC of
> our current solution in order to test it with our Domain, but those
> contributions are "annotated" :-)
>
> I couldn't quite parse what you are saying here. But if you are making
some local fixes to Isis, then please do consider raising tickets and
attaching patches. Then I can fold those changes back into Isis.
Also, it seems that you now doing a lot of work on Isis, and that there's a
chance it may become a key dependency of your system. Any dependency
implies a risk. To offset that risk, it might make sense for you to look
to being a committer (and having a more direct influence on the framework)
in the future. If that appeals, then the first step down that road is to
start providing some contributions.
cheers
Dan
Re: Suggestion: More helpful messages on validation exceptions for easier debugging
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
Nice to see there's going to be an official release this month. I understand they are not more often, if you were doing a lot of improvements due to the Statio project development.
By now we will continue to prioritize to implement on Apache Isis a BC of our current solution in order to test it with our Domain, but those contributions are "annotated" :-)
El 12/05/2013, a las 16:01, Dan Haywood <da...@haywood-associates.co.uk> escribió:
> On Friday, 10 May 2013, GESCONSULTOR - Óscar Bou wrote:
>
>>
>> Hi to all.
>>
>> First of all, it's recommended to evaluate Apache Isis over the current
>> snapshot's "quickstart_wicket_restful_jdo-archetype" or using the current
>> released version? It's quite stable for evaluation purposes? I can
>> understand the opposite, as all bugs I can found are well known. But if
>> there has been enough improvements to easier the evaluation, I would change.
>>
>
> For casual evaluation, the archetype is fine, but as you point out, there
> are a bunch of new changes and some bug fixes in trunk that need to be
> released.
>
> As I mentioned in my reply to your other email, I intend to push out an
> updated release later this month.
>
>
>
>>
>>
>> A suggestion that can help debugger's life.
>>
>> While debugging using the Junit viewer, an exception is raised for a
>> mandatory field (I assumed) that has not been entered. As all fields that
>> have no annotation are by default mandatory (@Optional must be written
>> explicitely), any non-Apache Isis migrated project will have plenty of
>> them.
>
>
> I know that in Naked Objects for .NET, there is a flag to allow the
> interpretation of unannotated fields to be either as optional or as
> mandatory. I believe this was done to conform with Microsoft's Entity
> Framework (their ORM).
>
> I mention this only to say that it can be done, not necessarily to say that
> we should do it. But we can start a separate thread about this and see
> what the community wants, if you wish.
>
>
>
>
>> Also, if a programmer's forget to annotate a field, it will be a commonly
>> found exception. Same will happen for non-mandatory parameters on actions
>> placed on Entities or Services.
>>
>> A more clear message could be something similar to this:
>>
>> "A Mandatory field (%s) has not been entered for an instance of Class: %s."
>>
>>
> What can I say?... it's open source; contributions welcome :-)
>
>
>
>
>
>> Also, in my case I finally noticed that it was an Action parameter what
>> was required, as Apache Isis also will assume that all parameters not
>> annotated with "@Optional" are also mandatory.
>>
>> In such a case, a message like this one would be expected:
>>
>> "A mandatory parameter (%s) has not been entered while executing action
>> '%s' on an instance of Class '%s'"
>>
>> I think all previous information is available on the Object Specification
>> and Listerners, so it could be possible to include it relatively "easily".
>>
>
> Again, contributions welcome ...
>
>
>
>
>> The following exception was raised instead:
>>
>> org.apache.isis.progmodel.wrapper.applib.InvalidException: Mandatory
>> at
>> org.apache.isis.progmodel.wrapper.metamodel.internal.DomainObjectInvocationHandler.toException(DomainObjectInvocationHandler.java:561)
>> at
>> org.apache.isis.progmodel.wrapper.metamodel.internal.DomainObjectInvocationHandler.notifyListenersAndVetoIfRequired(DomainObjectInvocationHandler.java:533)
>> at
>> org.apache.isis.progmodel.wrapper.metamodel.internal.DomainObjectInvocationHandler.handleActionMethod(DomainObjectInvocationHandler.java:483)
>> at
>> org.apache.isis.progmodel.wrapper.metamodel.internal.DomainObjectInvocationHandler.invoke(DomainObjectInvocationHandler.java:225)
>> at
>> org.apache.isis.progmodel.wrapper.metamodel.internal.InvocationHandlerMethodInterceptor.intercept(InvocationHandlerMethodInterceptor.java:37)
>> at
>> com.xms.framework.architecture.domain.model.technology.NodeFactory$$EnhancerByCGLIB$$17e4a172.createNode(<generated>)
>> at
>> com.xms.framework.architecture.domain.model.technology.NodeTest.testCreateCommunicationPathAssociatedWithNode(NodeTest.java:78)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:597)
>> at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:68)
>> at
>> org.apache.isis.viewer.junit.IsisTestRunner$1.invoke(IsisTestRunner.java:160)
>> at
>> org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:107)
>> at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:88)
>> at
>> org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:96)
>> at
>> org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:86)
>> at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:49)
>> at
>> org.apache.isis.viewer.junit.IsisTestRunner.invokeTestMethod(IsisTestRunner.java:124)
>> at
>> org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:61)
>> at
>> org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:54)
>> at
>> org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:33)
>> at
>> org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:45)
>> at
>> org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:52)
>> at
>> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
>> at
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
>>
>>
>>
>>
Re: Suggestion: More helpful messages on validation exceptions for
easier debugging
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On Friday, 10 May 2013, GESCONSULTOR - Óscar Bou wrote:
>
> Hi to all.
>
> First of all, it's recommended to evaluate Apache Isis over the current
> snapshot's "quickstart_wicket_restful_jdo-archetype" or using the current
> released version? It's quite stable for evaluation purposes? I can
> understand the opposite, as all bugs I can found are well known. But if
> there has been enough improvements to easier the evaluation, I would change.
>
For casual evaluation, the archetype is fine, but as you point out, there
are a bunch of new changes and some bug fixes in trunk that need to be
released.
As I mentioned in my reply to your other email, I intend to push out an
updated release later this month.
>
>
> A suggestion that can help debugger's life.
>
> While debugging using the Junit viewer, an exception is raised for a
> mandatory field (I assumed) that has not been entered. As all fields that
> have no annotation are by default mandatory (@Optional must be written
> explicitely), any non-Apache Isis migrated project will have plenty of
> them.
I know that in Naked Objects for .NET, there is a flag to allow the
interpretation of unannotated fields to be either as optional or as
mandatory. I believe this was done to conform with Microsoft's Entity
Framework (their ORM).
I mention this only to say that it can be done, not necessarily to say that
we should do it. But we can start a separate thread about this and see
what the community wants, if you wish.
> Also, if a programmer's forget to annotate a field, it will be a commonly
> found exception. Same will happen for non-mandatory parameters on actions
> placed on Entities or Services.
>
> A more clear message could be something similar to this:
>
> "A Mandatory field (%s) has not been entered for an instance of Class: %s."
>
>
What can I say?... it's open source; contributions welcome :-)
> Also, in my case I finally noticed that it was an Action parameter what
> was required, as Apache Isis also will assume that all parameters not
> annotated with "@Optional" are also mandatory.
>
> In such a case, a message like this one would be expected:
>
> "A mandatory parameter (%s) has not been entered while executing action
> '%s' on an instance of Class '%s'"
>
> I think all previous information is available on the Object Specification
> and Listerners, so it could be possible to include it relatively "easily".
>
Again, contributions welcome ...
> The following exception was raised instead:
>
> org.apache.isis.progmodel.wrapper.applib.InvalidException: Mandatory
> at
> org.apache.isis.progmodel.wrapper.metamodel.internal.DomainObjectInvocationHandler.toException(DomainObjectInvocationHandler.java:561)
> at
> org.apache.isis.progmodel.wrapper.metamodel.internal.DomainObjectInvocationHandler.notifyListenersAndVetoIfRequired(DomainObjectInvocationHandler.java:533)
> at
> org.apache.isis.progmodel.wrapper.metamodel.internal.DomainObjectInvocationHandler.handleActionMethod(DomainObjectInvocationHandler.java:483)
> at
> org.apache.isis.progmodel.wrapper.metamodel.internal.DomainObjectInvocationHandler.invoke(DomainObjectInvocationHandler.java:225)
> at
> org.apache.isis.progmodel.wrapper.metamodel.internal.InvocationHandlerMethodInterceptor.intercept(InvocationHandlerMethodInterceptor.java:37)
> at
> com.xms.framework.architecture.domain.model.technology.NodeFactory$$EnhancerByCGLIB$$17e4a172.createNode(<generated>)
> at
> com.xms.framework.architecture.domain.model.technology.NodeTest.testCreateCommunicationPathAssociatedWithNode(NodeTest.java:78)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:68)
> at
> org.apache.isis.viewer.junit.IsisTestRunner$1.invoke(IsisTestRunner.java:160)
> at
> org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:107)
> at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:88)
> at
> org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:96)
> at
> org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:86)
> at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:49)
> at
> org.apache.isis.viewer.junit.IsisTestRunner.invokeTestMethod(IsisTestRunner.java:124)
> at
> org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:61)
> at
> org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:54)
> at
> org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:33)
> at
> org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:45)
> at
> org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:52)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
>
>
>
>