springframework-developer — Spring Framework developers list

Re: [Springframework-developer] SqlUpdate and insert functionality

[Isabelle M. <isa...@me...>]

Hi Ken,

Looking at the mail you sent me this morning (included below), in table visits, column id is auto-increment, and it shouldn't be. Neither should the sequence column be, which is correct in the code below.

The definition of column id should be "int not null primary key"

Does this help?

Isabelle

On Fri, May 23, 2003 at 09:04:01AM -0500, Ken Krebs wrote:
> Isabelle,
> 
> My key column isn't auto-incremented, only the actual id column is.
> 
> My latest code snapshot is attached.
> 
> Ken
> 
> 
> Isabelle Muszynski wrote:
> 
> >Hi Ken,
> >
> >Your key column should NOT be auto-increment.
> >
> >If that doesn't solve the problem, let me know, and pls attach the code so 
> >I don't have top type it over. Will look at it tonight or tomorrow. I'll 
> >also look into the strange log output, probably a stupid booboo.
> >
> >Isabelle
> >
> >On Thu, May 22, 2003 at 11:25:08PM -0500, Ken Krebs wrote:
> > 
> >
> >>Hi Isabelle,
> >>
> >>I have a problem using the following petclinic class that inserts a new 
> >>visit into the DB :
> >>
> >>  class NewVisit extends SqlUpdate {
> >>     
> >>      public NewVisit(DataSource ds) {
> >>          super(ds, "INSERT INTO visits VALUES(?,?,?,?)");
> >>          declareParameter(new SqlParameter(Types.INTEGER));
> >>          declareParameter(new SqlParameter(Types.INTEGER));
> >>          declareParameter(new SqlParameter(Types.DATE));
> >>          declareParameter(new SqlParameter(Types.VARCHAR));
> >>          compile();
> >>      }
> >>     
> >>      public int insert(Visit visit) {
> >>          KeyBinder keybinder = new KeyBinder() {
> >>              public void bind(PreparedStatement ps, Object obj) 
> >>throws SQLException {
> >>                  ps.setObject(1, obj);
> >>              }
> >>          };
> >>         
> >>          MySQLMaxValueIncrementer incr = new 
> >>MySQLMaxValueIncrementer(getDataSource(), "visits_seq", "seq", 1);
> >>         
> >>          logger.info("Visit petId = " + visit.getPetId());
> >>         
> >>          Object[] objs = new Object[] {
> >>              null,
> >>              new Integer(visit.getPetId()),
> >>              visit.getVisitDate(),
> >>              visit.getDescription()
> >>          };
> >>         
> >>          JdbcTemplate.InsertRetval retVal = update(objs, keybinder, 
> >>incr, Integer.class);
> >>          visit.setId(((Integer) retVal.getKey()).intValue());
> >>         
> >>          logger.info("Visit id = " + visit.getId() + "   petId = " + 
> >>visit.getPetId());
> >>         
> >>          return retVal.getRowsAffected();
> >>      }
> >>     
> >>  }
> >>
> >>My table definitions for visits and its sequencer are :
> >>
> >>CREATE TABLE visits (
> >>id INT(4) UNSIGNED NOT NULL AUTO_INCREMENT,
> >>pet_id INT(4) UNSIGNED NOT NULL REFERENCES pets(id),
> >>visit_date DATE,
> >>description VARCHAR(255),
> >>PRIMARY KEY(id),
> >>INDEX(pet_id)
> >>);
> >>INSERT INTO visits VALUES (1, 7, '1996-03-04', 'rabies shot');
> >>INSERT INTO visits VALUES (NULL, 8, '1996-03-04', 'rabies shot');
> >>INSERT INTO visits VALUES (NULL, 8, '1996-06-04', 'neutered');
> >>INSERT INTO visits VALUES (NULL, 7, '1996-09-04', 'spayed');
> >>
> >>CREATE TABLE visits_seq (
> >>seq INT(4) UNSIGNED NOT NULL
> >>);
> >>INSERT INTO visits_seq VALUES (5);
> >>
> >>
> >>The data is written correctly to the DB using the auto-incremented 
> >>visit_id. The problem is that the getKey() function of the 
> >>returned InsertRetval returns 0, not the id that was used for the 
> >>insert. I wanted to use the value to update my cache directly without 
> >>having to requery the DB for all this pet's visits. I am working around 
> >>it by doing just that.
> >>
> >>
> >>I include below a relevant snippet from the INFO log:
> >>
> >>2003-05-22 22:53:37,966 INFO [petclinic.support.ClinicImpl$NewVisit] - 
> >><Compiled OK>
> >>2003-05-22 22:53:37,996 INFO [petclinic.support.ClinicImpl$NewVisit] - 
> >><Visit petId = 7>
> >>2003-05-22 22:53:38,006 INFO [com.interface21.jdbc.object.SqlUpdate] - 
> >><Compiled OK>
> >>2003-05-22 22:53:38,016 INFO [com.interface21.jdbc.core.JdbcTemplate] - 
> >><JDBCTemplate: update affected 1 rows>
> >>2003-05-22 22:53:38,016 INFO [com.interface21.jdbc.object.SqlUpdate] - 
> >><1 rows affected by SQL update [update visits_seq set seq = 
> >>last_insert_id(seq + 1)]>
> >>2003-05-22 22:53:38,026 INFO [com.interface21.jdbc.object.SqlFunction] - 
> >><Compiled OK>
> >>2003-05-22 22:53:38,036 INFO [com.interface21.jdbc.core.JdbcTemplate] - 
> >><Executing SQL query using PreparedStatement: 
> >>[PreparedStatementCreatorFactory.PreparedStatementCreatorImpl: 
> >>sql={select last_insert_id()}: params={}]>
> >>2003-05-22 22:53:38,036 INFO [com.interface21.jdbc.core.JdbcTemplate] - 
> >><JDBCTemplate: update affected 
> >>com.interface21.jdbc.core.JdbcTemplate$InsertRetval@1ebe3f0 rows>
> >>2003-05-22 22:53:38,036 INFO [petclinic.support.ClinicImpl$NewVisit] - 
> >><Visit id = 0   petId = 7>
> >>
> >>Note that the last line shows the visit_id == 0.
> >>Also note the odd output of the 2nd last line where instead of 
> >>outputting the no. of rows affected it's printing a toString() of the 
> >>InsertRetval !!!???
> >>
> >>
> >>Am I doing something wrong here ?
> >>
> >>
> >>Regards,
> >>
> >>Ken
> >>
> >>
> >>
> >>   
> >>
> >
> > 
> >
> 



-- 
Isabelle Muszynski
Software Engineer
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89
Email: isa...@me...
Website: www.meta-logix.com

RE: [Springframework-developer] Code changes for 0.8?

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

BTW, I've also made AbstractBeanFactory support circular references =
(including proper tests). A bean can now reference another bean that in =
turn references the original one, all via beanRefs. A bean can even =
reference itself now.

Juergen


-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT]=20
Sent: Friday, May 23, 2003 1:40 PM
To: tri...@tr...
Cc: spr...@li...
Subject: RE: [Springframework-developer] Code changes for 0.8?


I've just committed the changes.

There's a DataSourceUtils.getDataSourceFromJndi(jndiName) method again, =
assuming running in a container (i.e. adding the prefix "java:comp/env/" =
if not already contained). An overloaded =
getDataSourceFromJndi(jndiName,inContainer) version allows for control =
of the prefixing.

JndiObjectFactoryBean is now a very simple subclass of =
AbstractJndiLocator, supporting the same properties: jndiTemplate, =
jndiName, inContainer. A DataSource definition can thus look as follows:

	<bean name=3D"dataSource" =
class=3D"com.interface21.jndi.JndiObjectFactoryBean">
		<property name=3D"jndiName">jdbc/myds</property>
	</bean>

The following definition is equivalent:

	<bean name=3D"dataSource" =
class=3D"com.interface21.jndi.JndiObjectFactoryBean">
		<property name=3D"jndiName">java:comp/env/jdbc/myds</property>
	</bean>

Or, when not running in a container (no implicit "java:comp/env/" =
prefix):

	<bean name=3D"dataSource" =
class=3D"com.interface21.jndi.JndiObjectFactoryBean">
		<property name=3D"jndiName">java:/myds</property>
		<property name=3D"inContainer">false</property>
	</bean>

Notice the "jndiName" property, instead of the former =
JndiDataSourceBean's "name".

Regards,
Juergen


-----Original Message-----
From: tri...@tr... [mailto:tri...@tr...]
Sent: Friday, May 23, 2003 1:27 PM
To: j=FCrgen h=F6ller [werk3AT]
Cc: spr...@li...
Subject: RE: [Springframework-developer] Code changes for 0.8?


J=FCrgen,

Yes, that is the scenario.  Obtain the DataSource based on the JNDI name =
and=20
pass it in to the constructor for the JdbcTemplate or a class that =
extends=20
Mapping SqlQuery.

While we are on the subject of JDBC.  Do we really have to require an =
explicit=20
compile for the RdbmsOperation and its subclasses.  Currently we throw =20
InvalidDataAccessApiUsageException when we try to use an operation that =
has=20
not been comiled.  We could just as easily execute the compile() at that =

point, since we know what the problem is. =20

Thomas

> Good point indeed, using Spring JDBC without an ApplicationContext. =
I'll
> reintroduce a simple version of it, using a plain JndiTemplate. =
Sometimes I'm
> a little over-eager in terms of simplification, sorry :-)
>=20
> I assume that the typical scenario for this is somewhat like the =
following:
>=20
> 	DataSource ds =3D DataSourceUtils.getDataSourceFromJndi("jdbc/cbx");
> 	JdbcTemplate jt =3D new JdbcTemplate(ds);
> 	jt.<doSomething>;
>=20
> Would that be enough? I'm not keen on introducing an additional =
JdbcTemplate
> constructor with a DataSource NAME. The retrieved DataSource will =
typically
> be kept somewhere anyway.
>=20
> I'm also gonna make JndiObjectFactoryBean extend AbstractJndiLocator, =
for
> maximum code reuse. We'll also have AbstractJndiLocator's =
"inContainer"
> property then, to be able to control "java:comp/env" prefixing
> (inContainer=3Dfalse means plain JNDI name, the default =
inContainer=3Dtrue means
> prefix "java:comp/env" if not already contained).
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...]
> Sent: Friday, May 23, 2003 8:36 AM
> To: tri...@tr...; j=FCrgen h=F6ller [werk3AT]
> Cc: spr...@li...
> Subject: Re: [Springframework-developer] Code changes for 0.8?
>=20
>=20
> I agree with Thomas. Good point. At the moment I know of 2 companies =
using
> Spring JDBC only. If they have to do the JNDI stuff themselves it =
reduces
> the benefit.
>=20
> Rod
>=20
> ----- Original Message -----
> From: <tri...@tr...>
> To: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
> Cc: "Rod Johnson" <rod...@in...>;
> <spr...@li...>
> Sent: Friday, May 23, 2003 2:06 AM
> Subject: RE: [Springframework-developer] Code changes for 0.8?
>=20
>=20
> > J=FCrgen,
> >
> > I'd prefer to keep DataSourceUtils.getDataSourceFromJndi for =
applications
> that
> > only use the JDBC framework.  Maybe we could change the way it does =
the
> lookup
> > to make it similar to the JndiObjectFactoryBean.  What do you all =
think?
> >
> > Thomas
> >
> > > Regarding mock objects, I think that the JNDI mocks do have value =
for
> > > application developers: They can serve as JNDI replacement for
> applications
> > > test environments and standalone applications, running the same =
code and
> > > config files as in the container environment.
> > >
> > > We are using this to be able to reuse the same Hibernate config =
file for
> both
> > > web app and test environments. In the standalone access, we simply =
bind
> a
> > > DriverManagerDataSource to the same JNDI location, with Spring's =
JNDI
> mocks
> > > as infrastructure.
> > >
> > > Other development projects can use this strategy too, and EasyMock =
won't
> help
> > > here. Thus, I'd like the JNDI mocks to stay, but all other mocks =
should
> not
> > > be in our src tree IMO, as they only serve within our test suites.
> > >
> > > Regarding FrameworkServlet's debug support, that were exactly the
> reasons why
> > > I've removed them. It cluttered up the code somewhat, and I don't
> consider it
> > > necessary.
> > >
> > > ---
> > >
> > > I've just added one more refactoring: I've replaced both
> > > JndiDataSourceBean/JndiDataSourceEditor and
> > > JndiSessionFactoryBean/JndiSessionFactoryEditor with generic
> implementations,
> > > namely JndiObjectFactoryBean and JndiObjectEditor. Effectively, =
the
> > > FactoryBeans have just returned Objects, so there's no need for
> specialized
> > > implementations. I've also removed =
DataSourceUtils.getDataSourceFromJndi
> and
> > > SessionFactoryUtils.getSessionFactoryFromJndi, as they aren't
> recommended
> > > anymore. I don't like too many ways to achieve 1 thing.
> > >
> > > One more reason is that the former getDataSourceFromJndi always =
looked
> up the
> > > given name under "java:comp/env", if not contained in the name. =
This is
> too
> > > inflexible: A DataSource might be bound to any JNDI name, in fact.
> > > JndiObjectFactoryBean and JndiObjectEditor need the full JNDI =
name: This
> is
> > > clearer and not much effort.
> > >
> > > So Isabelle and Ken, please use
> com.interface21.jndi.JndiObjectFactoryBean
> > > for DataSource definitions instead of
> > > com.interface21.jdbc.datasource.JndiDataSourceBean! Sorry for the =
late
> > > change, but I think it's worth it.
> > >
> > > Gonna check all this stuff in the next hour...
> > >
> > > Regards,
> > > Juergen
> > >
> > >
> > > -----Original Message-----
> > > From: Rod Johnson [mailto:rod...@in...]
> > > Sent: Thursday, May 22, 2003 6:24 PM
> > > To: j=FCrgen h=F6ller [werk3AT]
> > > Cc: spr...@li...
> > > Subject: Re: [Springframework-developer] Code changes for 0.8?
> > >
> > >
> > > Excellent. Great news on the test coverage! You've been doing good =
work
> > > here.
> > >
> > > I'm glad you've cleaned up the stack traces... There were quite a =
few
> > > repeated stack traces a long time ago, and I got many of them (but
> obviously
> > > not all). I think the volume and quality of stack traces is very
> important.
> > > It's about the only thing that really bugs me with Hibernate 2.0 =
RC1,
> for
> > > example. We may need to consider a consistent approach to logging
> (levels
> > > etc.) for 0.9 or 1.0.
> > >
> > > I imagine removing debug support in framework servlet removed a =
lot of
> code.
> > > I actually eyed it myself with my scalpel in mind recently. It did =
make
> the
> > > code much harder to understand and the fewer lines of code, the =
fewer
> > > potential bugs. Also, I don't think it was documented anywhere, so =
I
> doubt
> > > anyone will miss it too much. (I did use it myself occasionally =
but I'm
> sure
> > > I can live without it.)
> > >
> > > I'm not sure that *any* mock objects should be in the main source =
tree.
> > > Maybe we need a third tree for the mocks and things like
> > > EjbContainerDetective that are handy but not part of the core =
spring
> > > runtime. I don't tend to use our mock objects much anymore, since =
I
> > > discovered the wonder that is EasyMock.
> > >
> > > Code formatting I think is a 0.9 thing. Certainly after we have a =
tagged
> > > stable release. We don't want to delay 0.8 for this.
> > >
> > > I'm away this weekend (bank holiday in the UK), so won't be doing =
any
> work.
> > > Anything I do add to Spring until we go to 0.8 will either be an =
urgent
> bug
> > > fix or simply additional tests.
> > >
> > > Regards,
> > > Rod
> > >
> > > ----- Original Message -----
> > > From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
> > > To: <spr...@li...>
> > > Sent: Thursday, May 22, 2003 4:29 PM
> > > Subject: RE: [Springframework-developer] Code changes for 0.8?
> > >
> > >
> > > Besides having reworked the form controller's handling of =
resubmits,
> I've
> > > also created an extensive test suite for ControllerServlet and =
some web
> > > support classes. We're at overall >64% now!
> > >
> > > Additionally, I've refined some ApplicationContext stuff (moved
> > > OPTIONS_BEAN_NAME from ApplicationContext to =
AbstractApplicationContext
> > > etc), and cleaned the exception handling in the beans package =
(e.g.
> rethrow
> > > BeansException directly when catching Exception instead of =
wrapping it).
> > >
> > > Rethrown exceptions don't get logged anymore, as they are logged =
by the
> > > highest level exception handler anyway (-> no double stack traces =
in the
> > > console). I've also commented out the println(this) on printing a
> rootCause
> > > stack trace: As a root stack trace will always get printed after =
the
> > > exception's message, those lines have only added redundant =
information,
> > > cluttering the console.
> > >
> > > I've removed FrameworkServlet's debug support, I don't see any =
real use
> case
> > > for it. During development, Log4J's debug log is all you need, IMO =
- you
> > > exactly see what handlers/mappings/etc get used, no need for =
binding
> them to
> > > the request.
> > >
> > > I'm also gonna move the web.mock classes back to the test sources, =
as
> they
> > > are pretty rough, and not really meant for usage within =
application
> > > development - in constrast to the JNDI mocks, for example.
> > >
> > > I'll check my stuff in within the next 2 hours. Everybody, please =
test
> the
> > > current framework version in your apps! We should really try to =
release
> a
> > > 0.8 as stable as possible.
> > >
> > > BTW, what's the current status in terms of code beautification =
(Jalopy
> etc)?
> > > We have mixed headers in our files at the moment, and sometimes
> inconsistent
> > > formatting. Do we aim to clean this for 0.8?
> > >
> > > Juergen
> > >
> > >
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: ObjectStore.
> > > If flattening out C++ or Java code to make your application fit in =
a
> > > relational database is painful, don't do it! Check out =
ObjectStore.
> > > Now part of Progress Software. =
http://www.objectstore.net/sourceforge
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > > =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> > >
> >
> >
> >
>=20
>=20
>=20





