springframework-developer — Spring Framework developers list

Re: [Springframework-developer] Dependency checking

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

Sounds sort of useful, although unless I am misunderstanding how this 
would work, it would not be useful for a lot of beans since you can use 
a lot of beans without setting all properties, relying on defaults, etc.

What I think would be useful for Spring is a tool for verifying that all 
classes and interfaces which have been specified in a context definition 
are actually available on the classpath. I have been hit by typos a few 
times, and having a tool in the build which would verify the context in 
this respect would be useful...


rod...@in... wrote:

>All,
>
>As I can see it the only arguable advantage that 
>PicoContainer has over Spring is that it can satisfy all 
>dependencies before allowing an object to be invoked, so that 
>an object can never be used when incompletely configured. I 
>don't like their constructor way of doing this, and I think 
>that it often makes sense to have optional properties, with 
>sensible default. So I've never been worried by this in 
>Spring.
>
>However, it's pretty easy to add optional dependency 
>checking. I've successfully prototyped the following, which 
>required very minor changes:
>- add a new DTD attribute for the "bean" element called 
>dependencyCheck
>- if this is set to true, XmlBeanFactory checks that all 
>properties on that bean have been set. If not it throws an 
>UnsatisfiedDependencyException. We can't do the PicoContainer-
>style automatic wiring up as we can support multiple objects 
>of any type. They can only accomplish this because they 
>support only a single object of each type, which doesn't 
>satisfy the kind of real-world requirements I've used Spring 
>in.
>
>At present my prototype checks only Object properties 
>(presumably other beans in the factory). It might be good to 
>have three values for dependencyCheck: "no" 
>(default), "object" (collaborators) and "all" (primitives and 
>collaborators).
>
>As this is backward compatible and easy to do I'm inclined to 
>add it, if only for marketing value. There may be real value 
>in that it means that an init method wouldn't need to check 
>that a certain property was non-null.
>
>What do you think? Is this worthwhile?
>
>Regards,
>Rod
>  
>

Re: [Springframework-developer] Dependency checking

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

+1

rod...@in... wrote:

>All,
>
>As I can see it the only arguable advantage that 
>PicoContainer has over Spring is that it can satisfy all 
>dependencies before allowing an object to be invoked, so that 
>an object can never be used when incompletely configured. I 
>don't like their constructor way of doing this, and I think 
>that it often makes sense to have optional properties, with 
>sensible default. So I've never been worried by this in 
>Spring.
>
>However, it's pretty easy to add optional dependency 
>checking. I've successfully prototyped the following, which 
>required very minor changes:
>- add a new DTD attribute for the "bean" element called 
>dependencyCheck
>- if this is set to true, XmlBeanFactory checks that all 
>properties on that bean have been set. If not it throws an 
>UnsatisfiedDependencyException. We can't do the PicoContainer-
>style automatic wiring up as we can support multiple objects 
>of any type. They can only accomplish this because they 
>support only a single object of each type, which doesn't 
>satisfy the kind of real-world requirements I've used Spring 
>in.
>
>At present my prototype checks only Object properties 
>(presumably other beans in the factory). It might be good to 
>have three values for dependencyCheck: "no" 
>(default), "object" (collaborators) and "all" (primitives and 
>collaborators).
>
>As this is backward compatible and easy to do I'm inclined to 
>add it, if only for marketing value. There may be real value 
>in that it means that an init method wouldn't need to check 
>that a certain property was non-null.
>
>What do you think? Is this worthwhile?
>
>Regards,
>Rod
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>  
>

Re: [Springframework-developer] Dependency checking

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

All,

As I can see it the only arguable advantage that 
PicoContainer has over Spring is that it can satisfy all 
dependencies before allowing an object to be invoked, so that 
an object can never be used when incompletely configured. I 
don't like their constructor way of doing this, and I think 
that it often makes sense to have optional properties, with 
sensible default. So I've never been worried by this in 
Spring.

