Hi Bartek, Thanks very much for your really helpful suggestions.
Bartosz Kowalewski <[email protected]> wrote on 06/01/2010 10:22:47 PM: [snip] > I have one minor comment to this sample. In order to make the pre-demo > set-up shorter, you could use the same approach to preparing DB as it > is now used in the blog sample. Both the JDBC and the JPA version use > in-memory Derby DB and schemas are created at runtime. Is my understanding correct that if we used the embedded database we'd have less pre-demo set-up but slightly more code in the actual application itself? (For example, the <properties> <property name="openjpa.SynchronizeMappings" value="buildSchema(SchemaAction=add,deleteTableContents)"/> </properties> element in the persistence.xml?) If I have that right, I think that's probably long enough it would need to be cut and pasted in. My personal feeling is that for this kind of demo the priority is keeping the code we write as short as possible, and we can impose a fair bit of pre-demo set-up on the presenter to keep that possible. :) However, other people's milage may vary, so we should definitely make a note of the option in the speaker notes, and perhaps switch the 'reference' implementation to use the embedded databases so that it works better out of the box. > A general comment to presentations on Apache Aries and OSGi Enterprise > (this is not really related to live demo): > Maybe it's just me, but I like seeing comparisons and I like to be > told that if I start using something, my life will be easier :). Aries > examples show realistic architectures and they show the power of > Aries. However, for people that haven't tried implementing such > applications in pure OSGi (without OSGi Enterprise) it might not > obvious that OSGi Enterprise is really that useful and makes using > OSGi easier :). I'd also show some sample applications doing the same > thing in pure OSGi and using Aries, i.e.: > - Java code with service trackers and service registrations vs. > Blueprint with its definitions > - Java code with various tricks (like thread context classloaders, > etc.) required to use JPA vs. JPA in Aries that could be used cleanly > without the need to use tricks, integrated into Blueprint, etc. Your suggestions about showing the alternatives to Aries is great - I think you've hit the nail on the head about how we should be presenting it. In the wordassociation application there isn't any 'pure' blueprint code, which is a bit of a shame since the blueprint vs service tracker story is a really good one in terms of the amount of code we can get rid of. However, we should definitely be able to write a 'normal' JPA version of the JPA wordassociation bundle. If we can show a 'before and after' for the JPA bundle I think you're right that it would be a much more compelling demo. There's probably some 'before and after' for the web bundle, too. I guess the most obvious benefit of Aries is avoiding the need to package all the other jars in with the web application/ear. Holly Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
