springframework-developer — Spring Framework developers list

Re: [Springframework-developer] Import tag for XML bean definitions

[Tom T. <tom...@pr...>]

This would be useful for "composed bean definition files" packaged in an
api jar file. We usually split up larger bean definition files by
functional domain, but this separation does not always make sense for the
application that uses the jar file.

It would be nice if the application using the jar file could just specify
a single contextConfigLocation, without knowing whether this file is
actually "composed" or not. In the "composed" case, the actual file would
probably consist of only import tags.

Maybe an <import resource=3D"classpath:/mypackage/imported.xml"/> syntax
would be more obvious? Or maybe "file" is always relative against the
current location?

Kind regards,
Tom.

On Fri, 4 Jun 2004 10:29:38 +0200, "j=FCrgen h=F6ller [werk3AT]"
<jue...@we...> said:
> We've got an enhancements request in JIRA, currently for the 1.0.3
> timeframe:
>=20=20
> http://opensource.atlassian.com/projects/spring/browse/SPR-137
>=20=20
> Essentially, it's about an <import> tag that allows to specify imports
> within an application context XML file rather than in an external
> "contextConfigLocation" setting - imports driven by the XML file itself
> rather than from the outside.
>=20=20
> <import file=3D'imported.xml'/>
>=20=20
> <beans>
>=20=20
>   ...
>=20=20
> </beans>
>=20
> Something similar can already be achieved with XML entity includes, but
> those are arguably not very convenient to use. XWork has such an <import>
> tag, BTW; Mike Cannon-Brookes has already suggested this for Spring a
> couple of months ago too.
>=20=20
> I wouldn't mind adding such an option, although I still prefer external
> contextConfigLocations. It does have some effects on our
> XmlBeanDefinitionReader/Parser signatures, though, as a ResourceLoader is
> needed by the parser now for resolving those import locations. This
> indicates that it might be better to introduce this for 1.1 rather than
> for 1.0.3, I guess.=20
>=20=20
> Thoughts?
>=20=20
> Juergen
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> From Windows to Linux, servers to mobile, InstallShield X is the one
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Import tag for XML bean definitions

[Timo V. <sic...@gm...>]

Hi!

Maybe the XInclude Candidate Recommendation from W3C should be=20
considered for the syntax (http://www.w3.org/TR/xinclude/). Future XML=20
Editors might provide support for it.

Regards,

Timo


Am Freitag, 4. Juni 2004 10:29 schrieb j=FCrgen h=F6ller [werk3AT]:
> We've got an enhancements request in JIRA, currently for the 1.0.3
> timeframe:
>
> http://opensource.atlassian.com/projects/spring/browse/SPR-137
>
> Essentially, it's about an <import> tag that allows to specify
> imports within an application context XML file rather than in an
> external "contextConfigLocation" setting - imports driven by the XML
> file itself rather than from the outside.
>
> <import file=3D'imported.xml'/>
>
> <beans>
>
>   ...
>
> </beans>
>
> Something similar can already be achieved with XML entity includes,
> but those are arguably not very convenient to use. XWork has such an
> <import> tag, BTW; Mike Cannon-Brookes has already suggested this for
> Spring a couple of months ago too.
>
> I wouldn't mind adding such an option, although I still prefer
> external contextConfigLocations. It does have some effects on our
> XmlBeanDefinitionReader/Parser signatures, though, as a
> ResourceLoader is needed by the parser now for resolving those import
> locations. This indicates that it might be better to introduce this
> for 1.1 rather than for 1.0.3, I guess.
>
> Thoughts?
>
> Juergen
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> From Windows to Linux, servers to mobile, InstallShield X is the one
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-develope
>r

[Springframework-developer] Import tag for XML bean definitions

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

We've got an enhancements request in JIRA, currently for the 1.0.3 =
timeframe:
=20
http://opensource.atlassian.com/projects/spring/browse/SPR-137
=20
Essentially, it's about an <import> tag that allows to specify imports =
within an application context XML file rather than in an external =
"contextConfigLocation" setting - imports driven by the XML file itself =
rather than from the outside.
=20
<import file=3D'imported.xml'/>
=20
<beans>
=20
  ...
=20
</beans>

Something similar can already be achieved with XML entity includes, but =
those are arguably not very convenient to use. XWork has such an =
<import> tag, BTW; Mike Cannon-Brookes has already suggested this for =
Spring a couple of months ago too.
=20
I wouldn't mind adding such an option, although I still prefer external =
contextConfigLocations. It does have some effects on our =
XmlBeanDefinitionReader/Parser signatures, though, as a ResourceLoader =
is needed by the parser now for resolving those import locations. This =
indicates that it might be better to introduce this for 1.1 rather than =
for 1.0.3, I guess.=20
=20
Thoughts?
=20
Juergen

Re: [Springframework-developer] newPreparedStatementCreator in SqlOperation has become final

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

I agree that Thomas' suggestion sounds like the best solution for this =
problem. I also agree that the code from my last mail would effectively =
bypass SqlQuery's functionality... It was rather meant as "the least =
effort to make it work again".
=20
If you're using a custom ResultReader anyway, you could indeed subclass =
RdbmsOperation directly, invoking its JdbcTemplate with your custom =
PreparedStatementCreator and ResultReader. In terms of the functionality =
that you're actually using, that would be the most appropriate =
inheritance design. The various operation objects in the jdbc.object =
package are effectively just a thin layer on top of JdbcTemplate and =
other jdbc.core functionality anyway.
=20
As a side note, that "newPreparedStatementCreator" became final was =
actually a side effect of the introduction of the =
"newPreparedStatementSetter" method in SqlOperation. That new method was =
final from the start, so it seemed to me that the other one had to be =
to, judging from SqlOperation's purpose - building a =
PreparedStatementCreatorFactory. Unfortunately, I completely forgot to =
discuss this on the mailing list, as this happened in the middle of a =
bunch of stuff.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Tom Turelinckx
Gesendet: Fr 04.06.2004 00:07
An: spr...@li...
Betreff: Re: [Springframework-developer] newPreparedStatementCreator in =
SqlOperation has become final



Hi Juergen!

> Basically, you're bypassing all of SqlOperation's functionality when =
you
> use a custom PreparedStatementCreatorFactory. That's why I considered =
it
> a bug that "newPreparedStatementCreator" wasn't final before.

True, but I don't actually want to use a custom one, I just want to
customize the existing one a bit ;-) Thomas' suggestion sounds like a
good idea!

