Remove all xsd versions from the reference manual samples in favor of
"versionless" XSDs. For example, spring-beans-3.0.xsd becomes
spring-beans.xsd
Issue: SPR-10010
Prior to this commit many imagedata elements were duplicated in
order to configure PDF sizes. Since HTML generation is configured
to ignore image scaling altogether this was unnecessary duplication.
Issue: SPR-10033
Convert all docbook XML files to well-formed docbook 5 syntax:
- Include xsi:schemaLocation element for tools support
- Convert all id elements to xml:id
- Convert all ulink elements to link
- Simplify <lineannotation> mark-up
- Fix misplaced </section> tags
- Fix <interface> tags to <interfacename>
- Cleanup trailing whitespace and tabs
Issue: SPR-10032
CGLIB 3 has been released in order to depend on ASM 4, which Spring now
depends on internally (see previous commit).
This commit eliminates spring-beans' optional dependency on cglib-nodep
v2.2 and instead repackages net.sf.cglib => org.springframework.cglib
much in the same way we have historically done with ASM.
This change is beneficial to users in several ways:
- Eliminates the need to manually add CGLIB to the application
classpath; especially important for the growing number of
@Configuration class users. Java-based configuration functionality,
along with proxy-target-class and method injection features now
work 'out of the box' in Spring 3.2.
- Eliminates the possibility of conflicts with other libraries that
may dependend on differing versions of CGLIB, e.g. Hibernate
3.3.1.ga and its dependency on CGLIB 2.1.3 would easily cause a
conflict if the application were depending on CGLIB 3 for
Spring-related purposes.
- Picks up CGLIB 3's changes to support ASM 4, meaning that CGLIB is
that much less likely to work well in a Java 7 environment due to
ASM 4's support for transforming classes with invokedynamic
bytecode instructions.
On CGLIB and ASM:
CGLIB's own dependency on ASM is also transformed along the way to
depend on Spring's repackaged org.springframework.asm, primarily to
eliminate unnecessary duplication of ASM classfiles in spring-core and
in the process save around 100K in the final spring-core JAR file size.
It is coincidental that spring-core and CGLIB currently depend on the
exact same version of ASM (4.0), but it is also unlikely to change any
time soon. If this change does occur and versions of ASM drift, then
the size optimization mentioned above will have to be abandoned. This
would have no compatibility impact, however, so this is a reasonable
solution now and for the forseeable future.
On a mysterious NoClassDefFoundError:
During the upgrade to CGLIB 3.0, Spring test cases began failing due to
NoClassDefFoundErrors being thrown from CGLIB's DebuggingClassWriter
regarding its use of asm-util's TraceClassVisitor type. previous
versions of cglib-nodep, particularly 2.2, did not cause this behavior,
even though cglib-nodep has never actually repackaged and bundled
asm-util classes. The reason for these NoClassDefFoundErrors occurring
now is still not fully understood, but appears to be due to subtle JVM
bytecode preverification rules. The hypothesis is that due to minor
changes in DebuggingClassWriter such as additional casts, access to
instance variables declared in the superclass, and indeed a change in
the superclass hierarchy, preverification may be kicking in on the
toByteArray method body, at which point the reference to the missing
TraceClassVisitor type is noticed and the NCDFE is thrown. For this
reason, a dummy implementation of TraceClassVisitor has been added to
spring-core in the org.springframework.asm.util package. This class
simply ensures that Spring's own tests never result in the NCDFE
described above, and more importantly that Spring's users never
encounter the same.
Other changes include:
- rename package-private Cglib2AopProxy => CglibAopProxy
- eliminate all 'cglibAvailable' checks, warnings and errors
- eliminate all 'CGLIB2' language in favor of 'CGLIB'
- eliminate all mention in reference and java docs of needing to add
cglib(-nodep) to one's application classpath
Issue: SPR-9669
Before this change bean scopes chapter in Spring reference documentation
had a note which mentioned that creating a scoped proxy for singleton-
or prototype-scoped beans will throw BeanCreationException.
This is no longer the case and this change removes the mentioned note.
Issue: SPR-7940
Problems
- Eliminate — in favor of —
— was causing 'no such entity' errors during docbook
processing; — produces the equivalent output.
- Fix column issues in appendices
column counts were set to 3, when they are in fact 4. This passed
under DocBook 4 and Spring Build for unknown reasons, but caused a
hard stop under DocBook 5 and the docbook-reference-plugin.
- Add jdbc callout section in docbook 5-friendly style
use <co/> tags as advertised in DocBook documentation.
- Set correct widths for PDF ref doc images
images were rendering larger than the PDF page; just set all to
width=400 and everything looks good.
Polish
- Update reference doc copyright to 2012
- Remove "work-in-progress" language from ref docs
- Update maven URLs to repo.springsource.org
- Update javadoc urls from 3.0.x/javadoc-api => current/api
- Replace hardcoded "3.1" with ${version} in ref doc
It was determined (through painful trial and error) that after the
upgrade to DocBook 5 and the gradle-docbook-reference plugin, that
<emphasis> elements embedded within <programlisting> elements causes
NullPointerExceptions during processing.
This change eliminates these <emphasis> elements to work around the
problem. This means a slight degradation in presentation for the
affected areas of the reference documentation. After some research,
it is not clear what other workarounds may be possible that leave
the text actually emphasized.
This change eliminates the spring-framework-reference subproject, moving
these sources into the root project's own src directory.
This makes sense because the reference docs span all submodules, and
also because api Javadoc is created at the root project level as well.
This means that both api and reference documentation output will now
reside in the root project's 'build' directory. This is more consistent
and easy to discover.
