Following on from this, have updated the users' and ref guide with some info on the upcoming @Mixin annotation...
Cheers Dan ... http://isis.apache.org/guides/ug.html#_ug_more-advanced_decoupling_mixins On 16 October 2015 at 17:08, Dan Haywood <[email protected]> wrote: > Hi Jörg > > within... > > > On 16 October 2015 at 16:13, Rade, Joerg / Kuehne + Nagel / Ham GI-PS < > [email protected]> wrote: > >> Hi Dan, >> >> changes to non-entity classes could be reloaded? >> I assume I have to rebuild the war. Correct? >> >> > When running from the IDE we tend to use the org.apache.isis.WebServer > bootstrapper, which basically runs an embedded Jetty. This saves having to > do any packaging or deployment, and works fine for both Eclipse and > IntelliJ. > > See the user guide [1] for more on that. > > > > > >> >One reasonable workaround is to use contributed actions, and/or event >> bus, >> >and have them in essence "decorate" the class. As your app gets larger >> you'll >> >probably want to be using these anyway. And the contributing services >> can be >> >reloaded by DCEVM without requiring any enhancing going on. >> >> Can you point me to an example? Or give more details? >> >> > I haven't used DCEVM on Eclipse, but it seems that it's easy enough to get > going, see eg [2]. > > As it looks like I mentioned before, the main thing that prevents hot > reloading is the DataNucleus enhancer... any change to entities is going to > require the entity to be re-enhanced, and the JDO metamodel recreated, > which usually "stuffs things up". > > However, more often than not the structure doesn't change that often, > however it's the behaviour that you're most likely wanting to change while > the app is still running. If you move that behaviour out into contributed > services, then these can be reloaded happily (when running in prototype > mode). Isis will automatically recreate the portion of the metamodel for > any domain object when it is rendered. > > There's a brief discussion of contributed services in the users' guide > [3]; you'll find that the various isis addons all use the technique quite > extensively (eg audit/command contribute to each other via the > HasTransactionId interface; audit/security/sessionlogger/command contribute > to each other via the HasUserName interface). > > In 1.10.0-SNAPSHOT I've been working on an improved programming model, > called "mixins", that makes this more overt. The new incode modules [4], > [5] use this throughout, see eg [6]. It's basically a simplified version > of the DCI architecture, per Trygve Reenskaug and Jim Coplien. > > > HTH > Dan > > > > [1] http://localhost:4000/guides/ug.html#_ug_deployment_cmd-line > [2] > http://tirthalpatel.blogspot.co.uk/2014/06/steps-to-setup-hotswap-agent-in-eclipse.html > [3] http://localhost:4000/guides/ug.html#_ug_how-tos_domain-services > [4] https://github.com/incodehq/incode-module-note > [5] https://github.com/incodehq/incode-module-commchannel > [6] > https://github.com/incodehq/incode-module-note/blob/master/dom/src/main/java/org/incode/module/note/dom/impl/note/Notable_notes.java#L35 > [7] http://www.artima.com/articles/dci_vision.html > > > > >> Thanks in advance >> Jörg >> -----Ursprüngliche Nachricht----- >> Von: Dan Haywood [mailto:[email protected]] >> Gesendet: Freitag, 31. Juli 2015 13:13 >> An: users >> Betreff: Re: faster development in eclipse >> >> I've been meaning to do add some docs and a quick screencast about DCEVM >> for a while; maybe this weekend.. >> >> To answer Martin's question: in fact, if running in prototype mode, then >> the Wicket viewer automatically invalidates the metamodel of the (class of >> the) displayed object... this is why editing the .layout.json file and >> reloading changes causes updates to be picked up automatically. >> >> What is more tricky is if the entity is changed itself, ie its >> structure/method signatures. If the internals are changed then regular >> Java Hotspot can mostly cope, and I suspect that DCEVM would make that more >> reliable still. But if the entity has changed then the class needs >> re-enhancing. Unfortunately DN doesn't provide any easy way to do that, so >> there's little point in Isis providing an API to invalidate a class if the >> underlying DN metamodel hasn't also been updated. >> >> One reasonable workaround is to use contributed actions, and/or event >> bus, and have them in essence "decorate" the class. As your app gets >> larger you'll probably want to be using these anyway. And the contributing >> services can be reloaded by DCEVM without requiring any enhancing going on. >> >> ~~~ >> Alternatively you could dust off the JRebel plugin that I worked on [1]. >> I did get this working reasonably well for me, though I'm not sure if >> anyone else did. (And, having said that I haven't found myself reaching >> for it, but partly because I switch context between projects all the time). >> Anyway, perhaps worth checking out. >> >> HTH >> Dan >> >> >> [1] https://github.com/isisaddons/isis-jrebel-plugin >> >> >> >> On 31 July 2015 at 09:03, Martin Grigorov <[email protected]> wrote: >> >> > Hi, >> > >> > I use DCEVM for code reloading. It is free and there is nothing to >> learn. >> > But it doesn't help with updating Isis meta model. >> > It would be nice if Isis exposes REST/JMX/... interface that triggers >> > rebuild of the model. >> > @Dan: is this possible with the code of isis-mavel-plugin? >> > On Jul 31, 2015 7:45 AM, "Stephen Cameron" >> > <[email protected]> >> > wrote: >> > >> > > Hi again, >> > > >> > > After playing around with options I now think there isn't much >> > opportunity >> > > to speed things up, other than to use JRebel or change the way I >> > > develop (not start the webapp so much). The webapp project looks for >> > > jars in the maven repository not the war, so I only need to do maven >> > > install on the >> > dom >> > > project when I change a dom class. That should have been apparent >> > > sooner >> > :( >> > > >> > > Bottomline: the webapp takes some time to start, but that is fine. >> > > >> > > >> > > >> > > On Fri, Jul 31, 2015 at 11:27 AM, Stephen Cameron < >> > > [email protected]> wrote: >> > > >> > > > Hi, >> > > > >> > > > I would greatly appreciate some advice on speeding up development >> > > > in Eclipse. Using the simpleapp project with separate dom, >> > > > fixture, >> > > integtest >> > > > and webapp subprojects. >> > > > >> > > > I'd at least like the webserver (jetty,tomcat) to restart when I >> > modify a >> > > > dom class. This is what I am used to with Dynamic Web Projects, >> > > > however after a bit of trying today I still cannot get that to >> > > > work, using >> > > Tomcat. >> > > > >> > > > It seems most are using JRebel with IntelliJ, but I am not so keen >> > > > to >> > go >> > > > there yet as I am (re)learning on many fronts at present. >> > > > >> > > > The issue with Tomcat is a jetty dependancy, this was noted >> > > > previously [1], but I could not get around it by removing >> > > > jetty-all-9.2.11.v20150529.jar as suggested, I then got a >> > > > null-pointer exception. >> > > > >> > > > At the moment I have to rebuild the whole project after a class >> > > > change >> > in >> > > > the dom-project then restart the server to see the change. Is the >> > because >> > > > the .war has to be rebuilt for mvn jetty:run to use the new >> > > > version of >> > > the >> > > > class file? >> > > > >> > > > I've just tried to use the eclipse jetty plugin but that is >> > > > telling me that the dom classes have not been enhanced by >> datanucleus. >> > > > >> > > > Hoping for some insights. >> > > > >> > > > Thanks >> > > > Steve C >> > > > >> > > > >> > > > [1] >> > > http://permalink.gmane.org/gmane.comp.apache.incubator.isis.devel/99 >> > > 31 >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > >> > >> >> Kühne + Nagel (AG & Co.) KG >> Rechtsform: Kommanditgesellschaft, Bremen HRA 21928, USt-IdNr.: DE >> 812773878. >> Geschäftsleitung Kühne + Nagel (AG & Co.) KG: Reiner Heiken (Vors.), Dirk >> Blesius, Martin Brinkmann, Matthias Heimbach, Jan-Hendrik Köstergarten, >> Nicholas Minde, Lars Wedel, Jens Wollesen. >> Persönlich haftende Gesellschafterin: Kühne & Nagel A.G., Rechtsform: >> Aktiengesellschaft nach luxemburgischem Recht, HR-Nr.: B 18745, >> Geschäftsführendes Verwaltungsratsmitglied: Karl Gernandt. >> Geschäftsleitung Region Westeuropa: Yngve Ruud (Vors.), Richard Huhn, >> Björn Johansson, Jan Kunze, Bruno Mang, Stefan Paul, Holger Ketz, Dominic >> Edmonds. >> >> Wir arbeiten ausschließlich auf Grundlage der Allgemeinen Deutschen >> Spediteursbedingungen (ADSp), jeweils neuester Fassung. Wir verweisen >> insbesondere auf die vom Gesetz abweichenden Haftungsbeschränkungen von >> Ziffer 23 und 24 ADSp. Den vollständigen Text der ADSp übersenden wir Ihnen >> gerne auf Anfrage und können Sie auch unter http://www.kuehne-nagel.com >> einsehen. Ergänzend wird vereinbart, dass (1) Ziffer 27 ADSp im Rahmen >> internationaler Übereinkommen weder unsere Haftung noch die Zurechnung des >> Verschuldens von Leuten und sonstigen Dritten zu Gunsten des Auftraggebers >> erweitert, und (2) wir in den im deutschen Seehandelsrecht aufgeführten >> Fällen des nautischen Verschuldens oder Feuer an Bord nur für eigenes >> Verschulden und (3) im Sinne der CMNI genannten Voraussetzungen nicht für >> nautisches Verschulden, Feuer an Bord oder Mängel des Schiffes haften. >> > >