However, it's pretty easy to add optional dependency 
checking. I've successfully prototyped the following, which 
required very minor changes:
- add a new DTD attribute for the "bean" element called 
dependencyCheck
- if this is set to true, XmlBeanFactory checks that all 
properties on that bean have been set. If not it throws an 
UnsatisfiedDependencyException. We can't do the PicoContainer-
style automatic wiring up as we can support multiple objects 
of any type. They can only accomplish this because they 
support only a single object of each type, which doesn't 
satisfy the kind of real-world requirements I've used Spring 
in.

At present my prototype checks only Object properties 
(presumably other beans in the factory). It might be good to 
have three values for dependencyCheck: "no" 
(default), "object" (collaborators) and "all" (primitives and 
collaborators).

As this is backward compatible and easy to do I'm inclined to 
add it, if only for marketing value. There may be real value 
in that it means that an init method wouldn't need to check 
that a certain property was non-null.

What do you think? Is this worthwhile?

Regards,
Rod

[Springframework-developer] =?iso-8859-1?Q?Re:[Springframework-developer]_Binding_to_a_Collection?=

[=?iso-8859-1?Q?<jp....@ti...>]

Dmitriy,=0D=0A=0D=0AI will split the answer in two parts:=0D=0A1) Html si=
ngle values (most form elements)=0D=0A2) Html multiple values (checkboxes=
, selects with "multiple")=0D=0A=0D=0A1) There is no support for multiple=
 commands as I know. In an earlier discussion on this topic, Juergen was =
against this possibility. What I use is a command embedding others as now=
 the problems with inner fields are fixed. So you can set 'subCmd1.person=
.name' for example.=0D=0A=0D=0A2) When using multiple Html values, These =
values are wrapped into a Strings array by default. If you prefer have a =
kind of collection instead, you will have to write a propertiesEditor for=
 your data type. In this case, you will receive as text value a comma del=
imited String including the values from the array.=0D=0A=0D=0AI use it fo=
r creating an Objects list receiving the ids by this way. If you are inte=
rested, I can provide you some examples.  =0D=0A=0D=0ARegards,=0D=0AJean-=
Pierre=0D=0A=0D=0A=0D=0A---------- Initial Header -----------=0D=0A=0D=0A=
From      : spr...@li...=0D=0ATo=
          : "'spr...@li...'" <springfr=
ame...@li...>=0D=0ACc          : =0D=0ADate   =
   : Wed, 3 Sep 2003 08:37:25 -0400=0D=0ASubject : [Springframework-devel=
oper] Binding to a Collection=0D=0A=0D=0AHi everybody. I have one questio=
n, if any one has a quick answer :-) What=0D=0Awould be the best way to "=
bind" html data into a collection of objects? =0D=0A=0D=0ALet's say I hav=
e an html table in the form, each row representing a=0D=0Amodel/command o=
bject. When submitting this form to a Controller, I would=0D=0Alike to bi=
nd the values from the html table into a Collection of=0D=0Amodel/command=
 objects. What would be the best way to do that?=0D=0A=0D=0AThanks,=0D=0A=
Dmitriy.=0D=0A=0D=0AP.S.=0D=0A=0D=0AI believe there was a message about t=
his issue on the list, but I'm to lazy=0D=0Ato search for it ;-)=0D=0A=0D=
=0A=0D=0A=0A=0A********** L'ADSL A 20 EUR/MOIS********** =0AAvec Tiscali,=
 l'ADSL est =E0 20 EUR/mois. Vous pourrez chercher longtemps avant de tro=
uver moins cher ! =0APour profiter de cette offre exceptionnelle, cliquez=
 ici : http://register.tiscali.fr/adsl/=0AOffre soumise =E0 conditions.=0A=

[Springframework-developer] Binding to a Collection

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

Hi everybody. I have one question, if any one has a quick answer :-) What
would be the best way to "bind" html data into a collection of objects? 

Let's say I have an html table in the form, each row representing a
model/command object. When submitting this form to a Controller, I would
like to bind the values from the html table into a Collection of
model/command objects. What would be the best way to do that?

Thanks,
Dmitriy.

P.S.

I believe there was a message about this issue on the list, but I'm to lazy
to search for it ;-)

[Springframework-developer] Javadocs

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

Thomas,