> wasn't a particular good idea to change that at this point of time,
> though - sorry for any inconvenience.

Never mind, I should have tested the cvs version before 1.0.2 was
released [shamefaced smiley here] ;-)

> What you can do is perform the query yourself rather than delegating =
to
> SqlQuery's execute method:

Hmm, wouldn't that be bypassing all of SqlQuery's functionality,
essentially? ;-)
As I'm also using a custom ResultReader (with range support), I can
probably just as well extend from RdbmsOperation directly...

Thanks for the suggestions!
Tom.


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] newPreparedStatementCreator in SqlOperation has become final

[Tom T. <tom...@pr...>]

Hi Juergen!

> Basically, you're bypassing all of SqlOperation's functionality when you
> use a custom PreparedStatementCreatorFactory. That's why I considered it
> a bug that "newPreparedStatementCreator" wasn't final before.

True, but I don't actually want to use a custom one, I just want to
customize the existing one a bit ;-) Thomas' suggestion sounds like a
good idea!

> wasn't a particular good idea to change that at this point of time,
> though - sorry for any inconvenience.

Never mind, I should have tested the cvs version before 1.0.2 was
released [shamefaced smiley here] ;-)

> What you can do is perform the query yourself rather than delegating to
> SqlQuery's execute method:

Hmm, wouldn't that be bypassing all of SqlQuery's functionality,
essentially? ;-)
As I'm also using a custom ResultReader (with range support), I can
probably just as well extend from RdbmsOperation directly...

Thanks for the suggestions!
Tom.

Re: [Springframework-developer] newPreparedStatementCreator in SqlOperation has become final

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

Basically, you're bypassing all of SqlOperation's functionality when you =
use a custom PreparedStatementCreatorFactory. That's why I considered it =
a bug that "newPreparedStatementCreator" wasn't final before. Probably =
wasn't a particular good idea to change that at this point of time, =
though - sorry for any inconvenience.

What you can do is perform the query yourself rather than delegating to =
SqlQuery's execute method:

public class MySqlQuery extends SqlQuery {

  public void myExecute(Object[] parameters) {
    ResultReader rr =3D newResultReader(0, parameters, null);
    return =
getJdbcTemplate().query(newMyPreparedStatementCreator(parameters), rr);
  }

  protected PreparedStatementCreator =
newMyPreparedStatementCreator(Object[] parameters) {
    ...;
  }
}

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Tom Turelinckx
Sent: Thursday, June 03, 2004 4:31 PM
To: spr...@li...
Subject: [Springframework-developer] newPreparedStatementCreator in
SqlOperation has become final


Hello Juergen,

While upgrading all of our applications to Spring 1.0.2, I noticed
newPreparedStatementCreator() in SqlOperation has become final. Though
this is probably a good thing, I currently don't see an easy way to have
SqlOperation use a custom PreparedStatementCreatorFactory...

We have some queries (extending SqlQuery) that use sql parameters of =
type
ARRAY, e.g.:

new SqlParameter( "dg_ids", Types.ARRAY, "DISCHARGE.NT_DIS_IDS" )

and thus require a custom (Oracle-specific)
PreparedStatementCreator/Setter to do something like this:

case Types.ARRAY:
    ps.setArray( idx, getOracleArray( con, declaredParam.getTypeName(),
    param ) );
    break;

private ARRAY getOracleArray( Connection con, String typeName, Object =
obj
) throws SQLException {
    Connection nativeCon =3D getNativeConnection( con );
    return new ARRAY( ArrayDescriptor.createDescriptor( typeName,
    nativeCon ), nativeCon, obj );
}

I was overriding newPreparedStatementCreator() to force the use of my =
own
OraclePreparedStatementCreator, but this is no longer possible, and, in
fact, I don't see another way of accomplishing this...

Maybe compileInternal() in SqlOperation could delegate the creation of
preparedStatementFactory to a protected
"createPreparedStatementCreatorFactory" method?

Kind regards,
Tom.


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] newPreparedStatementCreator in SqlOperation has become final

[<tho...@tr...>]

Tom,

While I don't know why this was changed to final, I have been thinking about
providing some additional features to the SqlParameter class.  One idea would
be to add a "TypeHandler" class that could do what you are looking for without
having to use a custom PreparedStatementCreator.  The TypeHandler would be
modeled after the current LobHandler.

Thomas


Quoting Tom Turelinckx <tom...@pr...>:

> Hello Juergen,
>
> While upgrading all of our applications to Spring 1.0.2, I noticed
> newPreparedStatementCreator() in SqlOperation has become final. Though
> this is probably a good thing, I currently don't see an easy way to have
> SqlOperation use a custom PreparedStatementCreatorFactory...
>
> We have some queries (extending SqlQuery) that use sql parameters of type
> ARRAY, e.g.:
>
> new SqlParameter( "dg_ids", Types.ARRAY, "DISCHARGE.NT_DIS_IDS" )
>
> and thus require a custom (Oracle-specific)
> PreparedStatementCreator/Setter to do something like this:
>
> case Types.ARRAY:
>     ps.setArray( idx, getOracleArray( con, declaredParam.getTypeName(),
>     param ) );
>     break;
>
> private ARRAY getOracleArray( Connection con, String typeName, Object obj
> ) throws SQLException {
>     Connection nativeCon = getNativeConnection( con );
>     return new ARRAY( ArrayDescriptor.createDescriptor( typeName,
>     nativeCon ), nativeCon, obj );
> }
>
> I was overriding newPreparedStatementCreator() to force the use of my own
> OraclePreparedStatementCreator, but this is no longer possible, and, in
> fact, I don't see another way of accomplishing this...
>
> Maybe compileInternal() in SqlOperation could delegate the creation of
> preparedStatementFactory to a protected
> "createPreparedStatementCreatorFactory" method?
>
> Kind regards,
> Tom.
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> >From Windows to Linux, servers to mobile, InstallShield X is the one
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] newPreparedStatementCreator in SqlOperation has become final

[Tom T. <tom...@pr...>]

Hello Juergen,

While upgrading all of our applications to Spring 1.0.2, I noticed
newPreparedStatementCreator() in SqlOperation has become final. Though
this is probably a good thing, I currently don't see an easy way to have
SqlOperation use a custom PreparedStatementCreatorFactory...

We have some queries (extending SqlQuery) that use sql parameters of type
ARRAY, e.g.:

new SqlParameter( "dg_ids", Types.ARRAY, "DISCHARGE.NT_DIS_IDS" )

and thus require a custom (Oracle-specific)
PreparedStatementCreator/Setter to do something like this:

case Types.ARRAY:
    ps.setArray( idx, getOracleArray( con, declaredParam.getTypeName(),
    param ) );
    break;

private ARRAY getOracleArray( Connection con, String typeName, Object obj
) throws SQLException {
    Connection nativeCon = getNativeConnection( con );
    return new ARRAY( ArrayDescriptor.createDescriptor( typeName,
    nativeCon ), nativeCon, obj );
}

I was overriding newPreparedStatementCreator() to force the use of my own
OraclePreparedStatementCreator, but this is no longer possible, and, in
fact, I don't see another way of accomplishing this...

Maybe compileInternal() in SqlOperation could delegate the creation of
preparedStatementFactory to a protected
"createPreparedStatementCreatorFactory" method?

Kind regards,
Tom.

Re: [Springframework-developer] about closing bean container

[<rn...@co...>]

I have a class that is responsible for creating a 
ClasspathXmlApplicationContext and allow access to it as a 
ApplicationContext.