-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] SqlUpdate and insert functionality

[Isabelle M. <isa...@me...>]

Ken,

I'll have a look at it as soon as I can.

Isabelle

On Fri, May 23, 2003 at 09:04:01AM -0500, Ken Krebs wrote:
> Isabelle,
> 
> My key column isn't auto-incremented, only the actual id column is.
> 
> My latest code snapshot is attached.
> 
> Ken
> 
> 
> Isabelle Muszynski wrote:
> 
> >Hi Ken,
> >
> >Your key column should NOT be auto-increment.
> >
> >If that doesn't solve the problem, let me know, and pls attach the code so 
> >I don't have top type it over. Will look at it tonight or tomorrow. I'll 
> >also look into the strange log output, probably a stupid booboo.
> >
> >Isabelle
> >
> >On Thu, May 22, 2003 at 11:25:08PM -0500, Ken Krebs wrote:
> > 
> >
> >>Hi Isabelle,
> >>
> >>I have a problem using the following petclinic class that inserts a new 
> >>visit into the DB :
> >>
> >>  class NewVisit extends SqlUpdate {
> >>     
> >>      public NewVisit(DataSource ds) {
> >>          super(ds, "INSERT INTO visits VALUES(?,?,?,?)");
> >>          declareParameter(new SqlParameter(Types.INTEGER));
> >>          declareParameter(new SqlParameter(Types.INTEGER));
> >>          declareParameter(new SqlParameter(Types.DATE));
> >>          declareParameter(new SqlParameter(Types.VARCHAR));
> >>          compile();
> >>      }
> >>     
> >>      public int insert(Visit visit) {
> >>          KeyBinder keybinder = new KeyBinder() {
> >>              public void bind(PreparedStatement ps, Object obj) 
> >>throws SQLException {
> >>                  ps.setObject(1, obj);
> >>              }
> >>          };
> >>         
> >>          MySQLMaxValueIncrementer incr = new 
> >>MySQLMaxValueIncrementer(getDataSource(), "visits_seq", "seq", 1);
> >>         
> >>          logger.info("Visit petId = " + visit.getPetId());
> >>         
> >>          Object[] objs = new Object[] {
> >>              null,
> >>              new Integer(visit.getPetId()),
> >>              visit.getVisitDate(),
> >>              visit.getDescription()
> >>          };
> >>         
> >>          JdbcTemplate.InsertRetval retVal = update(objs, keybinder, 
> >>incr, Integer.class);
> >>          visit.setId(((Integer) retVal.getKey()).intValue());
> >>         
> >>          logger.info("Visit id = " + visit.getId() + "   petId = " + 
> >>visit.getPetId());
> >>         
> >>          return retVal.getRowsAffected();
> >>      }
> >>     
> >>  }
> >>
> >>My table definitions for visits and its sequencer are :
> >>
> >>CREATE TABLE visits (
> >>id INT(4) UNSIGNED NOT NULL AUTO_INCREMENT,
> >>pet_id INT(4) UNSIGNED NOT NULL REFERENCES pets(id),
> >>visit_date DATE,
> >>description VARCHAR(255),
> >>PRIMARY KEY(id),
> >>INDEX(pet_id)
> >>);
> >>INSERT INTO visits VALUES (1, 7, '1996-03-04', 'rabies shot');
> >>INSERT INTO visits VALUES (NULL, 8, '1996-03-04', 'rabies shot');
> >>INSERT INTO visits VALUES (NULL, 8, '1996-06-04', 'neutered');
> >>INSERT INTO visits VALUES (NULL, 7, '1996-09-04', 'spayed');
> >>
> >>CREATE TABLE visits_seq (
> >>seq INT(4) UNSIGNED NOT NULL
> >>);
> >>INSERT INTO visits_seq VALUES (5);
> >>
> >>
> >>The data is written correctly to the DB using the auto-incremented 
> >>visit_id. The problem is that the getKey() function of the 
> >>returned InsertRetval returns 0, not the id that was used for the 
> >>insert. I wanted to use the value to update my cache directly without 
> >>having to requery the DB for all this pet's visits. I am working around 
> >>it by doing just that.
> >>
> >>
> >>I include below a relevant snippet from the INFO log:
> >>
> >>2003-05-22 22:53:37,966 INFO [petclinic.support.ClinicImpl$NewVisit] - 
> >><Compiled OK>
> >>2003-05-22 22:53:37,996 INFO [petclinic.support.ClinicImpl$NewVisit] - 
> >><Visit petId = 7>
> >>2003-05-22 22:53:38,006 INFO [com.interface21.jdbc.object.SqlUpdate] - 
> >><Compiled OK>
> >>2003-05-22 22:53:38,016 INFO [com.interface21.jdbc.core.JdbcTemplate] - 
> >><JDBCTemplate: update affected 1 rows>
> >>2003-05-22 22:53:38,016 INFO [com.interface21.jdbc.object.SqlUpdate] - 
> >><1 rows affected by SQL update [update visits_seq set seq = 
> >>last_insert_id(seq + 1)]>
> >>2003-05-22 22:53:38,026 INFO [com.interface21.jdbc.object.SqlFunction] - 
> >><Compiled OK>
> >>2003-05-22 22:53:38,036 INFO [com.interface21.jdbc.core.JdbcTemplate] - 
> >><Executing SQL query using PreparedStatement: 
> >>[PreparedStatementCreatorFactory.PreparedStatementCreatorImpl: 
> >>sql={select last_insert_id()}: params={}]>
> >>2003-05-22 22:53:38,036 INFO [com.interface21.jdbc.core.JdbcTemplate] - 
> >><JDBCTemplate: update affected 
> >>com.interface21.jdbc.core.JdbcTemplate$InsertRetval@1ebe3f0 rows>
> >>2003-05-22 22:53:38,036 INFO [petclinic.support.ClinicImpl$NewVisit] - 
> >><Visit id = 0   petId = 7>
> >>
> >>Note that the last line shows the visit_id == 0.
> >>Also note the odd output of the 2nd last line where instead of 
> >>outputting the no. of rows affected it's printing a toString() of the 
> >>InsertRetval !!!???
> >>
> >>
> >>Am I doing something wrong here ?
> >>
> >>
> >>Regards,
> >>
> >>Ken
> >>
> >>
> >>
> >>   
> >>
> >
> > 
> >
> 



-- 
Isabelle Muszynski
Software Engineer
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89
Email: isa...@me...
Website: www.meta-logix.com

Re: [Springframework-developer] AOP

[Isabelle M. <isa...@me...>]

Dmitriy,

Any chance of you putting together a small demo app during your lunch hour? It would help me (and Ken too I imagine) a great deal :-)

Isabelle

On Fri, May 23, 2003 at 09:47:28AM -0400, Kopylenko, Dmitry wrote:
> Yes, Rutgers University indeed. And for now we're are pretty happy about
> current aop implementation/ease of use.
> 
> Regards,
> Dmitriy.
> 
> -----Original Message-----
> From: rod...@in... [mailto:rod...@in...]
> Sent: Friday, May 23, 2003 09:38 AM
> To: Kopylenko, Dmitry
> Cc: 'spring-dev-list'
> Subject: Re: [Springframework-developer] AOP
> 
> 
> <dmitry>
> Rod, everyone,
> 
> I just want to report that we've started to use AOP framework 
> for one of our
> big web app. projects. 
> 
> Also, here is the list of Spring components/sub-frameworks 
> we're using for
> this project:
> 
> * BeanFactory
> * WebApplicationContext
> * JDBC
> * Tx infrastructure (via declarative aop approach)
> * MVC web framework
> * AOP
> 
> Regards,
> Dmitriy.
> </dmitry>
> 
> Good to hear this: thanks for letting us know. I assume you 
> mean Rutgers University? It would be great to have a list of 
> reference sites before we release 1.0.
> 
> I'm also very excited about AOP. 
> 
> I'm done with changes to AOP stuff for 0.8. Beyond that, I'm 
> keen to progress with better support for transaction and 
> other attributes, including source-level attributes.
> 
> As you progress with your project, it would be great to hear 
> any suggestions you may have about how to improve Spring AOP 
> and make it easier to use. If you're entirely happy, that's 
> useful feedback too!
> 
> Unfortunately it appears that Jon Tirsen (Nanning) won't 
> commit to supporting the AOP Alliance interfaces--which he 
> was heavily involved in defining--until the AOP Alliance "has 
> more momentum." I find this a disappointing copout, but I 
> think the problem is partly that he simply doesn't have time 
> to make the changes, which would impact his use of Nanning in 
> his day job. (It would be hard to justify the cost to his 
> employers.) So unfortunately I don't think the AOP 
> Alliance/interoperability is going to be a reality any time 
> soon. However, it does mean that not only is Spring unique in 
> the AOP space as a complete, integrated, solution (just drop 
> in AOP if you want to use it), but is the only AOP solution I 
> know of that has made a genuine effort to comply with an open 
> API.
> 
> As Spring is the only implementation of the AOP Alliance 
> interfaces for the moment, if anyone has any strong feelings 
> that anything should be changed about those interfaces, this 
> list is probably the best place to discuss it. I'm fairly 
> happy with them for now. I will have to comment them properly 
> before 1.0. And put Javadoc on AOP Alliance SF.
> 
> Regards,
> Rod
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 

-- 
Isabelle Muszynski
Software Engineer
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89
Email: isa...@me...
Website: www.meta-logix.com

RE: [Springframework-developer] AOP

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

Dmitriy,

This is great! I guess you're our biggest early adopter, even bigger =
than werk3AT, as we don't use the AOP support yet ;-) Maybe you'll =
discover some nice generic ideas, e.g. certain AOP interceptors, that we =
can include in the standard framework distribution.

BTW, the AOP package is now used by the remoting and ejb.access proxies, =
and by jdbc.datasource.DataSourceUtils (but only for the =
close-suppressing Connection proxy, used by SingleConnectionDataSource =
when suppressClose=3Dtrue). Remoting is currently only included in =
spring-full anyway. But spring-web requires aop now because of =
ejb.access, and it should contain transaction too. I'll adapt build.xml =
accordingly.

Non-EJB applications that fully leverage Spring will use spring-full =
anyway :-)

Regards,
Juergen


-----Original Message-----
From: Kopylenko, Dmitry [mailto:dko...@ac...]
Sent: Friday, May 23, 2003 2:41 PM
To: 'spring-dev-list'
Subject: [Springframework-developer] AOP


Rod, everyone,

I just want to report that we've started to use AOP framework for one of =
our
big web app. projects. We've successfully implemented and incorporated
aspects like "MailConfirmationInterceptor", "AuditTrailInterceptor",
"DebugInterceptor" to name a few. More to come.... The AOP paradigm is
really going to be big IMO.

Also, here is the list of Spring components/sub-frameworks we're using =
for
this project:

* BeanFactory
* WebApplicationContext
* JDBC
* Tx infrastructure (via declarative aop approach)
* MVC web framework
* AOP

Regards,
Dmitriy.


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] MVC Forms

[Ken K. <kk...@kk...>]

Juergen,

I've changed my code to remove the override of handleInvalidSubmit and 
it works well. I like the way this implemented now as it does make it 
intuitive and easy for developers. This is exactly how it should be: the 
framework takes care of the sticky but common Back button problem 
without the developer having to do extra work while providing the 
capability to explicitly forbid the duplicate submissions fairly easily.

Thanks,

Ken

jürgen höller [werk3AT] wrote:

>Ken,
>
>You're right about the back-and-resubmit-valid-form case. I've changed the default implementation of handleInvalidSubmit to fetch a new backing object and resubmit, instead of showing a new form. So you don't need to override handleInvalidSubmit in your case to get the desired behavior.
>
>Note that duplicate submissions are now possible with the default behavior. If you want to forbid them, you need to explicitly override handleInvalidSubmit and either show a "invalid submit" message or redirect to a new form. Only then will the form object in the session serve as transaction token.
>
>I hope this is now as intuitive as possible (it's also documented in JavaDoc). What do you think?
>
>BTW, I'm gonna check the change in this afternoon, together with some polishing, and full tests for ControllerServlet and co.
>
>Regards,
>Juergen
>
>
>-----Original Message-----
>From: Ken Krebs [mailto:kk...@kk...]
>Sent: Thursday, May 22, 2003 12:00 AM
>To: jürgen höller [werk3AT]
>Cc: spring-dev-list
>Subject: [Springframework-developer] MVC Forms
>
>
>Hi Juergen,
>
>Thanks for your changes, but there is something I still have a question 
>about.
>
>NOTE: In the following, I have removed my IsFormSubmission override and 
>set bindOnNewForm=true.
>
>Consider the scenario in petclinic where a user submits some changes to 
>an owner's info. The owner page is then displayed with the changes and 
>the user notices that a change was forgotten. The user then uses the 
>Back button to go back to the "change owner info"  page, makes another 
>change, and sumits the form. I expected that the change will be 
>validated and submitted and the owner page with the new info would then 
>be displayed. What happens is that 
>AbstractFormController.handleRequestInternal calls handleInvalidSubmit 
>as expected when it can't find the formObject but it then returns 
>without processing the validate/submit logic. The user must then submit 
>the new change a second time to actually get it submitted.
>
>To make it work the way I intended, I must override handleInvalidSubmit 
>and in it call showNewForm to rebind the data to the formObject, ignore 
>it's returned ModelandView, and then process a duplicate of 
> AbstractFormController's validate/submit logic. The complete code is 
>shown below.
>
>Is this the way you intended it to work and if so, why ?
>
>Best Regards,
>
>Ken
>
>
>/*
> * OwnerInfoForm.java
> *
> * Created on May 9, 2003, 9:53 AM
> */
>
>package petclinic.web;
>
>import petclinic.Clinic;
>import petclinic.Owner;
>
>import java.io.IOException;
>import java.util.List;
>
>import javax.servlet.http.HttpServletRequest;
>import javax.servlet.http.HttpServletResponse;
>import javax.servlet.http.HttpSession;
>import javax.servlet.ServletException;
>
>import com.interface21.validation.BindException;
>import com.interface21.web.servlet.ModelAndView;
>import com.interface21.web.servlet.mvc.SimpleFormController;
>import com.interface21.web.bind.ServletRequestDataBinder;
>import com.interface21.context.ApplicationContextException;
>
>/**
> *
> * @author  Ken Krebs
> */
>public class OwnerInfoForm extends SimpleFormController {
>   
>    /** Holds value of property clinic. */
>    private Clinic clinic;
>   
>    /** Creates a new instance of OwnerInfoForm */
>    public OwnerInfoForm() {
>    }
>   
>    /** Setter for property clinic.
>     * @param clinic New value of property plinic.
>     */
>    public void setClinic(Clinic clinic) {
>        this.clinic = clinic;
>    }
>   
>    protected void init() throws ApplicationContextException {
>        if(clinic == null)
>            throw new ApplicationContextException("Must set clinic bean 
>property on " + getClass());
>    }
>   
>    protected ModelAndView onSubmit(Object command) throws 
>ServletException {
>        Owner owner = (Owner) command;
>        // add stuff to test if adding new or updating existing owner
>        clinic.update(owner);
>        return new ModelAndView(getSuccessView(), "owner", owner);
>    }
>   
>    protected Object formBackingObject(HttpServletRequest request) 
>throws ServletException {
>        int ownerId = 0;
>        try {
>            ownerId = Integer.parseInt(request.getParameter("ownerId"));
>        } catch(NumberFormatException e) {/*OK to trap & ignore*/}
>        Owner owner = clinic.getOwner(ownerId);
>        return (owner != null) ? owner : new Owner();
>    }
>
>    protected ModelAndView handleInvalidSubmit(HttpServletRequest 
>request, HttpServletResponse response)
>    throws ServletException, IOException {
>        showNewForm(request, response);
>        // process submit
>        Object command = userObject(request);
>        ServletRequestDataBinder errors = bindAndValidate(request, command);
>        return processSubmit(request, response, command, errors);
>    }
>   
>}
>
>
>jürgen höller [werk3AT] wrote:
>
>  
>
>>Ken,
>>
>>I've further refined invalid submission handling. An invalid submit request in session form mode (i.e. when no form object is in the session) triggers AbstractFormController's handleInvalidSubmit method. The latter's default implementation simply shows a new form, binding the submitted values to the new form in case of "bindOnNewForm=true". But handleInvalidSubmit can be overridden now, to show an "invalid resubmit" error message or redirect to some other view.
>>
>>Regarding transaction tokens: In session mode, form objects can serve as transaction tokens. If a user presses the browser's reload button, he either sees a new form or some custom error message (as determined by the handleInvalidSubmit implementation). Thus, if you need to forbid duplicate submissions for a certain form, switch its controller into session form mode in any case (even if you wouldn't need to keep the form object in the session otherwise).
>>
>>Thus, we don't really need dedicated transaction token support - just leverage AbstractFormController's invalid submission handling in session form mode. A dedicated token attribute in the session would only be necessary if there isn't any form object involved. Do you see a use case for forbidding duplicate submissions without a form?
>>
>>Struts has programmatic token support: You can manually add it to a session/request in an Action implementation when showing the form, and manually check its validity on submit. The html:form tag automatically adds a respective hidden field. I don't see actual value in this, though, beyond what proper session form handling already provides. BTW, transaction tokens aren't even mentioned in the Struts User Guide.
>>
>>Regards,
>>Juergen
>>
>>
>>-----Original Message-----
>>From: Ken Krebs [mailto:kk...@kk...]
>>Sent: Tuesday, May 20, 2003 7:21 PM
>>To: jürgen höller [werk3AT]
>>Cc: 'spring-dev-list'
>>Subject: Re: [Springframework-developer] MVC Forms
>>
>>
>>Juergen,
>>
>>I haven't had a chance to look at them but your changes for the Back 
>>button problems, including some way of forbidding duplicate submission 
>>(hopefully possible through configuration of the form bean), sound like 
>>they will help provide what's needed and are a real plus for developers. 
>>I will try to point this out in the accompanying tutorial text.
>>
>>As for AbstractFormController and SimpleFormController seeming 
>>restrictive, this was probably just a perception I got as I tried to 
>>solve the Back button issue. My own AbstractSearchFormController 
>>subclass of SimpleFormController shows that it is not restrictive on 
>>submission. I was concerned about how to handle things going wrong prior 
>>to submission (see next paragraph).
>>
>>There is another class of MVC problem not necessarily just with forms, 
>>and that is when the user directly enters a mapped url to a Controller, 
>>and the Controller expects to see parameters that aren't there. An 
>>example of my own handling of this in petclinic is in the method 
>>ClinicController.ownerHandler. In this case, it's makes sense to just 
>>redirect the user to the FindOwnerForm as I've done. I was planning on 
>>handling this situation for the OwnerInfoForm by making the form 
>>dynamically show a "Update Owner Info" button if the preconfigured 
>>object can be provided or a "Add Owner" button if there is no 
>>preconfigured object, but redirection may be desirable in some 
>>situations. What do you think ?
>>
>>From the viewpoint of an organization considering adopting Spring, the 
>>fact that Spring addresses these problems directly without individual 
>>developers having to craft their own adhoc solutions should be seen as a 
>>plus.
>>
>>Ken
>>
>>
>> 
>>
>>    
>>
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: ObjectStore.
>If flattening out C++ or Java code to make your application fit in a
>relational database is painful, don't do it! Check out ObjectStore.
>Now part of Progress Software. http://www.objectstore.net/sourceforge
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>  
>

RE: [Springframework-developer] AOP

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

Yes, Rutgers University indeed. And for now we're are pretty happy about
current aop implementation/ease of use.

Regards,
Dmitriy.

-----Original Message-----
From: rod...@in... [mailto:rod...@in...]
Sent: Friday, May 23, 2003 09:38 AM
To: Kopylenko, Dmitry
Cc: 'spring-dev-list'
Subject: Re: [Springframework-developer] AOP


<dmitry>
Rod, everyone,

I just want to report that we've started to use AOP framework 
for one of our
big web app. projects. 

Also, here is the list of Spring components/sub-frameworks 
we're using for
this project:

* BeanFactory
* WebApplicationContext
* JDBC
* Tx infrastructure (via declarative aop approach)
* MVC web framework
* AOP

Regards,
Dmitriy.
</dmitry>

Good to hear this: thanks for letting us know. I assume you 
mean Rutgers University? It would be great to have a list of 
reference sites before we release 1.0.

I'm also very excited about AOP. 

I'm done with changes to AOP stuff for 0.8. Beyond that, I'm 
keen to progress with better support for transaction and 
other attributes, including source-level attributes.

As you progress with your project, it would be great to hear 
any suggestions you may have about how to improve Spring AOP 
and make it easier to use. If you're entirely happy, that's 
useful feedback too!

Unfortunately it appears that Jon Tirsen (Nanning) won't 
commit to supporting the AOP Alliance interfaces--which he 
was heavily involved in defining--until the AOP Alliance "has 
more momentum." I find this a disappointing copout, but I 
think the problem is partly that he simply doesn't have time 
to make the changes, which would impact his use of Nanning in 
his day job. (It would be hard to justify the cost to his 
employers.) So unfortunately I don't think the AOP 
Alliance/interoperability is going to be a reality any time 
soon. However, it does mean that not only is Spring unique in 
the AOP space as a complete, integrated, solution (just drop 
in AOP if you want to use it), but is the only AOP solution I 
know of that has made a genuine effort to comply with an open 
API.

As Spring is the only implementation of the AOP Alliance 
interfaces for the moment, if anyone has any strong feelings 
that anything should be changed about those interfaces, this 
list is probably the best place to discuss it. I'm fairly 
happy with them for now. I will have to comment them properly 
before 1.0. And put Javadoc on AOP Alliance SF.

Regards,
Rod

Re: [Springframework-developer] AOP

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

<dmitry>
Rod, everyone,

I just want to report that we've started to use AOP framework 
for one of our
big web app. projects. 

Also, here is the list of Spring components/sub-frameworks 
we're using for
this project:

* BeanFactory
* WebApplicationContext
* JDBC
* Tx infrastructure (via declarative aop approach)
* MVC web framework
* AOP

Regards,
Dmitriy.
</dmitry>

Good to hear this: thanks for letting us know. I assume you 
mean Rutgers University? It would be great to have a list of 
reference sites before we release 1.0.

I'm also very excited about AOP. 

I'm done with changes to AOP stuff for 0.8. Beyond that, I'm 
keen to progress with better support for transaction and 
other attributes, including source-level attributes.

As you progress with your project, it would be great to hear 
any suggestions you may have about how to improve Spring AOP 
and make it easier to use. If you're entirely happy, that's 
useful feedback too!

Unfortunately it appears that Jon Tirsen (Nanning) won't 
commit to supporting the AOP Alliance interfaces--which he 
was heavily involved in defining--until the AOP Alliance "has 
more momentum." I find this a disappointing copout, but I 
think the problem is partly that he simply doesn't have time 
to make the changes, which would impact his use of Nanning in 
his day job. (It would be hard to justify the cost to his 
employers.) So unfortunately I don't think the AOP 
Alliance/interoperability is going to be a reality any time 
soon. However, it does mean that not only is Spring unique in 
the AOP space as a complete, integrated, solution (just drop 
in AOP if you want to use it), but is the only AOP solution I 
know of that has made a genuine effort to comply with an open 
API.

As Spring is the only implementation of the AOP Alliance 
interfaces for the moment, if anyone has any strong feelings 
that anything should be changed about those interfaces, this 
list is probably the best place to discuss it. I'm fairly 
happy with them for now. I will have to comment them properly 
before 1.0. And put Javadoc on AOP Alliance SF.

Regards,
Rod

Re: [Springframework-developer] Web app and Log4J initialization

[Isabelle M. <isa...@me...>]

Hi Juergen,

Last time I looked the Sun One AS 7 was only available for Windows and Solaris, which rules me out (Linux). I just had a look again, and they now support RedHat 7.2, which is really old (it's at 9 now).
I'm sort of in favor of JRun4 for the demo because it is a lot more user friendly than JBoss and has better docs. And there is a service pack for version 4, which hopefully solved most of the bugs.

Isabelle

On Fri, May 23, 2003 at 02:50:41PM +0200, jürgen höller [werk3AT] wrote:
> There's an issue with Orion (up to 2.0.1), regarding web app startup: In contrast to most other servlet containers (including Tomcat 4.x, Resin, Jetty), Orion starts load-on-startup Servlets BEFORE invoking ServletContextListeners. This means that combining startup listeners with load-on-startup servlets can be problematic on Orion, if the latter depend on initialization performed by the listeners.
> 
> With Spring, this can occur when using both ContextLoaderListener and load-on-startup ControllerServlets. For Orion, the load-on-startup must be removed from the servlet descriptors, triggering servlet initialization on first request. Or you'll write a custom bootstrap servlet with a lower load-on-startup number than the ControllerServlets, invoking com.interface21.web.context.ContextLoader.initContext(ServletContext), and maybe other things that your app would normally do in a listener.
> 
> Admittedly, the Servlet 2.3 spec didn't specify whether listeners or load-on-startup servlets should be initialized first. But the Servlet 2.4 spec demands that listeners get invoked before servlets, so containers like Orion that do in the other way round need to change their behavior anyway. I've already filed an Orion bug report for it. Does anyone know of other containers that behave like Orion?
> 
> BTW, Orion's JSP engine has a quite extreme bug: It doesn't correctly export variables from custom tags. This means that our bind tag does not work, as it exports a status variable. I've already filed a bug report some time ago, but haven't got any feedback.
> 
> All things considered, I guess we shouldn't adopt Orion as our default "full" J2EE platform. For 1-database web apps, Tomcat 4 or Resin are perfectly sufficient anyway. But what about >1-database apps that need JTA, or apps leveraging JMS, JCA, or EJB?
> 
> - For the JTA case: Tomcat/Tyrex, Resin, or WebLogic Express Basic may do the job, WebLogic Express Premium even including WebLogic's full transaction recovery.
> 
> - But for JMS/JCA/EJB: Is JBoss back on the list again? Or Sun ONE AS 7, providing all 3 already in the free Platform Edition? Or JRun 4, free for development?
> 
> In any case, I'm not keen on having to stick to heavyweights like WebLogic or WebSphere. Unfortunately, I've experienced JRun 4 to be rather buggy, at least its initial release. I don't like internal NullPointerExceptions on deployment :-( So, has anyone tried Sun ONE AS 7?
> 
> Juergen
> 
> 
> -----Original Message-----
> From: jürgen höller [werk3AT] 
> Sent: Friday, May 16, 2003 2:58 PM
> To: spr...@li...
> Subject: [Springframework-developer] Web app and Log4J initialization
> 
> 
> Isabelle, Ken, everybody,
> 
> On the occasion, some examples for initializing a Spring web app, especially regarding Log4J.
> 
> 
> 1. Log4J for usage within a web app
> 
> In web.xml, add the following to activate Log4j with a config file location relative to the web app root, by default refreshing the config file every minute (also recognizes a context-param "log4jRefreshInterval", and assumes an XML file in case of a ".xml" extension):
> 
> 	<context-param>
> 		<param-name>webAppRootKey</param-name>
> 		<param-value>example.root</param-value>
> 	</context-param>
> 
> 	<context-param>
> 		<param-name>log4jConfigLocation</param-name>
> 		<param-value>WEB-INF/log4j.xml</param-value>
> 	</context-param>
> 
> 	<listener>
> 		<listener-class>com.interface21.web.util.Log4jConfigListener</listener-class>
> 	</listener>
> 
> In log4j.properties, the system property with the specified "webAppRootKey" can be used as follows:
> 
> 	log4j.appender.examplefile=org.apache.log4j.FileAppender
> 	log4j.appender.examplefile.File=${example.root}/WEB-INF/example.log
> 
> If you don't need a refresh check and use the default config location anyway (i.e. "WEB-INF\classes\log4j.properties"), you can omit the "log4jConfigLocation" param. Log4J performs its default initialization then, still recognizing the system property. Just to achieve the latter, WebAppRootListener would be enough, but Log4jConfigListener is fine in this case too (see respective javadoc). 
> 
> If you'd like to use absolute log file paths anyway, you can omit the "webAppRootKey" param. You can also omit it and use the default "webapp.root" key in your log4j.properties - if running in an appropriate container like Resin that isolates system properties per web app. With containers like Tomcat that no not separate each web app's system properties, you'll need to specify a unique key per web app to avoid clashes.
> 
> BTW, Log4J's ${key} simply looks for a system property named "key". So if you like to use the webAppRootKey mechanism but also support a test environment with the same Log4J config file, simply call Log4jConfigurer.setWorkingDirectorySystemProperty(<key>) to set the specified system property to the current working directory.
> 
> Note: The order of the listeners is important, to initialize Log4J before any Spring activity.
> 
> 
> 2. Loading Spring application contexts
> 
> The following illustrates a typical setup in web.xml:
> 
> 	<context-param>
> 		<param-name>contextConfigLocation</param-name>
> 		<param-value>WEB-INF/myContext.xml</param-value>
> 	</context-param>
> 
> 	<listener>
> 		<listener-class>com.interface21.web.context.ContextLoaderListener</listener-class>
> 	</listener>
> 
> 	<servlet>
> 		<servlet-name>example</servlet-name>
> 		<servlet-class>com.interface21.web.servlet.ControllerServlet</servlet-class>
>   		<load-on-startup>1</load-on-startup>
> 	</servlet>
> 
> If you'd like to use a root application context, register the ContextLoaderListener. If you do not, you will simply have no root application context but just servlet-specific ones without parent. If you'd like to use the default root context location (i.e. "/WEB-INF/applicationContext.xml") anyway, you can omit the "contextConfigLocation" param.
> 
> A FrameworkServlet resp. ControllerServlet looks up its namespaced context at "/WEB-INF/<servlet-name>-servlet.xml" by default. This can be customized via "contextConfigLocationPrefix" and "customConfigLocationSuffix" context-params, e.g. prefix "/WEB-INF/servlets/", suffix ".xml" -> "/WEB-INF/servlets/<servlet-name>-servlet.xml" (see XmlWebApplicationContext javadoc). The "<servlet-name>-servlet" namespace can be customized too, but at the FrameworkServlet level: It can be overridden by a "namespace" init-param.
> 
> Context implementation classes can also be customized, if desired. For the root context, this can be achieved via a "contextClass" context-param (see ContextLoader javadoc). A FrameworkServlet resp. ControllerServlet offers a "contextClass" init-param. Note that for the latter, the context implementation needs an (ApplicationContext, String) constructor, for the parent and the namespace (see FrameworkServlet javadoc).
> 
> 
> 3. Keep it simple
> 
> Let's review necessary settings:
> - A Spring web app doesn't need any context-params or listeners at all, if just using a FrameworkServlet resp. ControllerServlet with its own context.
> - If you want a root application context, register ContextLoaderListener.
> - If you'd like to specify a custom context config location, or FrameworkServlet namespace or prefix or suffix, add the respective context-param.
> - For the web app root system property (e.g. in your Log4J config), register WebAppRootListener or Log4jConfigListener, and specify the "webAppRootKey" context-param in a non-isolating container.
> - For custom Log4J initialization, register Log4jConfigListener and add respective context-params.
> 
> So please, let's not use context-params if not needed, i.e. if using the defaults anyway. This avoids cluttering web.xml.
> 
> Finally an important note: I've removed both Log4jConfigServlet and ContextLoaderServlet, as we require Servlet 2.3 and should thus use Log4jConfigListener resp. ContextLoaderListener in any case. You'll have to adapt your config files if you've still used those initialization servlets up to now, but I consider it important to clean this before a proper release: 1 way for 1 thing to achieve. Sorry for any inconvenience - in case of severe impacts regarding context loading, write your own initialization servlet, overriding init() with a ContextLoader.initContext(ServletContext) call.
> 
> 
> Regards,
> Juergen
> 
> 
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
> 
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 

-- 
Isabelle Muszynski
Software Engineer
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89
Email: isa...@me...
Website: www.meta-logix.com

RE: [Springframework-developer] Web app and Log4J initialization

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

There's an issue with Orion (up to 2.0.1), regarding web app startup: In =
contrast to most other servlet containers (including Tomcat 4.x, Resin, =
Jetty), Orion starts load-on-startup Servlets BEFORE invoking =
ServletContextListeners. This means that combining startup listeners =
with load-on-startup servlets can be problematic on Orion, if the latter =
depend on initialization performed by the listeners.

With Spring, this can occur when using both ContextLoaderListener and =
load-on-startup ControllerServlets. For Orion, the load-on-startup must =
be removed from the servlet descriptors, triggering servlet =
initialization on first request. Or you'll write a custom bootstrap =
servlet with a lower load-on-startup number than the ControllerServlets, =
invoking =
com.interface21.web.context.ContextLoader.initContext(ServletContext), =
and maybe other things that your app would normally do in a listener.

Admittedly, the Servlet 2.3 spec didn't specify whether listeners or =
load-on-startup servlets should be initialized first. But the Servlet =
2.4 spec demands that listeners get invoked before servlets, so =
containers like Orion that do in the other way round need to change =
their behavior anyway. I've already filed an Orion bug report for it. =
Does anyone know of other containers that behave like Orion?

BTW, Orion's JSP engine has a quite extreme bug: It doesn't correctly =
export variables from custom tags. This means that our bind tag does not =
work, as it exports a status variable. I've already filed a bug report =
some time ago, but haven't got any feedback.

All things considered, I guess we shouldn't adopt Orion as our default =
"full" J2EE platform. For 1-database web apps, Tomcat 4 or Resin are =
perfectly sufficient anyway. But what about >1-database apps that need =
JTA, or apps leveraging JMS, JCA, or EJB?

- For the JTA case: Tomcat/Tyrex, Resin, or WebLogic Express Basic may =
do the job, WebLogic Express Premium even including WebLogic's full =
transaction recovery.

- But for JMS/JCA/EJB: Is JBoss back on the list again? Or Sun ONE AS 7, =
providing all 3 already in the free Platform Edition? Or JRun 4, free =
for development?

In any case, I'm not keen on having to stick to heavyweights like =
WebLogic or WebSphere. Unfortunately, I've experienced JRun 4 to be =
rather buggy, at least its initial release. I don't like internal =
NullPointerExceptions on deployment :-( So, has anyone tried Sun ONE AS =
7?

Juergen


-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT]=20
Sent: Friday, May 16, 2003 2:58 PM
To: spr...@li...
Subject: [Springframework-developer] Web app and Log4J initialization


Isabelle, Ken, everybody,

On the occasion, some examples for initializing a Spring web app, =
especially regarding Log4J.


1. Log4J for usage within a web app

In web.xml, add the following to activate Log4j with a config file =
location relative to the web app root, by default refreshing the config =
file every minute (also recognizes a context-param =
"log4jRefreshInterval", and assumes an XML file in case of a ".xml" =
extension):

	<context-param>
		<param-name>webAppRootKey</param-name>
		<param-value>example.root</param-value>
	</context-param>

	<context-param>
		<param-name>log4jConfigLocation</param-name>
		<param-value>WEB-INF/log4j.xml</param-value>
	</context-param>

	<listener>
		=
<listener-class>com.interface21.web.util.Log4jConfigListener</listener-cl=
ass>
	</listener>

In log4j.properties, the system property with the specified =
"webAppRootKey" can be used as follows:

	log4j.appender.examplefile=3Dorg.apache.log4j.FileAppender
	log4j.appender.examplefile.File=3D${example.root}/WEB-INF/example.log

If you don't need a refresh check and use the default config location =
anyway (i.e. "WEB-INF\classes\log4j.properties"), you can omit the =
"log4jConfigLocation" param. Log4J performs its default initialization =
then, still recognizing the system property. Just to achieve the latter, =
WebAppRootListener would be enough, but Log4jConfigListener is fine in =
this case too (see respective javadoc).=20

If you'd like to use absolute log file paths anyway, you can omit the =
"webAppRootKey" param. You can also omit it and use the default =
"webapp.root" key in your log4j.properties - if running in an =
appropriate container like Resin that isolates system properties per web =
app. With containers like Tomcat that no not separate each web app's =
system properties, you'll need to specify a unique key per web app to =
avoid clashes.

BTW, Log4J's ${key} simply looks for a system property named "key". So =
if you like to use the webAppRootKey mechanism but also support a test =
environment with the same Log4J config file, simply call =
Log4jConfigurer.setWorkingDirectorySystemProperty(<key>) to set the =
specified system property to the current working directory.

Note: The order of the listeners is important, to initialize Log4J =
before any Spring activity.


2. Loading Spring application contexts

The following illustrates a typical setup in web.xml:

	<context-param>
		<param-name>contextConfigLocation</param-name>
		<param-value>WEB-INF/myContext.xml</param-value>
	</context-param>

	<listener>
		=
<listener-class>com.interface21.web.context.ContextLoaderListener</listen=
er-class>
	</listener>

	<servlet>
		<servlet-name>example</servlet-name>
		=
<servlet-class>com.interface21.web.servlet.ControllerServlet</servlet-cla=
ss>
  		<load-on-startup>1</load-on-startup>
	</servlet>

If you'd like to use a root application context, register the =
ContextLoaderListener. If you do not, you will simply have no root =
application context but just servlet-specific ones without parent. If =
you'd like to use the default root context location (i.e. =
"/WEB-INF/applicationContext.xml") anyway, you can omit the =
"contextConfigLocation" param.

A FrameworkServlet resp. ControllerServlet looks up its namespaced =
context at "/WEB-INF/<servlet-name>-servlet.xml" by default. This can be =
customized via "contextConfigLocationPrefix" and =
"customConfigLocationSuffix" context-params, e.g. prefix =
"/WEB-INF/servlets/", suffix ".xml" -> =
"/WEB-INF/servlets/<servlet-name>-servlet.xml" (see =
XmlWebApplicationContext javadoc). The "<servlet-name>-servlet" =
namespace can be customized too, but at the FrameworkServlet level: It =
can be overridden by a "namespace" init-param.

Context implementation classes can also be customized, if desired. For =
the root context, this can be achieved via a "contextClass" =
context-param (see ContextLoader javadoc). A FrameworkServlet resp. =
ControllerServlet offers a "contextClass" init-param. Note that for the =
latter, the context implementation needs an (ApplicationContext, String) =
constructor, for the parent and the namespace (see FrameworkServlet =
javadoc).


3. Keep it simple

Let's review necessary settings:
- A Spring web app doesn't need any context-params or listeners at all, =
if just using a FrameworkServlet resp. ControllerServlet with its own =
context.
- If you want a root application context, register =
ContextLoaderListener.
- If you'd like to specify a custom context config location, or =
FrameworkServlet namespace or prefix or suffix, add the respective =
context-param.
- For the web app root system property (e.g. in your Log4J config), =
register WebAppRootListener or Log4jConfigListener, and specify the =
"webAppRootKey" context-param in a non-isolating container.
- For custom Log4J initialization, register Log4jConfigListener and add =
respective context-params.

So please, let's not use context-params if not needed, i.e. if using the =
defaults anyway. This avoids cluttering web.xml.

Finally an important note: I've removed both Log4jConfigServlet and =
ContextLoaderServlet, as we require Servlet 2.3 and should thus use =
Log4jConfigListener resp. ContextLoaderListener in any case. You'll have =
to adapt your config files if you've still used those initialization =
servlets up to now, but I consider it important to clean this before a =
proper release: 1 way for 1 thing to achieve. Sorry for any =
inconvenience - in case of severe impacts regarding context loading, =
write your own initialization servlet, overriding init() with a =
ContextLoader.initContext(ServletContext) call.


Regards,
Juergen


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] AOP

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