We still have com.interface21 Javadocs on the web site. (I've 
only noticed after linking to the DataAccessException Javadoc 
directly on a TSS thread :-( Can you please update them. 
Maybe leave the I21 docs as well!?? Would be great to add 
some deprecation message to all of them, but that might be a 
pain.

Thanks,
Rod

[Springframework-developer] Pressing enhancements (was: Tiles Example (was: Integration samples))

[Alef A. \(JTeam\) <al...@jt...>]

There are two major things I'd like to address before M2 and a minor
issues

1 (major). Addition of propertyeditor support for reference data. A
customer has a language (Locale). A controller returns a
formbackingobject containing the setter for the Locale. The
referencedata method returns a list of Locale available to choose from.
For the BeanWrapper to be able to set the Locale the user has chosen
from the list, it (the reference data locale list) must be 'transformed'
using the PropertyEditor that has been registered for that specific
field (implications: additions of getter for the PropertyEditoron Errors
interface and a TransformTag actually allowing the transformation)

3 (major). Documentation. I plan to do a lot more JavaDOC (especially
the MVC package) and make it more accessible (by creating better package
descriptions).

2 (minor). Possibility of specifying which Binder to use, to allow for
transformation of input to Beanproperties based on something other than
http-params (for instance XML or whatever).

Feedback please ;-)

Alef

P.s. Yeah Juergen..., I keep on getting amazed by the guy...

-----Oorspronkelijk bericht-----
Van: Rod Johnson [mailto:rod...@in...] 
Verzonden: Wednesday, September 03, 2003 12:17 AM
Aan: al...@jt...; jp....@ti...
CC: 'springframework-developer'
Onderwerp: Re: [Springframework-developer] Tiles Example (was:
Integration samples)


>I don't know what the time-span for the next release is, I might have
some time to document things a bit further (we also need some kind of
tiles-howto), but not until at least next week...

We've been doing one release every 3 weeks, but I think 4-5 weeks is
more appropriate for M2. Early October. It was urgent to get the first
org.springframework release out ASAP

My main priority at present is source level metadata at present. That
and ResultSet returns from stored procedures might justify a release
before the end of September. If anyone else is aware of any other
pressing enhancements, let me know.

With Juergen away the pace of change will probably slow a bit...I don't
think I've ever come across anyone with that much (well-directed)
energy!

Regards,
Rod

Re: [Springframework-developer] Tiles Example (was: Integration samples)

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

>I don't know what the time-span for the next release is, I might have
some time to document things a bit further (we also need some kind of
tiles-howto), but not until at least next week...

We've been doing one release every 3 weeks, but I think 4-5 weeks is more
appropriate for M2. Early October. It was urgent to get the first
org.springframework release out ASAP

My main priority at present is source level metadata at present. That and
ResultSet returns from stored procedures might justify a release before the
end of September. If anyone else is aware of any other pressing
enhancements, let me know.

With Juergen away the pace of change will probably slow a bit...I don't
think I've ever come across anyone with that much (well-directed) energy!

Regards,
Rod

[Springframework-developer] RE: Tiles Example (was: Integration samples)

[Alef A. \(JTeam\) <al...@jt...>]

Ahh, forgot to say one other thing...

The retrieval of the news is doen right now on a per request basis, so
it's kinda slow... When I have time, I'll implement a small caching
mech.

Alef


-----Oorspronkelijk bericht-----
Van: Alef Arendsen (JTeam) [mailto:al...@jt...]=20
Verzonden: Wednesday, September 03, 2003 12:20 AM
Aan: 'jp....@ti...'
CC: 'springframework-developer'
Onderwerp: Tiles Example (was: Integration samples)


Tiles example is in the CVS right now...

I id _not_ add it to the sandbox, since that only contains .java files
and must frustrate users wanting to build the sandbox?

Anyway, the example it quite straightforward, however it does not have
_any_ documentation, except for a small piece in the webapp itself.

1. run ant warfile in the tiles-example-dir
2. deploy the tiles-example.war from dist
3. goto <host:port>/tiles-example/index.html
4. there it is...

It has a couple two templates (one for the complete site, one for the
newsfeeds that are automatically imported into the site). The main
template is re-used for the index, about and contact pages, the news
template is used for the news from worldpress, theserverside and
slashdot (two sources are displayed on every page, which ones depends on
what page you're viewing).

The news template uses a Controller (extending
ComponentControllerSupport) so it can reach the appCtx to retrieve the
feedConfigurator (mentioning the feed names and urls). How many and what
feeds are displayed is defined in the definitions.xml file...

I don't know what the time-span for the next release is, I might have
some time to document things a bit further (we also need some kind of
tiles-howto), but not until at least next week...

Alef

-----Oorspronkelijk bericht-----
Van: jp....@ti... [mailto:jp....@ti...]=20
Verzonden: Monday, September 01, 2003 11:01 AM
Aan: alef
CC: springframework-developer
Onderwerp: RE: [Springframework-developer] Integration samples


Alef,

Obviously, Tiles being integrated to Spring, it had to be first listed.

Maybe I or someone else could find any time for finishing the Tiles
sample. Could you upload it in the CVS? As long as it is not finished,
perhaps the sandbox could be a better place?

Regards,
Jean-Pierre

---------- Initial Header -----------

From      : "Alef Arendsen \(JTeam\)" <al...@jt...>
To          : "'JP Pawlak'" <jp....@ti...>,
<spr...@li...>
Cc          :=20
Date      : Mon, 1 Sep 2003 09:08:29 +0200
Subject : RE: [Springframework-developer] Integration samples

I still have a Tiles example lying around, however, I haven't got enough
time right now to finish it...

Alef


-----Oorspronkelijk bericht-----
Van: spr...@li...
[mailto:spr...@li...] Namens JP
Pawlak
Verzonden: Saturday, August 30, 2003 2:51 PM
Aan: spr...@li...
Onderwerp: [Springframework-developer] Integration samples


Hi all,

In addition to the samples discussion I provided two messages ago,
another family will certainly be helpful and no great work. I mean
integration samples with some others frameworks like :

- Tapestry
- Webwork
- Struts

Jean-Pierre





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf _______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



********** L'ADSL A 20 EUR/MOIS**********=20
Avec Tiscali, l'ADSL est =E0 20 EUR/mois. Vous pourrez chercher =
longtemps
avant de trouver moins cher !=20
Pour profiter de cette offre exceptionnelle, cliquez ici :
http://register.tiscali.fr/adsl/ Offre soumise =E0 conditions.

[Springframework-developer] Tiles Example (was: Integration samples)

[Alef A. \(JTeam\) <al...@jt...>]

Tiles example is in the CVS right now...

I id _not_ add it to the sandbox, since that only contains .java files
and must frustrate users wanting to build the sandbox?

Anyway, the example it quite straightforward, however it does not have
_any_ documentation, except for a small piece in the webapp itself.

1. run ant warfile in the tiles-example-dir
2. deploy the tiles-example.war from dist
3. goto <host:port>/tiles-example/index.html
4. there it is...

It has a couple two templates (one for the complete site, one for the
newsfeeds that are automatically imported into the site). The main
template is re-used for the index, about and contact pages, the news
template is used for the news from worldpress, theserverside and
slashdot (two sources are displayed on every page, which ones depends on
what page you're viewing).

The news template uses a Controller (extending
ComponentControllerSupport) so it can reach the appCtx to retrieve the
feedConfigurator (mentioning the feed names and urls). How many and what
feeds are displayed is defined in the definitions.xml file...

I don't know what the time-span for the next release is, I might have
some time to document things a bit further (we also need some kind of
tiles-howto), but not until at least next week...

Alef

-----Oorspronkelijk bericht-----
Van: jp....@ti... [mailto:jp....@ti...]=20
Verzonden: Monday, September 01, 2003 11:01 AM
Aan: alef
CC: springframework-developer
Onderwerp: RE: [Springframework-developer] Integration samples


Alef,

Obviously, Tiles being integrated to Spring, it had to be first listed.

Maybe I or someone else could find any time for finishing the Tiles
sample. Could you upload it in the CVS? As long as it is not finished,
perhaps the sandbox could be a better place?

Regards,
Jean-Pierre

---------- Initial Header -----------

From      : "Alef Arendsen \(JTeam\)" <al...@jt...>
To          : "'JP Pawlak'" <jp....@ti...>,
<spr...@li...>
Cc          :=20
Date      : Mon, 1 Sep 2003 09:08:29 +0200
Subject : RE: [Springframework-developer] Integration samples

I still have a Tiles example lying around, however, I haven't got enough
time right now to finish it...

Alef


-----Oorspronkelijk bericht-----
Van: spr...@li...
[mailto:spr...@li...] Namens JP
Pawlak
Verzonden: Saturday, August 30, 2003 2:51 PM
Aan: spr...@li...
Onderwerp: [Springframework-developer] Integration samples


Hi all,

In addition to the samples discussion I provided two messages ago,
another family will certainly be helpful and no great work. I mean
integration samples with some others frameworks like :

- Tapestry
- Webwork
- Struts

Jean-Pierre





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf _______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



********** L'ADSL A 20 EUR/MOIS**********=20
Avec Tiscali, l'ADSL est =E0 20 EUR/mois. Vous pourrez chercher =
longtemps
avant de trouver moins cher !=20
Pour profiter de cette offre exceptionnelle, cliquez ici :
http://register.tiscali.fr/adsl/ Offre soumise =E0 conditions.

Re: [Springframework-developer] Shared object support

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

Thanks Alef,

I've now removed shared object support.

Regards,
Rod

----- Original Message ----- 
From: "Alef Arendsen (JTeam)" <al...@jt...>
To: "'Rod Johnson'" <rod...@in...>
Cc: <spr...@li...>
Sent: Tuesday, September 02, 2003 10:59 PM
Subject: RE: [Springframework-developer] Shared object support


> Rod,
> 
> I've removed the dependencies on the shared object support from the
> Tiles classes, so you're free to remove it from the context classes and
> the tests.
> 
> Cheers,
> Alef
> 
> 
> 

RE: [Springframework-developer] Shared object support

[Alef A. \(JTeam\) <al...@jt...>]

Rod,

I've removed the dependencies on the shared object support from the
Tiles classes, so you're free to remove it from the context classes and
the tests.

Cheers,
Alef

RE: [Springframework-developer] Integration samples

[Alef A. \(JTeam\) <al...@jt...>]

Sorry for the delay, it'll be there this evening...

Alef


-----Oorspronkelijk bericht-----
Van: jp....@ti... [mailto:jp....@ti...]=20
Verzonden: Monday, September 01, 2003 11:01 AM
Aan: alef
CC: springframework-developer
Onderwerp: RE: [Springframework-developer] Integration samples


Alef,

Obviously, Tiles being integrated to Spring, it had to be first listed.

Maybe I or someone else could find any time for finishing the Tiles
sample. Could you upload it in the CVS? As long as it is not finished,
perhaps the sandbox could be a better place?

Regards,
Jean-Pierre

---------- Initial Header -----------

From      : "Alef Arendsen \(JTeam\)" <al...@jt...>
To          : "'JP Pawlak'" <jp....@ti...>,
<spr...@li...>
Cc          :=20
Date      : Mon, 1 Sep 2003 09:08:29 +0200
Subject : RE: [Springframework-developer] Integration samples

I still have a Tiles example lying around, however, I haven't got enough
time right now to finish it...

Alef


-----Oorspronkelijk bericht-----
Van: spr...@li...
[mailto:spr...@li...] Namens JP
Pawlak
Verzonden: Saturday, August 30, 2003 2:51 PM
Aan: spr...@li...
Onderwerp: [Springframework-developer] Integration samples


Hi all,

In addition to the samples discussion I provided two messages ago,
another family will certainly be helpful and no great work. I mean
integration samples with some others frameworks like :

- Tapestry
- Webwork
- Struts

Jean-Pierre





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf _______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



********** L'ADSL A 20 EUR/MOIS**********=20
Avec Tiscali, l'ADSL est =E0 20 EUR/mois. Vous pourrez chercher =
longtemps
avant de trouver moins cher !=20
Pour profiter de cette offre exceptionnelle, cliquez ici :
http://register.tiscali.fr/adsl/ Offre soumise =E0 conditions.

[Springframework-developer] Milestone

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

Guys,

We've just exceeded 1000 downloads on SourceForge (probably more as their
count is usually a bit out of date).

I think this is pretty good as we've only had anything to download for 2
months!

I've begun the draft of an article for TSS called "Introduction to the
Spring Framework". When I get time to get it into a coherent state (probably
late this week) I'll put it into CVS for other developers to review
(probably via Word comments) and possibly add material.

After the review (say about a week) I'll revise it again and send it to
Floyd mid September. Floyd told me in Boston he'd be happy to publish such
an article.

I think a TSS article will help boost interest significantly.

Regards,
Rod

RE: [Springframework-developer] Shared object support

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

+1

-----Original Message-----
From: Rod Johnson
To: spr...@li...
Sent: 8/31/2003 3:03 PM
Subject: [Springframework-developer] Shared object support

Another candidate on my simplification hitlist: shared object support
for
ApplicationContexts.

I added this relatively late before the project went open source.
Juergen
and I agree it's probably not necessary.

Anyone using it? Please let me know if you object to it being removed.

As I've said, I'm keen to simplify the API and implementation to just
what's
necessary and best practice before 1.0.

Regards,
Rod




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Shared object support

[Alef A. \(JTeam\) <al...@jt...>]

I don't object to anything that'll simplifies API's. I'll have a look
into in this afternoon...

Alef


-----Oorspronkelijk bericht-----
Van: Rod Johnson [mailto:rod...@in...] 
Verzonden: Tuesday, September 02, 2003 12:42 AM
Aan: al...@jt...; spr...@li...
Onderwerp: Re: [Springframework-developer] Shared object support


Alef,

Do you mean you do or don't object to removing shared object support?

The only thing that removing it breaks is the Tiles support. If you
agree it should be removed, are you happy to change this first?

Regards,
Rod


----- Original Message -----
From: "Alef Arendsen (JTeam)" <al...@jt...>
To: "'Rod Johnson'" <rod...@in...>;
<spr...@li...>
Sent: Monday, September 01, 2003 8:04 AM
Subject: RE: [Springframework-developer] Shared object support


> +1
>
> -----Oorspronkelijk bericht-----
> Van: spr...@li...
> [mailto:spr...@li...] Namens 
> Rod Johnson
> Verzonden: Sunday, August 31, 2003 9:04 PM
> Aan: spr...@li...
> Onderwerp: [Springframework-developer] Shared object support
>
>
> Another candidate on my simplification hitlist: shared object support 
> for ApplicationContexts.
>
> I added this relatively late before the project went open source. 
> Juergen and I agree it's probably not necessary.
>
> Anyone using it? Please let me know if you object to it being removed.
>
> As I've said, I'm keen to simplify the API and implementation to just 
> what's necessary and best practice before 1.0.
>
> Regards,
> Rod
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf 
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>

Re: [Springframework-developer] Shared object support

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

> Is this explained anywhere?
No, another reason for wanting to get rid of it :-)