Clients receive the ApplicationContext and ues the normal getBean() 
methods, etc. The originating class establishes the shutdown hook as it 
internally keeps the reference as a ConfigurableApplicationContext 
(since ClassPath... is both).

I only do this for legacy code where pushing dependencies in everywhere 
would be a problem. I don't like creating a factory for the Spring 
context (using the old static getInstance() pattern), but I'm 
constrained by current architecture.

So, in summary, the class that constructs your application context can 
create a shutdown hook right there, as you know it implements the 
close() method, everyone else should get a reference to 
ApplicationContext, because you don't want just anyone removing your 
singletons.

B.

Jozsa Kristof wrote:
> Ok.. and what about disposing the container's singletons from a shutdown 
> hook for non-web apps? If close() is not meant for the client view of 
> the context, than the server should take care about it imho.
> 
> dyn
> 
> jürgen höller [werk3AT] wrote:
> 
>> It's not in the ApplicationContext interface itself, because this is 
>> meant to be a client view of the context. Simply cast the context 
>> reference to ConfigurableApplicationContext; you can then invoke the 
>> close method there.
>>
>> Juergen
>>
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...]On Behalf
>> Of Jozsa Kristof
>> Sent: Thursday, June 03, 2004 1:14 PM
>> To: spr...@li...
>> Subject: [Springframework-developer] about closing bean container
>>
>>
>> Hi,
>>
>> I started to wonder today why ApplicationContext interface doesn't 
>> include the close() method to dispose the singleton beans in the bean 
>> container. Is there any reason not to expose this method? On the other 
>> side, wouldn't it make sense to add a shutdown hook to clear up any 
>> still-existing bean containers at least on jvm exit?
>>
>> dyn
> 
> 
> 

Re: [Springframework-developer] about closing bean container

[Jozsa K. <dy...@on...>]

Ok. My point was to add the shutdown hook thing for=20
ClassPathXmlApplicationContext, but maybe some won't like this=20
functionality, so I'll do it myself within my app / abstract testcase.

Thanks for the explanation,
dyn

j=FCrgen h=F6ller [werk3AT] wrote:
> If Spring manages your application context, like in the web app or EJB =
case, the respective context loaders will properly close the context on s=
hutdown.
>=20
> If you're instantiating your own context, like a ClassPathXmlApplicatio=
nContext, you're responsible for closing it on shutdown of your app. This=
 typically happens in the lifecycle code of a standalone app.
>=20
> ConfigurableApplicationContext context =3D new ClassPathXmlApplicationC=
ontext(...);
> // run app
> context.close();
>=20
> Nevertheless, none of your application objects in the context need to k=
now about the ConfigurableApplicationContext interface. If at all, they w=
ork with the ApplicationContext interface.
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Jozsa Kristof
> Sent: Thursday, June 03, 2004 2:19 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] about closing bean container
>=20
>=20
> Ok.. and what about disposing the container's singletons from a shutdow=
n=20
> hook for non-web apps? If close() is not meant for the client view of=20
> the context, than the server should take care about it imho.
>=20
> dyn
>=20
> j=FCrgen h=F6ller [werk3AT] wrote:
>=20
>>It's not in the ApplicationContext interface itself, because this is me=
ant to be a client view of the context. Simply cast the context reference=
 to ConfigurableApplicationContext; you can then invoke the close method =
there.
>>
>>Juergen
>>
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...]On Behalf
>>Of Jozsa Kristof
>>Sent: Thursday, June 03, 2004 1:14 PM
>>To: spr...@li...
>>Subject: [Springframework-developer] about closing bean container
>>
>>
>>Hi,
>>
>>I started to wonder today why ApplicationContext interface doesn't=20
>>include the close() method to dispose the singleton beans in the bean=20
>>container. Is there any reason not to expose this method? On the other=20
>>side, wouldn't it make sense to add a shutdown hook to clear up any=20
>>still-existing bean containers at least on jvm exit?
>>
>>dyn
>=20
>=20
>=20


--=20
.Digital.Yearning.for.Networked.Assassination.and.Xenocide.

Re: [Springframework-developer] about closing bean container

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

If Spring manages your application context, like in the web app or EJB =
case, the respective context loaders will properly close the context on =
shutdown.

If you're instantiating your own context, like a =
ClassPathXmlApplicationContext, you're responsible for closing it on =
shutdown of your app. This typically happens in the lifecycle code of a =
standalone app.

ConfigurableApplicationContext context =3D new =
ClassPathXmlApplicationContext(...);
// run app
context.close();

Nevertheless, none of your application objects in the context need to =
know about the ConfigurableApplicationContext interface. If at all, they =
work with the ApplicationContext interface.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Jozsa Kristof
Sent: Thursday, June 03, 2004 2:19 PM
To: spr...@li...
Subject: Re: [Springframework-developer] about closing bean container


