To try it out you have to build the Cinnamon jar from SVN. I also changed the XML Schema, making service-interface an optional attribute. You should now point the schemaLocation to http://www.spicefactory.org/cinnamon/schema/0.3.1/cinnamon-spring.xsd. Let me know if that works for you.

Regarding the access control: I probably should improve the docs to make it clearer. It’s not our goal to include a full blown security framework. Rather we would start to integrate with existing solutions like Spring Security with upcoming releases. The global switches that were irritating for you were only introduced to offer some kind of easy base configuration. So if you know that you would not want to allow clients to freely build JPAQL queries in AS3, you could simply disallow some or all operations of the AS3 EntityManager and then use standard Spring Security Aspects on the custom services that you use to read and write these entities.

If you DO want to use the AS3 EntityManager, you are right, you don’t get much options for declarative security now and would have to write some interceptors. I’ll evaluate (for Pimento 1.1) whether there is an elegant path to also integrate the AS3 EntityManager with something like Spring Security. Method level security wouldn’t make sense in this case though, so I’d have to look at their ACL stuff, with which I haven’t worked yet.

Btw.: If you don’t mind I would like to link to Part 2 of your blog post from the Pimento documentation for users who want to integrate Grails.

Thanks for your message.

I find the AS3 EntityManager approach very interesting. I think it will allow for very fast development, although I haven’t experimented with it enough to support this claim. To make it usable in a larger project, I think a lot of logic will have to be build into interceptors to implement standard JEE features such as security or application specific features such as audit trails. The framework seems to provide these plug-in points.

If I understand it correctly, the other approach will not work for Grails services, since they don’t have an interface as I explained in the blog. By quickly looking into the API documentation it seems like the SpringServiceFactory should be usable with Grails, since all Grails services are spring beans. The problem arises when creating a ServiceConfig object, which requires an interface constructor parameter and also checks that it is in fact an interface. Would it be possible to relax this requirement? I assume that the interface is used to create a proxy for the service. If so, maybe CGLib can be used to create proxies from concrete classes. This is the same approach that Spring uses.

Thanks for developing this interesting framework! I’m looking forward to the 1.0 release.

Regards,

-Maarten Winkels

as the Spicefactory lead developer I’d like to comment on some of the issues you mentioned.

Regarding Pimento: Yes, the approach that you describe has pros and cons. That’s the reason why Pimento actually supports two programming models, as described in the manual here:
http://www.spicefactory.org/pimento/docs/1.0/manual/?page=programming&section=intro
There may be use cases where using the AS3 EntityMangager might not be the best approach, for security reasons for example. In this case you can use the other programming model based on custom services and still benefit from some of Pimento’s data management features (like the client cache or sending only change sets when updating entities for example).

The existence of this second programming model is also the reason for the access control. Not sure why you find that crude, but the idea was, that you simply disallow queries on certain types of entities if you want to make sure that they can only be loaded through one of your custom services.

As for exposing Grails services for Cinnamon: It probably requires a custom ServiceFactory implementation. If you are interested in making this work, I’d be happy to assist. I’d need your help though as I don’t know Grails (yet).

Did you get a chance to look at prana framework which provides Spring like IOC implementation?

It works well with Cairngorm and removes some of its problems (singleton, writing front-controllers and other dependencies related problems) To me it looks similar to Parsley.