Just to complete this thread... this overlaps with work going on in ISIS-550, where we want to be able to use wrap(...) to post events to the EventBus without performing business rule checks.
The current proposal is to overload wrap(...) to have a flag to suppress business rule checking. That will address the issue raised here also (ie can use setXxx to call modifyXxx). Dan On 6 May 2014 10:45, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote: > Hi Dan. > > Many thanks for pointing this :-)) Excuse me I didn't read it before. > > > All seems ok for us, but when you say that the modifyXXX cannot be invoked > (as seen on the TodoItem.modifyDescription(...) test in [1]) this can break > some code for us. > > Let me explain. > > We normally use: > this.wrap(domainObject).setXXX(...); > > for setting properties. > > This way, if there's any logic associated when updating the property (by > means of a modifyXXX(...) method), that business logic is always execute > whereever it's called in the domain. > > When we see in the code something like: > > domainObject.setXXX(...); > > we know it's an error, unless there's a comment like this ones: > > // Always Disabled. > domainObject.setXXX(...); > > or > > // Always Hidden. > domainObject.setXXX(...); > > > In those cases, if there's business logic associated, the only way to > execute it is to explicitly invoke it as in: > > domainObject.modifyXXX(...); > > > If that's forbidden now, is there a better way to solve this? > > Many thanks! > > Oscar > > > > > > > [1] > https://git-wip-us.apache.org/repos/asf?p=isis.git;a=blob;f=example/application/quickstart_wicket_restful_jdo/integtests/src/test/java/integration/tests/props/ToDoItemTest_description.java;h=11e5ae315f1bc33241658999d4178b06d65c1c9b;hb=074d2c4 > > > > El 02/05/2014, a las 19:37, Dan Haywood <d...@haywood-associates.co.uk> > escribió: > > > Hi all, > > Just a quick update on some recent commits [1], [2], [3]. (Oscar, take > especial note, because of how you are wrap(...) all domain objects). > > The implementation of WrapperFactory uses cglib 2.x/asm 3.x, which is > incompatible with Java 7. Although cglib 3/asm 4 are compatible, in the > past we've had dependency convergence issues with these very popular > libraries. > > So, I've been working through our dependencies on cglib and looking to > replace them with javassist (JBoss' library). > > Specifically: > - in our JMock mocking we used to use the cglib-based ClassImposterier; > I've now implemented a new JavassistImposteriser > - in WrapperFactoryDefault, this similarly has been changed to use > Javassist. The original implementation is still available, renamed to > WrapperFactoryCglib. > > We still have dependencies on cglib in ObjectFactoryCglib, but this is not > used by the JDO Objectstore (it is to support lazy loading of the other > not-released objectstores). > > And there was also a cglib/asm dependency in the Wicket viewer, which I've > also removed. > > ~~~ > So, this is just a heads-up that as of the next release > WrapperFactoryDefault is using javassist under the covers. > > I also fixed one bug: the idea I had was to disallow calls to > foo.modifyBar), even if such a method existed; instead only foo.setBar(...) > must be called. This wasn't being checked for correctly. It won't impact > your code if you don't use the modifyXxx() supporting method. > > ~~~ > OK, that's it. Have a good weekend! > > Cheers > Dan > > [1] https://issues.apache.org/jira/browse/ISIS-569 > [2] https://issues.apache.org/jira/browse/ISIS-770 > [3] https://issues.apache.org/jira/browse/ISIS-772 > > > > Óscar Bou Bou > Responsable de Producto > Auditor Jefe de Certificación ISO 27001 en BSI > CISA, CRISC, APMG ISO 20000, ITIL-F > > 902 900 231 / 620 267 520 > http://www.twitter.com/oscarbou > > http://es.linkedin.com/in/oscarbou > > http://www.GesConsultor.com <http://www.gesconsultor.com/> > > > > Este mensaje y los ficheros anexos son confidenciales. Los mismos > contienen información reservada que no puede ser difundida. Si usted ha > recibido este correo por error, tenga la amabilidad de eliminarlo de su > sistema y avisar al remitente mediante reenvío a su dirección electrónica; > no deberá copiar el mensaje ni divulgar su contenido a ninguna persona. > Su dirección de correo electrónico junto a sus datos personales constan en > un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de > mantener el contacto con Ud. Si quiere saber de qué información disponemos > de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un > escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente > dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - > 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). > Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos > adjuntos no contengan virus informáticos, y en caso que los tuvieran > eliminarlos. > > > > > >