Fw: [Springframework-developer] docs & tutorial

[Rod J. <rod...@in...>]

Just thought I should provide some context for the AOP tx stuff by sharing
the notes I sent Isabelle for the bean factory tutorial.

There are no notes on AOP framework at the moment. It has many features the
tx tutorial doesn't touch on, and which I'll try to document next week. The
aop framework tests are a good place to look, as they have 95% coverage!


> Here are some notes on the current bean factory functionality. I'll add
some
> on ApplicationContext later. I think code examples would be good to
> illustrate the points: there are many in the tests and of course there's
> probably going to be a new sample app.
>
> I'll also try to put together an AOP one, but that's probably going to be
> after Easter now.
>
> I've put asteriscs against things that are new or changed since the book.
> The first part of chapter 11 has lots on the motivation of the bean
factory,
> so I haven't recapped too much of that.
>
>
> OVERVIEW
> A BeanFactory is a simple interface that provides a directory of
configured
> objects. Spring emphasises Java Beans heavily, and BeanFactories are used
> heavily by other Spring functionality. We've found BeanFactories to be an
> elegant way of providing a lightweight directory, and encouraging good
> practice by programming to interfaces rather than concrete classes.
Chapter
> 11 of "Expert One on One J2EE Design and Development" discusses the
> motivation of the bean factory, and ways in which it's superior to common
> alternative solutions to the problems it addresses.
>
> Bean instances are obtained from a BeanFactory by name. BeanFactory
> implementations support "singleton" bean instances (the commonest
> requirement) and "prototype" instances. With a singleton instance,
repeated
> call to the bean factory to obtain a particular bean by name will always
> return the same object. With prototype instances, each call will return an
> independent instance, expressing the Prototype GoF design pattern, rather
> than the Singleton. We've found singleton beans to be most useful, and
find
> that they tend to avoid any need to have multiple singletons scattered
> around an application. Avoiding multiple singletons or many independent
> factories is a Good Thing. For example, it facilitates unit testing: it's
> very easy to configure a factory at test time to return a mock object or
> other stub instead of a business object that requires resources beyond the
> scope of the test.
>
> How bean instances are configured is factory-specific, although XML
> documents and properties files are the commonest form. The syntax is
> intuitive, based around the specification of a fully qualified class name
> and JavaBean properties.
>
> **** Example of XML and properties syntax
>
> Although it's possible to cast beans to a specific class, it's strongly
> recommended that all application code knows only the interface(s)
> implemented by each bean. This ensures maximum pluggability. (Note that in
> the case of beans requiring an AOP proxy, it's impossible to code to the
> specific class, and interfaces _must_ be used.)
>
>
> From the user's perspective, all BeanFactory implementations are used
> identically. This means that it's possible to switch easily from a test
bean
> factory, which may replace some business objects with mock objects or
stubs,
> to a real bean factory without impacting client-side application code.
>
> ListableBeanFactory is a subinterface of BeanFactory implemented by
> BeanFactories that can enumerate the names and types of all beans they
> manage. Most of the supplied bean factories implement this interface.
> Sometimes code using BeanFactories will depend on a ListableBeanFactory.
For
> example, Spring's web functionality looks for an enumeration of beans that
> can handle HTTP requests.
>
>
> FACTORY BEANS
> Sometimes a bean definition is more complex than the definition of the
class
> to return along with its JavaBeans properties. We might want to perform
some
> special steps between definition and returned object, for example, with
the
> returned class varying depending on some state.
>
> We might want to do return a proxy to an underlying object: for example,
an
> AOP proxy that invokes a number of interceptors before the target, or a
> proxy concealing access to a remote object.
>
> The FactoryBean interface provides an additional step of abstraction in
> which the FactoryBean manages the lifecycle of a single type of bean. Any
> class that implements that com.interface21.beans.factory.FactoryBean
> interface will automatically be treated as  a factory bean.
>
> Note that this replaces the more complex "custom bean definition" approach
> discussed in "Expert 1:1 J2EE". *
>
> Because a factory bean introduces two objects (the FactoryBean and the
> object(s) it returns) we also need to be able to get to the factory. All
> BeanFactory implementations support a special syntax to allow this,
inspired
> by C/C++ pointer dereferencing.
>
> getBean("&factoryName")
>
> will return the factory, rather than an instance of the bean managed by
the
> factory. The ampersand syntax may only be used on factory beans: a
> BeanIsNotAFactoryException will be thrown if it is used on ordinary beans.
>
> Being able to obtain the factory gives us the option of altering or
querying
> factory settings programmatically. (As this reduces implementation
choices,
> it shouldn't be done lightly.)
>
> ADVANCED FEATURES
> All bean factory implementations support the creation of references
amongst
> beans. This enables the easy creation of sophisticated object graphs. It
> also enables application objects used as beans in a BeanFactory to avoid
any
> dependence on the BeanFactory or other Spring APIs, merely exposing
JavaBean
> properties that will be set to the value of other beans at runtime. This
> ability for application code to avoid dependence on proprietary APIs is
one
> of Spring's major advantages.
>
> EXAMPLE of references**
>
> Most BeanFactory implementations, such as XML and properties-based
> implementations, use string representations of JavaBean properties. What
if
> we want to specify an object other than a reference to another bean using
a
> string? All BeanFactory implementations (and the underlying
> com.interface21.beans JavaBean manipulation API) uses the standard
JavaBeans
> PropertyEditor functionality. Installed PropertyEditors will automatically
> be invoked to create JavaBean instances from Strings if necessary. Thus
> Spring provides a number of PropertyEditor implementations itself, in the
> com.interface21.beans.propertyeditors package, for types such as
> java.util.Properties and String[], but can automatically take advantage of
> any other available PropertyEditors, including those provided for
primitive
> type wrappers with the core JavaBeans API.
>
>
> Sometimes multiple beans inherit from a common base bean definition (or
> hierarchy of bean definitions), meaning that the descendant beans
"inherit"
> all properties from the ancestor definitions, but can override and add
> further properties as they desire. This can safe a lot of typing and allow
> for consistent changes in a single place only when many beans share a lot
of
> properties. A common use of this is web tier views, in which many views
> share most of their properties.
>
>
> INHERITANCE
>
> The concept of inheritance doesn't apply only to bean instances in the
same
> factory; BeanFactories themselves can also have parents, to an arbitrary
> depth. Each bean instance will be sought by the parent if not found in a
> child bean factory.
>
> Why is this useful? Consider how the Spring MVC framework uses Spring's
> BeanFactories. Each controller servlet has its own BeanFactory
> implementation, backed by default by its own XML file. However all
servlets
> extend a shared BeanFactory that is ServletContext wide, enabling them to
> share common objects but override specific objects and add new objects as
> they desire.
>
> A base bean factory can contain common definitions, such as AOP
> interceptors, which may be used across a whole application.
>
> Note that another way to get reuse out of bean definitions when using an
XML
> bean factory is to import content in the form of XML entity references.
This
> avoids the duplication of boilerplate code.
>
>
> FUTURE DIRECTIONS
> - BeanFactories are likely to support dynamic reconfiguration of
beans--for
> example, by monitoring an XML or properties file and reapplying any
changed
> properties.
> - We may introduce "private" beans. These will be available to configure
> other beans, but will not be accessible to user code with the getBean()
> method. This might be used to conceal the underlying object behind an AOP
> proxy, for example, to ensure that the necessary interception always
occurs.
> - More BeanFactory implementations may be added. For example, a
BeanFactory
> could easily be added to expose all SLSB instances in a JNDI tree, or all
> web services at a specific location. Exactly what new factories are added
> are up to you, as Spring users. Both these are just examples of what can
be
> done: we're hoping for suggestions and contributions that people have
found
> useful in real applications. Because the BeanFactory, and even
> ListableBeanFactory, interface is so simple, it's very easy to implement
> additional bean factories.
>
> All BeanFactory changes are likely to be backward compatible.
>
>
>
>
> Rod
>
>
>
> > Hi everyone,
> >
> > Rod's ideas are fine by me.
> >
> > (1) create a new module in cvs called samples, at the same level as main
> (I don't think I have the privileges to do that, so I hereby delegate this
> task)
> > (2) we should have separate examples for each area; so for ex. some jdbc
> examples, some jndi examples etc... Everyone should send me whatever they
> have (maybe the stuff they used for testing, playing etc..). I will
collate
> and create examples where they are lacking. If I get into trouble (for ex.
> with the AOP stuff, which I haven't looked at yet) I will ask for help.
> > (3) everyone should send me some documentation on what they did.
Together
> with Rod's book, this will hopefully be enough to put together the 1.0
docs
> > (4) we should also have an end-to-end application with maybe a tutorial.
I
> did not like the example app in Rod's book very much, I felt the business
> logic obscured the point here and there and something simpler would have
> come across better. Maybe we could do a bookstore with
> > a) entry screen with promotions, a list of categories to browse and a
> search button
> > (b) the search button offers a screen where one can fill in either
author,
> title or keywords
> > (c) in each category a list of books with author, title, etc... and the
> possibility to purchase
> > (d) a shopping cart
> > (e) a checkout screen
> >
> > If everybody agrees with this idea for the tutorial, I will create the
> database design and UML model, and we can apportion the work from there
> >
> > Isabelle
> >
> > --
> > Isabelle Muszynski
> > Zandweellaan 4
> > 2660 Antwerpen
> > Belgium
> > Tel. 32-(0)3-830 18 54
> > Mobile: 32-(0)485 49 50 89
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Etnus, makers of TotalView, The
> debugger
> > for complex code. Debugging C/C++ programs can leave you feeling lost
and
> > disoriented. TotalView can help you find your way. Available on major
UNIX
> > and Linux platforms. Try it free. www.etnus.com
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
>