Ok.. and what about disposing the container's singletons from a shutdown =

hook for non-web apps? If close() is not meant for the client view of=20
the context, than the server should take care about it imho.

dyn

j=FCrgen h=F6ller [werk3AT] wrote:
> It's not in the ApplicationContext interface itself, because this is =
meant to be a client view of the context. Simply cast the context =
reference to ConfigurableApplicationContext; you can then invoke the =
close method there.
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On =
Behalf
> Of Jozsa Kristof
> Sent: Thursday, June 03, 2004 1:14 PM
> To: spr...@li...
> Subject: [Springframework-developer] about closing bean container
>=20
>=20
> Hi,
>=20
> I started to wonder today why ApplicationContext interface doesn't=20
> include the close() method to dispose the singleton beans in the bean=20
> container. Is there any reason not to expose this method? On the other =

> side, wouldn't it make sense to add a shutdown hook to clear up any=20
> still-existing bean containers at least on jvm exit?
>=20
> dyn


--=20
.Digital.Yearning.for.Networked.Assassination.and.Xenocide.


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Spring Portlet MVC layer

[<mpe...@in...>]

Hello, All

I am going to help William G. Thompson, Jr.  develop MVC layer in org.springframework.web.portlet package in the same way as this was done in org.springframework.web.servlet package. 
At the first time I going to develop SimpleFormController.

Did somebody this development before (it's need to know for avoid duplication of our efforts)? 

With best regards,
Maxim Petrashev

Re: [Springframework-developer] about closing bean container

[Jozsa K. <dy...@on...>]

Ok.. and what about disposing the container's singletons from a shutdown=20
hook for non-web apps? If close() is not meant for the client view of=20
the context, than the server should take care about it imho.

dyn

j=FCrgen h=F6ller [werk3AT] wrote:
> It's not in the ApplicationContext interface itself, because this is me=
ant to be a client view of the context. Simply cast the context reference=
 to ConfigurableApplicationContext; you can then invoke the close method =
there.
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Jozsa Kristof
> Sent: Thursday, June 03, 2004 1:14 PM
> To: spr...@li...
> Subject: [Springframework-developer] about closing bean container
>=20
>=20
> Hi,
>=20
> I started to wonder today why ApplicationContext interface doesn't=20
> include the close() method to dispose the singleton beans in the bean=20
> container. Is there any reason not to expose this method? On the other=20
> side, wouldn't it make sense to add a shutdown hook to clear up any=20
> still-existing bean containers at least on jvm exit?
>=20
> dyn


--=20
.Digital.Yearning.for.Networked.Assassination.and.Xenocide.

Re: [Springframework-developer] about closing bean container

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

It's not in the ApplicationContext interface itself, because this is =
meant to be a client view of the context. Simply cast the context =
reference to ConfigurableApplicationContext; you can then invoke the =
close method there.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Jozsa Kristof
Sent: Thursday, June 03, 2004 1:14 PM
To: spr...@li...
Subject: [Springframework-developer] about closing bean container


Hi,

I started to wonder today why ApplicationContext interface doesn't=20
include the close() method to dispose the singleton beans in the bean=20
container. Is there any reason not to expose this method? On the other=20
side, wouldn't it make sense to add a shutdown hook to clear up any=20
still-existing bean containers at least on jvm exit?

dyn
--=20
.Digital.Yearning.for.Networked.Assassination.and.Xenocide.


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Spring Framework 1.0.2 released

[Jozsa K. <dy...@on...>]

j=FCrgen h=F6ller [werk3AT] wrote:
> Dear Spring community,
> =20
> I'm pleased to announce that Spring Framework 1.0.2 has just been relea=
sed. This release introduces a variety of enhancements throughout the fra=
mework, plus some minor bugs fixes. Among the enhancements in this releas=
e are:
> =20
> * new "mock" source tree and "spring-mock" jar file, containing JNDI an=
d Servlet API mocks for usage in applications

.. and we just missed the new Hibernate maintaince release 2.1.4 :)

dyn
--=20
.Digital.Yearning.for.Networked.Assassination.and.Xenocide.

[Springframework-developer] about closing bean container

[Jozsa K. <dy...@on...>]

Hi,

I started to wonder today why ApplicationContext interface doesn't 
include the close() method to dispose the singleton beans in the bean 
container. Is there any reason not to expose this method? On the other 
side, wouldn't it make sense to add a shutdown hook to clear up any 
still-existing bean containers at least on jvm exit?

dyn
-- 
.Digital.Yearning.for.Networked.Assassination.and.Xenocide.

Re: [Springframework-developer] Fw: [Spring-JIRA] Commented: (SPR-154) Make log event "Initiating transaction commit" DEBUG

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

