On Thu, Dec 9, 2010 at 11:33 AM, Rickard Öberg <[email protected]> wrote: > On 2010-12-08 18.20, Niclas Hedhman wrote: >> >> * Deployment of Qi4j applications on OSGi platform. >> - Fixing all Import/Export Package issues and versionings. >> - Ensuring that OSGi Services can be nicely imported to Qi4j >> - Exporting of QI4j services to OSGi. > > Interesting. Like I said, I've given up on OSGi myself due to packaging and > deployment problems, but those are not inherent problems and so are > theoretically fixable.
Yes, I remember that. And when I set out on this, there was a lot of small mistakes here and there with versioning, and not trivial to get it to work if you are not 'fluent' in OSGi. By having OSGi as a harder requirement than Qi4j at work, I think I can sort this out permanent. FTR, While having an AssemblyException in my domain code, Apache Karaf (my OSGi container of choice) and my Qi4j started, was trying to create the Qi4j app every 15 secs or something, over night. When I came in the morning, 1.2 million classes had been loaded and unloaded, with a delta of 4000 (kind of expected). And memory had not grown over the top; From a minimum of ~12MB to ~22MB. Let's say there was 7000 (only every 30sec) Qi4j starts per hour, times 15 hours, gives us ~100,000 tried starts. That would be 100 bytes leak per start, and I doubt a ASM generated class would fit in that, assuming only a single Mixin subclass was created. > In Streamflow we have done similar things a bit different. Entities should > not subscribe to events, but only consume commands (from external sources), > and so what happens is that you instead create an application service that > consumes the events and create the appropriate commands on the domain. That > works really well, even cross-JVM (consume locally by service, invoke > entities remotely, probably hidden under a REST API). Hmmm... This at first glance increases the complexity level. I also have a mental issues with "events" being converted to "commands", since I have this notion that "commands may fail". I will consider this for a while, since I can also see advantages on scalability and resilience that has not been solved yet. > Just need to port the EventSourcing API/SPI/impl to Qi4j. Hopefully this > weekend. Perhaps you should code dump it first. Just don't modify the lib/pom.xml to include the module in the build. OR, try out 'create a new remote branch with it'... :-) Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