>Perhaps you could point me to the class or
> package if it takes more than a sentence or two to describe what it is...

org.sfw.context.ApplicationContext interface and
org.sfw.context.support.AbstractApplicationContext.

Regards,
Rod


>
> Rod Johnson wrote:
>
> >Another candidate on my simplification hitlist: shared object support for
> >ApplicationContexts.
> >
> >I added this relatively late before the project went open source. Juergen
> >and I agree it's probably not necessary.
> >
> >Anyone using it? Please let me know if you object to it being removed.
> >
> >As I've said, I'm keen to simplify the API and implementation to just
what's
> >necessary and best practice before 1.0.
> >
> >Regards,
> >Rod
> >
> >
>
>
>
>

[Springframework-developer] BeanFactoryBootstrap

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

Is anyone using, or does anyone have suggestions as to how to improve, the
BeanFactoryBootstrap class (in beans.factory.support)?

I'm inclined to demote it to the sandbox, unless it can be made
significantly more useful.

The motivation was to provide a generic way of configuring a BeanFactory on
those occasions when a BeanFactory had to be loaded as a singleton.

It works by looking at System properties to find a bean definition called
"bootstrapBeanFactory". The problem with this is that most BeanFactory
implementations, like the XmlBeanFactory, are not JavaBeans, and hence can't
easily be configured themselves via a BeanFactory.