I've always believed it should be INFO. Transactions are important and I
want them to be fairly obvious...

When it was DEBUG at one point I found it a bit confusing in development,
hence I changed it back.

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Thursday, June 03, 2004 9:42 AM
Subject: [Springframework-developer] Fw: [Spring-JIRA] Commented: (SPR-15=
4)
Make log event "Initiating transaction commit" DEBUG


We've already discussed this before, haven't we? As far as I remember, we
wanted to leave this message at INFO level to make people aware that Spri=
ng
is properly initiating a database transaction here, assuming that product=
ion
is turned to WARN anyway. However, there is an argument that this should =
be
a DEBUG message, so that Spring doesn't issue any INFO statements in norm=
al
operation... Thoughts?

Juergen


________________________________

Von: leg...@at... [mailto:leg...@at...=
m]
Gesendet: Do 03.06.2004 10:54
An: j=FCrgen h=F6ller [werk3AT]
Betreff: [Spring-JIRA] Commented: (SPR-154) Make log event "Initiating
transaction commit" DEBUG



The following comment has been added to this issue:

     Author: Mathias Bogaert
    Created: Thu, 3 Jun 2004 3:54 AM
       Body:
I agree with WARN in production systems, but just for initializing a
transaction commit which is not effectively committed (readOnly) a INFO l=
og
statement? Not that useful info to me...
---------------------------------------------------------------------
View this comment:

http://opensource.atlassian.com/projects/spring/browse/SPR-154?page=3Dcom=
ments
#action_10442

---------------------------------------------------------------------
View the issue:
  http://opensource.atlassian.com/projects/spring/browse/SPR-154

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: SPR-154
    Summary: Make log event "Initiating transaction commit" DEBUG
       Type: Improvement

     Status: Open
   Priority: Major

    Project: Spring Framework
 Components:
             SpringDA
   Versions:
             1.0.2

   Assignee: Juergen Hoeller
   Reporter: Mathias Bogaert

    Created: Thu, 3 Jun 2004 3:38 AM
    Updated: Thu, 3 Jun 2004 3:54 AM

Description:
I'm having a lot of read transactions (e.g. checking security multiple ti=
mes
on the same JSP using WebWork2 OGNL), and for each one of them, I get "IN=
FO
[tcpConnection-8080-3] (orm.hibernate.HibernateTransactionManager:315) -
Initiating transaction commit". This result in up to 15 log lines per
request!


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:

http://opensource.atlassian.com/projects/spring/secure/Administrators.jsp=
a

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira





-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Fw: [Spring-JIRA] Commented: (SPR-154) Make log event "Initiating transaction commit" DEBUG

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

We've already discussed this before, haven't we? As far as I remember, =
we wanted to leave this message at INFO level to make people aware that =
Spring is properly initiating a database transaction here, assuming that =
production is turned to WARN anyway. However, there is an argument that =
this should be a DEBUG message, so that Spring doesn't issue any INFO =
statements in normal operation... Thoughts?
=20
Juergen
=20

________________________________

Von: leg...@at... =
[mailto:leg...@at...]
Gesendet: Do 03.06.2004 10:54
An: j=FCrgen h=F6ller [werk3AT]
Betreff: [Spring-JIRA] Commented: (SPR-154) Make log event "Initiating =
transaction commit" DEBUG



The following comment has been added to this issue:

     Author: Mathias Bogaert
    Created: Thu, 3 Jun 2004 3:54 AM
       Body:
I agree with WARN in production systems, but just for initializing a =
transaction commit which is not effectively committed (readOnly) a INFO =
log statement? Not that useful info to me...
---------------------------------------------------------------------
View this comment:
  =
http://opensource.atlassian.com/projects/spring/browse/SPR-154?page=3Dcom=
ments#action_10442

---------------------------------------------------------------------
View the issue:
  http://opensource.atlassian.com/projects/spring/browse/SPR-154

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: SPR-154
    Summary: Make log event "Initiating transaction commit" DEBUG
       Type: Improvement

     Status: Open
   Priority: Major

    Project: Spring Framework
 Components:
             SpringDA
   Versions:
             1.0.2

   Assignee: Juergen Hoeller
   Reporter: Mathias Bogaert

    Created: Thu, 3 Jun 2004 3:38 AM
    Updated: Thu, 3 Jun 2004 3:54 AM

Description:
I'm having a lot of read transactions (e.g. checking security multiple =
times on the same JSP using WebWork2 OGNL), and for each one of them, I =
get "INFO  [tcpConnection-8080-3] =
(orm.hibernate.HibernateTransactionManager:315) - Initiating transaction =
commit". This result in up to 15 log lines per request!


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   =
http://opensource.atlassian.com/projects/spring/secure/Administrators.jsp=
a

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Springframework-developer] Shameless plug about Colorado JUG Meetings next week