Rod, everyone,

I just want to report that we've started to use AOP framework for one of our
big web app. projects. We've successfully implemented and incorporated
aspects like "MailConfirmationInterceptor", "AuditTrailInterceptor",
"DebugInterceptor" to name a few. More to come.... The AOP paradigm is
really going to be big IMO.

Also, here is the list of Spring components/sub-frameworks we're using for
this project:

* BeanFactory
* WebApplicationContext
* JDBC
* Tx infrastructure (via declarative aop approach)
* MVC web framework
* AOP

Regards,
Dmitriy.

RE: [Springframework-developer] Code changes for 0.8?

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

Hopefully the list will grow after the official release and good
docs/tutorials

D.

-----Original Message-----
From: William G. Thompson, Jr. [mailto:wg...@ru...]
Sent: Friday, May 23, 2003 07:56 AM
To: "j=FCrgen h=F6ller [werk3AT]"
Cc: Rod Johnson; tri...@tr...;
spr...@li...
Subject: Re: [Springframework-developer] Code changes for 0.8?


Rod, you can add a third org to the list of folks who are using Spring=20
JDBC without an ApplicationContext.  We are using it with in conjuction =

with the open source uPortal framwork for channel (aka portlet) =
development.

later.
Bill


j=FCrgen h=F6ller [werk3AT] wrote:
> Good point indeed, using Spring JDBC without an ApplicationContext. =
I'll
reintroduce a simple version of it, using a plain JndiTemplate. =
Sometimes
I'm a little over-eager in terms of simplification, sorry :-)
>=20
> I assume that the typical scenario for this is somewhat like the
following:
>=20
> 	DataSource ds =3D DataSourceUtils.getDataSourceFromJndi("jdbc/cbx");
> 	JdbcTemplate jt =3D new JdbcTemplate(ds);
> 	jt.<doSomething>;
>=20
> Would that be enough? I'm not keen on introducing an additional
JdbcTemplate constructor with a DataSource NAME. The retrieved =
DataSource
will typically be kept somewhere anyway.
>=20
> I'm also gonna make JndiObjectFactoryBean extend AbstractJndiLocator, =
for
maximum code reuse. We'll also have AbstractJndiLocator's "inContainer"
property then, to be able to control "java:comp/env" prefixing
(inContainer=3Dfalse means plain JNDI name, the default =
inContainer=3Dtrue means
prefix "java:comp/env" if not already contained).
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...]
> Sent: Friday, May 23, 2003 8:36 AM
> To: tri...@tr...; j=FCrgen h=F6ller [werk3AT]
> Cc: spr...@li...
> Subject: Re: [Springframework-developer] Code changes for 0.8?
>=20
>=20
> I agree with Thomas. Good point. At the moment I know of 2 companies =
using
> Spring JDBC only. If they have to do the JNDI stuff themselves it =
reduces
> the benefit.
>=20
> Rod
>=20
> ----- Original Message -----
> From: <tri...@tr...>
> To: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
> Cc: "Rod Johnson" <rod...@in...>;
> <spr...@li...>
> Sent: Friday, May 23, 2003 2:06 AM
> Subject: RE: [Springframework-developer] Code changes for 0.8?
>=20
>=20
>=20
>>J=FCrgen,
>>
>>I'd prefer to keep DataSourceUtils.getDataSourceFromJndi for =
applications
>=20
> that
>=20
>>only use the JDBC framework.  Maybe we could change the way it does =
the
>=20
> lookup
>=20
>>to make it similar to the JndiObjectFactoryBean.  What do you all =
think?
>>
>>Thomas
>>
>>
>>>Regarding mock objects, I think that the JNDI mocks do have value =
for
>>>application developers: They can serve as JNDI replacement for
>=20
> applications
>=20
>>>test environments and standalone applications, running the same code =
and
>>>config files as in the container environment.
>>>
>>>We are using this to be able to reuse the same Hibernate config file =
for
>=20
> both
>=20
>>>web app and test environments. In the standalone access, we simply =
bind
>=20
> a
>=20
>>>DriverManagerDataSource to the same JNDI location, with Spring's =
JNDI
>=20
> mocks
>=20
>>>as infrastructure.
>>>
>>>Other development projects can use this strategy too, and EasyMock =
won't
>=20
> help
>=20
>>>here. Thus, I'd like the JNDI mocks to stay, but all other mocks =
should
>=20
> not
>=20
>>>be in our src tree IMO, as they only serve within our test suites.
>>>
>>>Regarding FrameworkServlet's debug support, that were exactly the
>=20
> reasons why
>=20
>>>I've removed them. It cluttered up the code somewhat, and I don't
>=20
> consider it
>=20
>>>necessary.
>>>
>>>---
>>>
>>>I've just added one more refactoring: I've replaced both
>>>JndiDataSourceBean/JndiDataSourceEditor and
>>>JndiSessionFactoryBean/JndiSessionFactoryEditor with generic
>=20
> implementations,
>=20
>>>namely JndiObjectFactoryBean and JndiObjectEditor. Effectively, the
>>>FactoryBeans have just returned Objects, so there's no need for
>=20
> specialized
>=20
>>>implementations. I've also removed =
DataSourceUtils.getDataSourceFromJndi
>=20
> and
>=20
>>>SessionFactoryUtils.getSessionFactoryFromJndi, as they aren't
>=20
> recommended
>=20
>>>anymore. I don't like too many ways to achieve 1 thing.
>>>
>>>One more reason is that the former getDataSourceFromJndi always =
looked
>=20
> up the
>=20
>>>given name under "java:comp/env", if not contained in the name. This =
is
>=20
> too
>=20
>>>inflexible: A DataSource might be bound to any JNDI name, in fact.
>>>JndiObjectFactoryBean and JndiObjectEditor need the full JNDI name: =
This
>=20
> is
>=20
>>>clearer and not much effort.
>>>
>>>So Isabelle and Ken, please use
>=20
> com.interface21.jndi.JndiObjectFactoryBean
>=20
>>>for DataSource definitions instead of
>>>com.interface21.jdbc.datasource.JndiDataSourceBean! Sorry for the =
late
>>>change, but I think it's worth it.
>>>
>>>Gonna check all this stuff in the next hour...
>>>
>>>Regards,
>>>Juergen
>>>
>>>
>>>-----Original Message-----
>>>From: Rod Johnson [mailto:rod...@in...]
>>>Sent: Thursday, May 22, 2003 6:24 PM
>>>To: j=FCrgen h=F6ller [werk3AT]
>>>Cc: spr...@li...
>>>Subject: Re: [Springframework-developer] Code changes for 0.8?
>>>
>>>
>>>Excellent. Great news on the test coverage! You've been doing good =
work
>>>here.
>>>
>>>I'm glad you've cleaned up the stack traces... There were quite a =
few
>>>repeated stack traces a long time ago, and I got many of them (but
>=20
> obviously
>=20
>>>not all). I think the volume and quality of stack traces is very
>=20
> important.
>=20
>>>It's about the only thing that really bugs me with Hibernate 2.0 =
RC1,
>=20
> for
>=20
>>>example. We may need to consider a consistent approach to logging
>=20
> (levels
>=20
>>>etc.) for 0.9 or 1.0.
>>>
>>>I imagine removing debug support in framework servlet removed a lot =
of
>=20
> code.
>=20
>>>I actually eyed it myself with my scalpel in mind recently. It did =
make
>=20
> the
>=20
>>>code much harder to understand and the fewer lines of code, the =
fewer
>>>potential bugs. Also, I don't think it was documented anywhere, so I
>=20
> doubt
>=20
>>>anyone will miss it too much. (I did use it myself occasionally but =
I'm
>=20
> sure
>=20
>>>I can live without it.)
>>>
>>>I'm not sure that *any* mock objects should be in the main source =
tree.
>>>Maybe we need a third tree for the mocks and things like
>>>EjbContainerDetective that are handy but not part of the core spring
>>>runtime. I don't tend to use our mock objects much anymore, since I
>>>discovered the wonder that is EasyMock.
>>>
>>>Code formatting I think is a 0.9 thing. Certainly after we have a =
tagged
>>>stable release. We don't want to delay 0.8 for this.
>>>
>>>I'm away this weekend (bank holiday in the UK), so won't be doing =
any
>=20
> work.
>=20
>>>Anything I do add to Spring until we go to 0.8 will either be an =
urgent
>=20
> bug
>=20
>>>fix or simply additional tests.
>>>
>>>Regards,
>>>Rod
>>>
>>>----- Original Message -----
>>>From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
>>>To: <spr...@li...>
>>>Sent: Thursday, May 22, 2003 4:29 PM
>>>Subject: RE: [Springframework-developer] Code changes for 0.8?
>>>
>>>
>>>Besides having reworked the form controller's handling of resubmits,
>=20
> I've
>=20
>>>also created an extensive test suite for ControllerServlet and some =
web
>>>support classes. We're at overall >64% now!
>>>
>>>Additionally, I've refined some ApplicationContext stuff (moved
>>>OPTIONS_BEAN_NAME from ApplicationContext to =
AbstractApplicationContext
>>>etc), and cleaned the exception handling in the beans package (e.g.
>=20
> rethrow
>=20
>>>BeansException directly when catching Exception instead of wrapping =
it).
>>>
>>>Rethrown exceptions don't get logged anymore, as they are logged by =
the
>>>highest level exception handler anyway (-> no double stack traces in =
the
>>>console). I've also commented out the println(this) on printing a
>=20
> rootCause
>=20
>>>stack trace: As a root stack trace will always get printed after the
>>>exception's message, those lines have only added redundant =
information,
>>>cluttering the console.
>>>
>>>I've removed FrameworkServlet's debug support, I don't see any real =
use
>=20
> case
>=20
>>>for it. During development, Log4J's debug log is all you need, IMO - =
you
>>>exactly see what handlers/mappings/etc get used, no need for binding
>=20
> them to
>=20
>>>the request.
>>>
>>>I'm also gonna move the web.mock classes back to the test sources, =
as
>=20
> they
>=20
>>>are pretty rough, and not really meant for usage within application
>>>development - in constrast to the JNDI mocks, for example.
>>>
>>>I'll check my stuff in within the next 2 hours. Everybody, please =
test
>=20
> the
>=20
>>>current framework version in your apps! We should really try to =
release
>=20
> a
>=20
>>>0.8 as stable as possible.
>>>
>>>BTW, what's the current status in terms of code beautification =
(Jalopy
>=20
> etc)?
>=20
>>>We have mixed headers in our files at the moment, and sometimes
>=20
> inconsistent
>=20
>>>formatting. Do we aim to clean this for 0.8?
>>>
>>>Juergen
>>>
>>>







-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Code changes for 0.8?

[William G. T. Jr. <wg...@ru...>]

Rod, you can add a third org to the list of folks who are using Sprin=
g=20
JDBC without an ApplicationContext.  We are using it with in conjucti=
on=20
with the open source uPortal framwork for channel (aka portlet) devel=
opment.

later.
Bill


j=FCrgen h=F6ller [werk3AT] wrote:
> Good point indeed, using Spring JDBC without an ApplicationContext.=
 I'll reintroduce a simple version of it, using a plain JndiTemplate.=
 Sometimes I'm a little over-eager in terms of simplification, sorry =
