Re: [Bodington-developers] spring

[Ian B. <ia...@ca...>]

Hi,
I've been lurking for all of 24 hours, Im not a Bodington expert, but I 
can tell you a bit about Spring-Hibernate-JSF in the Sakai context.

First off, don't use JSF.
Unless you are prepared to buy everyone a top end IDE plugin (or 
complete IDE) from BEA, IBM, Sun, Oracle or one of the other JSF-JCP 
members.
Personal experience here is bad. Its really difficult to debug, it has 
horrible semantics (you don't own the URL). I tried to write RWiki with 
JSF (what an idiot!) and gave up when I couldn't do GET's, silly me, 
though I was writing a web application :)
We've also used JSF for about 4 projects before, loosing developers and 
  giving up. Its what caused Antranig to (go mad and) write RSF.

If you want to write Win32GUI apps in a web environment and not know 
anything about the HTTP or HTML, then JSF or ASP.NET+VS2003 is for you!

Rant over.

Spring == Good, but be careful.
-------------------------------
Spring is the simplest form is great (same can be said for other IoC's). 
It removes nearly all the factory code and provided you are disciplined 
about completely abstract APIs (putting them in the their own jar) and 
implementing those API's you get real separation of concerns.
Be careful about the Component Manager. The native Spring Component 
manager is quite good, it has a good structure to it and will not cause 
problems reloading etc. If you want more isolation ( as Sakai did) you 
can write your own Component manager, but be careful not to eliminate 
the reload ability. Having 1M lines of code that require a full Tomcat 
restart when 1 package is changes is not exactly fast development. But 
that just means that you Junit test your components properly, and don't 
have to use the tomcat container as your test environment.

Spring also comes with lots of goodies that can make life easier if you 
don't overuse them. eg Declarative Proxies (transaction, method etc) 
Lazy inits

So I would advocate, use it in is basic way and avoid too many of the 
confusing complex concepts, don't try and replace the ComponentManager 
until you know you absolutely have to.

SpringMVC == excellent
----------------------
This is a really nice Controller IMHO. It integrates well with Spring 
and leaves you free to choose your own model and view technologies. Its 
very service oriented and doesn't make any demands on how you interact 
with URL's or HTTP. I think its better than struts, but thats just personal.

You *must* use the spring plugin for eclipse, it takes all the pain out 
of writing the application context files.

View technology
---------------
Up to you, I like JSP, as view containers with most of the view code in 
beans, eg 10 line JSP that does basic layout. There are plenty of other 
alternatives. Most of the older ones demand that you extend existing 
classes which can be a pain and tie you in knots. It Antranig is 
listening he will no doubt tell you about RSF which is fast, has zero 
bindings and looks just like html. Tapestry is Ok, but has some binding 
issues, the same can be said for Trails. You might also consider SAX 
based XSLT, provided the output is single stage and fast (ie not huge 
chains as is possible with Cocoon). You might also think carefully about 
  pre-publishing content to an intermediary stage to keep performance 
right up. (This was the one thing that Coursework from Stanford did 
really well, it wrote its own templates greatly reducing server load)

One thing with JSP,s watch out for the perm space they use, if you have 
lots you will run out, and have to increase it. Also big JSPs are not as 
fast as small JSPs with Beans...  and tags with lots of el lead to big 
call trees, all of which costs.

Hibernate == good sometimes, bad others.
----------------------------------------
Be careful with hibernate. If you want to do standard CRUD type 
operations on single records, with some lists, then its great. It also 
great an generating Schemas, provided you check what the schema really 
looks like. This aspect takes all the the pain out managing multiple DB 
targets.

Where it is not so great is the way it interacts with the DB. If you 
want to do anything complex (like an optimized join or a bulk update) 
then you are probably better off using Spring JDBC (which has a proxy to 
make life easy). Some of the reasons are.

1. Hibernate treats the Object model as just that, as you navigate 
object relationships it will either load entire object trees from the 
db, or lazy load individual objects on demand. Each of these is an 
individual sql statement. Often a single SQL statement gets the answer 
at much lower cost.
Simple example, delete all objects in a collection, this will generate 1 
SQL delete per object where a single statement would have done the trick.

Hibernate 3 has a bulk update feature that is supposed to address some 
of this, but it will never beat hand coded SQL92.

2. On update, these multiple statements generate 1000's of locks in the 
DB. Depending on how locking is implemented you will at some point run 
into deadlock situations, MySQL.InnoDB is more susceptible than Oracle. 
For instance, 10 threads, started at the same time all trying to create 
and update a single record, each with their own GUID will deadlock after 
about 5 attempts. Thats not much load in real life. Oracle is a bit 
better but you *must* use high inittrans settings on the database blocks 
(default=2, with hibernate ~50). Debugging is a complete  nightmare when 
it happens.

3. Object staleness. Dont use pessimistic locking, Use optimistic 
locking and *dont* ever put hibernate objects into session and try and 
reattach them between request cycles, its a nightmare to get right (JSF 
sort of makes you want to try this, another reason not to use JSF).

You *must* use the Hibernate eclipse plugin ( Synchornise?) it takes the 
hard work out of most operations


Currently my top architecture stack would be
--------------------------------------------
A SOA, no/minimal in session state, no big in memory object models, no 
EJB (:)), Separation of Concerns etc etc etc
Spring
Hibernate for Schema
Spring JDBC and Hibernate (for simple crud ops)
Spring MVC for the controller
JSP/SAX-XSLT/RSF for the view.

