springframework-developer — Spring Framework developers list

[Springframework-developer] Optional dependencies

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

Guys,

I've just been discussing our forthcoming Struts integration with Yann and
Paul.

This raises a problem that's likely to recur. This will probably involve
adding a small number of classes that are Struts-dependent. But not all
developers might be interested in them.

In the following, read "Struts" to mean "any third party product some
classes will depend on but which aren't of interest to everyone".

How can we prevent our whole source tree being Struts-dependent and prevent
developers uninterested in Struts from having to download the relevant Jars?
* Make it a separate CVS module?  But this will lead to a profusion of CVS
modules. Harder to build etc.
* Put it in the main module and change the Ant build script to compile the
necessary classes and run the the relevant tests only if it finds Struts on
the classpath? This could eventually make the build script very long and
complicated.
* Better ideas I haven't thought off?? How do other projects handle this?

From a distribution point of view, many users won't want the Struts classes
either. We could make them a sep download. Or we could just include them in
one of the main Jars, and they wouldn't do any harm unless they were used
without Struts.

From a documentation view, we'll also need a dependencies table, showing
what depends on what.

Regards,
Rod

____________________________________________________
Rod Johnson
J2EE Architect and Author
+44 7973 409 132

Author of "Expert One-on-One J2EE Design and Development"
(Wrox Press, October 2002).
http://www.amazon.com/exec/obidos/tg/detail/-/1861007841/

http://www.wrox.com/books/1861007841.htm

http://www.wrox.com/dynamic/books/find.aspx?author=Rod+Johnson

Re: [Springframework-developer] adding eclipse files to cvs

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

Juergen,

> My main interest is in Spring's web functionality, validation, and the
core infrastructure, so I will generally focus on those.

I would be happy for you to take the lead in the web area, as I don't
anticipate that I'll be looking that much at that area in the near future,
as I'm currently involved mostly in financial middleware. Of course I will
be happy to contribute my ideas and discuss yours.

I think the basic MVC design is very flexible--much more so than Struts--and
very sound.

The validation mechanism, however, needs attention. I think it might aim to
do too much.

The whole issue of how Spring MVC integrates with custom tags etc. is
another interesting point. Personally I think that Struts is too
JSP-centric. I'm not a big fan of JSP. However, the fact is that the main
strength and selling point of Struts is its integration with custom tags.

The Spring philosophy of "don't reinvent the wheel" means that integration
with JSTL is a priority. However, this still leaves some areas unfilled.

Regards,
Rod
----- Original Message -----
From: "jürgen höller [werk3AT]" <jue...@we...>
To: "Spring Developers (E-mail)"
<spr...@li...>
Sent: Thursday, February 13, 2003 5:33 PM
Subject: Re: [Springframework-developer] adding eclipse files to cvs


Hi Trevor, all,

I don't mind Eclipse project files being added to the repository. I'm using
IntelliJ IDEA, by the way - and I love it! Of course, Eclipse is fine, too
;-) Maybe I will add an IDEA project file to the repository too, if I find
enough time to create a clean one.

The current week is a laborious but final week for my company's current
major project, for the time being. I hope I will be able to dedicate a
significant part of the next few weeks to infrastructure development for the
next major project, i.e. digging into Spring and Hibernate. Of course, I
will use my spare time too, especially for further code review and
documentation, and comparative research concerning Struts and WebWork.

My main interest is in Spring's web functionality, validation, and the core
infrastructure, so I will generally focus on those.

Regards,
Juergen



-----Ursprüngliche Nachricht-----
Von: Trevor Cook [mailto:tc...@in...]
Gesendet: Donnerstag, 13. Februar 2003 17:10
An: Spring Developers (E-mail)
Betreff: [Springframework-developer] adding eclipse files to cvs



I hope I'm not being too forward or aggressive in making some
recommendations for this project.  My experience so far has mainly been
working solo or in small teams as lead developer, so my experience with open
source (as a contributor) and large project management is nil.  If I'm out
to lunch, just let me know.

I think that the suggestion by "William G. Thompson, Jr." on the Wrox board
about adding eclipse files is a good one.  It sounds like those so far
involved (Rod, Yann, and me - not sure what Juergen is using) are using
eclipse, so adding the few eclipse specific files (.project and .classpath)
make sense to me.  I would also recommend standarizing on an eclipse
variable for the one jar we don't distribute (j2ee) as being "J2EE_HOME".
Finally, we would need to specify the eclipse output folder.  I prefer
"target" and eclipse defaults to "build", but I'll use whatever the team
decides.  To get started though, the files would be as follows (subject to
any changes recommended by the team):

.project
<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
        <name>springframework</name>
        <comment></comment>
        <projects>
        </projects>
        <buildSpec>
                <buildCommand>
                        <name>org.eclipse.jdt.core.javabuilder</name>
                </buildCommand>
        </buildSpec>
        <natures>
                <nature>org.eclipse.jdt.core.javanature</nature>
        </natures>
</projectDescription>

.classpath
<?xml version="1.0" encoding="UTF-8"?>
<classpath>
    <classpathentry kind="src" path="src"/>
    <classpathentry kind="src" path="test"/>
    <classpathentry kind="con"
path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
    <classpathentry kind="lib" path="lib/clover/clover.jar"/>
    <classpathentry kind="lib" path="lib/easymock/easymock.jar"/>
    <classpathentry kind="lib" path="lib/junit/junit.jar"/>
    <classpathentry kind="lib"
path="lib/mockobjects/mockobjects-0.07-core.jar"/>
    <classpathentry kind="lib" path="lib/velocity/velocity-1.3.jar"/>
    <classpathentry kind="lib" path="lib/log4j-1.2.jar"/>
    <classpathentry kind="lib"
path="lib/mockobjects/mockobjects-0.07-j1.3-j2ee1.3.jar"/>
    <classpathentry kind="lib"
path="lib/mockobjects/mockobjects-0.07-jdk1.3.jar"/>
    <classpathentry kind="lib" path="lib/velocity/velocity-dep-1.3.jar"/>
    <classpathentry kind="var" path="J2EE_HOME/lib/j2ee.jar"/>
    <classpathentry kind="output" path="target"/>
</classpath>

My other suggestion is partly a question which is adding .cvsignore to cvs.
I'm not sure if this is normal/good practice, or just something I've been
doing.  If we did add it, as a start it would look like:

junit-reports
.classes
.testclasses
spring-core-0.8.jar
spring-ejbimpl-0.8.jar
spring-jdbc-0.8.jar
spring-web-0.8.jar
target

My last suggestion is actually a response to an email from Rod, which I'll
quote here to get it out to the team.

>>I'm not sure about mo.whatever: maybe com.interface21.mockobjects
>>would be better--I didn't think very hard about the naming.

I think that "com.interface21.mockobjects" makes a lot more sense. I was
just recommending mo.xxx to try to match the mo.ejb which already existed.
I'll use "com.interface21.mockobjects.jdbc" for the tests I'm refactoring.
When the other tests are refactored, we should probably move mo.ejb into an
equivelent package, and possibly move servletapi as well (haven't looked
closely enough at those test objects to comment).


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/03

Re: [Springframework-developer] adding eclipse files to cvs

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

Sounds fine to me. I considered checking in the Eclipse project file myself,
but was worried about the J2EE absolute path. You seem to know Eclipse
better than I so I'm happy with your suggestion.

Please don't use /target as the output directory. This conflicts with the
default for Maven, a build tool we may use for some tasks. No other special
requests. I don't mind /build myself.

If you want to check this in, please go for it. It's useful.

Also: can we check in excludes, formatting settings...

Regarding Eclipse or other IDEs, how about we standardize on @todo to mark
tasks in the source? Eclipse handles this very nicely.

The mo.ejb package isn't really necessary, in my opinion. I actually tried
to delete it last night. I'd be inclined to delete it rather than move it.
But moving the other mock objects makes sense.

Regards,
Rod

----- Original Message -----
From: "Trevor Cook" <tc...@in...>
To: "Spring Developers (E-mail)"
<spr...@li...>
Sent: Thursday, February 13, 2003 4:10 PM
Subject: [Springframework-developer] adding eclipse files to cvs


> I hope I'm not being too forward or aggressive in making some
> recommendations for this project.  My experience so far has mainly been
> working solo or in small teams as lead developer, so my experience with
open
> source (as a contributor) and large project management is nil.  If I'm out
> to lunch, just let me know.
>
> I think that the suggestion by "William G. Thompson, Jr." on the Wrox
board
> about adding eclipse files is a good one.  It sounds like those so far
> involved (Rod, Yann, and me - not sure what Juergen is using) are using
> eclipse, so adding the few eclipse specific files (.project and
.classpath)
> make sense to me.  I would also recommend standarizing on an eclipse
> variable for the one jar we don't distribute (j2ee) as being "J2EE_HOME".
> Finally, we would need to specify the eclipse output folder.  I prefer
> "target" and eclipse defaults to "build", but I'll use whatever the team
> decides.  To get started though, the files would be as follows (subject to
> any changes recommended by the team):
>
> .project
> <?xml version="1.0" encoding="UTF-8"?>
> <projectDescription>
> <name>springframework</name>
> <comment></comment>
> <projects>
> </projects>
> <buildSpec>
> <buildCommand>
> <name>org.eclipse.jdt.core.javabuilder</name>
> </buildCommand>
> </buildSpec>
> <natures>
> <nature>org.eclipse.jdt.core.javanature</nature>
> </natures>
> </projectDescription>
>
> .classpath
> <?xml version="1.0" encoding="UTF-8"?>
> <classpath>
>     <classpathentry kind="src" path="src"/>
>     <classpathentry kind="src" path="test"/>
>     <classpathentry kind="con"
> path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
>     <classpathentry kind="lib" path="lib/clover/clover.jar"/>
>     <classpathentry kind="lib" path="lib/easymock/easymock.jar"/>
>     <classpathentry kind="lib" path="lib/junit/junit.jar"/>
>     <classpathentry kind="lib"
> path="lib/mockobjects/mockobjects-0.07-core.jar"/>
>     <classpathentry kind="lib" path="lib/velocity/velocity-1.3.jar"/>
>     <classpathentry kind="lib" path="lib/log4j-1.2.jar"/>
>     <classpathentry kind="lib"
> path="lib/mockobjects/mockobjects-0.07-j1.3-j2ee1.3.jar"/>
>     <classpathentry kind="lib"
> path="lib/mockobjects/mockobjects-0.07-jdk1.3.jar"/>
>     <classpathentry kind="lib" path="lib/velocity/velocity-dep-1.3.jar"/>
>     <classpathentry kind="var" path="J2EE_HOME/lib/j2ee.jar"/>
>     <classpathentry kind="output" path="target"/>
> </classpath>
>
> My other suggestion is partly a question which is adding .cvsignore to
cvs.
> I'm not sure if this is normal/good practice, or just something I've been
> doing.  If we did add it, as a start it would look like:
>
> junit-reports
> .classes
> .testclasses
> spring-core-0.8.jar
> spring-ejbimpl-0.8.jar
> spring-jdbc-0.8.jar
> spring-web-0.8.jar
> target
>
> My last suggestion is actually a response to an email from Rod, which I'll
> quote here to get it out to the team.
>
> >>I'm not sure about mo.whatever: maybe com.interface21.mockobjects
> >>would be better--I didn't think very hard about the naming.
>
> I think that "com.interface21.mockobjects" makes a lot more sense. I was
> just recommending mo.xxx to try to match the mo.ejb which already existed.
> I'll use "com.interface21.mockobjects.jdbc" for the tests I'm refactoring.
> When the other tests are refactored, we should probably move mo.ejb into
an
> equivelent package, and possibly move servletapi as well (haven't looked
> closely enough at those test objects to comment).
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/03
>
>

Re: [Springframework-developer] AOP Code

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

Chris,

The interceptors get invoked in order before each method call on the target
object. Actually, interceptors are chained, so that the head of the
interceptor chain gets to do processing before and after subsequent
interceptors are invoked--hence before and after the ultimate method call.

Imagine that debugInterceptor and invokerInterceptor are interceptors, that
the proxy implements interface ITestBean and TestBean is the target
implementation.

The control flow will be:

client calls ITestBean method -> AopProxy (dynamic proxy) ->
debugInterceptor -> invokerInterceptor -> TestBean ->
invokerInterceptor ->debugInterceptor -> client

Each interceptor has access to an com.interface21.aop.Invocation object that
contains information about the method signature, attributes and
"resources"--objects added to the invocation by previous interceptors in the
chain.

Let's look at how this is set up in the aoproxy_chain2.xml file from the
test suite.

Interceptors and target objects are set up as beans (what else). The
AopProxy is also created via a special bean definition.

<beans>

Interceptors are simply bean definitions, and must implement
com.interface21.aop.Interceptor:

 <bean name="debugInterceptor" class="com.interface21.aop.DebugInterceptor"
singleton="false">

 </bean>

 <bean name="invokerInterceptor"
class="com.interface21.aop.InvokerInterceptor" singleton="false">
  <property name="target" beanRef="true">test</property>
 </bean>

If we use the invoker interceptor, it will need to use reflection to invoke
a target, so in this case we need an actual implementation of ITestBean:

 <bean name="test" class="com.interface21.beans.TestBean">
  <property name="name">custom</property>
  <property name="age">666</property>
 </bean>

When we set up the AopProxy we specify
* the interfaces it must "implement" (only one in this case)
* the debug interceptor names: the beans will be configured in the order
specified. this makes it very easy to change interceptor ordering
* attributes that set interceptor behaviour. These are per method. NB: I'm
considering overhauling the attribute implementation, which is not complete
anyway. I'm interested in the .NET approach in which attributes are objects.
Maybe they could also be bean references.

Attributes, for example, would govern the behaviour of a transaction
interceptor.

 <bean name="aoproxy"
   definitionClass="com.interface21.aop.AopProxyBeanDefinition"
 >
  <customDefinition
property="proxyInterfaces">com.interface21.beans.ITestBean</customDefinition
>

  <customDefinition
property="interceptors">debugInterceptor,invokerInterceptor</customDefinitio
n>

  <customDefinition property="attributes">
   setAge=txAge
   getName=txName,txName2
  </customDefinition>

 </bean>


</beans>


Now we can access the proxy like any other implementation of the ITestBean
interface. The use of AOP is transparent to client code.

ITestBean t = (ITestBean) beanFactory.getBean("aoproxy");

Cross-cutting functionality can be added to all proxied method invocations,
through the interceptor's behaviour.


Regards,
Rod

> Rod,
>
> I have been reviewing your AOP code and wonder if you could provide a
brief
> explanation on how it works. I'm not sure when the interceptors get
invoked
> and how you can control their timing. Also are the interceptors the
> mechanism to add, "cross cutting functionality"? Please explain.
>
> Regards,
>
> Chris Axe

Re: [Springframework-developer] adding eclipse files to cvs

[<jue...@we...>]

Hi Trevor, all,
=20
I don't mind Eclipse project files being added to the repository. I'm =
using IntelliJ IDEA, by the way - and I love it! Of course, Eclipse is =
fine, too ;-) Maybe I will add an IDEA project file to the repository =
too, if I find enough time to create a clean one.
=20
The current week is a laborious but final week for my company's current =
major project, for the time being. I hope I will be able to dedicate a =
significant part of the next few weeks to infrastructure development for =
the next major project, i.e. digging into Spring and Hibernate. Of =
course, I will use my spare time too, especially for further code review =
and documentation, and comparative research concerning Struts and =
WebWork.
=20
My main interest is in Spring's web functionality, validation, and the =
core infrastructure, so I will generally focus on those.
=20
Regards,
Juergen
=20
=20

	-----Urspr=FCngliche Nachricht-----
	Von: Trevor Cook [mailto:tc...@in...]=20
	Gesendet: Donnerstag, 13. Februar 2003 17:10
	An: Spring Developers (E-mail)
	Betreff: [Springframework-developer] adding eclipse files to cvs
=09
=09

	I hope I'm not being too forward or aggressive in making some =
recommendations for this project.  My experience so far has mainly been =
working solo or in small teams as lead developer, so my experience with =
open source (as a contributor) and large project management is nil.  If =
I'm out to lunch, just let me know.

	I think that the suggestion by "William G. Thompson, Jr." on the Wrox =
board about adding eclipse files is a good one.  It sounds like those so =
far involved (Rod, Yann, and me - not sure what Juergen is using) are =
using eclipse, so adding the few eclipse specific files (.project and =
.classpath) make sense to me.  I would also recommend standarizing on an =
eclipse variable for the one jar we don't distribute (j2ee) as being =
"J2EE_HOME".  Finally, we would need to specify the eclipse output =
folder.  I prefer "target" and eclipse defaults to "build", but I'll use =
whatever the team decides.  To get started though, the files would be as =
follows (subject to any changes recommended by the team):

	.project=20
	<?xml version=3D"1.0" encoding=3D"UTF-8"?>=20
	<projectDescription>=20
	        <name>springframework</name>=20
	        <comment></comment>=20
	        <projects>=20
	        </projects>=20
	        <buildSpec>=20
	                <buildCommand>=20
	                        <name>org.eclipse.jdt.core.javabuilder</name>=20
	                </buildCommand>=20
	        </buildSpec>=20
	        <natures>=20
	                <nature>org.eclipse.jdt.core.javanature</nature>=20
	        </natures>=20
	</projectDescription>=20

	.classpath=20
	<?xml version=3D"1.0" encoding=3D"UTF-8"?>=20
	<classpath>=20
	    <classpathentry kind=3D"src" path=3D"src"/>=20
	    <classpathentry kind=3D"src" path=3D"test"/>=20
	    <classpathentry kind=3D"con" =
path=3D"org.eclipse.jdt.launching.JRE_CONTAINER"/>=20
	    <classpathentry kind=3D"lib" path=3D"lib/clover/clover.jar"/>=20
	    <classpathentry kind=3D"lib" path=3D"lib/easymock/easymock.jar"/>=20
	    <classpathentry kind=3D"lib" path=3D"lib/junit/junit.jar"/>=20
	    <classpathentry kind=3D"lib" =
path=3D"lib/mockobjects/mockobjects-0.07-core.jar"/>=20
	    <classpathentry kind=3D"lib" =
path=3D"lib/velocity/velocity-1.3.jar"/>=20
	    <classpathentry kind=3D"lib" path=3D"lib/log4j-1.2.jar"/>=20
	    <classpathentry kind=3D"lib" =
path=3D"lib/mockobjects/mockobjects-0.07-j1.3-j2ee1.3.jar"/>=20
	    <classpathentry kind=3D"lib" =
path=3D"lib/mockobjects/mockobjects-0.07-jdk1.3.jar"/>=20
	    <classpathentry kind=3D"lib" =
path=3D"lib/velocity/velocity-dep-1.3.jar"/>=20
	    <classpathentry kind=3D"var" path=3D"J2EE_HOME/lib/j2ee.jar"/>=20
	    <classpathentry kind=3D"output" path=3D"target"/>=20
	</classpath>=20

	My other suggestion is partly a question which is adding .cvsignore to =
cvs.  I'm not sure if this is normal/good practice, or just something =
I've been doing.  If we did add it, as a start it would look like:

	junit-reports=20
	.classes=20
	.testclasses=20
	spring-core-0.8.jar=20
	spring-ejbimpl-0.8.jar=20
	spring-jdbc-0.8.jar=20
	spring-web-0.8.jar=20
	target=20

	My last suggestion is actually a response to an email from Rod, which =
I'll quote here to get it out to the team.=20

	>>I'm not sure about mo.whatever: maybe com.interface21.mockobjects=20
	>>would be better--I didn't think very hard about the naming.=20

	I think that "com.interface21.mockobjects" makes a lot more sense. I =