:-)
>=20
> I assume that the typical scenario for this is somewhat like the fo=
llowing:
>=20
> =09DataSource ds =3D DataSourceUtils.getDataSourceFromJndi("jdbc/cb=
x");
> =09JdbcTemplate jt =3D new JdbcTemplate(ds);
> =09jt.<doSomething>;
>=20
> Would that be enough? I'm not keen on introducing an additional Jdb=
cTemplate constructor with a DataSource NAME. The retrieved DataSourc=
e will typically be kept somewhere anyway.
>=20
> I'm also gonna make JndiObjectFactoryBean extend AbstractJndiLocato=
r, for maximum code reuse. We'll also have AbstractJndiLocator's "inC=
ontainer" property then, to be able to control "java:comp/env" prefix=
ing (inContainer=3Dfalse means plain JNDI name, the default inContain=
er=3Dtrue means prefix "java:comp/env" if not already contained).
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...]
> Sent: Friday, May 23, 2003 8:36 AM
> To: tri...@tr...; j=FCrgen h=F6ller [werk3AT]
> Cc: spr...@li...
> Subject: Re: [Springframework-developer] Code changes for 0.8?
>=20
>=20
> I agree with Thomas. Good point. At the moment I know of 2 companie=
s using
> Spring JDBC only. If they have to do the JNDI stuff themselves it r=
educes
> the benefit.
>=20
> Rod
>=20
> ----- Original Message -----
> From: <tri...@tr...>
> To: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
> Cc: "Rod Johnson" <rod...@in...>;
> <spr...@li...>
> Sent: Friday, May 23, 2003 2:06 AM
> Subject: RE: [Springframework-developer] Code changes for 0.8?
>=20
>=20
>=20
>>J=FCrgen,
>>
>>I'd prefer to keep DataSourceUtils.getDataSourceFromJndi for applic=
ations
>=20
> that
>=20
>>only use the JDBC framework.  Maybe we could change the way it does=
 the
>=20
> lookup
>=20
>>to make it similar to the JndiObjectFactoryBean.  What do you all t=
hink?
>>
>>Thomas
>>
>>
>>>Regarding mock objects, I think that the JNDI mocks do have value =
for
>>>application developers: They can serve as JNDI replacement for
>=20
> applications
>=20
>>>test environments and standalone applications, running the same co=
de and
>>>config files as in the container environment.
>>>
>>>We are using this to be able to reuse the same Hibernate config fi=
le for
>=20
> both
>=20
>>>web app and test environments. In the standalone access, we simply=
 bind
>=20
> a
>=20
>>>DriverManagerDataSource to the same JNDI location, with Spring's J=
NDI
>=20
> mocks
>=20
>>>as infrastructure.
>>>
>>>Other development projects can use this strategy too, and EasyMock=
 won't
>=20
> help
>=20
>>>here. Thus, I'd like the JNDI mocks to stay, but all other mocks s=
hould
>=20
> not
>=20
>>>be in our src tree IMO, as they only serve within our test suites.
>>>
>>>Regarding FrameworkServlet's debug support, that were exactly the
>=20
> reasons why
>=20
>>>I've removed them. It cluttered up the code somewhat, and I don't
>=20
> consider it
>=20
>>>necessary.
>>>
>>>---
>>>
>>>I've just added one more refactoring: I've replaced both
>>>JndiDataSourceBean/JndiDataSourceEditor and
>>>JndiSessionFactoryBean/JndiSessionFactoryEditor with generic
>=20
> implementations,
>=20
>>>namely JndiObjectFactoryBean and JndiObjectEditor. Effectively, th=
e
>>>FactoryBeans have just returned Objects, so there's no need for
>=20
> specialized
>=20
>>>implementations. I've also removed DataSourceUtils.getDataSourceFr=
omJndi
>=20
> and
>=20
>>>SessionFactoryUtils.getSessionFactoryFromJndi, as they aren't
>=20
> recommended
>=20
>>>anymore. I don't like too many ways to achieve 1 thing.
>>>
>>>One more reason is that the former getDataSourceFromJndi always lo=
oked
>=20
> up the
>=20
>>>given name under "java:comp/env", if not contained in the name. Th=
is is
>=20
> too
>=20
>>>inflexible: A DataSource might be bound to any JNDI name, in fact.
>>>JndiObjectFactoryBean and JndiObjectEditor need the full JNDI name=
: This
>=20
> is
>=20
>>>clearer and not much effort.
>>>
>>>So Isabelle and Ken, please use
>=20
> com.interface21.jndi.JndiObjectFactoryBean
>=20
>>>for DataSource definitions instead of
>>>com.interface21.jdbc.datasource.JndiDataSourceBean! Sorry for the =
late
>>>change, but I think it's worth it.
>>>
>>>Gonna check all this stuff in the next hour...
>>>
>>>Regards,
>>>Juergen
>>>
>>>
>>>-----Original Message-----
>>>From: Rod Johnson [mailto:rod...@in...]
>>>Sent: Thursday, May 22, 2003 6:24 PM
>>>To: j=FCrgen h=F6ller [werk3AT]
>>>Cc: spr...@li...
>>>Subject: Re: [Springframework-developer] Code changes for 0.8?
>>>
>>>
>>>Excellent. Great news on the test coverage! You've been doing good=
 work
>>>here.
>>>
>>>I'm glad you've cleaned up the stack traces... There were quite a =
few
>>>repeated stack traces a long time ago, and I got many of them (but
>=20
> obviously
>=20
>>>not all). I think the volume and quality of stack traces is very
>=20
> important.
>=20
>>>It's about the only thing that really bugs me with Hibernate 2.0 R=
C1,
>=20
> for
>=20
>>>example. We may need to consider a consistent approach to logging
>=20
> (levels
>=20
>>>etc.) for 0.9 or 1.0.
>>>
>>>I imagine removing debug support in framework servlet removed a lo=
t of
>=20
> code.
>=20
>>>I actually eyed it myself with my scalpel in mind recently. It did=
 make
>=20
> the
>=20
>>>code much harder to understand and the fewer lines of code, the fe=
wer
>>>potential bugs. Also, I don't think it was documented anywhere, so=
 I
>=20
> doubt
>=20
>>>anyone will miss it too much. (I did use it myself occasionally bu=
t I'm
>=20
> sure
>=20
>>>I can live without it.)
>>>
>>>I'm not sure that *any* mock objects should be in the main source =
tree.
>>>Maybe we need a third tree for the mocks and things like
>>>EjbContainerDetective that are handy but not part of the core spri=
ng
>>>runtime. I don't tend to use our mock objects much anymore, since =
I
>>>discovered the wonder that is EasyMock.
>>>
>>>Code formatting I think is a 0.9 thing. Certainly after we have a =
tagged
>>>stable release. We don't want to delay 0.8 for this.
>>>
>>>I'm away this weekend (bank holiday in the UK), so won't be doing =
any
>=20
> work.
>=20
>>>Anything I do add to Spring until we go to 0.8 will either be an u=
rgent
>=20
> bug
>=20
>>>fix or simply additional tests.
>>>
>>>Regards,
>>>Rod
>>>
>>>----- Original Message -----
>>>From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
>>>To: <spr...@li...>
>>>Sent: Thursday, May 22, 2003 4:29 PM
>>>Subject: RE: [Springframework-developer] Code changes for 0.8?
>>>
>>>
>>>Besides having reworked the form controller's handling of resubmit=
s,
>=20
> I've
>=20
>>>also created an extensive test suite for ControllerServlet and som=
e web
>>>support classes. We're at overall >64% now!
>>>
>>>Additionally, I've refined some ApplicationContext stuff (moved
>>>OPTIONS_BEAN_NAME from ApplicationContext to AbstractApplicationCo=
ntext
>>>etc), and cleaned the exception handling in the beans package (e.g=
.
>=20
> rethrow
>=20
>>>BeansException directly when catching Exception instead of wrappin=
g it).
>>>
>>>Rethrown exceptions don't get logged anymore, as they are logged b=
y the
>>>highest level exception handler anyway (-> no double stack traces =
in the
>>>console). I've also commented out the println(this) on printing a
>=20
> rootCause
>=20
>>>stack trace: As a root stack trace will always get printed after t=
he
>>>exception's message, those lines have only added redundant informa=
tion,
>>>cluttering the console.
>>>
>>>I've removed FrameworkServlet's debug support, I don't see any rea=
l use
>=20
> case
>=20
>>>for it. During development, Log4J's debug log is all you need, IMO=
 - you
>>>exactly see what handlers/mappings/etc get used, no need for bindi=
ng
>=20
> them to
>=20
>>>the request.
>>>
>>>I'm also gonna move the web.mock classes back to the test sources,=
 as
>=20
> they
>=20
>>>are pretty rough, and not really meant for usage within applicatio=
n
>>>development - in constrast to the JNDI mocks, for example.
>>>
>>>I'll check my stuff in within the next 2 hours. Everybody, please =
test
>=20
> the
>=20
>>>current framework version in your apps! We should really try to re=
lease
>=20
> a
>=20
>>>0.8 as stable as possible.
>>>
>>>BTW, what's the current status in terms of code beautification (Ja=
lopy
>=20
> etc)?
>=20
>>>We have mixed headers in our files at the moment, and sometimes
>=20
> inconsistent
>=20
>>>formatting. Do we aim to clean this for 0.8?
>>>
>>>Juergen
>>>
>>>

RE: [Springframework-developer] Code changes for 0.8?

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

I've just committed the changes.

There's a DataSourceUtils.getDataSourceFromJndi(jndiName) method again, =
assuming running in a container (i.e. adding the prefix "java:comp/env/" =
if not already contained). An overloaded =
getDataSourceFromJndi(jndiName,inContainer) version allows for control =
of the prefixing.

JndiObjectFactoryBean is now a very simple subclass of =
AbstractJndiLocator, supporting the same properties: jndiTemplate, =
jndiName, inContainer. A DataSource definition can thus look as follows:

	<bean name=3D"dataSource" =
class=3D"com.interface21.jndi.JndiObjectFactoryBean">
		<property name=3D"jndiName">jdbc/myds</property>
	</bean>

The following definition is equivalent:

	<bean name=3D"dataSource" =
class=3D"com.interface21.jndi.JndiObjectFactoryBean">
		<property name=3D"jndiName">java:comp/env/jdbc/myds</property>
	</bean>

Or, when not running in a container (no implicit "java:comp/env/" =
prefix):

	<bean name=3D"dataSource" =
class=3D"com.interface21.jndi.JndiObjectFactoryBean">
		<property name=3D"jndiName">java:/myds</property>
		<property name=3D"inContainer">false</property>
	</bean>

Notice the "jndiName" property, instead of the former =
JndiDataSourceBean's "name".

Regards,
Juergen


-----Original Message-----
From: tri...@tr... [mailto:tri...@tr...]
Sent: Friday, May 23, 2003 1:27 PM
To: j=FCrgen h=F6ller [werk3AT]
Cc: spr...@li...
Subject: RE: [Springframework-developer] Code changes for 0.8?


J=FCrgen,

Yes, that is the scenario.  Obtain the DataSource based on the JNDI name =
and=20
pass it in to the constructor for the JdbcTemplate or a class that =
extends=20
Mapping SqlQuery.

While we are on the subject of JDBC.  Do we really have to require an =
explicit=20
compile for the RdbmsOperation and its subclasses.  Currently we throw =20
InvalidDataAccessApiUsageException when we try to use an operation that =
has=20
not been comiled.  We could just as easily execute the compile() at that =

point, since we know what the problem is. =20

Thomas

> Good point indeed, using Spring JDBC without an ApplicationContext. =
I'll
> reintroduce a simple version of it, using a plain JndiTemplate. =
Sometimes I'm
> a little over-eager in terms of simplification, sorry :-)
>=20
> I assume that the typical scenario for this is somewhat like the =
following:
>=20
> 	DataSource ds =3D DataSourceUtils.getDataSourceFromJndi("jdbc/cbx");
> 	JdbcTemplate jt =3D new JdbcTemplate(ds);
> 	jt.<doSomething>;
>=20
> Would that be enough? I'm not keen on introducing an additional =
JdbcTemplate
> constructor with a DataSource NAME. The retrieved DataSource will =
typically
> be kept somewhere anyway.
>=20
> I'm also gonna make JndiObjectFactoryBean extend AbstractJndiLocator, =
for
> maximum code reuse. We'll also have AbstractJndiLocator's =
"inContainer"
> property then, to be able to control "java:comp/env" prefixing
> (inContainer=3Dfalse means plain JNDI name, the default =
inContainer=3Dtrue means
> prefix "java:comp/env" if not already contained).
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...]
> Sent: Friday, May 23, 2003 8:36 AM
> To: tri...@tr...; j=FCrgen h=F6ller [werk3AT]
> Cc: spr...@li...
> Subject: Re: [Springframework-developer] Code changes for 0.8?
>=20
>=20
> I agree with Thomas. Good point. At the moment I know of 2 companies =
using
> Spring JDBC only. If they have to do the JNDI stuff themselves it =
reduces
> the benefit.
>=20
> Rod
>=20
> ----- Original Message -----
> From: <tri...@tr...>
> To: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
> Cc: "Rod Johnson" <rod...@in...>;
> <spr...@li...>
> Sent: Friday, May 23, 2003 2:06 AM
> Subject: RE: [Springframework-developer] Code changes for 0.8?
>=20
>=20
> > J=FCrgen,
> >
> > I'd prefer to keep DataSourceUtils.getDataSourceFromJndi for =
applications
> that
> > only use the JDBC framework.  Maybe we could change the way it does =
the
> lookup
> > to make it similar to the JndiObjectFactoryBean.  What do you all =
think?
> >
> > Thomas
> >
> > > Regarding mock objects, I think that the JNDI mocks do have value =
for
> > > application developers: They can serve as JNDI replacement for
> applications
> > > test environments and standalone applications, running the same =
code and
> > > config files as in the container environment.
> > >
> > > We are using this to be able to reuse the same Hibernate config =
file for
> both
> > > web app and test environments. In the standalone access, we simply =
bind
> a
> > > DriverManagerDataSource to the same JNDI location, with Spring's =
JNDI
> mocks
> > > as infrastructure.
> > >
> > > Other development projects can use this strategy too, and EasyMock =
won't
> help
> > > here. Thus, I'd like the JNDI mocks to stay, but all other mocks =
should
> not
> > > be in our src tree IMO, as they only serve within our test suites.
> > >
> > > Regarding FrameworkServlet's debug support, that were exactly the
> reasons why
> > > I've removed them. It cluttered up the code somewhat, and I don't
> consider it
> > > necessary.
> > >
> > > ---
> > >
> > > I've just added one more refactoring: I've replaced both
> > > JndiDataSourceBean/JndiDataSourceEditor and
> > > JndiSessionFactoryBean/JndiSessionFactoryEditor with generic
> implementations,
> > > namely JndiObjectFactoryBean and JndiObjectEditor. Effectively, =
the
> > > FactoryBeans have just returned Objects, so there's no need for
> specialized
> > > implementations. I've also removed =
DataSourceUtils.getDataSourceFromJndi
> and
> > > SessionFactoryUtils.getSessionFactoryFromJndi, as they aren't
> recommended
> > > anymore. I don't like too many ways to achieve 1 thing.
> > >
> > > One more reason is that the former getDataSourceFromJndi always =
looked
> up the
> > > given name under "java:comp/env", if not contained in the name. =
This is
> too
> > > inflexible: A DataSource might be bound to any JNDI name, in fact.
> > > JndiObjectFactoryBean and JndiObjectEditor need the full JNDI =
name: This
> is
> > > clearer and not much effort.
> > >
> > > So Isabelle and Ken, please use
> com.interface21.jndi.JndiObjectFactoryBean
> > > for DataSource definitions instead of
> > > com.interface21.jdbc.datasource.JndiDataSourceBean! Sorry for the =
late
> > > change, but I think it's worth it.
> > >
> > > Gonna check all this stuff in the next hour...
> > >
> > > Regards,
> > > Juergen
> > >
> > >
> > > -----Original Message-----
> > > From: Rod Johnson [mailto:rod...@in...]
> > > Sent: Thursday, May 22, 2003 6:24 PM
> > > To: j=FCrgen h=F6ller [werk3AT]
> > > Cc: spr...@li...
> > > Subject: Re: [Springframework-developer] Code changes for 0.8?
> > >
> > >
> > > Excellent. Great news on the test coverage! You've been doing good =
work
> > > here.
> > >
> > > I'm glad you've cleaned up the stack traces... There were quite a =
few
> > > repeated stack traces a long time ago, and I got many of them (but
> obviously
> > > not all). I think the volume and quality of stack traces is very
> important.
> > > It's about the only thing that really bugs me with Hibernate 2.0 =
RC1,
> for
> > > example. We may need to consider a consistent approach to logging
> (levels
> > > etc.) for 0.9 or 1.0.
> > >
> > > I imagine removing debug support in framework servlet removed a =
lot of
> code.
> > > I actually eyed it myself with my scalpel in mind recently. It did =
make
> the
> > > code much harder to understand and the fewer lines of code, the =
fewer
> > > potential bugs. Also, I don't think it was documented anywhere, so =
I
> doubt
> > > anyone will miss it too much. (I did use it myself occasionally =
but I'm
> sure
> > > I can live without it.)
> > >
> > > I'm not sure that *any* mock objects should be in the main source =
tree.
> > > Maybe we need a third tree for the mocks and things like
> > > EjbContainerDetective that are handy but not part of the core =
spring
> > > runtime. I don't tend to use our mock objects much anymore, since =
I
> > > discovered the wonder that is EasyMock.
> > >
> > > Code formatting I think is a 0.9 thing. Certainly after we have a =
tagged
> > > stable release. We don't want to delay 0.8 for this.
> > >
> > > I'm away this weekend (bank holiday in the UK), so won't be doing =
any
> work.
> > > Anything I do add to Spring until we go to 0.8 will either be an =
urgent
> bug
> > > fix or simply additional tests.
> > >
> > > Regards,
> > > Rod
> > >
> > > ----- Original Message -----
> > > From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
> > > To: <spr...@li...>
> > > Sent: Thursday, May 22, 2003 4:29 PM
> > > Subject: RE: [Springframework-developer] Code changes for 0.8?
> > >
> > >
> > > Besides having reworked the form controller's handling of =
resubmits,
> I've
> > > also created an extensive test suite for ControllerServlet and =
some web
> > > support classes. We're at overall >64% now!
> > >
> > > Additionally, I've refined some ApplicationContext stuff (moved
> > > OPTIONS_BEAN_NAME from ApplicationContext to =
AbstractApplicationContext
> > > etc), and cleaned the exception handling in the beans package =
(e.g.
> rethrow
> > > BeansException directly when catching Exception instead of =
wrapping it).
> > >
> > > Rethrown exceptions don't get logged anymore, as they are logged =
by the
> > > highest level exception handler anyway (-> no double stack traces =
in the
> > > console). I've also commented out the println(this) on printing a
> rootCause
> > > stack trace: As a root stack trace will always get printed after =
the
> > > exception's message, those lines have only added redundant =
information,
> > > cluttering the console.
> > >
> > > I've removed FrameworkServlet's debug support, I don't see any =
real use
> case
> > > for it. During development, Log4J's debug log is all you need, IMO =
- you
> > > exactly see what handlers/mappings/etc get used, no need for =
binding
> them to
> > > the request.
> > >
> > > I'm also gonna move the web.mock classes back to the test sources, =
as
> they
> > > are pretty rough, and not really meant for usage within =
application
> > > development - in constrast to the JNDI mocks, for example.
> > >
> > > I'll check my stuff in within the next 2 hours. Everybody, please =
test
> the
> > > current framework version in your apps! We should really try to =
release
> a
> > > 0.8 as stable as possible.
> > >
> > > BTW, what's the current status in terms of code beautification =
(Jalopy
> etc)?
> > > We have mixed headers in our files at the moment, and sometimes
> inconsistent
> > > formatting. Do we aim to clean this for 0.8?
> > >
> > > Juergen
> > >
> > >
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: ObjectStore.
> > > If flattening out C++ or Java code to make your application fit in =
a
> > > relational database is painful, don't do it! Check out =
ObjectStore.
> > > Now part of Progress Software. =
http://www.objectstore.net/sourceforge
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > > =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> > >
> >
> >
> >
>=20
>=20
>=20

