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 <[email protected]> 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 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.