I did also once consider supporting alternative sources of
properties--properties file on classpath etc--that could be searched in a
documented order.

Is this a potentially useful piece of functionality that we should get
right? Or should we just leave users to write their own custom singletons if
they really need to bootstrap via a Singleton rather than a J2EE hook like
ServletContext?

Regards,
Rod

Re: [Springframework-developer] Shared object support

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

Is this explained anywhere? Perhaps you could point me to the class or 
package if it takes more than a sentence or two to describe what it is...

Regards,
Colin

Rod Johnson wrote:

>Another candidate on my simplification hitlist: shared object support for
>ApplicationContexts.
>
>I added this relatively late before the project went open source. Juergen
>and I agree it's probably not necessary.
>
>Anyone using it? Please let me know if you object to it being removed.
>
>As I've said, I'm keen to simplify the API and implementation to just what's
>necessary and best practice before 1.0.
>
>Regards,
>Rod
>  
>

Re: [Springframework-developer] Shared object support

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

Alef,

Do you mean you do or don't object to removing shared object support?

The only thing that removing it breaks is the Tiles support. If you agree it
should be removed, are you happy to change this first?

Regards,
Rod


----- Original Message -----
From: "Alef Arendsen (JTeam)" <al...@jt...>
To: "'Rod Johnson'" <rod...@in...>;
<spr...@li...>
Sent: Monday, September 01, 2003 8:04 AM
Subject: RE: [Springframework-developer] Shared object support