RE: [Springframework-developer] Code changes for 0.8?

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

Jürgen,

Yes, that is the scenario.  Obtain the DataSource based on the JNDI name and 
pass it in to the constructor for the JdbcTemplate or a class that extends 
Mapping SqlQuery.

While we are on the subject of JDBC.  Do we really have to require an explicit 
compile for the RdbmsOperation and its subclasses.  Currently we throw  
InvalidDataAccessApiUsageException when we try to use an operation that has 
not been comiled.  We could just as easily execute the compile() at that 
point, since we know what the problem is.  

Thomas

> Good point indeed, using Spring JDBC without an ApplicationContext. I'll
> reintroduce a simple version of it, using a plain JndiTemplate. Sometimes I'm
> a little over-eager in terms of simplification, sorry :-)
> 
> I assume that the typical scenario for this is somewhat like the following:
> 
> 	DataSource ds = DataSourceUtils.getDataSourceFromJndi("jdbc/cbx");
> 	JdbcTemplate jt = new JdbcTemplate(ds);
> 	jt.<doSomething>;
> 
> Would that be enough? I'm not keen on introducing an additional JdbcTemplate
> constructor with a DataSource NAME. The retrieved DataSource will typically
> be kept somewhere anyway.
> 
> I'm also gonna make JndiObjectFactoryBean extend AbstractJndiLocator, for
> maximum code reuse. We'll also have AbstractJndiLocator's "inContainer"
> property then, to be able to control "java:comp/env" prefixing
> (inContainer=false means plain JNDI name, the default inContainer=true means
> prefix "java:comp/env" if not already contained).
> 
> Juergen
> 
> 
> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...]
> Sent: Friday, May 23, 2003 8:36 AM
> To: tri...@tr...; jürgen höller [werk3AT]
> Cc: spr...@li...
> Subject: Re: [Springframework-developer] Code changes for 0.8?
> 
> 
> I agree with Thomas. Good point. At the moment I know of 2 companies using
> Spring JDBC only. If they have to do the JNDI stuff themselves it reduces
> the benefit.
> 
> Rod
> 
> ----- Original Message -----
> From: <tri...@tr...>
> To: "jürgen höller [werk3AT]" <jue...@we...>
> Cc: "Rod Johnson" <rod...@in...>;
> <spr...@li...>
> Sent: Friday, May 23, 2003 2:06 AM
> Subject: RE: [Springframework-developer] Code changes for 0.8?
> 
> 
> > Jürgen,
> >
> > I'd prefer to keep DataSourceUtils.getDataSourceFromJndi for applications
> that
> > only use the JDBC framework.  Maybe we could change the way it does the
> lookup
> > to make it similar to the JndiObjectFactoryBean.  What do you all think?
> >
> > Thomas
> >
> > > Regarding mock objects, I think that the JNDI mocks do have value for
> > > application developers: They can serve as JNDI replacement for
> applications
> > > test environments and standalone applications, running the same code and
> > > config files as in the container environment.
> > >
> > > We are using this to be able to reuse the same Hibernate config file for
> both
> > > web app and test environments. In the standalone access, we simply bind
> a
> > > DriverManagerDataSource to the same JNDI location, with Spring's JNDI
> mocks
> > > as infrastructure.
> > >
> > > Other development projects can use this strategy too, and EasyMock won't
> help
> > > here. Thus, I'd like the JNDI mocks to stay, but all other mocks should
> not
> > > be in our src tree IMO, as they only serve within our test suites.
> > >
> > > Regarding FrameworkServlet's debug support, that were exactly the
> reasons why
> > > I've removed them. It cluttered up the code somewhat, and I don't
> consider it
> > > necessary.
> > >
> > > ---
> > >
> > > I've just added one more refactoring: I've replaced both
> > > JndiDataSourceBean/JndiDataSourceEditor and
> > > JndiSessionFactoryBean/JndiSessionFactoryEditor with generic
> implementations,
> > > namely JndiObjectFactoryBean and JndiObjectEditor. Effectively, the
> > > FactoryBeans have just returned Objects, so there's no need for
> specialized
> > > implementations. I've also removed DataSourceUtils.getDataSourceFromJndi
> and
> > > SessionFactoryUtils.getSessionFactoryFromJndi, as they aren't
> recommended
> > > anymore. I don't like too many ways to achieve 1 thing.
> > >
> > > One more reason is that the former getDataSourceFromJndi always looked
> up the
> > > given name under "java:comp/env", if not contained in the name. This is
> too
> > > inflexible: A DataSource might be bound to any JNDI name, in fact.
> > > JndiObjectFactoryBean and JndiObjectEditor need the full JNDI name: This
> is
> > > clearer and not much effort.
> > >
> > > So Isabelle and Ken, please use
> com.interface21.jndi.JndiObjectFactoryBean
> > > for DataSource definitions instead of
> > > com.interface21.jdbc.datasource.JndiDataSourceBean! Sorry for the late
> > > change, but I think it's worth it.
> > >
> > > Gonna check all this stuff in the next hour...
> > >
> > > Regards,
> > > Juergen
> > >
> > >
> > > -----Original Message-----
> > > From: Rod Johnson [mailto:rod...@in...]
> > > Sent: Thursday, May 22, 2003 6:24 PM
> > > To: jürgen höller [werk3AT]
> > > Cc: spr...@li...
> > > Subject: Re: [Springframework-developer] Code changes for 0.8?
> > >
> > >
> > > Excellent. Great news on the test coverage! You've been doing good work
> > > here.
> > >
> > > I'm glad you've cleaned up the stack traces... There were quite a few
> > > repeated stack traces a long time ago, and I got many of them (but
> obviously
> > > not all). I think the volume and quality of stack traces is very
> important.
> > > It's about the only thing that really bugs me with Hibernate 2.0 RC1,
> for
> > > example. We may need to consider a consistent approach to logging
> (levels
> > > etc.) for 0.9 or 1.0.
> > >
> > > I imagine removing debug support in framework servlet removed a lot of
> code.
> > > I actually eyed it myself with my scalpel in mind recently. It did make
> the
> > > code much harder to understand and the fewer lines of code, the fewer
> > > potential bugs. Also, I don't think it was documented anywhere, so I
> doubt
> > > anyone will miss it too much. (I did use it myself occasionally but I'm
> sure
> > > I can live without it.)
> > >
> > > I'm not sure that *any* mock objects should be in the main source tree.
> > > Maybe we need a third tree for the mocks and things like
> > > EjbContainerDetective that are handy but not part of the core spring
> > > runtime. I don't tend to use our mock objects much anymore, since I
> > > discovered the wonder that is EasyMock.
> > >
> > > Code formatting I think is a 0.9 thing. Certainly after we have a tagged
> > > stable release. We don't want to delay 0.8 for this.
> > >
> > > I'm away this weekend (bank holiday in the UK), so won't be doing any
> work.
> > > Anything I do add to Spring until we go to 0.8 will either be an urgent
> bug
> > > fix or simply additional tests.
> > >
> > > Regards,
> > > Rod
> > >
> > > ----- Original Message -----
> > > From: "jürgen höller [werk3AT]" <jue...@we...>
> > > To: <spr...@li...>
> > > Sent: Thursday, May 22, 2003 4:29 PM
> > > Subject: RE: [Springframework-developer] Code changes for 0.8?
> > >
> > >
> > > Besides having reworked the form controller's handling of resubmits,
> I've
> > > also created an extensive test suite for ControllerServlet and some web
> > > support classes. We're at overall >64% now!
> > >
> > > Additionally, I've refined some ApplicationContext stuff (moved
> > > OPTIONS_BEAN_NAME from ApplicationContext to AbstractApplicationContext
> > > etc), and cleaned the exception handling in the beans package (e.g.
> rethrow
> > > BeansException directly when catching Exception instead of wrapping it).
> > >
> > > Rethrown exceptions don't get logged anymore, as they are logged by the
> > > highest level exception handler anyway (-> no double stack traces in the
> > > console). I've also commented out the println(this) on printing a
> rootCause
> > > stack trace: As a root stack trace will always get printed after the
> > > exception's message, those lines have only added redundant information,
> > > cluttering the console.
> > >
> > > I've removed FrameworkServlet's debug support, I don't see any real use
> case
> > > for it. During development, Log4J's debug log is all you need, IMO - you
> > > exactly see what handlers/mappings/etc get used, no need for binding
> them to
> > > the request.
> > >
> > > I'm also gonna move the web.mock classes back to the test sources, as
> they
> > > are pretty rough, and not really meant for usage within application
> > > development - in constrast to the JNDI mocks, for example.
> > >
> > > I'll check my stuff in within the next 2 hours. Everybody, please test
> the
> > > current framework version in your apps! We should really try to release
> a
> > > 0.8 as stable as possible.
> > >
> > > BTW, what's the current status in terms of code beautification (Jalopy
> etc)?
> > > We have mixed headers in our files at the moment, and sometimes
> inconsistent
> > > formatting. Do we aim to clean this for 0.8?
> > >
> > > Juergen
> > >
> > >
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: ObjectStore.
> > > If flattening out C++ or Java code to make your application fit in a
> > > relational database is painful, don't do it! Check out ObjectStore.
> > > Now part of Progress Software. http://www.objectstore.net/sourceforge
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> > >
> >
> >
> >
> 
> 
> 

RE: [Springframework-developer] Code changes for 0.8?

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

>I'm not keen on introducing an additional JdbcTemplate 
constructor with a DataSource NAME. 

I agree.

R

RE: [Springframework-developer] Code changes for 0.8?

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

Good point indeed, using Spring JDBC without an ApplicationContext. I'll =
reintroduce a simple version of it, using a plain JndiTemplate. =
Sometimes I'm a little over-eager in terms of simplification, sorry :-)

I assume that the typical scenario for this is somewhat like the =
following:

	DataSource ds =3D DataSourceUtils.getDataSourceFromJndi("jdbc/cbx");
	JdbcTemplate jt =3D new JdbcTemplate(ds);
	jt.<doSomething>;

Would that be enough? I'm not keen on introducing an additional =
JdbcTemplate constructor with a DataSource NAME. The retrieved =
DataSource will typically be kept somewhere anyway.

I'm also gonna make JndiObjectFactoryBean extend AbstractJndiLocator, =
for maximum code reuse. We'll also have AbstractJndiLocator's =
"inContainer" property then, to be able to control "java:comp/env" =
prefixing (inContainer=3Dfalse means plain JNDI name, the default =
inContainer=3Dtrue means prefix "java:comp/env" if not already =
contained).

Juergen


-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: Friday, May 23, 2003 8:36 AM
To: tri...@tr...; j=FCrgen h=F6ller [werk3AT]
Cc: spr...@li...
Subject: Re: [Springframework-developer] Code changes for 0.8?


I agree with Thomas. Good point. At the moment I know of 2 companies =
using
Spring JDBC only. If they have to do the JNDI stuff themselves it =
reduces
the benefit.

Rod

----- Original Message -----
From: <tri...@tr...>
To: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
Cc: "Rod Johnson" <rod...@in...>;
<spr...@li...>
Sent: Friday, May 23, 2003 2:06 AM
Subject: RE: [Springframework-developer] Code changes for 0.8?


> J=FCrgen,
>
> I'd prefer to keep DataSourceUtils.getDataSourceFromJndi for =
applications
that
> only use the JDBC framework.  Maybe we could change the way it does =
the
lookup
> to make it similar to the JndiObjectFactoryBean.  What do you all =
think?
>
> Thomas
>
> > Regarding mock objects, I think that the JNDI mocks do have value =
for
> > application developers: They can serve as JNDI replacement for
applications
> > test environments and standalone applications, running the same code =
and
> > config files as in the container environment.
> >
> > We are using this to be able to reuse the same Hibernate config file =
for
both
> > web app and test environments. In the standalone access, we simply =
bind
a
> > DriverManagerDataSource to the same JNDI location, with Spring's =
JNDI
mocks
> > as infrastructure.
> >
> > Other development projects can use this strategy too, and EasyMock =
won't
help
> > here. Thus, I'd like the JNDI mocks to stay, but all other mocks =
should
not
> > be in our src tree IMO, as they only serve within our test suites.
> >
> > Regarding FrameworkServlet's debug support, that were exactly the
reasons why
> > I've removed them. It cluttered up the code somewhat, and I don't
consider it
> > necessary.
> >
> > ---
> >
> > I've just added one more refactoring: I've replaced both
> > JndiDataSourceBean/JndiDataSourceEditor and
> > JndiSessionFactoryBean/JndiSessionFactoryEditor with generic
implementations,
> > namely JndiObjectFactoryBean and JndiObjectEditor. Effectively, the
> > FactoryBeans have just returned Objects, so there's no need for
specialized
> > implementations. I've also removed =
DataSourceUtils.getDataSourceFromJndi
and
> > SessionFactoryUtils.getSessionFactoryFromJndi, as they aren't
recommended
> > anymore. I don't like too many ways to achieve 1 thing.
> >
> > One more reason is that the former getDataSourceFromJndi always =
looked
up the
> > given name under "java:comp/env", if not contained in the name. This =
is
too
> > inflexible: A DataSource might be bound to any JNDI name, in fact.
> > JndiObjectFactoryBean and JndiObjectEditor need the full JNDI name: =
This
is
> > clearer and not much effort.
> >
> > So Isabelle and Ken, please use
com.interface21.jndi.JndiObjectFactoryBean
> > for DataSource definitions instead of
> > com.interface21.jdbc.datasource.JndiDataSourceBean! Sorry for the =
late
> > change, but I think it's worth it.
> >
> > Gonna check all this stuff in the next hour...
> >
> > Regards,
> > Juergen
> >
> >
> > -----Original Message-----
> > From: Rod Johnson [mailto:rod...@in...]
> > Sent: Thursday, May 22, 2003 6:24 PM
> > To: j=FCrgen h=F6ller [werk3AT]
> > Cc: spr...@li...
> > Subject: Re: [Springframework-developer] Code changes for 0.8?
> >
> >
> > Excellent. Great news on the test coverage! You've been doing good =
work
> > here.
> >
> > I'm glad you've cleaned up the stack traces... There were quite a =
few
> > repeated stack traces a long time ago, and I got many of them (but
obviously
> > not all). I think the volume and quality of stack traces is very
important.
> > It's about the only thing that really bugs me with Hibernate 2.0 =
RC1,
for
> > example. We may need to consider a consistent approach to logging
(levels
> > etc.) for 0.9 or 1.0.
> >
> > I imagine removing debug support in framework servlet removed a lot =
of
code.
> > I actually eyed it myself with my scalpel in mind recently. It did =
make
the
> > code much harder to understand and the fewer lines of code, the =
fewer
> > potential bugs. Also, I don't think it was documented anywhere, so I
doubt
> > anyone will miss it too much. (I did use it myself occasionally but =
I'm
sure
> > I can live without it.)
> >
> > I'm not sure that *any* mock objects should be in the main source =
tree.
> > Maybe we need a third tree for the mocks and things like
> > EjbContainerDetective that are handy but not part of the core spring
> > runtime. I don't tend to use our mock objects much anymore, since I
> > discovered the wonder that is EasyMock.
> >
> > Code formatting I think is a 0.9 thing. Certainly after we have a =
tagged
> > stable release. We don't want to delay 0.8 for this.
> >
> > I'm away this weekend (bank holiday in the UK), so won't be doing =
any
work.
> > Anything I do add to Spring until we go to 0.8 will either be an =
urgent
bug
> > fix or simply additional tests.
> >
> > Regards,
> > Rod
> >
> > ----- Original Message -----
> > From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
> > To: <spr...@li...>
> > Sent: Thursday, May 22, 2003 4:29 PM
> > Subject: RE: [Springframework-developer] Code changes for 0.8?
> >
> >
> > Besides having reworked the form controller's handling of resubmits,
I've
> > also created an extensive test suite for ControllerServlet and some =
web
> > support classes. We're at overall >64% now!
> >
> > Additionally, I've refined some ApplicationContext stuff (moved
> > OPTIONS_BEAN_NAME from ApplicationContext to =
AbstractApplicationContext
> > etc), and cleaned the exception handling in the beans package (e.g.
rethrow
> > BeansException directly when catching Exception instead of wrapping =
it).
> >
> > Rethrown exceptions don't get logged anymore, as they are logged by =
the
> > highest level exception handler anyway (-> no double stack traces in =
the
> > console). I've also commented out the println(this) on printing a
rootCause
> > stack trace: As a root stack trace will always get printed after the
> > exception's message, those lines have only added redundant =
information,
> > cluttering the console.
> >
> > I've removed FrameworkServlet's debug support, I don't see any real =
use
case
> > for it. During development, Log4J's debug log is all you need, IMO - =
you
> > exactly see what handlers/mappings/etc get used, no need for binding
them to
> > the request.
> >
> > I'm also gonna move the web.mock classes back to the test sources, =
as
they
> > are pretty rough, and not really meant for usage within application
> > development - in constrast to the JNDI mocks, for example.
> >
> > I'll check my stuff in within the next 2 hours. Everybody, please =
test
the
> > current framework version in your apps! We should really try to =
release
a
> > 0.8 as stable as possible.
> >
> > BTW, what's the current status in terms of code beautification =
(Jalopy
etc)?
> > We have mixed headers in our files at the moment, and sometimes
inconsistent
> > formatting. Do we aim to clean this for 0.8?
> >
> > Juergen
> >
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: ObjectStore.
> > If flattening out C++ or Java code to make your application fit in a
> > relational database is painful, don't do it! Check out ObjectStore.
> > Now part of Progress Software. =
http://www.objectstore.net/sourceforge
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
>
>
>

