TODO server app observations
by Marko Strukelj
I’ve been looking into TODO app to get a better understanding of how aerogear.js works in a browser, and how we could abstract server-side into something we could call ‘aerogear-server’ as opposed to TODO app.
Here are some observations:
- The *Endpoint classes are SLSB, but use extended persistence context [1]
Extended persistence context is not supported on Stateless session beans per JPA spec [2].
The reason is that stateless beans are not singletons or contextual objects (i.e. CDI scoped) but are pooled instances, so you can receive a different one for each call that you make. That would mean that you could get a different EntityManager instance each time, with possible uncommitted state from another method call by another client. It would be impossible to do consistent persistence across multiple invocations with that kind of random behaviour. Also if ten requests hit at the same time there would be ten instances of EntityManager, and ten separate persistence contexts, and since they are extended and ‘never’ cleared (EJB container decides, behaviour is unspecified) - we have ten memory leaks.
It looks like AS7 doesn’t much care if you use EXTENDED annotation in a SLSB - it will happily comply (and create a memory leak for you), whereas some other app servers will break on deployment [3], and Scott Marlow concedes it should probably be a deployment error [4], so maybe one day this would also break on AS7.
- Method joinTransaction() only makes sense on application-managed entity manager
We are using container-managed entity manager - one that gets injected - as opposed to one retrieved by calling EntityManagerFactory.createEntityManager() method (that would be application-managed). Call to joinTransaction() is therefore a no-op, and should be removed [5][6][7].
- Custom serializers look like plumbing
Would be good to have a way to autogenerate them during compile based on annotations. Also, for the purpose of autogenerating entities for the client based on server data definitions (metadata) we need to use those same definitions during serialization. This is the most obvious point where aerogear-server as a server-side framework comes to play.
[1] https://github.com/aerogear/TODO/tree/picketbox/server/src/main/java/org/...
[2] http://stackoverflow.com/questions/2547817/what-is-the-difference-between...
[3] https://community.jboss.org/thread/196404
[4] https://community.jboss.org/message/721988#721988
[5] http://docs.oracle.com/javaee/6/api/javax/persistence/EntityManager.html#...
[6] http://docs.oracle.com/javaee/5/tutorial/doc/bnbqw.html
[7] http://docs.jboss.org/hibernate/orm/4.0/hem/en-US/html/architecture.html#...
- marko
10 years, 5 months
REST API document project
by Jay Balunas
http://apiary.io/
This or something like it might be a good way to document out RESTful api's? I have not done more than just a quick look, but perhaps there is something there that could be useful.
Thoughts?
-Jay
10 years, 5 months
[iOS] Proposal Passing 'Auth Module' into pipe.
by Matthias Wessendorf
Hi,
in order to use the 'auth module' to access protected resources (after
login...) we (somehow) need to pass the AGAuthenticationModule object
into the pipe, when creating it. There are several ways to do that....
Today I played around with the idea of using the builder pattern (see
[1]), or going with some (as varargs) 'PipeOption's (see [2]). The
builder pattern looks ugly, due to deep nested calls (from [1]):
id<AGPipe> tasksPipe = [[[[myPipeline newPipe]
withName:@"logicalName"] withEnpoint:@"tasks" ] buildAndAdd];
The 'Options' approach may look a bit more natural for iOS folks, but
to be honest, I don't want to rush on this API rewrite, especially
since we are just one week away from the first (Alphpa1) release of
the iOS lib....
= Proposal =
For passing in the AGAuthenticationModule, I leverage our CURRENT
'add' approach on the AGPipeline class......
However, for the next release (December timeframe), I want to see what
the best options are to get a new 'AGPipeline API' (=> builder VS.
Options VS Config-Object (similar to what our JavaScript API does) VS
???). Hopefully we can come up with a nice 'DSL' or something like
that which allows an elegant and flexible solution for creating AGPipe
objects....
I will update the release roadmap, that for the next release we do
want to spend some time to get rid of the 'add' approach..... That
gives us some more time to DEEPLY think about it. Also since we are
just on Alpha1, it is IMO not a big deal to change the API
afterwards...
However, if we/I would rush..., I do see the following risks:
- not having security in Alpha1
- another API rewrite due to a rushed API 'design'
IMO having the security _functionality_ in there is a bit of higher
interest, instead of have a CLEAN and STABLE API already in Alpha1....
I know that API changes are awful, but... honestly... there aren't
much users yet and I just don't want to rush for an API, without doing
several prototypes etc. Hence I am moving that API rewrite to the
December timeframe release.
Cheers!
Matthias
[1] https://gist.github.com/3892038
[2] https://gist.github.com/3892384
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
10 years, 5 months
First (Very Rough) Draft of JS AeroGear.SyncManager
by Kris Borchers
So I have continued on from my basic data status tracking that I added to start doing some real syncing. This is very early and only "works" when you save to a store. I have started with an event based model where if a save is made to a store that has dataSync enabled, it fires a custom event on the document. From there, if a conductor (individual SyncManager instance named for the conductor of an orchestra keeping everyone "in sync") has been created that monitors this store, it will catch that event and attempt to perform a save to the pipe that was associated with this conductor on creation. Callbacks can be provided to perform actions on a success or error during sync in addition to the callbacks that would be fired on a normal pipe save but none of that has been tested. :)
This does introduce some API changes that I think are good and gets us on our way to an awesome new feature that I think devs will really appreciate.
Like I said, this is all very early but wanted to throw it out there before I am gone all next week. I would appreciate all thoughts.
https://github.com/aerogear/aerogear-js/tree/SyncManager
Thanks,
Kris
P.S. - I hope this doesn't come through again but looks like my first attempt to send to the list failed.
10 years, 5 months
test
by Kris Borchers
test
10 years, 5 months
AeroGear.SyncManager
by Kris Borchers
So I have continued on from my basic data status tracking that I added to start doing some real syncing. This is very early and only "works" when you save to a store. I have started with an event based model where if a save is made to a store that has dataSync enabled, it fires a custom event on the document. From there, if a conductor (individual SyncManager instance named for the conductor of an orchestra keeping everyone "in sync") has been created that monitors this store, it will catch that event and attempt to perform a save to the pipe that was associated with this conductor on creation. Callbacks can be provided to perform actions on a success or error during sync in addition to the callbacks that would be fired on a normal pipe save but none of that has been tested. :)
This does introduce some API changes that I think are good and gets us on our way to an awesome new feature that I think devs will really appreciate.
Like I said, this is all very early but wanted to throw it out there before I am gone all next week. I would appreciate all thoughts.
https://github.com/aerogear/aerogear-js/tree/SyncManager
Thanks,
Kris
10 years, 5 months
