Re: [Bodington-developers] spring

[Sean M. <se...@sm...>]

Thanks, Ian, for the brain dump.

Interesting to see that we mesh on so much. We ran away from JSF at UHI
some time ago as well.

I will have a look at the sakai mini and perhaps we can come back to you
with some ?s / comments....


s



<quote who=3D"Ian Boston">
> 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 =3D=3D 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 =3D=3D 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 abou=
t
>   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 a=
s
> fast as small JSPs with Beans...  and tags with lots of el lead to big
> call trees, all of which costs.
>
> Hibernate =3D=3D 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 t=
o
> 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 tric=
k.
>
> 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 afte=
r
> 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 block=
s
> (default=3D2, with hibernate ~50). Debugging is a complete  nightmare w=
hen
> 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 th=
e
> 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 yo=
u
> 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. Template=
s
>> 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 a=
s
>> 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 muc=
h
>> more flexible. SpringMVC has a reasonable community, acceptable
>> documentation and books. SpringMVC works ok alongside Bodington so tha=
t
>> 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.
>>
>>
>
>
>
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers
>


--=20
Sean Mehan
Head of e-Frameworks
Learning and Information Services
UHI