aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bartosz Kowalewski <>
Subject Re: Apache Aries presentations
Date Thu, 03 Jun 2010 14:07:37 GMT
Hi Holly,

My comments below.

2010/6/2 Holly Cummins <>:
> 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.

You're right - this approach requires some additional settings in the
persistence.xml file. One extra property also needs to be set on the
datasource. I fully agree that it might make the demo a little bit
longer, so it should be left up to the presenter to decide which
option is better for him/her.

> 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.

Writting an alternate (non-Aries) version of this sample would require
some effort, but I think that it's worth it :-).
Right now there's no bundle with blueprint definitions that use
service references, but there's one that registers them. Services are
only looked up from web bundle through JNDI. For the purpose of
showing how cool Aries is, a second client bundle could be created.
Instead of providing a servlet, it could expose the functionality of
the two wordassociation services in a different way and use Blueprint
for getting references to these services. Of course this would not be
written from scratch during the live demo session, but still it would
be really helpful when comparing Aries-based approach with the 'pure
OSGi' one.


View raw message