Hi Nacho, thanks for this write-up and feedback.
I can understand why you went down the path you did, though I think you have gone about solving the issue the wrong way. Because of that, I think it would be worth changing the framework to make this area easier to work with. To explain, we should distinguish the bits of the security module that are the actual component (ie released to maven central repo) as opposed to the demo app that merely tests/demonstrates its functionality. The pattern is the same for pretty much all the isisaddons modules: - isis-module-xxx-dom ... this is the released component - isis-module-xxx-fixture / -integtests / -webapp ... these is the demo app/tests The issue is that the "-dom" component includes the org.isisaddons.module.security.seed.SeedSecurityModuleService, but - as you correctly point out - this requires an instance of FixtureScripts domain service. The mistake you've made is that you've gone ahead and used the instance of FixtureScripts provided by the -fixture module. This isn't ideal because the -fixture module doesn't get released to Maven central repo. The issue here is that the Apache Isis framework does not provide an out-of-the-box instance of this domain service. Instead, the intended use is for the developer to subclass FixtureScripts; this becomes the instance to use. The reason for subclassing is because the subclass specifies the package(s) to automatically search for FixtureScript instances. But the problem with this design of FixtureScripts is that it conflates two separate responsibilities... (a) being able to execute fixture scripts (which is all the SeedSecurityModuleService requires) along with (b) the responsibility of indicating where FixtureScript classes can be found. I think that a better design would be to separate these. For example, the framework could provide an out-of-the-box concrete instance of FixtureScripts domain service, and then have some other way for the classes to search for to be provided; probably some other domain service that is injected in. The complication is that there is already a legacy of domain applications out there that will have provided their own FixtureScripts subclass, so any new design needs to be backward compatible. My idea, then, is that the framework will only supply an instance of FixtureScripts service as a fallback, ie if none are provided. The responsibility of specifying the package where FixtureScript instances can be found could then move to a FixutreScriptsServiceConfigurer service, or something similar. I've raised a ticket ISIS-1173 [1] and write some migration notes for this design. But comments welcome in the meantime. Thanks Dan [1] https://issues.apache.org/jira/browse/ISIS-1173 The reason - the security module as released to maven central repo, as opposed to the demo app that merely demonstrates its 2015-07-15 13:35 GMT+01:00 Nacho Cánovas Rejón <[email protected]>: > Hi Dan. > > I was including "isis-module-security" to our webapp and I followed your > "Readme" file, but I had to deal with some differences on this. I don't > know if I lost something or if the configuration I made is well too. > > "org.isisaddons.module.security.seed.SeedSecurityModuleService" needs > "FixtureScripts" injected, and I had to add > "SecurityModuleAppFixturesService" because is the only one inheriting from > "FixtureScripts". In this case I didn't need "SecurityModuleAppSetUp" > fixture. > > I had also to add dependency with "isis-module-security-fixture". Version > code is in red because I want you to see that is a different version and I > suppose that it would be "1.9.0-SNAPSHOT" because is needed (you comment > this aspect on "Forking the repo" inside "Readme" file). > > *Changes I propose:* > *isis.properties* > > *Removed * > > isis.fixtures= \ > org.isisaddons.module.security.fixture.scripts.SecurityModuleAppSetUp > > *Add* > > isis.services = \ > > org.isisaddons.module.security.fixture.scripts.SecurityModuleAppFixturesService > > *pom.xml* > > *Add* > > <dependency> > <groupId>org.isisaddons.module.security</groupId> > <artifactId>isis-module-security-fixture</artifactId> > <version>0.0.1-SNAPSHOT</version> > </dependency> > > Cheers, Nacho. > > -- > Ignacio Cánovas Rejón > Tel. 902 900 231 > Fax 96 353 19 09 > [email protected] > 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. Av. Cortes Valencianas 50-1º-C, C.P. > 46015 de 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. > > > > --- > El software de antivirus Avast ha analizado este correo electrónico en > busca de virus. > http://www.avast.com >