Re: [Springframework-developer] SqlUpdate and insert functionality

[Isabelle M. <isa...@me...>]

Hi Ken,

Your key column should NOT be auto-increment.

If that doesn't solve the problem, let me know, and pls attach the code so I don't have top type it over. Will look at it tonight or tomorrow. I'll also look into the strange log output, probably a stupid booboo.

Isabelle

On Thu, May 22, 2003 at 11:25:08PM -0500, Ken Krebs wrote:
> Hi Isabelle,
> 
> I have a problem using the following petclinic class that inserts a new 
> visit into the DB :
> 
>    class NewVisit extends SqlUpdate {
>       
>        public NewVisit(DataSource ds) {
>            super(ds, "INSERT INTO visits VALUES(?,?,?,?)");
>            declareParameter(new SqlParameter(Types.INTEGER));
>            declareParameter(new SqlParameter(Types.INTEGER));
>            declareParameter(new SqlParameter(Types.DATE));
>            declareParameter(new SqlParameter(Types.VARCHAR));
>            compile();
>        }
>       
>        public int insert(Visit visit) {
>            KeyBinder keybinder = new KeyBinder() {
>                public void bind(PreparedStatement ps, Object obj) 
> throws SQLException {
>                    ps.setObject(1, obj);
>                }
>            };
>           
>            MySQLMaxValueIncrementer incr = new 
> MySQLMaxValueIncrementer(getDataSource(), "visits_seq", "seq", 1);
>           
>            logger.info("Visit petId = " + visit.getPetId());
>           
>            Object[] objs = new Object[] {
>                null,
>                new Integer(visit.getPetId()),
>                visit.getVisitDate(),
>                visit.getDescription()
>            };
>           
>            JdbcTemplate.InsertRetval retVal = update(objs, keybinder, 
> incr, Integer.class);
>            visit.setId(((Integer) retVal.getKey()).intValue());
>           
>            logger.info("Visit id = " + visit.getId() + "   petId = " + 
> visit.getPetId());
>           
>            return retVal.getRowsAffected();
>        }
>       
>    }
> 
> My table definitions for visits and its sequencer are :
> 
> CREATE TABLE visits (
>  id INT(4) UNSIGNED NOT NULL AUTO_INCREMENT,
>  pet_id INT(4) UNSIGNED NOT NULL REFERENCES pets(id),
>  visit_date DATE,
>  description VARCHAR(255),
>  PRIMARY KEY(id),
>  INDEX(pet_id)
> );
> INSERT INTO visits VALUES (1, 7, '1996-03-04', 'rabies shot');
> INSERT INTO visits VALUES (NULL, 8, '1996-03-04', 'rabies shot');
> INSERT INTO visits VALUES (NULL, 8, '1996-06-04', 'neutered');
> INSERT INTO visits VALUES (NULL, 7, '1996-09-04', 'spayed');
> 
> CREATE TABLE visits_seq (
>  seq INT(4) UNSIGNED NOT NULL
> );
> INSERT INTO visits_seq VALUES (5);
> 
> 
> The data is written correctly to the DB using the auto-incremented 
> visit_id. The problem is that the getKey() function of the 
> returned InsertRetval returns 0, not the id that was used for the 
> insert. I wanted to use the value to update my cache directly without 
> having to requery the DB for all this pet's visits. I am working around 
> it by doing just that.
> 
> 
> I include below a relevant snippet from the INFO log:
> 
> 2003-05-22 22:53:37,966 INFO [petclinic.support.ClinicImpl$NewVisit] - 
> <Compiled OK>
> 2003-05-22 22:53:37,996 INFO [petclinic.support.ClinicImpl$NewVisit] - 
> <Visit petId = 7>
> 2003-05-22 22:53:38,006 INFO [com.interface21.jdbc.object.SqlUpdate] - 
> <Compiled OK>
> 2003-05-22 22:53:38,016 INFO [com.interface21.jdbc.core.JdbcTemplate] - 
> <JDBCTemplate: update affected 1 rows>
> 2003-05-22 22:53:38,016 INFO [com.interface21.jdbc.object.SqlUpdate] - 
> <1 rows affected by SQL update [update visits_seq set seq = 
> last_insert_id(seq + 1)]>
> 2003-05-22 22:53:38,026 INFO [com.interface21.jdbc.object.SqlFunction] - 
> <Compiled OK>
> 2003-05-22 22:53:38,036 INFO [com.interface21.jdbc.core.JdbcTemplate] - 
> <Executing SQL query using PreparedStatement: 
> [PreparedStatementCreatorFactory.PreparedStatementCreatorImpl: 
> sql={select last_insert_id()}: params={}]>
> 2003-05-22 22:53:38,036 INFO [com.interface21.jdbc.core.JdbcTemplate] - 
> <JDBCTemplate: update affected 
> com.interface21.jdbc.core.JdbcTemplate$InsertRetval@1ebe3f0 rows>
> 2003-05-22 22:53:38,036 INFO [petclinic.support.ClinicImpl$NewVisit] - 
> <Visit id = 0   petId = 7>
> 
> Note that the last line shows the visit_id == 0.
> Also note the odd output of the 2nd last line where instead of 
> outputting the no. of rows affected it's printing a toString() of the 
> InsertRetval !!!???
> 
> 
> Am I doing something wrong here ?
> 
> 
> Regards,
> 
> Ken
> 
> 
> 

-- 
Isabelle Muszynski
Software Engineer
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89
Email: isa...@me...
Website: www.meta-logix.com

Re: [Springframework-developer] Code changes for 0.8?

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

I agree with Thomas. Good point. At the moment I know of 2 companies using
Spring JDBC only. If they have to do the JNDI stuff themselves it reduces
the benefit.

Rod

----- Original Message -----
From: <tri...@tr...>
To: "jürgen höller [werk3AT]" <jue...@we...>
Cc: "Rod Johnson" <rod...@in...>;
<spr...@li...>
Sent: Friday, May 23, 2003 2:06 AM
Subject: RE: [Springframework-developer] Code changes for 0.8?


> Jürgen,
>
> I'd prefer to keep DataSourceUtils.getDataSourceFromJndi for applications
that
> only use the JDBC framework.  Maybe we could change the way it does the
lookup
> to make it similar to the JndiObjectFactoryBean.  What do you all think?
>
> Thomas
>
> > Regarding mock objects, I think that the JNDI mocks do have value for
> > application developers: They can serve as JNDI replacement for
applications
> > test environments and standalone applications, running the same code and
> > config files as in the container environment.
> >
> > We are using this to be able to reuse the same Hibernate config file for
both
> > web app and test environments. In the standalone access, we simply bind
a
> > DriverManagerDataSource to the same JNDI location, with Spring's JNDI
mocks
> > as infrastructure.
> >
> > Other development projects can use this strategy too, and EasyMock won't
help
> > here. Thus, I'd like the JNDI mocks to stay, but all other mocks should
not
> > be in our src tree IMO, as they only serve within our test suites.
> >
> > Regarding FrameworkServlet's debug support, that were exactly the
reasons why
> > I've removed them. It cluttered up the code somewhat, and I don't
consider it
> > necessary.
> >
> > ---
> >
> > I've just added one more refactoring: I've replaced both
> > JndiDataSourceBean/JndiDataSourceEditor and
> > JndiSessionFactoryBean/JndiSessionFactoryEditor with generic
implementations,
> > namely JndiObjectFactoryBean and JndiObjectEditor. Effectively, the
> > FactoryBeans have just returned Objects, so there's no need for
specialized
> > implementations. I've also removed DataSourceUtils.getDataSourceFromJndi
and
> > SessionFactoryUtils.getSessionFactoryFromJndi, as they aren't
recommended
> > anymore. I don't like too many ways to achieve 1 thing.
> >
> > One more reason is that the former getDataSourceFromJndi always looked
up the
> > given name under "java:comp/env", if not contained in the name. This is
too
> > inflexible: A DataSource might be bound to any JNDI name, in fact.
> > JndiObjectFactoryBean and JndiObjectEditor need the full JNDI name: This
is
> > clearer and not much effort.
> >
> > So Isabelle and Ken, please use
com.interface21.jndi.JndiObjectFactoryBean
> > for DataSource definitions instead of
> > com.interface21.jdbc.datasource.JndiDataSourceBean! Sorry for the late
> > change, but I think it's worth it.
> >
> > Gonna check all this stuff in the next hour...
> >
> > Regards,
> > Juergen
> >
> >
> > -----Original Message-----
> > From: Rod Johnson [mailto:rod...@in...]
> > Sent: Thursday, May 22, 2003 6:24 PM
> > To: jürgen höller [werk3AT]
> > Cc: spr...@li...
> > Subject: Re: [Springframework-developer] Code changes for 0.8?
> >
> >
> > Excellent. Great news on the test coverage! You've been doing good work
> > here.
> >
> > I'm glad you've cleaned up the stack traces... There were quite a few
> > repeated stack traces a long time ago, and I got many of them (but
obviously
> > not all). I think the volume and quality of stack traces is very
important.
> > It's about the only thing that really bugs me with Hibernate 2.0 RC1,
for
> > example. We may need to consider a consistent approach to logging
(levels
> > etc.) for 0.9 or 1.0.
> >
> > I imagine removing debug support in framework servlet removed a lot of
code.
> > I actually eyed it myself with my scalpel in mind recently. It did make
the
> > code much harder to understand and the fewer lines of code, the fewer
> > potential bugs. Also, I don't think it was documented anywhere, so I
doubt
> > anyone will miss it too much. (I did use it myself occasionally but I'm
sure
> > I can live without it.)
> >
> > I'm not sure that *any* mock objects should be in the main source tree.
> > Maybe we need a third tree for the mocks and things like
> > EjbContainerDetective that are handy but not part of the core spring
> > runtime. I don't tend to use our mock objects much anymore, since I
> > discovered the wonder that is EasyMock.
> >
> > Code formatting I think is a 0.9 thing. Certainly after we have a tagged
> > stable release. We don't want to delay 0.8 for this.
> >
> > I'm away this weekend (bank holiday in the UK), so won't be doing any
work.
> > Anything I do add to Spring until we go to 0.8 will either be an urgent
bug
> > fix or simply additional tests.
> >
> > Regards,
> > Rod
> >
> > ----- Original Message -----
> > From: "jürgen höller [werk3AT]" <jue...@we...>
> > To: <spr...@li...>
> > Sent: Thursday, May 22, 2003 4:29 PM
> > Subject: RE: [Springframework-developer] Code changes for 0.8?
> >
> >
> > Besides having reworked the form controller's handling of resubmits,
I've
> > also created an extensive test suite for ControllerServlet and some web
> > support classes. We're at overall >64% now!
> >
> > Additionally, I've refined some ApplicationContext stuff (moved
> > OPTIONS_BEAN_NAME from ApplicationContext to AbstractApplicationContext
> > etc), and cleaned the exception handling in the beans package (e.g.
rethrow
> > BeansException directly when catching Exception instead of wrapping it).
> >
> > Rethrown exceptions don't get logged anymore, as they are logged by the
> > highest level exception handler anyway (-> no double stack traces in the
> > console). I've also commented out the println(this) on printing a
rootCause
> > stack trace: As a root stack trace will always get printed after the
> > exception's message, those lines have only added redundant information,
> > cluttering the console.
> >
> > I've removed FrameworkServlet's debug support, I don't see any real use
case
> > for it. During development, Log4J's debug log is all you need, IMO - you
> > exactly see what handlers/mappings/etc get used, no need for binding
them to
> > the request.
> >
> > I'm also gonna move the web.mock classes back to the test sources, as
they
> > are pretty rough, and not really meant for usage within application
> > development - in constrast to the JNDI mocks, for example.
> >
> > I'll check my stuff in within the next 2 hours. Everybody, please test
the
> > current framework version in your apps! We should really try to release
a
> > 0.8 as stable as possible.
> >
> > BTW, what's the current status in terms of code beautification (Jalopy
etc)?
> > We have mixed headers in our files at the moment, and sometimes
inconsistent
> > formatting. Do we aim to clean this for 0.8?
> >
> > Juergen
> >
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: ObjectStore.
> > If flattening out C++ or Java code to make your application fit in a
> > relational database is painful, don't do it! Check out ObjectStore.
> > Now part of Progress Software. http://www.objectstore.net/sourceforge
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
>
>
>

[Springframework-developer] SqlUpdate and insert functionality

[Ken K. <kk...@kk...>]

Hi Isabelle,

I have a problem using the following petclinic class that inserts a new 
visit into the DB :

    class NewVisit extends SqlUpdate {
       
        public NewVisit(DataSource ds) {
            super(ds, "INSERT INTO visits VALUES(?,?,?,?)");
            declareParameter(new SqlParameter(Types.INTEGER));
            declareParameter(new SqlParameter(Types.INTEGER));
            declareParameter(new SqlParameter(Types.DATE));
            declareParameter(new SqlParameter(Types.VARCHAR));
            compile();
        }
       
        public int insert(Visit visit) {
            KeyBinder keybinder = new KeyBinder() {
                public void bind(PreparedStatement ps, Object obj) 
throws SQLException {
                    ps.setObject(1, obj);
                }
            };
           
            MySQLMaxValueIncrementer incr = new 
MySQLMaxValueIncrementer(getDataSource(), "visits_seq", "seq", 1);
           
            logger.info("Visit petId = " + visit.getPetId());
           
            Object[] objs = new Object[] {
                null,
                new Integer(visit.getPetId()),
                visit.getVisitDate(),
                visit.getDescription()
            };
           
            JdbcTemplate.InsertRetval retVal = update(objs, keybinder, 
incr, Integer.class);
            visit.setId(((Integer) retVal.getKey()).intValue());
           
            logger.info("Visit id = " + visit.getId() + "   petId = " + 
visit.getPetId());
           
            return retVal.getRowsAffected();
        }
       
    }

My table definitions for visits and its sequencer are :