[Matt R. <ma...@ra...>]

Since I've seen a few event postings on the springframework.org
regarding JUG meetings, I thought I'd mention that I'll be speaking
about AppFuse at the Denver JUG and Boulder JUG next week in Colorado.
Since AppFuse uses Spring all over the place - I'll naturally be talking
a lot about Spring - showing how it easily resolves dependencies and
greatly simplifies Hibernate DAOs.  I doubt I'll get much into Spring
MVC because I only have an hour, but I'll be sure to mention it and my
(good) experiences with it.  

From past presentations I've done on AppFuse, folks seem to leave the
room *very* excited about Spring.  And of course, I have nothing but
good things to say about it. ;-)

Congrats on the 1.0.2 release,

Matt

Re: [Springframework-developer] Spring Framework 1.0.2 released

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

Wait, I have some changes I would like to include :-)

I'm updating the web site right now.

Thomas

jürgen höller [werk3AT] wrote:

>Dear Spring community,
> 
>I'm pleased to announce that Spring Framework 1.0.2 has just been released. This release introduces a variety of enhancements throughout the framework, plus some minor bugs fixes. Among the enhancements in this release are:
> 
>* new "mock" source tree and "spring-mock" jar file, containing JNDI and Servlet API mocks for usage in applications
> 
>* CachedIntrospectionResults flushes the JavaBeans Introspector cache for proper garbage collection on shutdown
>* added ObjectFactory interface and ObjectFactoryCreatingFactoryBean, for non-intrusive creation of prototype beans
>* AbstractXmlApplicationContext uses PathMatchingResourcePatternResolver for Ant-style config location patterns
>* added support for "xxx*" field patterns to BindException's "getFieldErrors" and "getFieldError" methods
>* QuartzJobBean applies SchedulerContext entries as bean properties, just like it also does for JobDataMap entries
>
>* added UserCredentialsDataSourceAdapter, for transparently appying username and password to target DataSource calls
>* added RowMapperResultReader, to be used instead of a custom RowCallbackHandler when mapping rows to objects
>* added AbstractLobStreamingResultSetExtractor and AbstractLobCreatingPreparedStatementCallback
>* reworked "imagedb" sample app, with a redesigned implementation of the DefaultImageDatabase class
>* iBATIS SQL Maps 2.0 integration classes support per-SqlMapClient DataSource and lazy loading of paginated lists
>
>* DispatcherServlet detects ViewResolvers by type to allow for ViewResolver chaining (respecting order values)
>* added "doSubmitAction" template method to SimpleFormController, for submit actions without caring about ModelAndView
>* AbstractWizardFormController optionally supports "_page" request parameter, for proper handling of back button usage
>* added support for "person.na*"/"person.address.*"-style field patterns to BindTag's "path" attribute
>* added Struts DelegatingRequestProcessor and DelegatingTilesRequestProcessor as alternatives to DelegatingActionProxy
>
>See the changelog for details. We have also refined our roadmap; see our JIRA for a rough plan of what's ahead.
> 
>Thanks for using Spring!
> 
>Regards,
> 
>Juergen
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by the new InstallShield X.
>>From Windows to Linux, servers to mobile, InstallShield X is the one
>installation-authoring solution that does it all. Learn more and
>evaluate today! http://www.installshield.com/Dev2Dev/0504
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>  
>

Re: [Springframework-developer] Should DataBinder be an interface?