> +1
>
> -----Oorspronkelijk bericht-----
> Van: spr...@li...
> [mailto:spr...@li...] Namens
> Rod Johnson
> Verzonden: Sunday, August 31, 2003 9:04 PM
> Aan: spr...@li...
> Onderwerp: [Springframework-developer] Shared object support
>
>
> Another candidate on my simplification hitlist: shared object support
> for ApplicationContexts.
>
> I added this relatively late before the project went open source.
> Juergen and I agree it's probably not necessary.
>
> Anyone using it? Please let me know if you object to it being removed.
>
> As I've said, I'm keen to simplify the API and implementation to just
> what's necessary and best practice before 1.0.
>
> Regards,
> Rod
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>

[Springframework-developer] =?iso-8859-1?Q?RE:_[Springframework-developer]_Integration_samples?=

[=?iso-8859-1?Q?<jp....@ti...>]

Alef,=0D=0A=0D=0AObviously, Tiles being integrated to Spring, it had to b=
e first listed.=0D=0A=0D=0AMaybe I or someone else could find any time fo=
r finishing the Tiles sample. Could you upload it in the CVS? As long as =
it is not finished, perhaps the sandbox could be a better place?=0D=0A=0D=
=0ARegards,=0D=0AJean-Pierre=0D=0A=0D=0A---------- Initial Header -------=
----=0D=0A=0D=0AFrom      : "Alef Arendsen \(JTeam\)" <al...@jt...>=0D=0A=
To          : "'JP Pawlak'" <jp....@ti...>,  <springframework-dev=
el...@li...>=0D=0ACc          : =0D=0ADate      : Mon, 1=
 Sep 2003 09:08:29 +0200=0D=0ASubject : RE: [Springframework-developer] I=
ntegration samples=0D=0A=0D=0AI still have a Tiles example lying around, =
however, I haven't got enough=0D=0Atime right now to finish it...=0D=0A=0D=
=0AAlef=0D=0A=0D=0A=0D=0A-----Oorspronkelijk bericht-----=0D=0AVan: sprin=
gfr...@li...=0D=0A[mailto:springframe=
wor...@li...] Namens JP=0D=0APawlak=0D=0AVe=
rzonden: Saturday, August 30, 2003 2:51 PM=0D=0AAan: springframework-deve=
lo...@li...=0D=0AOnderwerp: [Springframework-developer] I=
ntegration samples=0D=0A=0D=0A=0D=0AHi all,=0D=0A=0D=0AIn addition to the=
 samples discussion I provided two messages ago,=0D=0Aanother family will=
 certainly be helpful and no great work. I mean=0D=0Aintegration samples =
with some others frameworks like :=0D=0A=0D=0A- Tapestry=0D=0A- Webwork=0D=
=0A- Struts=0D=0A=0D=0AJean-Pierre=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A---=
----------------------------------------------------=0D=0AThis sf.net ema=
il is sponsored by:ThinkGeek=0D=0AWelcome to geek heaven.=0D=0Ahttp://thi=
nkgeek.com/sf _______________________________________________=0D=0ASpring=
framework-developer mailing lis...@li...=
rceforge.net=0D=0Ahttps://lists.sourceforge.net/lists/listinfo/springfram=
ework-developer=0D=0A=0D=0A=0A=0A********** L'ADSL A 20 EUR/MOIS*********=
* =0AAvec Tiscali, l'ADSL est =E0 20 EUR/mois. Vous pourrez chercher long=
temps avant de trouver moins cher ! =0APour profiter de cette offre excep=
tionnelle, cliquez ici : http://register.tiscali.fr/adsl/=0AOffre soumise=
 =E0 conditions.=0A

