RE: [Springframework-developer] Latest internal reworkings

[Keith D. <kd...@cs...>]

>Regarding Assert: I've omitted all methods that use default messages =
there,
>because I believe that this is bad practice. Assert.nonNull(myRef) =
would
>throw a generic IllegalArgumentException, which is not really more =
useful
>that an NPE... There needs to be a specific message, for example:
>Assert.nonNull(ds, "No DataSource specified").

While I certainly agree that assertions with descriptive failure =
messages
are much better than those with not, I feel general assertion checks =
aren't
bad programming practice.  Any assert still catches the invariant/state
violation when it happens and not later (for example, by having to track =
it
down manually via some symptomatic, cryptic NPE), which is the most
compelling benefit of such checks.  It's also really easy to jump to the
spot in the code where the assertion was thrown to see what WAS =
violated:
the point is that it is caught early and before use.

I actually worked on the cramped plane ride back from Oslo on improving =
the
Assert class and adding an additional Assert.state(expression, message) =
that
throws IllegalState.  I've also been readying util.closure, =
util.comparator,
util.visitor for commit to the core util package with complete test =
cases
and javadocs.  I'd like to commit these ASAP as they've been hanging =
around
in the sandbox for awhile; it's not much code, they're all generally =
useful,
and they're used in both in the rules code and spring-rich.

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
j=FCrgen h=F6ller [werk3AT]
Sent: Sunday, October 10, 2004 11:23 AM
To: spr...@li...
Subject: [Springframework-developer] Latest internal reworkings

Everybody,
=20
I've reworked a couple of internal things over the past few days =
(already
committed):
=20
* AbstractBeanFactory implements "destroyBean" functionality itself, =
which
was made possible by an earlier change in the dependency tracking =
strategy.
AbstractAutowireCapableBeanFactory is purely responsible for actual bean
instance creation now.
=20
* DefaultListableBeanFactory's "getBeansOfType" is completely =
reimplemented
now, always detecting FactoryBeans correctly (no matter if a FactoryBean
implements other interfaces too or was registered as a manual =
singleton).
=20
* ProxyFactoryBean and AbstractPrototypeBasedTargetSource leverage
BeanFactory's new "getType" method now, to determine the type upfront =
before
fetching bean instances (usually for prototypes). This works for child =
bean
definitions etc too now, not just for conventional beans.
=20
* The "invokeJoinpointUsingReflection" has moved from
aop.framework.AopProxyUtils to aop.support.AopUtils, to resolve a =
subpackage
interdependency (aop.framework should use aop.support, not the other way
round).
=20
* JdkDynamicAopProxy handles the "hashCode" method locally now, just =
like it
does for "equals". This is mainly necessary for remoting proxies, but =
also
for consistent behavior of a proxy's "equals" and "hashCode" methods =
(i.e.
always return same hash code if equals).
=20
* HttpInvokerClientInterceptor and RmiClientInterceptor handle =
"toString"
invocations locally now, returning a description of the remoting proxy.
"equals" and "hashCode" are handled locally too, through =
JdkDynamicAopProxy
(see above).
=20
* I've moved the util.Assert class over from the sandbox, in a stripped =
down
fashion. It is used in a couple of places in the data access support =
now, to
catch null DataSource arguments etc early and in an obvious fashion. =
Note
that such stuff is usually caught by afterPropertiesSet, but only inside =
a
bean factory...
=20
Regarding Assert: I've omitted all methods that use default messages =
there,
because I believe that this is bad practice. Assert.nonNull(myRef) would
throw a generic IllegalArgumentException, which is not really more =
useful
that an NPE... There needs to be a specific message, for example:
Assert.nonNull(ds, "No DataSource specified").
=20
Most of the above is about improvements and optimizations in the =
internals,
also solving corner cases in behavior. While all tests pass again, there
could be undiscovered side effects: Therefore, I'd like to encourage
everybody to test the current CVS contents as thoroughly as possible. =
1.1.2
is still 4 weeks away, but it's never too early to start testing :-)
=20
Juergen


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give =
us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out =
more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer