springframework-developer

Re: [Springframework-developer] Release schedule

[Paul F. <pau...@ho...>]

Juergen/group

Wow - I am very impressed with the amount of work you are contributing
towards the Spring framework - if only I could find the time I would love to
be more active.

Personally, I think it would help if tasks were cleary defined and assigned
to individuals - I am unsure what areas need looking at and am conscience
that I may be duplicating effort if I just dive in.  I know that tasks are
discussed within this list but this should be documented  - or does this go
against the open source idealogy.

BTW I have attached a struts plugin that I have written and am using with
success - it needs reviewing.

Here is a brief description of its use - I assume struts familarity:

A Struts PlugIn can be used to provide close integration with Spring's bean
based infrastructure.  The root
com.interface21.web.context.WebApplicationContext object, which defines
JavaBeans and their relationships ,can be added to a web application's
ServletContext by this PlugIn, as an alternative to using the
ContextLoaderServlet.

PlugIn modules can be configured using the <plug-in> element in the
struts-config.xml file.  Classes that implement the PlugIn interface must
have a zero-argument constructor, configuration is performed by providing
standard JavaBeans property setter methods.

The PlugIn requires a single configuration parameter to be provided in the
deployment descriptor, contextClass. This parameter is the class name of the
WebApplicationContext implementation to provide a context for this
application, in this case XmlWebApplicationContext.   The PlugIn merely
instantiates the class and provides it with the current ServletContext
object.

<plug-in className="com.phoenix.web.context.ContextLoaderPlugin">
    <set-property property="contextClass"
value="com.interface21.web.context.support.XmlWebApplicationContext"/>
</plug-in>

The WebApplicationContext requires a configUrl to be set in the web.xml
file.  This is the URL to the configuration file that defines the business
objects and their relationships.  These are exposed as JavaBeans to classes
in the web application framework, servlet filters and JSP custom tags.

<context-param>
    <param-name>configUrl</param-name>
    <param-value>/WEB-INF/applicationContext.xml</param-value>
</context-param>

Struts Actions can access these business objects by looking up the
WebApplicationContext in the ServletContext.

Note:  Certain bean names have special significance and one must be provided
in the configuration file, "messageSource".  This defines an
internationalizable repository for errors and other messages.  Even if the
application uses the Struts resource bundle, this is still required, along
with the messages.properties file in /WEB-INF/classes.

<bean name="messageSource"
class="com.interface21.context.support.ResourceBundleMessageSource">
    <property name="basename">messages</property>
</bean>


----- Original Message -----
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Thursday, March 06, 2003 10:18 AM
Subject: [Springframework-developer] Release schedule


Hi committers,

We should try to approach a 0.8 release ASAP, as the lack of a formal
distribution definitely hinders Spring adopting. IMO we should aim at end of
March.

Unfortunately, the lack of documentation is a major issue: Currently, a
potential user should have both Rod's book and the framework sources. I
consider polishing JavaDoc comments and including generated JavaDoc a must,
already for 0.8. Separate online documentation will be a must for 1.0, but
not earlier, I guess. Any volunteers for either?

The further schedule will probably consist of 0.9 at end of April and 1.0
around June. Of course, the actual dates will be determined by Spring's
quality and stability, not by a deadline. Nevertheless, I have the urge to
proceed release-oriented.

IMHO, we are easily feature-complete for 0.8 now, as multipart request
handling can also wait until 0.9. Beyond that, we should think about further
must-haves for 1.0. The Struts plugin comes to my mind, for example, and
better test coverage and homogeneous code style. Beyond the framework
itself, we will need example apps, and a nice little website with some sort
of "project identity".

What do you think?

Regards,
Juergen


DI Jürgen Höller
Senior System Architect
__________________________________

werk3ATS - division systementwicklung
part of werk3AT internetmedien oeg

europaplatz 4
A - 4020 linz

t.  +43 (0) 732 71 65 29
f.  +43 (0) 732 71 65 29 3
jue...@we...
www.werk3at.com
__________________________________
werk3ATS - WIR ENTWICKELN ERFOLG


-------------------------------------------------------
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

RE: [Springframework-developer] Release schedule

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

Paul,

I must admit I haven't thought about the internals of Struts support =
earlier. But now that I've reviewed your plugin, I am aware of how easy =
this actually is. We just need to initialize the ApplicationContext and =
expose it to the ServletContext, and off we go writing Struts actions =
that use Spring beans via retrieving the ApplicationContext from the =
ServletContext.

Facing this simple way, I wonder if we need explicit Struts support at =
all, at least in the technical sense. Isn't setting up a standard =
ContextLoaderServlet or ContextLoaderListener in web.xml just as easy as =
registering a Struts-specific plugin in struts-config.xml? The Struts =
plugin doesn't seem to add any specific handling, as the ServletContext =
contained by the ActionServlet instance should be equal to the standard =
ServletContext of the web application.

The only obvious difference seems to be the attribute name, which is not =
meant for manual usage in standard Spring. But Struts actions could =
simply retrieve the current ApplicationContext via =
com.interface21.web.context.support.WebApplicationContextUtils.getWebAppl=
icationContext(ServletContext), using Spring's standard attribute name =
underneath.

So, should we adopt my proposed pattern? Its major advantage is its =
simplicity - it does not need any specific Struts support at all, =
especially no binary dependency on Struts classes within Spring. And it =
should work nicely, at the same level of convenience as the Struts =
plugin. Is there any added value of the latter that I am missing?

Finally, with Spring's newly refactored ContextLoader class, a minimal =
Plugin implementation should do the job now, analogous to the =
ContextLoaderListener implementation - if one really needs configuration =
via struts-config.xml. Instead of replicating the initialization code, =
the following should be enough:

  public void init(ActionServlet servlet, ModuleConfig config) throws =
ServletException {
    ContextLoader.initContext(servlet.getServletContext(), =
contextClass);
  }

But still, I consider configuration via web.xml equally simple.

Regards,
Juergen


> -----Original Message-----
> From: Paul Feaviour [mailto:pau...@ho...]=20
> Sent: Thursday, March 06, 2003 12:06 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Release schedule
>=20
>=20
> Juergen/group
>=20
> Wow - I am very impressed with the amount of work you are=20
> contributing towards the Spring framework - if only I could=20
> find the time I would love to be more active.
>=20
> Personally, I think it would help if tasks were cleary=20
> defined and assigned to individuals - I am unsure what areas=20
> need looking at and am conscience that I may be duplicating=20
> effort if I just dive in.  I know that tasks are discussed=20
> within this list but this should be documented  - or does=20
> this go against the open source idealogy.
>=20
> BTW I have attached a struts plugin that I have written and=20
> am using with success - it needs reviewing.
>=20
> Here is a brief description of its use - I assume struts familarity:
>=20
> A Struts PlugIn can be used to provide close integration with=20
> Spring's bean based infrastructure.  The root=20
> com.interface21.web.context.WebApplicationContext object,=20
> which defines JavaBeans and their relationships ,can be added=20
> to a web application's ServletContext by this PlugIn, as an=20
> alternative to using the ContextLoaderServlet.
>=20
> PlugIn modules can be configured using the <plug-in> element=20
> in the struts-config.xml file.  Classes that implement the=20
> PlugIn interface must have a zero-argument constructor,=20
> configuration is performed by providing standard JavaBeans=20
> property setter methods.
>=20
> The PlugIn requires a single configuration parameter to be=20
> provided in the deployment descriptor, contextClass. This=20
> parameter is the class name of the WebApplicationContext=20
> implementation to provide a context for this
> application, in this case XmlWebApplicationContext.   The=20
> PlugIn merely
> instantiates the class and provides it with the current=20
> ServletContext object.
>=20
> <plug-in className=3D"com.phoenix.web.context.ContextLoaderPlugin">
>     <set-property property=3D"contextClass"=20
> =
value=3D"com.interface21.web.context.support.XmlWebApplicationContext"/>
> </plug-in>
>=20
> The WebApplicationContext requires a configUrl to be set in=20
> the web.xml file.  This is the URL to the configuration file=20
> that defines the business objects and their relationships. =20
> These are exposed as JavaBeans to classes in the web=20
> application framework, servlet filters and JSP custom tags.
>=20
> <context-param>
>     <param-name>configUrl</param-name>
>     <param-value>/WEB-INF/applicationContext.xml</param-value>
> </context-param>
>=20
> Struts Actions can access these business objects by looking=20
> up the WebApplicationContext in the ServletContext.
>=20
> Note:  Certain bean names have special significance and one=20
> must be provided in the configuration file, "messageSource". =20
> This defines an internationalizable repository for errors and=20
> other messages.  Even if the application uses the Struts=20
> resource bundle, this is still required, along with the=20
> messages.properties file in /WEB-INF/classes.
>=20
> <bean name=3D"messageSource"=20
> class=3D"com.interface21.context.support.ResourceBundleMessageSource">
>     <property name=3D"basename">messages</property>
> </bean>
>=20
>=20
> ----- Original Message -----
> From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
> To: <spr...@li...>
> Sent: Thursday, March 06, 2003 10:18 AM
> Subject: [Springframework-developer] Release schedule
>=20
>=20
> Hi committers,
>=20
> We should try to approach a 0.8 release ASAP, as the lack of=20
> a formal distribution definitely hinders Spring adopting. IMO=20
> we should aim at end of March.
>=20
> Unfortunately, the lack of documentation is a major issue:=20
> Currently, a potential user should have both Rod's book and=20
> the framework sources. I consider polishing JavaDoc comments=20
> and including generated JavaDoc a must, already for 0.8.=20
> Separate online documentation will be a must for 1.0, but not=20
> earlier, I guess. Any volunteers for either?
>=20
> The further schedule will probably consist of 0.9 at end of=20
> April and 1.0 around June. Of course, the actual dates will=20
> be determined by Spring's quality and stability, not by a=20
> deadline. Nevertheless, I have the urge to proceed release-oriented.
>=20
> IMHO, we are easily feature-complete for 0.8 now, as=20
> multipart request handling can also wait until 0.9. Beyond=20
> that, we should think about further must-haves for 1.0. The=20
> Struts plugin comes to my mind, for example, and better test=20
> coverage and homogeneous code style. Beyond the framework=20
> itself, we will need example apps, and a nice little website=20
> with some sort of "project identity".
>=20
> What do you think?
>=20
> Regards,
> Juergen
>=20
>=20
> DI J=FCrgen H=F6ller
> Senior System Architect
> __________________________________
>=20
> werk3ATS - division systementwicklung
> part of werk3AT internetmedien oeg
>=20
> europaplatz 4
> A - 4020 linz
>=20
> t.  +43 (0) 732 71 65 29
> f.  +43 (0) 732 71 65 29 3
> jue...@we...
> www.werk3at.com
> __________________________________
> werk3ATS - WIR ENTWICKELN ERFOLG
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of=20
> TotalView, The debugger for complex code. Debugging C/C++=20
> programs can leave you feeling lost and disoriented.=20
> TotalView can help you find your way. Available on major UNIX=20
> and Linux platforms. Try it free. www.etnus.com=20
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20

RE: [Springframework-developer] Release schedule

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

Schedule looks great to me.

Also, I was out-of-town for the past week with 2 deaths in the family.  =
I
will have the jdbc tests I promised committed by the end of the =
weekend.
Sorry for the delay( especially to Thomas).  Also, this new test =
coverage
puts the jdbc objects package over 85%.

Finally, I agree with Juergen.  I've found it very easy to hook up =
Spring to
various projects, and Struts appears to be similiarly easy.  Rather =
than
having native struts support inside Spring, it would propbably be =
better to
simply maintain a how-to tutorial on integrating Spring with Struts.  =
It
would accomplish the same thing without affecting the code base and
introducing dependancies.

Trevor D. Cook


-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: March 6, 2003 11:11 PM
To: j=FCrgen h=F6ller [werk3AT];
spr...@li...
Subject: Re: [Springframework-developer] Release schedule


I agree: I think a release schedule is very important. Of course it's =
hard
to commit to deadlines for open source projects, but if we want people =
to
start using Spring we need to give them a roadmap, and a download ASAP.

I think the API is unlikely to change much from now to 1.0, although =
some
internals might change a bit (e.g. JDBC changes), so I think we're =
nearly
ready for 0.8 now.

I pretty much agree with Juergen re timescales.

0.8: download, polished JavaDoc, with better package.html files. I've =
been
using EclipseUML (modelling plugin for Eclipse) and I'm impressed. I =
might
try to add some class diagrams to package.html files. How about we say =
March
23 for this (2 weeks + a weekend), as I think we're fairly close and =
there's
huge value in having a download.
We will need to coordinate tasks closely. I'm not sure how best to do =
this.
Yann, you mentioned SourceForge facilities: can you please help suggest =
how
best to use them, as I'm unsure.
-- Thomas, were are with we your JDBC changes? This is perhaps the =
biggest
area of change nearly ready to go --

0.9: Whatever we have one month later (late April). A progress release.
Would be good to get Struts plugin in here, although maybe we could =
even do
that for 0.8.

1.0 beta: Mid May. Should be exactly what we hope to have in 1.0, =
possibly
with incomplete docs.

1.0: Late May. I'm talking at TSS symposium in late June and I think it
would be great if we were at 1.0 by then, as I'd like to mention =
Spring. We
need:
- tutorial
- sample app (yes, maybe the first one could be based on the book's)
- overview docs of areas such as JDBC/Web
- website as Juergen says
- significantly improved test coverage. We're currently at 44%: I would =
like
to see >=3D 60% by 1.0, and hopefully a steady increase up till then.

No AOP in any of these releases. I'm hoping to knock that into shape =
over
the next 3 weeks, but anyone who's interested can check out CVS.

Outstanding issues:
- Packaging, regarding the old EJB/WAR class loader issues when =
deploying
WAR+EJB EARs. Hopefully the present packaging will work fine for 0.8. =
Things
may get tougher with Thomas's new JDBC stuff.

Regards,
Rod

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Thursday, March 06, 2003 10:18 AM
Subject: [Springframework-developer] Release schedule


Hi committers,

We should try to approach a 0.8 release ASAP, as the lack of a formal
distribution definitely hinders Spring adopting. IMO we should aim at =
end of
March.

Unfortunately, the lack of documentation is a major issue: Currently, a
potential user should have both Rod's book and the framework sources. I
consider polishing JavaDoc comments and including generated JavaDoc a =
must,
already for 0.8. Separate online documentation will be a must for 1.0, =
but
not earlier, I guess. Any volunteers for either?

The further schedule will probably consist of 0.9 at end of April and =
1.0
around June. Of course, the actual dates will be determined by Spring's
quality and stability, not by a deadline. Nevertheless, I have the urge =
to
proceed release-oriented.

IMHO, we are easily feature-complete for 0.8 now, as multipart request
handling can also wait until 0.9. Beyond that, we should think about =
further
must-haves for 1.0. The Struts plugin comes to my mind, for example, =
and
better test coverage and homogeneous code style. Beyond the framework
itself, we will need example apps, and a nice little website with some =
sort
of "project identity".

What do you think?

Regards,
Juergen


DI J=FCrgen H=F6ller
Senior System Architect
__________________________________

werk3ATS - division systementwicklung
part of werk3AT internetmedien oeg

europaplatz 4
A - 4020 linz

t.  +43 (0) 732 71 65 29
f.  +43 (0) 732 71 65 29 3
jue...@we...
www.werk3at.com
__________________________________
werk3ATS - WIR ENTWICKELN ERFOLG


-------------------------------------------------------
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




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The =
debugger=20
for complex code. Debugging C/C++ programs can leave you feeling lost =
and=20
disoriented. TotalView can help you find your way. Available on major =
UNIX=20
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03
=20

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03
=20

Re: [Springframework-developer] Release schedule

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

Trevor

>  I was out-of-town for the past week with 2 deaths in the family.

Sorry to hear this.

> I will have the jdbc tests I promised committed by the end of the weekend.
>Sorry for the delay( especially to Thomas).  Also, this new test coverage
>puts the jdbc objects package over 85%.
I've added a couple of methods to JdbcTemplate and two new interfaces,
PreparedStatementSetter and BulkPreparedStatement setter.  The aim is to
provide an easy-to-use API when we don't need to create the PS, just set
values on it.  I did this test-first (as I am doing consistently now), so
test coverage is up marginally.

This coverage on the jdbc.object package is great! Thanks a lot!

<trevor>
Finally, I agree with Juergen.  I've found it very easy to hook up Spring to
various projects, and Struts appears to be similiarly easy.  Rather than
having native struts support inside Spring, it would propbably be better to
simply maintain a how-to tutorial on integrating Spring with Struts.  It
would accomplish the same thing without affecting the code base and
introducing dependancies.
</trevor>

Yes, my first thought was to do exactly as Paul did. (In fact I think I
mention it in the book somewhere.) But the ServletContext does provide
communication.

Despite my low opinion of Struts, I think we have to help users who want to
use Struts + Spring, as many people are committed to Struts and still need
many of the services Spring provides.

Paul, what do you think?

Regards,
Rod

Re: [Springframework-developer] Release schedule

[Paul F. <pau...@ho...>]

Guys,

I would have to Juergen's analysis of the Struts plugin that I submitted -
it does seem superfluous.  The plugin increases the number of 3rd party
dependencies and this seems pointless if we can achieve the same end by
using ServletContext.  I wrote it purely because my current project already
uses Struts - not my decision - and was pointed in the direction of the
plugin via the book.  I never thought of the alternatives, plus I was keen
to submit something and become part of the group.

I have a question regarding data access that I'd appreciate some help on: I
need to write to and retrieve data from a clob - what would you say my best
approach is, and can I use the data access framework?

Regards,

Paul

----- Original Message -----
From: "Rod Johnson" <rod...@in...>
To: "Trevor Cook" <tc...@in...>; "Spring Developers
(E-mail)" <spr...@li...>
Sent: Saturday, March 08, 2003 6:01 AM
Subject: Re: [Springframework-developer] Release schedule


> Trevor
>
> >  I was out-of-town for the past week with 2 deaths in the family.
>
> Sorry to hear this.
>
> > I will have the jdbc tests I promised committed by the end of the
weekend.
> >Sorry for the delay( especially to Thomas).  Also, this new test coverage
> >puts the jdbc objects package over 85%.
> I've added a couple of methods to JdbcTemplate and two new interfaces,
> PreparedStatementSetter and BulkPreparedStatement setter.  The aim is to
> provide an easy-to-use API when we don't need to create the PS, just set
> values on it.  I did this test-first (as I am doing consistently now), so
> test coverage is up marginally.
>
> This coverage on the jdbc.object package is great! Thanks a lot!
>
> <trevor>
> Finally, I agree with Juergen.  I've found it very easy to hook up Spring
to
> various projects, and Struts appears to be similiarly easy.  Rather than
> having native struts support inside Spring, it would propbably be better
to
> simply maintain a how-to tutorial on integrating Spring with Struts.  It
> would accomplish the same thing without affecting the code base and
> introducing dependancies.
> </trevor>
>
> Yes, my first thought was to do exactly as Paul did. (In fact I think I
> mention it in the book somewhere.) But the ServletContext does provide
> communication.
>
> Despite my low opinion of Struts, I think we have to help users who want
to
> use Struts + Spring, as many people are committed to Struts and still need
> many of the services Spring provides.
>
> Paul, what do you think?
>
> Regards,
> Rod
>
>
>
> -------------------------------------------------------
> 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
>

Re: [Springframework-developer] Release schedule

[Thomas R. <tri...@tr...>]

Hi,

> -- Thomas, were are with we your JDBC changes? This is perhaps the biggest
> area of change nearly ready to go --
> -- 

I have just committed my changes to some of the JDBC classes.  Most of
my changes relate to the SQLExceptionTranslater functionality.  I
created an SQLExceptionTranslaterFactory that loads error codes defined
in a file named 'sql-error-codes.xml'.  This is done on startup, and
whenever a new JdbcTemplate class is created it will get the
SQLExceptionTranslater from this factory file.  The factory will check
to see what database is used and create a new SQLExceptionTranslater
populated with the corresponding error codes for translation.  If the
database does not have a defined set of error codes, then we will fall
back on using a SQLStateSQLExeptionTranslater.

The 'sql-error-codes.xml' is loaded from the classpath with the
XmlBeanFactory.  For a Tomcat web app I put 'sql-error-codes.xml' in the
WEB-INF\classes directory.  In general, I tend to put this file in the
same directory where I put the log4j.properties file.  To use this
functionality we need the XmlBeans classes as well as the core and jdbc
classes.  I added a task 'xmlbean' to the build script to build this
extra jar file.  I have the following jar files in my WEB-INF\lib
directory:  spring-core-0.8.jar, spring-jdbc-0.8.jar and
spring-xmlbean-0.8.jar.

I have tested and included a few codes for Oracle 9i, MySQL 4.0,
PostgreSQL 7.3, Microsoft SQL Server 2000 and IBM DB2 8.1.  Postgres
does not use any error codes or sql state currently, so we will have to
come up with an alternative strategy if we want some translations.

Let me know if there are any issues.


Thomas

RE: [Springframework-developer] Release schedule

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

Hi Paul,

Thanks for the contribution, anyway! Every feedback is helpful, be it =
bug reports, enhancement requests, or code contributions.

I guess that a lot of people will face your situation, i.e. having to =
use Struts due to project or even company standards. So straightforward =
integration between Struts and Spring is definitely a must. If we can =
achieve this so easily via ContextLoaderServlet/Listener and =
WebApplicationContextUtils, using a ServletContext attribute underneath, =
then this is really good news.

BTW, you are already part of the group! ;-) Seriously, if you want to =
take part, then try the current snapshot and report your experiences. Go =
through the API, or even some implementation, and note any obvious =
shortcomings. Within a short time, we need to write or review =
documentation for the website. There are so many ways to contribute!