RE: [Springframework-developer] Integration samples

[Alef A. \(JTeam\) <al...@jt...>]

I still have a Tiles example lying around, however, I haven't got enough
time right now to finish it...

Alef


-----Oorspronkelijk bericht-----
Van: spr...@li...
[mailto:spr...@li...] Namens JP
Pawlak
Verzonden: Saturday, August 30, 2003 2:51 PM
Aan: spr...@li...
Onderwerp: [Springframework-developer] Integration samples


Hi all,

In addition to the samples discussion I provided two messages ago,
another family will certainly be helpful and no great work. I mean
integration samples with some others frameworks like :

- Tapestry
- Webwork
- Struts

Jean-Pierre





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf _______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Validation package

[Alef A. \(JTeam\) <al...@jt...>]

+1

About the databinder, I've having a small discussion lately about the
possibility of changing the databinder implementation used. Right now it
works with servletrequestparameters, however, I'd like to investigate
the possiblity to for instance have a databinder that works with for
instance castor XML contained in the servletrequest... Any idea, or
would this make things needlessly complex?

Alef

-----Oorspronkelijk bericht-----
Van: spr...@li...
[mailto:spr...@li...] Namens
Rod Johnson
Verzonden: Sunday, August 31, 2003 8:48 PM
Aan: spr...@li...
Onderwerp: [Springframework-developer] Validation package


Is anyone using the addPropertyChangeListener() or
addVetoableChangeListener() method of DataBinder?

I'm looking at removing the JavaBean event propagation from the
BeanWrapper, as I mentioned before. The only other functionality
affected is in the validator.

A consequence is that setPropertyValues() methods will not throw any
checked exceptions (PropertyVetoException from JavaBeans API is
checked).

Is everyone happy with this change, which I think is a worthwhile
simplification of API and implementation?

Regards,
Rod




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf _______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Shared object support

[Alef A. \(JTeam\) <al...@jt...>]

+1

-----Oorspronkelijk bericht-----
Van: spr...@li...
[mailto:spr...@li...] Namens
Rod Johnson
Verzonden: Sunday, August 31, 2003 9:04 PM
Aan: spr...@li...
Onderwerp: [Springframework-developer] Shared object support


Another candidate on my simplification hitlist: shared object support
for ApplicationContexts.

I added this relatively late before the project went open source.
Juergen and I agree it's probably not necessary.

Anyone using it? Please let me know if you object to it being removed.

As I've said, I'm keen to simplify the API and implementation to just
what's necessary and best practice before 1.0.

Regards,
Rod




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf _______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Shared object support

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

Another candidate on my simplification hitlist: shared object support for
ApplicationContexts.

I added this relatively late before the project went open source. Juergen
and I agree it's probably not necessary.

Anyone using it? Please let me know if you object to it being removed.

As I've said, I'm keen to simplify the API and implementation to just what's
necessary and best practice before 1.0.

Regards,
Rod