If you are not already using
maven
to build (write your own jelly plugin to make it easy to get up and 
running , maven sakai builds sakai)
keeps dependencies out of SVN and well defined (precise control over 
versions)

svn for SCM
as both of these make it much easier for a larger number of developers 
to work concurrently. (Sakai has had about 7K commits from about 50 
developers on about 100 components since 1/1/06)

I think thats my 2p's worth.
You might look a stealing/borrowing/reusing some of the framework parts 
of Sakai if you are thinking in this area, have a look a mini, which you 
could strip back further.

https://source.sakaiproject.org/svn/sakai/branches/sakai_mini/

url when your up is
http://localhost:8080/mercury/
user: admin, admin

Ian Boston

Matthew Buckett wrote:
> John Norman wrote:
>> Would you welcome some of my developers to share what we have learned  
>> from our Sakai work? I can get Ian and Antranig to join the list and  
>> maybe someone from Indiana if you want to thrash out where these  
>> technologies work well and where they don't...
> 
> Yeah I'd be interested to hear about others experience.
> 
> Background:
> 
> At the moment Bodington hands control straight to the template(view) 
> which then calls the business logic and renders the response. Templates 
> are like restricted JSPs.
> 
> I wanted to move to an MVC architecture for the servlet layer as it is 
> one of the weaker areas of Bodington at the moment. Due to bodingtons 
> use of good URLs and very page orientated layout some frameworks didn't 
> get much consideration:
> 
> 	Tapestry - Bad URLs (better now), component architecture.
> 	JSF - Bad URLs, component architecture.
> 
> An obvious candidate was struts as it is very popular (if aging) and as 
> a result most experienced Java developers will know a little about it. I 
> also had used it on a previous project. Although I got it working a 
> little I couldn't manage to get it to work well with Bodingtons tree 
> style URLs without starting to hack at struts itself.
> 
> Next I looked at SpringMVC which is harder to get started with but much 
> more flexible. SpringMVC has a reasonable community, acceptable 
> documentation and books. SpringMVC works ok alongside Bodington so that 
> is what I have stuck with so far.
> 
> For the presentation I used JSPs (no scriptlets) with Core, Spring and 
> Template taglibs. SpringMVC can work with XSLT, Velocity, Freemarker 
> istead of JSPs for view.
> 
>