was just recommending mo.xxx to try to match the mo.ejb which already =
existed.  I'll use "com.interface21.mockobjects.jdbc" for the tests I'm =
refactoring.  When the other tests are refactored, we should probably =
move mo.ejb into an equivelent package, and possibly move servletapi as =
well (haven't looked closely enough at those test objects to comment).


	---
	Outgoing mail is certified Virus Free.
	Checked by AVG anti-virus system (http://www.grisoft.com).
	Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/03
	 =20

[Springframework-developer] Coding standards

[Trevor C. <tc...@in...>]

I noticed that coding standards were discussed previously on the Wrox board,
and they were going to be documented.  Are those ready, and if so can they
be published to sourceforge.  Also, are the coding standards such that they
can be entered into eclipse code formatting preferences (to support
right-click Format)?  If so, maybe we should include these settings with the
document to make it easy to setup.  If not, can we document any
incompatabilities (or possibly change the standard so there are no
incompatabilities).  

Personally, I often make rapid changes to the code, run tests to ensure
correctness, right-click Format to pretty them up, and then commit them.  If
this won't work (in other words we need to manually format the code since
right-click Format would mess it up according to our standards) we should
probably document this in the spec as a warning (since most developers I
know use this feature).

Trevor D. Cook

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/03
 

[Springframework-developer] use of FOR UPDATE

[Kopylenko, D. <dko...@ac...>]

Rod and co.,

would you please advise me on how to use Oracle's "FOR UPDATE" clause using
current JDBC framework? The thing is that by default the autoCommit property
of the Connection object is set to true and it causes the Oracle to raise:
"ORA-01002: fetch out of sequence" when trying to issue a "FOR UPDATE"
query. Since only the DataSource is passed all the way to JdbcTemplate,
there is now way to control it like this conn.setAutoCommit(false) outside
JdbcTemplate. Is there any way to configure the autoCommint attribute to
false in JBoss' xxx-service.xml for the particular connection pool or any
other suggestions.
I would appreciate some help.
Dmitriy.

 

[Springframework-developer] adding eclipse files to cvs

[Trevor C. <tc...@in...>]

I hope I'm not being too forward or aggressive in making some
recommendations for this project.  My experience so far has mainly been
working solo or in small teams as lead developer, so my experience with open
source (as a contributor) and large project management is nil.  If I'm out
to lunch, just let me know.

I think that the suggestion by "William G. Thompson, Jr." on the Wrox board
about adding eclipse files is a good one.  It sounds like those so far
involved (Rod, Yann, and me - not sure what Juergen is using) are using
eclipse, so adding the few eclipse specific files (.project and .classpath)
make sense to me.  I would also recommend standarizing on an eclipse
variable for the one jar we don't distribute (j2ee) as being "J2EE_HOME".
Finally, we would need to specify the eclipse output folder.  I prefer
"target" and eclipse defaults to "build", but I'll use whatever the team
decides.  To get started though, the files would be as follows (subject to
any changes recommended by the team):

.project
<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
	<name>springframework</name>
	<comment></comment>
	<projects>
	</projects>
	<buildSpec>
		<buildCommand>
			<name>org.eclipse.jdt.core.javabuilder</name>
		</buildCommand>
	</buildSpec>
	<natures>
		<nature>org.eclipse.jdt.core.javanature</nature>
	</natures>
</projectDescription>

.classpath
<?xml version="1.0" encoding="UTF-8"?>
<classpath>
    <classpathentry kind="src" path="src"/>
    <classpathentry kind="src" path="test"/>
    <classpathentry kind="con"
path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
    <classpathentry kind="lib" path="lib/clover/clover.jar"/>
    <classpathentry kind="lib" path="lib/easymock/easymock.jar"/>
    <classpathentry kind="lib" path="lib/junit/junit.jar"/>
    <classpathentry kind="lib"
path="lib/mockobjects/mockobjects-0.07-core.jar"/>
    <classpathentry kind="lib" path="lib/velocity/velocity-1.3.jar"/>
    <classpathentry kind="lib" path="lib/log4j-1.2.jar"/>
    <classpathentry kind="lib"
path="lib/mockobjects/mockobjects-0.07-j1.3-j2ee1.3.jar"/>
    <classpathentry kind="lib"
path="lib/mockobjects/mockobjects-0.07-jdk1.3.jar"/>
    <classpathentry kind="lib" path="lib/velocity/velocity-dep-1.3.jar"/>
    <classpathentry kind="var" path="J2EE_HOME/lib/j2ee.jar"/>
    <classpathentry kind="output" path="target"/>
</classpath>

My other suggestion is partly a question which is adding .cvsignore to cvs.
I'm not sure if this is normal/good practice, or just something I've been
doing.  If we did add it, as a start it would look like:

junit-reports
.classes
.testclasses
spring-core-0.8.jar
spring-ejbimpl-0.8.jar
spring-jdbc-0.8.jar
spring-web-0.8.jar
target

My last suggestion is actually a response to an email from Rod, which I'll
quote here to get it out to the team.

>>I'm not sure about mo.whatever: maybe com.interface21.mockobjects
>>would be better--I didn't think very hard about the naming.

I think that "com.interface21.mockobjects" makes a lot more sense. I was
just recommending mo.xxx to try to match the mo.ejb which already existed.
I'll use "com.interface21.mockobjects.jdbc" for the tests I'm refactoring.
When the other tests are refactored, we should probably move mo.ejb into an
equivelent package, and possibly move servletapi as well (haven't looked
closely enough at those test objects to comment).


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/03
 

[Springframework-developer] AOP Code

[Christopher A. <ca...@pa...>]

Rod,

I have been reviewing your AOP code and wonder if you could provide a brief
explanation on how it works. I'm not sure when the interceptors get invoked
and how you can control their timing. Also are the interceptors the
mechanism to add, "cross cutting functionality"? Please explain.

Regards,

Chris Axe