[Seth L. <se...@eh...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Colin Sampaleanu wrote:

| W/regards to issues with EasyMock, you may also want to try jMock
| (jmock.codehaus.org). It's quite nice, and now at a 1.0 version. I find
| it nicer than EasyMock in some respects...

Thanks, I've taken a brief look at it.  We use mockobjects here, but
they don't support mocking classes.  The only thing I didn't quite dig
about jMock was that it looked like I had to create a subclass of its
TestCase class.  I couldn't just use it any old class.  I'll take a
closer look, though.  EasyMock didn't seem as easy as possible, and part
of that is the documentation style is very odd (plus, no javadocs on
their website??).

Seth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAvoXvKZsFSwtW+wIRAkx+AJ9EkrUYtH6GR9QdXifMa8m2fBlspACcCO95
Z8BNkjSrw//aC3JUKlm+4yg=
=uue/
-----END PGP SIGNATURE-----

Re: [Springframework-developer] Should DataBinder be an interface?

[Colin S. <col...@ex...>]

W/regards to issues with EasyMock, you may also want to try jMock 
(jmock.codehaus.org). It's quite nice, and now at a 1.0 version. I find 
it nicer than EasyMock in some respects...


Seth Ladd wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> In writing unit tests for my Controllers, I find I need to test the
> initBinder method and test what I place inside the binder (via
> registerCustomEditor).
>
> I tried mocking the DataBinder class w/ easymock + cglib extension, but
> it would generate an NPE.  The easymock list thinks this is a bug in
> their code, though haven't heard from them since.
>
> Is there a reason not to move (at some point) DataBinder to an
> interface?  This would help with testing and mocks.  Another option
> would be to create a MockDataBinder and add it to the spring-mocks.
>
> Any thoughts?
>
> Thanks!
> Seth
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3-nr1 (Windows XP)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFAvm7fKZsFSwtW+wIRAuH+AJ0SvEc4sh6P8qaRe2XwEKoDVrspPwCfSWz7
> tOxXVGKAnmqsVuKrUoYVQHo=
> =2nLo
> -----END PGP SIGNATURE-----
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> From Windows to Linux, servers to mobile, InstallShield X is the one
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Spring Framework 1.0.2 released

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

Dear Spring community,
=20
I'm pleased to announce that Spring Framework 1.0.2 has just been =
released. This release introduces a variety of enhancements throughout =
the framework, plus some minor bugs fixes. Among the enhancements in =
this release are:
=20
* new "mock" source tree and "spring-mock" jar file, containing JNDI and =
Servlet API mocks for usage in applications
=20
* CachedIntrospectionResults flushes the JavaBeans Introspector cache =
for proper garbage collection on shutdown
* added ObjectFactory interface and ObjectFactoryCreatingFactoryBean, =
for non-intrusive creation of prototype beans
* AbstractXmlApplicationContext uses PathMatchingResourcePatternResolver =
for Ant-style config location patterns
* added support for "xxx*" field patterns to BindException's =
"getFieldErrors" and "getFieldError" methods
* QuartzJobBean applies SchedulerContext entries as bean properties, =
just like it also does for JobDataMap entries

* added UserCredentialsDataSourceAdapter, for transparently appying =
username and password to target DataSource calls
* added RowMapperResultReader, to be used instead of a custom =
RowCallbackHandler when mapping rows to objects
* added AbstractLobStreamingResultSetExtractor and =
AbstractLobCreatingPreparedStatementCallback
* reworked "imagedb" sample app, with a redesigned implementation of the =
DefaultImageDatabase class
* iBATIS SQL Maps 2.0 integration classes support per-SqlMapClient =
DataSource and lazy loading of paginated lists

* DispatcherServlet detects ViewResolvers by type to allow for =
ViewResolver chaining (respecting order values)
* added "doSubmitAction" template method to SimpleFormController, for =
submit actions without caring about ModelAndView
* AbstractWizardFormController optionally supports "_page" request =
parameter, for proper handling of back button usage
* added support for "person.na*"/"person.address.*"-style field patterns =
to BindTag's "path" attribute
* added Struts DelegatingRequestProcessor and =
DelegatingTilesRequestProcessor as alternatives to DelegatingActionProxy

See the changelog for details. We have also refined our roadmap; see our =
JIRA for a rough plan of what's ahead.
=20
Thanks for using Spring!
=20
Regards,
=20
Juergen

[Springframework-developer] Should DataBinder be an interface?

[Seth L. <se...@eh...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

In writing unit tests for my Controllers, I find I need to test the
initBinder method and test what I place inside the binder (via
registerCustomEditor).

I tried mocking the DataBinder class w/ easymock + cglib extension, but
it would generate an NPE.  The easymock list thinks this is a bug in
their code, though haven't heard from them since.

Is there a reason not to move (at some point) DataBinder to an
interface?  This would help with testing and mocks.  Another option
would be to create a MockDataBinder and add it to the spring-mocks.

Any thoughts?

Thanks!
Seth

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAvm7fKZsFSwtW+wIRAuH+AJ0SvEc4sh6P8qaRe2XwEKoDVrspPwCfSWz7
tOxXVGKAnmqsVuKrUoYVQHo=
=2nLo
-----END PGP SIGNATURE-----

Re: [Springframework-developer] Possible Bug in DefaultMessageSourceResolver

[Seth L. <se...@eh...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

jürgen höller [werk3AT] wrote:

| You mean overworked because that guy spends the third night in
succession on release preparations (till around 4:00 AM yesterday and
the day before)? ;-)
|
| Actually, that's a last-minute bugfix - good timing, Seth :-) I've
already finished all testing and am about to upload the zip to
SourceForge within the next half hour.

Where do we send the beer? :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAvmklKZsFSwtW+wIRAufRAJ0TxQ3glS6FDQJsGmYnZEEv33z9bACfVcQP
09dOgfSLGLLx+uOZQZqqWQM=
=dLya
-----END PGP SIGNATURE-----