Regards,
Juergen


> -----Original Message-----
> From: Paul Feaviour [mailto:pau...@ho...]=20
> Sent: Monday, March 10, 2003 3:28 PM
> To: Rod Johnson; Spring Developers (E-mail)
> Subject: Re: [Springframework-developer] Release schedule
>=20
>=20
> Guys,
>=20
> I would have to Juergen's analysis of the Struts plugin that=20
> I submitted - it does seem superfluous.  The plugin increases=20
> the number of 3rd party dependencies and this seems pointless=20
> if we can achieve the same end by using ServletContext.  I=20
> wrote it purely because my current project already uses=20
> Struts - not my decision - and was pointed in the direction=20
> of the plugin via the book.  I never thought of the=20
> alternatives, plus I was keen to submit something and become=20
> part of the group.
>=20
> I have a question regarding data access that I'd appreciate=20
> some help on: I need to write to and retrieve data from a=20
> clob - what would you say my best approach is, and can I use=20
> the data access framework?
>=20
> Regards,
>=20
> Paul
>=20
> ----- Original Message -----
> From: "Rod Johnson" <rod...@in...>
> To: "Trevor Cook" <tc...@in...>; "Spring=20
> Developers (E-mail)" <spr...@li...>
> Sent: Saturday, March 08, 2003 6:01 AM
> Subject: Re: [Springframework-developer] Release schedule
>=20
>=20
> > Trevor
> >
> > >  I was out-of-town for the past week with 2 deaths in the family.
> >
> > Sorry to hear this.
> >
> > > I will have the jdbc tests I promised committed by the end of the
> weekend.
> > >Sorry for the delay( especially to Thomas).  Also, this new test=20
> > >coverage puts the jdbc objects package over 85%.
> > I've added a couple of methods to JdbcTemplate and two new=20
> interfaces,=20
> > PreparedStatementSetter and BulkPreparedStatement setter. =20
> The aim is=20
> > to provide an easy-to-use API when we don't need to create the PS,=20
> > just set values on it.  I did this test-first (as I am doing=20
> > consistently now), so test coverage is up marginally.
> >
> > This coverage on the jdbc.object package is great! Thanks a lot!
> >
> > <trevor>
> > Finally, I agree with Juergen.  I've found it very easy to hook up=20
> > Spring
> to
> > various projects, and Struts appears to be similiarly easy.  Rather=20
> > than having native struts support inside Spring, it would=20
> propbably be=20
> > better
> to
> > simply maintain a how-to tutorial on integrating Spring=20
> with Struts. =20
> > It would accomplish the same thing without affecting the=20
> code base and=20
> > introducing dependancies. </trevor>
> >
> > Yes, my first thought was to do exactly as Paul did. (In=20
> fact I think=20
> > I mention it in the book somewhere.) But the ServletContext does=20
> > provide communication.
> >
> > Despite my low opinion of Struts, I think we have to help users who=20
> > want
> to
> > use Struts + Spring, as many people are committed to Struts=20
> and still=20
> > need many of the services Spring provides.
> >
> > Paul, what do you think?
> >
> > Regards,
> > Rod
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Etnus, makers of TotalView, The
> debugger
> > for complex code. Debugging C/C++ programs can leave you=20
> feeling lost=20
> > and disoriented. TotalView can help you find your way. Available on=20
> > major UNIX and Linux platforms. Try it free. www.etnus.com=20
> > _______________________________________________
> > Springframework-developer mailing list=20
> > Spr...@li...
> >=20
> https://lists.sourceforge.net/lists/listinfo/s> =
pringframework-developer
> >
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf=20
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20