CREATE TABLE visits (
  id INT(4) UNSIGNED NOT NULL AUTO_INCREMENT,
  pet_id INT(4) UNSIGNED NOT NULL REFERENCES pets(id),
  visit_date DATE,
  description VARCHAR(255),
  PRIMARY KEY(id),
  INDEX(pet_id)
);
INSERT INTO visits VALUES (1, 7, '1996-03-04', 'rabies shot');
INSERT INTO visits VALUES (NULL, 8, '1996-03-04', 'rabies shot');
INSERT INTO visits VALUES (NULL, 8, '1996-06-04', 'neutered');
INSERT INTO visits VALUES (NULL, 7, '1996-09-04', 'spayed');

CREATE TABLE visits_seq (
  seq INT(4) UNSIGNED NOT NULL
);
INSERT INTO visits_seq VALUES (5);


The data is written correctly to the DB using the auto-incremented 
visit_id. The problem is that the getKey() function of the 
returned InsertRetval returns 0, not the id that was used for the 
insert. I wanted to use the value to update my cache directly without 
having to requery the DB for all this pet's visits. I am working around 
it by doing just that.


I include below a relevant snippet from the INFO log:

2003-05-22 22:53:37,966 INFO [petclinic.support.ClinicImpl$NewVisit] - 
<Compiled OK>
2003-05-22 22:53:37,996 INFO [petclinic.support.ClinicImpl$NewVisit] - 
<Visit petId = 7>
2003-05-22 22:53:38,006 INFO [com.interface21.jdbc.object.SqlUpdate] - 
<Compiled OK>
2003-05-22 22:53:38,016 INFO [com.interface21.jdbc.core.JdbcTemplate] - 
<JDBCTemplate: update affected 1 rows>
2003-05-22 22:53:38,016 INFO [com.interface21.jdbc.object.SqlUpdate] - 
<1 rows affected by SQL update [update visits_seq set seq = 
last_insert_id(seq + 1)]>
2003-05-22 22:53:38,026 INFO [com.interface21.jdbc.object.SqlFunction] - 
<Compiled OK>
2003-05-22 22:53:38,036 INFO [com.interface21.jdbc.core.JdbcTemplate] - 
<Executing SQL query using PreparedStatement: 
[PreparedStatementCreatorFactory.PreparedStatementCreatorImpl: 
sql={select last_insert_id()}: params={}]>
2003-05-22 22:53:38,036 INFO [com.interface21.jdbc.core.JdbcTemplate] - 
<JDBCTemplate: update affected 
com.interface21.jdbc.core.JdbcTemplate$InsertRetval@1ebe3f0 rows>
2003-05-22 22:53:38,036 INFO [petclinic.support.ClinicImpl$NewVisit] - 
<Visit id = 0   petId = 7>

Note that the last line shows the visit_id == 0.
Also note the odd output of the 2nd last line where instead of 
outputting the no. of rows affected it's printing a toString() of the 
InsertRetval !!!???


Am I doing something wrong here ?


Regards,

Ken

RE: [Springframework-developer] Code changes for 0.8?

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

Jürgen,

I'd prefer to keep DataSourceUtils.getDataSourceFromJndi for applications that
only use the JDBC framework.  Maybe we could change the way it does the lookup
to make it similar to the JndiObjectFactoryBean.  What do you all think?

Thomas

> Regarding mock objects, I think that the JNDI mocks do have value for
> application developers: They can serve as JNDI replacement for applications
> test environments and standalone applications, running the same code and
> config files as in the container environment.
> 
> We are using this to be able to reuse the same Hibernate config file for both
> web app and test environments. In the standalone access, we simply bind a
> DriverManagerDataSource to the same JNDI location, with Spring's JNDI mocks
> as infrastructure.
> 
> Other development projects can use this strategy too, and EasyMock won't help
> here. Thus, I'd like the JNDI mocks to stay, but all other mocks should not
> be in our src tree IMO, as they only serve within our test suites.
> 
> Regarding FrameworkServlet's debug support, that were exactly the reasons why
> I've removed them. It cluttered up the code somewhat, and I don't consider it
> necessary.
> 
> ---
> 
> I've just added one more refactoring: I've replaced both
> JndiDataSourceBean/JndiDataSourceEditor and
> JndiSessionFactoryBean/JndiSessionFactoryEditor with generic implementations,
> namely JndiObjectFactoryBean and JndiObjectEditor. Effectively, the
> FactoryBeans have just returned Objects, so there's no need for specialized
> implementations. I've also removed DataSourceUtils.getDataSourceFromJndi and
> SessionFactoryUtils.getSessionFactoryFromJndi, as they aren't recommended
> anymore. I don't like too many ways to achieve 1 thing.
> 
> One more reason is that the former getDataSourceFromJndi always looked up the
> given name under "java:comp/env", if not contained in the name. This is too
> inflexible: A DataSource might be bound to any JNDI name, in fact.
> JndiObjectFactoryBean and JndiObjectEditor need the full JNDI name: This is
> clearer and not much effort.
> 
> So Isabelle and Ken, please use com.interface21.jndi.JndiObjectFactoryBean
> for DataSource definitions instead of
> com.interface21.jdbc.datasource.JndiDataSourceBean! Sorry for the late
> change, but I think it's worth it.
> 
> Gonna check all this stuff in the next hour...
> 
> Regards,
> Juergen
> 
> 
> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...]
> Sent: Thursday, May 22, 2003 6:24 PM
> To: jürgen höller [werk3AT]
> Cc: spr...@li...
> Subject: Re: [Springframework-developer] Code changes for 0.8?
> 
> 
> Excellent. Great news on the test coverage! You've been doing good work
> here.
> 
> I'm glad you've cleaned up the stack traces... There were quite a few
> repeated stack traces a long time ago, and I got many of them (but obviously
> not all). I think the volume and quality of stack traces is very important.
> It's about the only thing that really bugs me with Hibernate 2.0 RC1, for
> example. We may need to consider a consistent approach to logging (levels
> etc.) for 0.9 or 1.0.
> 
> I imagine removing debug support in framework servlet removed a lot of code.
> I actually eyed it myself with my scalpel in mind recently. It did make the
> code much harder to understand and the fewer lines of code, the fewer
> potential bugs. Also, I don't think it was documented anywhere, so I doubt
> anyone will miss it too much. (I did use it myself occasionally but I'm sure
> I can live without it.)
> 
> I'm not sure that *any* mock objects should be in the main source tree.
> Maybe we need a third tree for the mocks and things like
> EjbContainerDetective that are handy but not part of the core spring
> runtime. I don't tend to use our mock objects much anymore, since I
> discovered the wonder that is EasyMock.
> 
> Code formatting I think is a 0.9 thing. Certainly after we have a tagged
> stable release. We don't want to delay 0.8 for this.
> 
> I'm away this weekend (bank holiday in the UK), so won't be doing any work.
> Anything I do add to Spring until we go to 0.8 will either be an urgent bug
> fix or simply additional tests.
> 
> Regards,
> Rod
> 
> ----- Original Message -----
> From: "jürgen höller [werk3AT]" <jue...@we...>
> To: <spr...@li...>
> Sent: Thursday, May 22, 2003 4:29 PM
> Subject: RE: [Springframework-developer] Code changes for 0.8?
> 
> 
> Besides having reworked the form controller's handling of resubmits, I've
> also created an extensive test suite for ControllerServlet and some web
> support classes. We're at overall >64% now!
> 
> Additionally, I've refined some ApplicationContext stuff (moved
> OPTIONS_BEAN_NAME from ApplicationContext to AbstractApplicationContext
> etc), and cleaned the exception handling in the beans package (e.g. rethrow
> BeansException directly when catching Exception instead of wrapping it).
> 
> Rethrown exceptions don't get logged anymore, as they are logged by the
> highest level exception handler anyway (-> no double stack traces in the
> console). I've also commented out the println(this) on printing a rootCause
> stack trace: As a root stack trace will always get printed after the
> exception's message, those lines have only added redundant information,
> cluttering the console.
> 
> I've removed FrameworkServlet's debug support, I don't see any real use case
> for it. During development, Log4J's debug log is all you need, IMO - you
> exactly see what handlers/mappings/etc get used, no need for binding them to
> the request.
> 
> I'm also gonna move the web.mock classes back to the test sources, as they
> are pretty rough, and not really meant for usage within application
> development - in constrast to the JNDI mocks, for example.
> 
> I'll check my stuff in within the next 2 hours. Everybody, please test the
> current framework version in your apps! We should really try to release a
> 0.8 as stable as possible.
> 
> BTW, what's the current status in terms of code beautification (Jalopy etc)?
> We have mixed headers in our files at the moment, and sometimes inconsistent
> formatting. Do we aim to clean this for 0.8?
> 
> Juergen
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

RE: [Springframework-developer] Code changes for 0.8?

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

Regarding mock objects, I think that the JNDI mocks do have value for =
application developers: They can serve as JNDI replacement for =
applications test environments and standalone applications, running the =
same code and config files as in the container environment.

We are using this to be able to reuse the same Hibernate config file for =
both web app and test environments. In the standalone access, we simply =
bind a DriverManagerDataSource to the same JNDI location, with Spring's =
JNDI mocks as infrastructure.

Other development projects can use this strategy too, and EasyMock won't =
help here. Thus, I'd like the JNDI mocks to stay, but all other mocks =
should not be in our src tree IMO, as they only serve within our test =
suites.

Regarding FrameworkServlet's debug support, that were exactly the =
reasons why I've removed them. It cluttered up the code somewhat, and I =
don't consider it necessary.

---

I've just added one more refactoring: I've replaced both =
JndiDataSourceBean/JndiDataSourceEditor and =
JndiSessionFactoryBean/JndiSessionFactoryEditor with generic =
implementations, namely JndiObjectFactoryBean and JndiObjectEditor. =
Effectively, the FactoryBeans have just returned Objects, so there's no =
need for specialized implementations. I've also removed =
DataSourceUtils.getDataSourceFromJndi and =
SessionFactoryUtils.getSessionFactoryFromJndi, as they aren't =
recommended anymore. I don't like too many ways to achieve 1 thing.

One more reason is that the former getDataSourceFromJndi always looked =
up the given name under "java:comp/env", if not contained in the name. =
This is too inflexible: A DataSource might be bound to any JNDI name, in =
fact. JndiObjectFactoryBean and JndiObjectEditor need the full JNDI =
name: This is clearer and not much effort.

So Isabelle and Ken, please use =
com.interface21.jndi.JndiObjectFactoryBean for DataSource definitions =
instead of com.interface21.jdbc.datasource.JndiDataSourceBean! Sorry for =
the late change, but I think it's worth it.

Gonna check all this stuff in the next hour...

Regards,
Juergen


-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: Thursday, May 22, 2003 6:24 PM
To: j=FCrgen h=F6ller [werk3AT]
Cc: spr...@li...
Subject: Re: [Springframework-developer] Code changes for 0.8?


Excellent. Great news on the test coverage! You've been doing good work
here.

I'm glad you've cleaned up the stack traces... There were quite a few
repeated stack traces a long time ago, and I got many of them (but =
obviously
not all). I think the volume and quality of stack traces is very =
important.
It's about the only thing that really bugs me with Hibernate 2.0 RC1, =
for
example. We may need to consider a consistent approach to logging =
(levels
etc.) for 0.9 or 1.0.

I imagine removing debug support in framework servlet removed a lot of =
code.
I actually eyed it myself with my scalpel in mind recently. It did make =
the
code much harder to understand and the fewer lines of code, the fewer
potential bugs. Also, I don't think it was documented anywhere, so I =
doubt
anyone will miss it too much. (I did use it myself occasionally but I'm =
sure
I can live without it.)

I'm not sure that *any* mock objects should be in the main source tree.
Maybe we need a third tree for the mocks and things like
EjbContainerDetective that are handy but not part of the core spring
runtime. I don't tend to use our mock objects much anymore, since I
discovered the wonder that is EasyMock.

Code formatting I think is a 0.9 thing. Certainly after we have a tagged
stable release. We don't want to delay 0.8 for this.

I'm away this weekend (bank holiday in the UK), so won't be doing any =
work.
Anything I do add to Spring until we go to 0.8 will either be an urgent =
bug
fix or simply additional tests.

Regards,
Rod

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Thursday, May 22, 2003 4:29 PM
Subject: RE: [Springframework-developer] Code changes for 0.8?


Besides having reworked the form controller's handling of resubmits, =
I've
also created an extensive test suite for ControllerServlet and some web
support classes. We're at overall >64% now!

Additionally, I've refined some ApplicationContext stuff (moved
OPTIONS_BEAN_NAME from ApplicationContext to AbstractApplicationContext
etc), and cleaned the exception handling in the beans package (e.g. =
rethrow
BeansException directly when catching Exception instead of wrapping it).

Rethrown exceptions don't get logged anymore, as they are logged by the
highest level exception handler anyway (-> no double stack traces in the
console). I've also commented out the println(this) on printing a =
rootCause
stack trace: As a root stack trace will always get printed after the
exception's message, those lines have only added redundant information,
cluttering the console.

I've removed FrameworkServlet's debug support, I don't see any real use =
case
for it. During development, Log4J's debug log is all you need, IMO - you
exactly see what handlers/mappings/etc get used, no need for binding =
them to
the request.

I'm also gonna move the web.mock classes back to the test sources, as =
they
are pretty rough, and not really meant for usage within application
development - in constrast to the JNDI mocks, for example.

I'll check my stuff in within the next 2 hours. Everybody, please test =
the
current framework version in your apps! We should really try to release =
a
0.8 as stable as possible.

BTW, what's the current status in terms of code beautification (Jalopy =
etc)?
We have mixed headers in our files at the moment, and sometimes =
inconsistent
formatting. Do we aim to clean this for 0.8?

Juergen

RE: [Springframework-developer] Code changes for 0.8?

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

>Regarding mock objects, I think that the JNDI mocks do have 
value for application developers: They can serve as JNDI 
replacement for applications test environments and standalone 
applications, running the same code and config files as in 
the container environment. 

I agree. I wasn't suggesting dropping them, just moving them 
along with some other stuff to a new /support or such tree. 
So developers could choose to use them, but they'd be clearly 
intended *not* to be part of most Spring apps in production.

Rod

Re: [Springframework-developer] Code changes for 0.8?

[Isabelle M. <isa...@me...>]

Hi everyone,

I'll do as much work as I can on the tutorial over the weekend. Hopefully, I can get the equivalent of chapter 12 done, maybe even some of chapter 13. I guess the JNDI and EJB stuff will have to wait until the next release.
As always, I'll notify the list and post the new version on my website.

Isabelle

-- 
Isabelle Muszynski
Software Engineer
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89
Email: isa...@me...
Website: www.meta-logix.com

Re: [Springframework-developer] Code changes for 0.8?

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

Excellent. Great news on the test coverage! You've been doing good work
here.

I'm glad you've cleaned up the stack traces... There were quite a few
repeated stack traces a long time ago, and I got many of them (but obviously
not all). I think the volume and quality of stack traces is very important.
It's about the only thing that really bugs me with Hibernate 2.0 RC1, for
example. We may need to consider a consistent approach to logging (levels
etc.) for 0.9 or 1.0.

I imagine removing debug support in framework servlet removed a lot of code.
I actually eyed it myself with my scalpel in mind recently. It did make the
code much harder to understand and the fewer lines of code, the fewer
potential bugs. Also, I don't think it was documented anywhere, so I doubt
anyone will miss it too much. (I did use it myself occasionally but I'm sure
I can live without it.)

I'm not sure that *any* mock objects should be in the main source tree.
Maybe we need a third tree for the mocks and things like
EjbContainerDetective that are handy but not part of the core spring
runtime. I don't tend to use our mock objects much anymore, since I
discovered the wonder that is EasyMock.

Code formatting I think is a 0.9 thing. Certainly after we have a tagged
stable release. We don't want to delay 0.8 for this.

I'm away this weekend (bank holiday in the UK), so won't be doing any work.
Anything I do add to Spring until we go to 0.8 will either be an urgent bug
fix or simply additional tests.

Regards,
Rod

----- Original Message -----
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Thursday, May 22, 2003 4:29 PM
Subject: RE: [Springframework-developer] Code changes for 0.8?


Besides having reworked the form controller's handling of resubmits, I've
also created an extensive test suite for ControllerServlet and some web
support classes. We're at overall >64% now!

Additionally, I've refined some ApplicationContext stuff (moved
OPTIONS_BEAN_NAME from ApplicationContext to AbstractApplicationContext
etc), and cleaned the exception handling in the beans package (e.g. rethrow
BeansException directly when catching Exception instead of wrapping it).

Rethrown exceptions don't get logged anymore, as they are logged by the
highest level exception handler anyway (-> no double stack traces in the
console). I've also commented out the println(this) on printing a rootCause
stack trace: As a root stack trace will always get printed after the
exception's message, those lines have only added redundant information,
cluttering the console.

I've removed FrameworkServlet's debug support, I don't see any real use case
for it. During development, Log4J's debug log is all you need, IMO - you
exactly see what handlers/mappings/etc get used, no need for binding them to
the request.

I'm also gonna move the web.mock classes back to the test sources, as they
are pretty rough, and not really meant for usage within application
development - in constrast to the JNDI mocks, for example.

I'll check my stuff in within the next 2 hours. Everybody, please test the
current framework version in your apps! We should really try to release a
0.8 as stable as possible.

BTW, what's the current status in terms of code beautification (Jalopy etc)?
We have mixed headers in our files at the moment, and sometimes inconsistent
formatting. Do we aim to clean this for 0.8?

Juergen