springframework-developer — Spring Framework developers list

Re: [Springframework-developer] BeanWrapperImpl & PropertyEditors

[Guillaume P. <gpo...@gl...>]

I went back looking and indeed your right.  I guess I didn't see it at first
because I was looking at a closed issue. :-)

----- Original Message ----- 
From: "Alef Arendsen" <al...@jt...>
To: <spr...@li...>
Sent: Sunday, March 07, 2004 10:35 AM
Subject: RE: [Springframework-developer] BeanWrapperImpl & PropertyEditors


Hmmm, maybe users somehow don't have the rights to attach files. Sure you
haven't missed the attach menu item on left-hand side?

Well, anyway, I've attached it to the issue.

Alef


> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
> Of Guillaume Poirier
> Sent: Sunday, March 07, 2004 4:11 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] BeanWrapperImpl & PropertyEditors
>
> Also, I ran a similar Test Case against XmlBeanFactory with prototypes and
> custom PropertyEditors, and it failled the test.  I assume BeanFactory is
> supposed to be thread safe since it can be shared in a client-server
> environnement.  Making the method
> AbstractAutowireCapableBeanFactory.createBean(String, RootBeanDefinition)
> synchronized fixed my particular test case, but I'm not sure if it's the
> best way to get around this problem.  The test case is attached to this
> mail, all of the files should go in the package
> org.springframework.beans.factory.  I would fill an issue in JIRA, but I
> didn't see a way to include an attachement, so I thought I should probably
> just post here.
>
> Guillaume
>
> ----- Original Message -----
> From: "Alef Arendsen" <al...@jt...>
> To: <spr...@li...>
> Sent: Sunday, March 07, 2004 7:35 AM
> Subject: RE: [Springframework-developer] BeanWrapperImpl & PropertyEditors
>
>
> I ran the testcase and it seems you're right ;-).
>
> I'll include it in JIRA, Jürgen should have a look at this, he's the
> BeanWrapper expert ;-).
>
> Alef
>
>
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...] On Behalf
> > Of Guillaume Poirier
> > Sent: Saturday, March 06, 2004 6:04 AM
> > To: spr...@li...
> > Subject: Re: [Springframework-developer] BeanWrapperImpl &
> PropertyEditors
> >
> > I have created a test case to illustrate the problem, and fixed the
> > BeanWrapperImpl code so that it passes my test case.  Both are included
> in
> > the patch attached to this E-Mail.  Feel free to use/modify the code.
> > (The
> > number of threads created might need adjustement).
> >
> > Guillaume
> >
> > ----- Original Message -----
> > From: "Guillaume Poirier" <gpo...@gl...>
> > To: <spr...@li...>
> > Sent: Friday, March 05, 2004 1:02 PM
> > Subject: [Springframework-developer] BeanWrapperImpl & PropertyEditors
> >
> >
> > > Hello,
> > >
> > > While answering to the question concerning PropertyEditors in the post
> > "permanantly registering property editor with BeanWrapper?", I looked
> the
> > the source code of BeanWrapperImpl and noticed something.  It sounds
> like
> > BeanWrapperImpl's class is not thread safe?  And I don't mean instance
> of
> > the class, but rather the class itself.  There's a static HashMap
> > defaultEditors that contains PropertyEditors.  However, PropertyEditors
> > are
> > not thread safe.  That means if there's two threads using two different
> > instances of BeanWrapperImpl at the same time, there's a possiblity they
> > both get a reference on the same PropertyEditor, and that the getValue()
> > of
> > the first one to call setAsText is the value of the second one that
> called
> > that method.  Or am I missing something?
> > >
> > > Guillaume
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by: IBM Linux Tutorials
> > > Free Linux tutorial presented by Daniel Robbins, President and CEO of
> > > GenToo technologies. Learn everything from fundamentals to system
> > > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> > >
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=ick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=ick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] BeanWrapperImpl & PropertyEditors

[Alef A. <al...@jt...>]

Hmmm, maybe users somehow don't have the rights to attach files. Sure =
you
haven't missed the attach menu item on left-hand side?

Well, anyway, I've attached it to the issue.

Alef


> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On =
Behalf
> Of Guillaume Poirier
> Sent: Sunday, March 07, 2004 4:11 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] BeanWrapperImpl & =
PropertyEditors
>=20
> Also, I ran a similar Test Case against XmlBeanFactory with prototypes =
and
> custom PropertyEditors, and it failled the test.  I assume BeanFactory =
is
> supposed to be thread safe since it can be shared in a client-server
> environnement.  Making the method
> AbstractAutowireCapableBeanFactory.createBean(String, =
RootBeanDefinition)
> synchronized fixed my particular test case, but I'm not sure if it's =
the
> best way to get around this problem.  The test case is attached to =
this
> mail, all of the files should go in the package
> org.springframework.beans.factory.  I would fill an issue in JIRA, but =
I
> didn't see a way to include an attachement, so I thought I should =
probably
> just post here.
>=20
> Guillaume
>=20
> ----- Original Message -----
> From: "Alef Arendsen" <al...@jt...>
> To: <spr...@li...>
> Sent: Sunday, March 07, 2004 7:35 AM
> Subject: RE: [Springframework-developer] BeanWrapperImpl & =
PropertyEditors
>=20
>=20
> I ran the testcase and it seems you're right ;-).
>=20
> I'll include it in JIRA, J=FCrgen should have a look at this, he's the
> BeanWrapper expert ;-).
>=20
> Alef
>=20
>=20
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...] On =
Behalf
> > Of Guillaume Poirier
> > Sent: Saturday, March 06, 2004 6:04 AM
> > To: spr...@li...
> > Subject: Re: [Springframework-developer] BeanWrapperImpl &
> PropertyEditors
> >
> > I have created a test case to illustrate the problem, and fixed the
> > BeanWrapperImpl code so that it passes my test case.  Both are =
included
> in
> > the patch attached to this E-Mail.  Feel free to use/modify the =
code.
> > (The
> > number of threads created might need adjustement).
> >
> > Guillaume
> >
> > ----- Original Message -----
> > From: "Guillaume Poirier" <gpo...@gl...>
> > To: <spr...@li...>
> > Sent: Friday, March 05, 2004 1:02 PM
> > Subject: [Springframework-developer] BeanWrapperImpl & =
PropertyEditors
> >
> >
> > > Hello,
> > >
> > > While answering to the question concerning PropertyEditors in the =
post
> > "permanantly registering property editor with BeanWrapper?", I =
looked
> the
> > the source code of BeanWrapperImpl and noticed something.  It sounds
> like
> > BeanWrapperImpl's class is not thread safe?  And I don't mean =
instance
> of
> > the class, but rather the class itself.  There's a static HashMap
> > defaultEditors that contains PropertyEditors.  However, =
PropertyEditors
> > are
> > not thread safe.  That means if there's two threads using two =
different
> > instances of BeanWrapperImpl at the same time, there's a possiblity =
they
> > both get a reference on the same PropertyEditor, and that the =
getValue()
> > of
> > the first one to call setAsText is the value of the second one that
> called
> > that method.  Or am I missing something?
> > >
> > > Guillaume
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by: IBM Linux Tutorials
> > > Free Linux tutorial presented by Daniel Robbins, President and CEO =
of
> > > GenToo technologies. Learn everything from fundamentals to system
> > > =
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > > =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> > >
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] BeanWrapperImpl & PropertyEditors

[Guillaume P. <gpo...@gl...>]

Also, I ran a similar Test Case against XmlBeanFactory with prototypes and
custom PropertyEditors, and it failled the test.  I assume BeanFactory is
supposed to be thread safe since it can be shared in a client-server
environnement.  Making the method
AbstractAutowireCapableBeanFactory.createBean(String, RootBeanDefinition)
synchronized fixed my particular test case, but I'm not sure if it's the
best way to get around this problem.  The test case is attached to this
mail, all of the files should go in the package
org.springframework.beans.factory.  I would fill an issue in JIRA, but I
didn't see a way to include an attachement, so I thought I should probably
just post here.

Guillaume

----- Original Message ----- 
From: "Alef Arendsen" <al...@jt...>
To: <spr...@li...>
Sent: Sunday, March 07, 2004 7:35 AM
Subject: RE: [Springframework-developer] BeanWrapperImpl & PropertyEditors


I ran the testcase and it seems you're right ;-).

I'll include it in JIRA, Jürgen should have a look at this, he's the
BeanWrapper expert ;-).

Alef


> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
> Of Guillaume Poirier
> Sent: Saturday, March 06, 2004 6:04 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] BeanWrapperImpl & PropertyEditors
>
> I have created a test case to illustrate the problem, and fixed the
> BeanWrapperImpl code so that it passes my test case.  Both are included in
> the patch attached to this E-Mail.  Feel free to use/modify the code.
> (The
> number of threads created might need adjustement).
>
> Guillaume
>
> ----- Original Message -----
> From: "Guillaume Poirier" <gpo...@gl...>
> To: <spr...@li...>
> Sent: Friday, March 05, 2004 1:02 PM
> Subject: [Springframework-developer] BeanWrapperImpl & PropertyEditors
>
>
> > Hello,
> >
> > While answering to the question concerning PropertyEditors in the post
> "permanantly registering property editor with BeanWrapper?", I looked the
> the source code of BeanWrapperImpl and noticed something.  It sounds like
> BeanWrapperImpl's class is not thread safe?  And I don't mean instance of
> the class, but rather the class itself.  There's a static HashMap
> defaultEditors that contains PropertyEditors.  However, PropertyEditors
> are
> not thread safe.  That means if there's two threads using two different
> instances of BeanWrapperImpl at the same time, there's a possiblity they
> both get a reference on the same PropertyEditor, and that the getValue()
> of
> the first one to call setAsText is the value of the second one that called
> that method.  Or am I missing something?
> >
> > Guillaume
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO of
> > GenToo technologies. Learn everything from fundamentals to system
> > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=ick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] BeanWrapperImpl & PropertyEditors

[Alef A. <al...@jt...>]

I ran the testcase and it seems you're right ;-).

I'll include it in JIRA, J=FCrgen should have a look at this, he's the
BeanWrapper expert ;-).

Alef


> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On =
Behalf
> Of Guillaume Poirier
> Sent: Saturday, March 06, 2004 6:04 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] BeanWrapperImpl & =
PropertyEditors
>=20
> I have created a test case to illustrate the problem, and fixed the
> BeanWrapperImpl code so that it passes my test case.  Both are =
included in
> the patch attached to this E-Mail.  Feel free to use/modify the code.
> (The
> number of threads created might need adjustement).
>=20
> Guillaume
>=20
> ----- Original Message -----
> From: "Guillaume Poirier" <gpo...@gl...>
> To: <spr...@li...>
> Sent: Friday, March 05, 2004 1:02 PM
> Subject: [Springframework-developer] BeanWrapperImpl & PropertyEditors
>=20
>=20
> > Hello,
> >
> > While answering to the question concerning PropertyEditors in the =
post
> "permanantly registering property editor with BeanWrapper?", I looked =
the
> the source code of BeanWrapperImpl and noticed something.  It sounds =
like
> BeanWrapperImpl's class is not thread safe?  And I don't mean instance =
of
> the class, but rather the class itself.  There's a static HashMap
> defaultEditors that contains PropertyEditors.  However, =
PropertyEditors
> are
> not thread safe.  That means if there's two threads using two =
different
> instances of BeanWrapperImpl at the same time, there's a possiblity =
they
> both get a reference on the same PropertyEditor, and that the =
getValue()
> of
> the first one to call setAsText is the value of the second one that =
called
> that method.  Or am I missing something?
> >
> > Guillaume
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO =
of
> > GenToo technologies. Learn everything from fundamentals to system
> > =
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >

Re: [Springframework-developer] BeanWrapperImpl & PropertyEditors

[Guillaume P. <gpo...@gl...>]

I have created a test case to illustrate the problem, and fixed the
BeanWrapperImpl code so that it passes my test case.  Both are included in
the patch attached to this E-Mail.  Feel free to use/modify the code.  (The
number of threads created might need adjustement).

Guillaume

----- Original Message ----- 
From: "Guillaume Poirier" <gpo...@gl...>
To: <spr...@li...>
Sent: Friday, March 05, 2004 1:02 PM
Subject: [Springframework-developer] BeanWrapperImpl & PropertyEditors


> Hello,
>
> While answering to the question concerning PropertyEditors in the post
"permanantly registering property editor with BeanWrapper?", I looked the
the source code of BeanWrapperImpl and noticed something.  It sounds like
BeanWrapperImpl's class is not thread safe?  And I don't mean instance of
the class, but rather the class itself.  There's a static HashMap
defaultEditors that contains PropertyEditors.  However, PropertyEditors are
not thread safe.  That means if there's two threads using two different
instances of BeanWrapperImpl at the same time, there's a possiblity they
both get a reference on the same PropertyEditor, and that the getValue() of
the first one to call setAsText is the value of the second one that called
that method.  Or am I missing something?
>
> Guillaume
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] FreeMarker

[Darren D. <da...@da...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've committed freemarker ui and view components to the sandbox as there ar=
e=20
a couple of things still outstanding to do, and they're not fully tested.

Cameron - if you're able to take a look and see if you can get the shared=20
variables aspect working in your project that would be helpful.

Specify a FreemarkerConfig bean in your servlet context file like so;

<!-- freemarker config -->
<bean=20
  id=3D"freemarkerConfig"
  class=3D"org.springfr...view.freemarker.FreemarkerConfigurer"

  <!-- optional -->
  <property name=3D"freemarkerSettings">
    <props>
      <prop key=3D"localized_lookup">true</prop>
      <!-- etc... -->
    </props>
  </property>

  <!-- optional -->
  <map name=3D"freemarkerVariables">
    <entry key=3D"my_helper">
      <ref local=3D"freemarkerHelperObject"/>
    </entry>
    <!-- etc... -->
  </map>
</bean>



and similar to the following to define a view;

fmView.class=3Dorg.springframework.web.servlet.view.freemarker.FreemarkerVi=
ew
# if you don't specify a templateContext, WEB-INF/freemarker will be
# searched for templates
fmView.templateContext=3DWEB-INF/ftl
fmView.url=3Dtest.ftl



=2D --=20

Darren Davison
Public Key: http://www.davison.uk.net/key.jsp
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFASN8IKLMLAN01aw0RAqClAJ4pPlH0MaHWvp2TPxk4j3/T6J3rqwCdG4ny
DOuc/+gNCQrVqZdPuFB7Ug0=3D
=3DpFHR
=2D----END PGP SIGNATURE-----

Re: [Springframework-developer] "permanantly" registering property editor with BeanWrapper?

[Eduardo I. I. <zi...@su...>]

Chris Winters wrote:
> Plus I'm not sure how to do this from an ApplicationContext vs. a 
> BeanFactory -- the registerCustomEditor() seems to be implemented in 
> AbstractBeanFactory which doesn't seem to be a parent of any 
> ApplicationContext class. (I'm a little hazy on the relationships among 
> the objects at this level tho.)

As the CustomEditorConfigurer object implements BeanFactoryPostProcessor it will 
be automatically called by the ApplicationContext and the custom editors will be 
configured. So you can just declare the bean in the xml file and thats all.

If you are using just a BeanFactory it will no work and you will have to do 
something like:

CustomEditorConfigurer c = new CustomEditorConfigurer();
c.setWhatever(..);
c.postProcessBeanFactory(beanFactory);


It raised me a question: what will happen if I do

CustomEditorConfigurer c = beanFactory.getBean("customEditorConfigurer");
c.postProcessBeanFactory(beanFactory);

Is it possible to register a post processor this way?

Re: [Springframework-developer] Commons-Validator for Spring

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

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

Daniel Miller wrote:
| Seth and Keith,
|
| Did you get a chance to look at my commons-validator adaptor? I was
| wondering if you had any feedback? Feel free to tell me that it sucks, or
| that it was so elementary that you didn't want to waste any more time
| talking to me about it :)

Daniel,

I took a look at it briefly.  I think it's a wonderful idea.  It's also
nice because it will help prove the new interfaces being proposed for
the validation system.  I think your commons-validator should integrate
perfectly into the system as an option for validation.

|
| I don't know much about commons-attributes, but from what I've been
picking
| up between the lines on your recent validator-related posts it's quite
| different from the commons-validator approach. The main difference
seems to
| be that validation meta-data is expressed directly in the source of
the bean
| to be validated, while the commons-validator approach uses the
| validation.xml file to hold all of that meta-data.

That's correct.

|
| Your attributes validator sounds a bit more powerful than the commons
| validator, but many of the objects that I want to validate are
generated (by
| Middlegen) and I have no way of adding meta-data to the objects without
| modifying the generated code. Of course, I could just write a wrapper for
| each object that I want to validate, but I might as well just write a
| validator class for each object. That being said, I think there is
room for
| both an attributes validator and a commons validator in the Spring
| framework.

I agree.  I'm not sure either is more powerful, just different ways to
do it.  If they all follow the same interface(s), then it fits with the
Spring mindset.  Just choose a different implementation and let IoC wire
it up!

|
| The main thing I am interested in knowing is the patch that you (Seth)
| posted to allow message resources to be nested (as arguments) in another
| message resource. Do you have any idea how soon this will make its way
into
| a Spring release or should I just get the source and build it in for
my own
| use?

I think Keith is looking into that and hopefully we'll get something
added soon.

Looking forward to the options!
Seth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFASMYn5EIB1scRes8RAopIAJ4mnVTFnAVMevdtIgXWbrIYY8x1FACfSbJh
399P7qxijwtrUNELlxvFOtg=
=I9Wj
-----END PGP SIGNATURE-----

[Springframework-developer] BeanWrapperImpl & PropertyEditors

[Guillaume P. <gpo...@gl...>]

Hello,

While answering to the question concerning PropertyEditors in the post "permanantly registering property editor with BeanWrapper?", I looked the the source code of BeanWrapperImpl and noticed something.  It sounds like BeanWrapperImpl's class is not thread safe?  And I don't mean instance of the class, but rather the class itself.  There's a static HashMap defaultEditors that contains PropertyEditors.  However, PropertyEditors are not thread safe.  That means if there's two threads using two different instances of BeanWrapperImpl at the same time, there's a possiblity they both get a reference on the same PropertyEditor, and that the getValue() of the first one to call setAsText is the value of the second one that called that method.  Or am I missing something?

Guillaume

Re: RE: [Springframework-developer] "permanantly" registering property editor with BeanWrapper?

[Guillaume P. <gpo...@gl...>]

=3E I wouldn=27t know how to add additional custom editors to beanwrapper=
s
=3E instantiated manually=2E The solution Guillaume is suggesting (with =

=3E Sun=27sPropertyManager) will not work=3B since Spring doesn=27t use i=
t =

=3E (securityrestrictions might give problems there)=2E

That=27s not accurate=2E  What Spring does not use (anymore)=2C is the Pr=
opertyEditorManager to register its own PropertyEditor=2C in case the Sec=
urityManager does not allows it=2E  It=27s why there=27s a need for a def=
aultEditors static Map=2E  The method PropertyEditorManager=2EfindEditor(=
Class requiredType) is used by Spring in the method that does the convers=
ion=2C and that method would look for PropertyEditors in the two way I me=
ntionned earlier=2C and also in the search path that I forgot to mention=2E=


See the Javadoc of BeanWrapperImpl =3A
=3C=3C=3C=3C=3C=3C=3C=3C=3C=3C=3C=3C=3C=3C=3C=3C=3C=3C=3C=3C=3E=3E=3E=3E=3E=
=3E=3E=3E=3E=3E=3E=3E=3E=3E=3E=3E=3E=3E=3E=3E=3E=3E=3E
 * =3Cp=3ENote=3A Regards property editors in org=2Espringframework=2Ebea=
ns=2Epropertyeditors=2E
 * Also explictly register the default ones to care for JREs that do not =
use
 * the thread context class loader for editor search paths=2E
 * Applications can either use a standard PropertyEditorManager to regist=
er a
 * custom editor before using a BeanWrapperImpl instance=2C or call the i=
nstance=27s
 * registerCustomEditor method to register an editor for the particular i=
nstance=2E
=3C=3C=3C=3C=3C=3C=3C=3C=3C=3C=3C=3C=3C=3C=3C=3C=3C=3C=3C=3C=3E=3E=3E=3E=3E=
=3E=3E=3E=3E=3E=3E=3E=3E=3E=3E=3E=3E=3E=3E=3E=3E=3E=3E

The Javadoc is somewhat outdated thought=2C it does not add =22org=2Espri=
ngframework=2Ebeans=2Epropertyeditors=22 to the search path anymore=2C bu=
t add each of the editors in the defaultEditors=2E  Previous version of t=
he BeanWrapperImpl registered the search path=2C and added them to the ma=
p just in case=2C and it was changed since to only use the defaultEditors=
 map for Spring=27s register=2C but that has no effect on Application=27s=
 Custom Editors=2E

Guillaume
---- Messages d=B4origine ----
De=3A Alef Arendsen =3Calef=40jteam=2Enl=3E
Date=3A vendredi=2C mars 5=2C 2004 11=3A19 am
Objet=3A RE=3A =5BSpringframework-developer=5D =22permanantly=22 register=
ing property editor with BeanWrapper=3F

=3E Oops=2C I guess (no I don=27t guess=2C I know for sure =3B-) manually=
 =

=3E instantiatinga BeanWrapperImpl won=27t give you the additional =

=3E PropertyEditors registered
=3E through CustomEditorConfigurer=2C if that=27s what you meant! The =

=3E BeanWrapperdoesn=27t know of anything like an ApplicationContext =

=3E when just instantiating
=3E it=2E
=3E =

=3E I=27m using the BeanWrapperImpl in some rare cases as well (same =

=3E reason=2C it=27s
=3E really convenient)=2E
=3E =

=3E I wouldn=27t know how to add additional custom editors to beanwrapper=
s
=3E instantiated manually=2E The solution Guillaume is suggesting (with =

=3E Sun=27sPropertyManager) will not work=3B since Spring doesn=27t use i=
t =

=3E (securityrestrictions might give problems there)=2E
=3E =

=3E Alef
=3E =

=3E =3E -----Original Message-----
=3E =3E From=3A springframework-developer-admin=40lists=2Esourceforge=2En=
et
=3E =3E =5Bmailto=3Aspringframework-developer-admin=40lists=2Esourceforge=
=2Enet=5D =

=3E On Behalf
=3E =3E Of Chris Winters
=3E =3E Sent=3A Friday=2C March 05=2C 2004 4=3A58 PM
=3E =3E To=3A springframework-developer=40lists=2Esourceforge=2Enet
=3E =3E Subject=3A Re=3A =5BSpringframework-developer=5D =22permanantly=22=
 registering
=3E =3E property editor with BeanWrapper=3F
=3E =3E =

=3E =3E Alef Arendsen wrote=3A
=3E =3E =3E It=27s not possible to do this via a static on the BeanWrappe=
r=2E =

=3E It IS
=3E =3E possible
=3E =3E =3E however=2E=2E=2E
=3E =3E =3E
=3E =3E =3E J=FCrgen added a CustomEditorConfigurer that you can use to d=
o =

=3E this=2E Just
=3E =3E add
=3E =3E =3E it to you app context and you=27re done=2E
=3E =3E =3E
=3E =3E =3E =3C!-- taken from JavaDOC --=3E
=3E =3E =3E =3Cbean id=3D=22customEditorConfigurer=22
=3E =3E  =3E =2E=2E=2E
=3E =3E =

=3E =3E Excellent! That should work just fine=2E
=3E =3E =

=3E =3E =3E If you=27re programmatically using the BeanFactory=2C you can=
 add
=3E =3E =3E propertyeditors using registerCustomEditor from the =

=3E BeanFactory (or use
=3E =3E a
=3E =3E =3E BeanFactoryPostProcessor)=2E
=3E =3E =

=3E =3E This is what I started doing=2C but if I instantiate a
=3E =3E BeanWrapperImpl myself the editors aren=27t available=2E (I=27m j=
ust
=3E =3E using the BeanWrapper as a shortcut to do some property mapping
=3E =3E because it=27s so darned convenient=2E)
=3E =3E =

=3E =3E Plus I=27m not sure how to do this from an ApplicationContext vs=2E=
 a
=3E =3E BeanFactory -- the registerCustomEditor() seems to be implemented=

=3E =3E in AbstractBeanFactory which doesn=27t seem to be a parent of any=

=3E =3E ApplicationContext class=2E (I=27m a little hazy on the relations=
hips
=3E =3E among the objects at this level tho=2E)
=3E =3E =

=3E =3E Thanks!
=3E =3E =

=3E =3E Chris
=3E =3E =

=3E =3E --
=3E =3E Chris Winters (cwinters=40optiron=2Ecom)
=3E =3E Senior Software Architect
=3E =3E =

=3E =3E =

=3E =3E -------------------------------------------------------
=3E =3E This SF=2ENet email is sponsored by=3A IBM Linux Tutorials
=3E =3E Free Linux tutorial presented by Daniel Robbins=2C President and =

=3E CEO of
=3E =3E GenToo technologies=2E Learn everything from fundamentals to syst=
em
=3E =3E administration=2Ehttp=3A//ads=2Eosdn=2Ecom/=3Fad=5Fid=1470=26allo=
c=5Fid638=26op=3Dick
=3E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=

=3E =3E Springframework-developer mailing list
=3E =3E Springframework-developer=40lists=2Esourceforge=2Enet
=3E =3E https=3A//lists=2Esourceforge=2Enet/lists/listinfo/springframewor=
k-
=3E developer
=3E =

=3E =

=3E -------------------------------------------------------
=3E This SF=2ENet email is sponsored by=3A IBM Linux Tutorials
=3E Free Linux tutorial presented by Daniel Robbins=2C President and CEO =
of
=3E GenToo technologies=2E Learn everything from fundamentals to system
=3E administration=2Ehttp=3A//ads=2Eosdn=2Ecom/=3Fad=5Fid=1470=26alloc=5F=
id638=26op=D5ick
=3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
=3E Springframework-developer mailing list
=3E Springframework-developer=40lists=2Esourceforge=2Enet
=3E https=3A//lists=2Esourceforge=2Enet/lists/listinfo/springframework-de=
veloper
=3E 

Re: [Springframework-developer] "permanantly" registering property editor with BeanWrapper?

[Chris W. <cwi...@op...>]

Alef Arendsen wrote:
> Oops, I guess (no I don't guess, I know for sure ;-) manually instantiating
> a BeanWrapperImpl won't give you the additional PropertyEditors registered
> through CustomEditorConfigurer, if that's what you meant! The BeanWrapper
> doesn't know of anything like an ApplicationContext when just instantiating
> it.

Yeah, that's what I meant. I guess the static method (adding the 
editor manually to the BeanWrapperImpl class) would be the way to 
go then since there aren't any dependencies on a 
AppContext/BeanFactory.

Thanks,

Chris

-- 
Chris Winters (cwi...@op...)
Senior Software Architect

RE: [Springframework-developer] "permanantly" registering property editor with BeanWrapper?

[Alef A. <al...@jt...>]

Oops, I guess (no I don't guess, I know for sure ;-) manually =
instantiating
a BeanWrapperImpl won't give you the additional PropertyEditors =
registered
through CustomEditorConfigurer, if that's what you meant! The =
BeanWrapper
doesn't know of anything like an ApplicationContext when just =
instantiating
it.

I'm using the BeanWrapperImpl in some rare cases as well (same reason, =
it's
really convenient).

I wouldn't know how to add additional custom editors to beanwrappers
instantiated manually. The solution Guillaume is suggesting (with Sun's
PropertyManager) will not work; since Spring doesn't use it (security
restrictions might give problems there).

Alef

> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On =
Behalf
> Of Chris Winters
> Sent: Friday, March 05, 2004 4:58 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] "permanantly" registering
> property editor with BeanWrapper?
>=20
> Alef Arendsen wrote:
> > It's not possible to do this via a static on the BeanWrapper. It IS
> possible
> > however...
> >
> > J=FCrgen added a CustomEditorConfigurer that you can use to do this. =
Just
> add
> > it to you app context and you're done.
> >
> > <!-- taken from JavaDOC -->
> > <bean id=3D"customEditorConfigurer"
>  > ...
>=20
> Excellent! That should work just fine.
>=20
> > If you're programmatically using the BeanFactory, you can add
> > propertyeditors using registerCustomEditor from the BeanFactory (or =
use
> a
> > BeanFactoryPostProcessor).
>=20
> This is what I started doing, but if I instantiate a
> BeanWrapperImpl myself the editors aren't available. (I'm just
> using the BeanWrapper as a shortcut to do some property mapping
> because it's so darned convenient.)
>=20
> Plus I'm not sure how to do this from an ApplicationContext vs. a
> BeanFactory -- the registerCustomEditor() seems to be implemented
> in AbstractBeanFactory which doesn't seem to be a parent of any
> ApplicationContext class. (I'm a little hazy on the relationships
> among the objects at this level tho.)
>=20
> Thanks!
>=20
> Chris
>=20
> --
> Chris Winters (cwi...@op...)
> Senior Software Architect
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] "permanantly" registering property editor with BeanWrapper?

[Chris W. <cwi...@op...>]

Guillaume Poirier wrote:
>  ...
> Using java.beans, you can have define a PropertyEditor in two
> ways that I know of.  One is to use
> PropertyEditorManager.registerEditor(Class targetType, Class
> editorClass).  The other way is with class name pattern.  In
> the same way as for BeanInfo, if you have a class named
> com.company.Bean, the PropertyEditorManager will use the
> editor named com.company.BeanEditor if the class exists.

Excellent ideas, thanks!

Chris

-- 
Chris Winters (cwi...@op...)
Senior Software Architect

Re: [Springframework-developer] "permanantly" registering property editor with BeanWrapper?

[Chris W. <cwi...@op...>]

Alef Arendsen wrote:
> It's not possible to do this via a static on the BeanWrapper. It IS pos=
sible
> however...
>=20
> J=FCrgen added a CustomEditorConfigurer that you can use to do this. Ju=
st add
> it to you app context and you're done.
>=20
> <!-- taken from JavaDOC -->
> <bean id=3D"customEditorConfigurer"
 > ...

Excellent! That should work just fine.

> If you're programmatically using the BeanFactory, you can add
> propertyeditors using registerCustomEditor from the BeanFactory (or use=
 a
> BeanFactoryPostProcessor).

This is what I started doing, but if I instantiate a=20
BeanWrapperImpl myself the editors aren't available. (I'm just=20
using the BeanWrapper as a shortcut to do some property mapping=20
because it's so darned convenient.)

Plus I'm not sure how to do this from an ApplicationContext vs. a=20
BeanFactory -- the registerCustomEditor() seems to be implemented=20
in AbstractBeanFactory which doesn't seem to be a parent of any=20
ApplicationContext class. (I'm a little hazy on the relationships=20
among the objects at this level tho.)

Thanks!

Chris

--=20
Chris Winters (cwi...@op...)
Senior Software Architect

Re: RE: [Springframework-developer] "permanantly" registering property editor with BeanWrapper?

[Guillaume P. <gpo...@gl...>]

CustomEditorConfigurer only registers the PropertyEditors for the current=
 factory=2C not the whole JVM=2E

---- Messages d=B4origine ----
De=3A Alef Arendsen =3Calef=40jteam=2Enl=3E
Date=3A vendredi=2C mars 5=2C 2004 10=3A37 am
Objet=3A RE=3A =5BSpringframework-developer=5D =22permanantly=22 register=
ing property editor with BeanWrapper=3F

=3E It=27s not possible to do this via a static on the BeanWrapper=2E It =

=3E IS possible
=3E however=2E=2E=2E
=3E =

=3E J=FCrgen added a CustomEditorConfigurer that you can use to do this=2E=
 =

=3E Just add
=3E it to you app context and you=27re done=2E
=3E =

=3E =3C!-- taken from JavaDOC --=3E
=3E =3Cbean id=3D=22customEditorConfigurer=22
=3E class=3D=22org=2Espringframework=2Ebeans=2Efactory=2Econfig=2ECustomE=
ditorConfigurer=22=3E
=3E  =3Cproperty name=3D=22customEditors=22=3E
=3E    =3Cmap=3E
=3E      =3Centry key=3D=22java=2Eutil=2EDate=22=3E
=3E        =3Cbean class=3D=22mypackage=2EMyCustomDateEditor=22/=3E
=3E      =3C/entry=3E
=3E      =3Centry key=3D=22mypackage=2EMyObject=22=3E
=3E        =3Cbean id=3D=22myEditor=22 class=3D=22mypackage=2EMObjectEdit=
or=22=3E
=3E          =3Cproperty name=3D=22myParam=22=3E=3Cvalue=3EmyValue=3C/val=
ue=3E=3C/property=3E
=3E        =3C/bean=3E
=3E      =3C/entry=3E
=3E    =3C/map=3E
=3E  =3C/property=3E
=3E =3C/bean=3E
=3E =

=3E If you=27re programmatically using the BeanFactory=2C you can add
=3E propertyeditors using registerCustomEditor from the BeanFactory =

=3E (or use a
=3E BeanFactoryPostProcessor)=2E
=3E =

=3E Alef
=3E 	=

=3E =

=3E =3E -----Original Message-----
=3E =3E From=3A springframework-developer-admin=40lists=2Esourceforge=2En=
et
=3E =3E =5Bmailto=3Aspringframework-developer-admin=40lists=2Esourceforge=
=2Enet=5D =

=3E On Behalf
=3E =3E Of Chris Winters
=3E =3E Sent=3A Friday=2C March 05=2C 2004 4=3A17 PM
=3E =3E To=3A Spring-Dev
=3E =3E Subject=3A =5BSpringframework-developer=5D =22permanantly=22 regi=
stering =

=3E property=3E editor with BeanWrapper=3F
=3E =3E =

=3E =3E Is there a way to permanantly (for the life of the current JVM
=3E =3E instance) register a property editor for the BeanWrapper
=3E =3E (BeanWrapperImpl) to use=3F I see it maintains a static map of
=3E =3E =27defaultEditors=27 but it looks like custom editors have to be
=3E =3E registered with each wrapper instance=2E
=3E =3E =

=3E =3E Would it be possible to add a=3A
=3E =3E =

=3E =3E    static void registerCustomerEditor( Class c=2C PropertyEditor =
e )
=3E =3E =

=3E =3E or something similar that adds a custom editor to the default (or=

=3E =3E global) editors=3F
=3E =3E =

=3E =3E Thanks=2C
=3E =3E =

=3E =3E Chris
=3E =3E =

=3E =3E --
=3E =3E Chris Winters (cwinters=40optiron=2Ecom)
=3E =3E Senior Software Architect
=3E =3E =

=3E =3E =

=3E =3E -------------------------------------------------------
=3E =3E This SF=2ENet email is sponsored by=3A IBM Linux Tutorials
=3E =3E Free Linux tutorial presented by Daniel Robbins=2C President and =

=3E CEO of
=3E =3E GenToo technologies=2E Learn everything from fundamentals to syst=
em
=3E =3E =

=3E administration=2Ehttp=3A//ads=2Eosdn=2Ecom/=3Fad=5Fid=3D1470=26alloc=5F=
id=3D3638=26op=3Dclick=3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F
=3E =3E Springframework-developer mailing list
=3E =3E Springframework-developer=40lists=2Esourceforge=2Enet
=3E =3E https=3A//lists=2Esourceforge=2Enet/lists/listinfo/springframewor=
k-
=3E developer
=3E =

=3E =

=3E -------------------------------------------------------
=3E This SF=2ENet email is sponsored by=3A IBM Linux Tutorials
=3E Free Linux tutorial presented by Daniel Robbins=2C President and CEO =
of
=3E GenToo technologies=2E Learn everything from fundamentals to system
=3E administration=2Ehttp=3A//ads=2Eosdn=2Ecom/=3Fad=5Fid=1470=26alloc=5F=
id638=26op=D5ick
=3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
=3E Springframework-developer mailing list
=3E Springframework-developer=40lists=2Esourceforge=2Enet
=3E https=3A//lists=2Esourceforge=2Enet/lists/listinfo/springframework-de=
veloper
=3E 

Re: [Springframework-developer] "permanantly" registering property editor with BeanWrapper?

[Guillaume P. <gpo...@gl...>]

As far as I know=2C there=27s no real way of doing it within Spring=2E  H=
owever=2C java=2Ebeans do offer something that might works for you=2E  Bu=
t the method signature you used as example would not work correctly=2C as=
 PropertyEditors are not tread safe=2C which mean would could only either=
 register the class (if it has a default constructor) or register a facto=
ry=2E

Using java=2Ebeans=2C you can have define a PropertyEditor in two ways th=
at I know of=2E  One is to use PropertyEditorManager=2EregisterEditor(Cla=
ss targetType=2C Class editorClass)=2E  The other way is with class name =
pattern=2E  In the same way as for BeanInfo=2C if you have a class named =
com=2Ecompany=2EBean=2C the PropertyEditorManager will use the editor nam=
ed com=2Ecompany=2EBeanEditor if the class exists=2E

I hope this helps=2C
Guillaume

---- Messages d=B4origine ----
De=3A Chris Winters =3Ccwinters=40optiron=2Ecom=3E
Date=3A vendredi=2C mars 5=2C 2004 10=3A16 am
Objet=3A =5BSpringframework-developer=5D =22permanantly=22 registering pr=
operty editor with BeanWrapper=3F

=3E Is there a way to permanantly (for the life of the current JVM =

=3E instance) register a property editor for the BeanWrapper =

=3E (BeanWrapperImpl) to use=3F I see it maintains a static map of =

=3E =27defaultEditors=27 but it looks like custom editors have to be =

=3E registered with each wrapper instance=2E
=3E =

=3E Would it be possible to add a=3A
=3E =

=3E   static void registerCustomerEditor( Class c=2C PropertyEditor e )
=3E =

=3E or something similar that adds a custom editor to the default (or =

=3E global) editors=3F
=3E =

=3E Thanks=2C
=3E =

=3E Chris
=3E =

=3E -- =

=3E Chris Winters (cwinters=40optiron=2Ecom)
=3E Senior Software Architect
=3E =

=3E =

=3E -------------------------------------------------------
=3E This SF=2ENet email is sponsored by=3A IBM Linux Tutorials
=3E Free Linux tutorial presented by Daniel Robbins=2C President and CEO =
of
=3E GenToo technologies=2E Learn everything from fundamentals to system
=3E administration=2Ehttp=3A//ads=2Eosdn=2Ecom/=3Fad=5Fid=3D1470=26alloc=5F=
id=3D3638=26op=3Dclick
=3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
=3E Springframework-developer mailing list
=3E Springframework-developer=40lists=2Esourceforge=2Enet
=3E https=3A//lists=2Esourceforge=2Enet/lists/listinfo/springframework-de=
veloper
=3E 

RE: [Springframework-developer] "permanantly" registering property editor with BeanWrapper?

[Alef A. <al...@jt...>]

It's not possible to do this via a static on the BeanWrapper. It IS =
possible
however...

J=FCrgen added a CustomEditorConfigurer that you can use to do this. =
Just add
it to you app context and you're done.

<!-- taken from JavaDOC -->
<bean id=3D"customEditorConfigurer"
class=3D"org.springframework.beans.factory.config.CustomEditorConfigurer"=
>
  <property name=3D"customEditors">
    <map>
      <entry key=3D"java.util.Date">
        <bean class=3D"mypackage.MyCustomDateEditor"/>
      </entry>
      <entry key=3D"mypackage.MyObject">
        <bean id=3D"myEditor" class=3D"mypackage.MObjectEditor">
          <property name=3D"myParam"><value>myValue</value></property>
        </bean>
      </entry>
    </map>
  </property>
</bean>

If you're programmatically using the BeanFactory, you can add
propertyeditors using registerCustomEditor from the BeanFactory (or use =
a
BeanFactoryPostProcessor).

Alef
=09

> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On =
Behalf
> Of Chris Winters
> Sent: Friday, March 05, 2004 4:17 PM
> To: Spring-Dev
> Subject: [Springframework-developer] "permanantly" registering =
property
> editor with BeanWrapper?
>=20
> Is there a way to permanantly (for the life of the current JVM
> instance) register a property editor for the BeanWrapper
> (BeanWrapperImpl) to use? I see it maintains a static map of
> 'defaultEditors' but it looks like custom editors have to be
> registered with each wrapper instance.
>=20
> Would it be possible to add a:
>=20
>    static void registerCustomerEditor( Class c, PropertyEditor e )
>=20
> or something similar that adds a custom editor to the default (or
> global) editors?
>=20
> Thanks,
>=20
> Chris
>=20
> --
> Chris Winters (cwi...@op...)
> Senior Software Architect
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> =
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] "permanantly" registering property editor with BeanWrapper?

[Chris W. <cwi...@op...>]

Is there a way to permanantly (for the life of the current JVM 
instance) register a property editor for the BeanWrapper 
(BeanWrapperImpl) to use? I see it maintains a static map of 
'defaultEditors' but it looks like custom editors have to be 
registered with each wrapper instance.

Would it be possible to add a:

   static void registerCustomerEditor( Class c, PropertyEditor e )

or something similar that adds a custom editor to the default (or 
global) editors?

Thanks,

Chris

-- 
Chris Winters (cwi...@op...)
Senior Software Architect

Re: [Springframework-developer] Commons-Validator for Spring

[Keith D. <kd...@cs...>]

Daniel,

One other thing: I agree Seth's idea and patch for using
MessageSourceResolvable's as arguments of other MessageResourceResolvables
for recursively resolving arguments using a message source is a slick idea
and we need it.  I will be working on getting that integrated.

Keith

----- Original Message ----- 
From: "Keith Donald" <kd...@cs...>
To: <spr...@li...>
Sent: Friday, March 05, 2004 8:33 AM
Subject: Re: [Springframework-developer] Commons-Validator for Spring


> Daniel,
>
> I can take a look at it.  I'm curious if it is feasible to use the same
> declarative validator design we're developing and apply another mechanism
> (adapter) for configuration from commons-validator's format.  That'd be
> nice, because we could use the same framework for all sources of
> configuration.  I know I am already doing this in my implementation on my
> system as I use Spring IoC for configuration, while Seth uses attributes.
> But that might prove to be too much work, and that your way is better
> overall.  I really can't say yet.
>
> commons-validator handles javascript validation client-side, too, right?
> Your adapter enables that? I know that's one area we have not addressed.
> Keith
>
> ----- Original Message ----- 
> From: "Daniel Miller" <mi...@pa...>
> To: <spr...@li...>
> Sent: Friday, March 05, 2004 12:10 AM
> Subject: RE: [Springframework-developer] Commons-Validator for Spring
>
>
> > Seth and Keith,
> >
> > Did you get a chance to look at my commons-validator adaptor? I was
> > wondering if you had any feedback? Feel free to tell me that it sucks,
or
> > that it was so elementary that you didn't want to waste any more time
> > talking to me about it :)
> >
> > I don't know much about commons-attributes, but from what I've been
> picking
> > up between the lines on your recent validator-related posts it's quite
> > different from the commons-validator approach. The main difference seems
> to
> > be that validation meta-data is expressed directly in the source of the
> bean
> > to be validated, while the commons-validator approach uses the
> > validation.xml file to hold all of that meta-data.
> >
> > Your attributes validator sounds a bit more powerful than the commons
> > validator, but many of the objects that I want to validate are generated
> (by
> > Middlegen) and I have no way of adding meta-data to the objects without
> > modifying the generated code. Of course, I could just write a wrapper
for
> > each object that I want to validate, but I might as well just write a
> > validator class for each object. That being said, I think there is room
> for
> > both an attributes validator and a commons validator in the Spring
> > framework.
> >
> > The main thing I am interested in knowing is the patch that you (Seth)
> > posted to allow message resources to be nested (as arguments) in another
> > message resource. Do you have any idea how soon this will make its way
> into
> > a Spring release or should I just get the source and build it in for my
> own
> > use?
> >
> > Thanks,
> > Daniel
> >
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...]On Behalf
> > Of Daniel Miller
> > Sent: Tuesday, March 02, 2004 12:19 AM
> > To: spr...@li...
> > Subject: RE: [Springframework-developer] Commons-Validator for Spring
> >
> >
> > Seth,
> >
> > That looks great. This would make my validation support super easy to
> > implement. You can grab my current source here:
> >
> >
>
http://www.paonline.com/millerd/Spring-commons-validator_no-dependencies.zip
> >
> > I have not had time to write up a good example, tests, or complete the
> > documentation. Hopefully I will be able to do this soon.
> >
> > Thanks,
> > Daniel
> >
> >
> > Original Message: -----------------------------------------------------
> >
> > | (2) Improve the handling of Errors objects to allow message resources
> > to be
> > | specified as arguments that would not be resolved to their
corresponding
> > | messages until reaching the view. I really like this solution, but I
> have
> > | not thought it through completely. One more note: since the errorArgs
> > | parameter is an array of Objects (not an array of Strings), maybe
there
> > | would be a way to use a "Message" object that would be resolved at a
> later
> > | time, while preserving the current functionality of Strings that are
> used
> > | directly as arguments. For all I know, there is already a way to do
> > this (it
> > | seems logical enough), and I just don't know about it. This J2EE stuff
> > is so
> > | hard to keep up with...
> >
> > Daniel,
> >
> > I just posted a simple patch w/ unit test for the functionality we've
> > discussed.  Please review and see if it meets your needs.
> >
> >
>
http://opensource.atlassian.com/projects/spring/secure/ViewIssue.jspa?key=SP
> > R-56
> >
> >
> > Seth
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> > Build and deploy apps & Web services for Linux with
> > a free DVD software kit from IBM. Click Now!
> > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO of
> > GenToo technologies. Learn everything from fundamentals to system
> > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] Commons-Validator for Spring

[Keith D. <kd...@cs...>]

Daniel,

I can take a look at it.  I'm curious if it is feasible to use the same
declarative validator design we're developing and apply another mechanism
(adapter) for configuration from commons-validator's format.  That'd be
nice, because we could use the same framework for all sources of
configuration.  I know I am already doing this in my implementation on my
system as I use Spring IoC for configuration, while Seth uses attributes.
But that might prove to be too much work, and that your way is better
overall.  I really can't say yet.

commons-validator handles javascript validation client-side, too, right?
Your adapter enables that? I know that's one area we have not addressed.
Keith

----- Original Message ----- 
From: "Daniel Miller" <mi...@pa...>
To: <spr...@li...>
Sent: Friday, March 05, 2004 12:10 AM
Subject: RE: [Springframework-developer] Commons-Validator for Spring


> Seth and Keith,
>
> Did you get a chance to look at my commons-validator adaptor? I was
> wondering if you had any feedback? Feel free to tell me that it sucks, or
> that it was so elementary that you didn't want to waste any more time
> talking to me about it :)
>
> I don't know much about commons-attributes, but from what I've been
picking
> up between the lines on your recent validator-related posts it's quite
> different from the commons-validator approach. The main difference seems
to
> be that validation meta-data is expressed directly in the source of the
bean
> to be validated, while the commons-validator approach uses the
> validation.xml file to hold all of that meta-data.
>
> Your attributes validator sounds a bit more powerful than the commons
> validator, but many of the objects that I want to validate are generated
(by
> Middlegen) and I have no way of adding meta-data to the objects without
> modifying the generated code. Of course, I could just write a wrapper for
> each object that I want to validate, but I might as well just write a
> validator class for each object. That being said, I think there is room
for
> both an attributes validator and a commons validator in the Spring
> framework.
>
> The main thing I am interested in knowing is the patch that you (Seth)
> posted to allow message resources to be nested (as arguments) in another
> message resource. Do you have any idea how soon this will make its way
into
> a Spring release or should I just get the source and build it in for my
own
> use?
>
> Thanks,
> Daniel
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Daniel Miller
> Sent: Tuesday, March 02, 2004 12:19 AM
> To: spr...@li...
> Subject: RE: [Springframework-developer] Commons-Validator for Spring
>
>
> Seth,
>
> That looks great. This would make my validation support super easy to
> implement. You can grab my current source here:
>
>
http://www.paonline.com/millerd/Spring-commons-validator_no-dependencies.zip
>
> I have not had time to write up a good example, tests, or complete the
> documentation. Hopefully I will be able to do this soon.
>
> Thanks,
> Daniel
>
>
> Original Message: -----------------------------------------------------
>
> | (2) Improve the handling of Errors objects to allow message resources
> to be
> | specified as arguments that would not be resolved to their corresponding
> | messages until reaching the view. I really like this solution, but I
have
> | not thought it through completely. One more note: since the errorArgs
> | parameter is an array of Objects (not an array of Strings), maybe there
> | would be a way to use a "Message" object that would be resolved at a
later
> | time, while preserving the current functionality of Strings that are
used
> | directly as arguments. For all I know, there is already a way to do
> this (it
> | seems logical enough), and I just don't know about it. This J2EE stuff
> is so
> | hard to keep up with...
>
> Daniel,
>
> I just posted a simple patch w/ unit test for the functionality we've
> discussed.  Please review and see if it meets your needs.
>
>
http://opensource.atlassian.com/projects/spring/secure/ViewIssue.jspa?key=SP
> R-56
>
>
> Seth
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Commons-Validator for Spring

[Daniel M. <mi...@pa...>]

Seth and Keith,

Did you get a chance to look at my commons-validator adaptor? I was
wondering if you had any feedback? Feel free to tell me that it sucks, or
that it was so elementary that you didn't want to waste any more time
talking to me about it :)

I don't know much about commons-attributes, but from what I've been picking
up between the lines on your recent validator-related posts it's quite
different from the commons-validator approach. The main difference seems to
be that validation meta-data is expressed directly in the source of the bean
to be validated, while the commons-validator approach uses the
validation.xml file to hold all of that meta-data.

Your attributes validator sounds a bit more powerful than the commons
validator, but many of the objects that I want to validate are generated (by
Middlegen) and I have no way of adding meta-data to the objects without
modifying the generated code. Of course, I could just write a wrapper for
each object that I want to validate, but I might as well just write a
validator class for each object. That being said, I think there is room for
both an attributes validator and a commons validator in the Spring
framework.

The main thing I am interested in knowing is the patch that you (Seth)
posted to allow message resources to be nested (as arguments) in another
message resource. Do you have any idea how soon this will make its way into
a Spring release or should I just get the source and build it in for my own
use?

Thanks,
Daniel

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Daniel Miller
Sent: Tuesday, March 02, 2004 12:19 AM
To: spr...@li...
Subject: RE: [Springframework-developer] Commons-Validator for Spring


Seth,

That looks great. This would make my validation support super easy to
implement. You can grab my current source here:

http://www.paonline.com/millerd/Spring-commons-validator_no-dependencies.zip

I have not had time to write up a good example, tests, or complete the
documentation. Hopefully I will be able to do this soon.

Thanks,
Daniel


Original Message: -----------------------------------------------------

| (2) Improve the handling of Errors objects to allow message resources
to be
| specified as arguments that would not be resolved to their corresponding
| messages until reaching the view. I really like this solution, but I have
| not thought it through completely. One more note: since the errorArgs
| parameter is an array of Objects (not an array of Strings), maybe there
| would be a way to use a "Message" object that would be resolved at a later
| time, while preserving the current functionality of Strings that are used
| directly as arguments. For all I know, there is already a way to do
this (it
| seems logical enough), and I just don't know about it. This J2EE stuff
is so
| hard to keep up with...

Daniel,

I just posted a simple patch w/ unit test for the functionality we've
discussed.  Please review and see if it meets your needs.

http://opensource.atlassian.com/projects/spring/secure/ViewIssue.jspa?key=SP
R-56


Seth



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Release policy

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

1.0.x sure does mainly imply a bugfix release: I just intend to allow =
*minor* (really minor) features to slip into such point releases if =
they're ready. I'd like to release early here, instead of waiting for =
the next 1.x release. For examples, take Hibernate 2.0.3 (which =
introduced "all-delete-orphans") or Tomcat 4.0.4 (which introduced the =
Coyote HTTP connector).
=20
My main argument is about the 1.x releases though. I'd like to have a =
quick 1.1, possibly with JMX support and JMS support; then a 1.2 with =
whatever gets ready next - instead of waiting for all those major new =
features to be ready for a single combined release. I simply feel there =
are too many major features planned when I look at our JIRA roadmap for =
1.1.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Mike Cannon-Brookes
Gesendet: Do 04.03.2004 14:57
An: Spring
Betreff: Re: [Springframework-developer] Release policy



Love it - great ideas.

I don't really think the versioning number matters really, although =
1.0.1
sounds more like a bugfix release to me than new features?

Cheers,
Mike

On 4/3/04 8:13 PM, "j=FCrgen h=F6ller [werk3AT]" =
(jue...@we...)
penned the words:

> Everybody,
>
> I'd like to propose a somewhat different release policy for post-1.0.
> Currently, we're targetting a major 1.1 release, with a M1 milestone =
as first
> goal. This doesn't seem very appropriate for getting features and =
add-ons out
> early.
>
> When I look at the 1.1 roadmap in JIRA, almost all suggested features =
are
> add-ons that do not affect the Spring core. They could easily be added
> one-by-one as soon as they're stable. 1.0 users could still easily =
upgrade
> without worrying: Such 1.x releases would be fully compatible, mainly =
adding
> additional classes.
>
> OGNL support probably requires special consideration: However, if we =
added it
> via a FactoryBean implementation analogous to =
MethodInvokingFactoryBean, it
> would be a simple add-on too.
>
> So what I'd like to propose concretely is:
> - quick 1.x releases, getting out smaller sets of new features and =
add-ons
> early
> - no milestones for 1.x releases, just release candidates
> - CVS HEAD always contains the current 1.x codebase
> - bugfix releases like 1.0.x only when there's no compatible next =
release like
> 1.1 available
> - 1.0.x/1.1.x/etc releases can also introduce minor new features if
> appropriate
> - major new features or add-ons force a jump to the next 1.x release =
number
> (1.0 -> 1.1)
>
> This essentially means that we do not stick to a release plan that's =
cast in
> stone. Assuming that 1.0 final will be out in mid March, we'll simply =
work on
> some planned features: in the sandbox while not fully baked, moving to =
the
> main source tree when something approaches release candidate status. =
Once a
> noteworthy number of new features is there, we'll do a follow-up =
release: in
> case of bugfixes and minor features, 1.0.1/1.0.2/etc; in case of one =
or more
> major features, 1.1/1.2/etc.
>
> My main intent is to get new features - that are ready and do not =
require
> signficant modifications to the Spring core - out promptly: When we =
finish
> FreemarkerView, let's do 1.0.1; when we finish JMS support or any such =
major
> feature (one or more), let's do 1.1. When e.g. JMX support gets done, =
we'll do
> a follow-up 1.2; or the other way round, if JMX support gets ready =
first. If
> there's pressure for a bugfix release, let's fit that in; it might =
also
> contain minor new features that are ready.
>
> If we decide to break compatibility (beyond trivial things in rather =
obscure
> places) at some time, we need to jump to the next major version, doing =
further
> bugfixing for 1.x and such new development on a 2.0 branch in parallel =
- then
> and only then. I see no need to impose such burdens for add-on =
features in 1.x
> releases, particularly when raising them in the sandbox before they =
join the
> mainstream.
>
> All things considered, the release policy that I propose is much more =
agile
> than a fixed set of 1.1 features that will just make it into a final =
release
> when all of them are ready. A large number of such fixed features =
could delay
> a release for a long time. Note that significant changes to the Spring =
core
> are a different matter; features that depend on such require special
> consideration. But for rather straightforward add-ons, we don't need =
to tie
> ourselves to a strict release plan, IMO.
>
> In other words, let's adopt a Hibernate-style release policy, not a
> Jakarta-style one ;-) Eagerly awaiting your feedback!
>
> Regards,
> Juergen
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=CCk
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Reversed dependencies

[Hagen O. <hag...@hp...>]

Hi all,


after looking at pico and hivemind, I finally took the time to dive in 
to spring. I got scared of at first, because I just wanted a container 
and there is soooo much else in the framework... but after finding 
spring-core.jar I got up to speed.

Anyway this it what I want to do:

large pool of containers
	| 1
	| *
specific pool, that has a component the the parent components depend on.


I am evaluating this design, because I don't want to replicate the 
parent pool each time, but its components are dependent on a use case 
specific component.

This is what I came up with:

package testing;

import java.util.HashMap;
import java.util.HashSet;
import java.util.Iterator;
import java.util.Map;
import java.util.Set;

import org.springframework.beans.BeansException;
import org.springframework.beans.factory.BeanFactory;
import 
org.springframework.beans.factory.support.DefaultListableBeanFactory;
import org.springframework.beans.factory.support.RootBeanDefinition;
import org.springframework.beans.factory.xml.XmlBeanDefinitionReader;
import org.springframework.core.io.Resource;


public class ReversedDependencyBeanFactory extends 
DefaultListableBeanFactory {
     private Map dependentSingeltonCache = new HashMap();

     public ReversedDependencyBeanFactory(BeanFactory aParent) {
         super(aParent);
     }

	public ReversedDependencyBeanFactory(Resource aResource, BeanFactory 
aParent) throws BeansException {
	    this(aParent);
	    (new XmlBeanDefinitionReader(this)).loadBeanDefinitions(aResource);
     }

	public ReversedDependencyBeanFactory(Resource aResource) throws 
BeansException {
	    this(aResource, null);
     }

     public Object getBean(String aName) throws BeansException {
         String theBeanName = transformedBeanName(aName);

         if (dependentSingeltonCache.containsKey(theBeanName)) {
             return dependentSingeltonCache.get(theBeanName);
         }
         try {
            return super.getBean(aName);
         } catch (BeansException ex) {
			RootBeanDefinition theDefinition = 
getMergedBeanDefinition(theBeanName, true);
			Object theBean = createBean(theBeanName, theDefinition);
			if (theDefinition.isSingleton()) {
			    dependentSingeltonCache.put(theBeanName, theBean);
			}
			return theBean;
         }
	}

     public void destroySingletons() {
		Set singletonCacheKeys = new 
HashSet(dependentSingeltonCache.keySet());
		for (Iterator theIterator = singletonCacheKeys.iterator(); 
theIterator.hasNext();) {
		    String theBeanName = (String) theIterator.next();
			Object theInstance = dependentSingeltonCache.remove(theBeanName);
			if (theInstance != null) {
				destroyBean(theBeanName, theInstance);
			}
		}
         super.destroySingletons();
     }
}

I also looked at a BeanFactoryAware FactoryBean, but it get's passed in 
the parent container only...

Anyway, this does pass my test cases (create a parent container, that 
has a dependency in the child and play around with it). Since I am very 
new to spring (2h in the source), I'd like feedback from the group.

Also, I am looking for a way to ask the child, which components of the 
parent (with a certain interface) it can instanciate (because it 
satifies its dependencies). I get a little confused about the 
Root/ChildBeanDefinition... and this has to perform also ;-)

Any suggestions greatly appreciated

Cheers
	)-(agen

Re: [Springframework-developer] RE: validation stuff

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

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


| I agree completely we should use Errors.  What I would like to do is take
| the best parts of your design and take the parts of mine I feel are strong
| and merge the two in the sandbox for review.  Nothings going to be
| complicated, hopefully simplified.  If something doesn't meet your
| requirements, let me know immediately!  I'll work with you to get our
stuff
| committed ASAP.

I agree, let's get something into sandbox soon.

Here are some requirements:

- - Be allowed to put MessageSourceResolvable into message args of
messages (patch in JIRA to do this)
- - attach validation rules to getters of objects
- - use a singleton validator (of type AttributeValidator, or whatever) to
validate all Command objects.  In other words, remove requirement to
write a Validator for each Command Object.
- - Minimize any configurations.  Since it deals w/ attributes, shouldn't
be an issue.
- - Validate object graphs (recurse through command object)
- - Make it easy to add new rules
- - Javascript generation from rules (we'll worry about that later :)
- - Impact on Spring should be minimal

Hope that helps.  Looking forward to helping!
Seth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAR4bk5EIB1scRes8RAkhjAKCSZZ/VTks2fgQ6uESOmSwMmvdX5QCeOGVb
H0SyYuiT1LBpEFodafGfPjE=
=1r71
-----END PGP SIGNATURE-----

RE: [Springframework-developer] declarative validation rules inte rfaces

[<sam...@ma...>]

Confluence looks very good - I look forward to it! I know the Pico guys are in
the process of using it to host both their Wiki and website. I especially like
the fact that you can display code directly from CVS in your pages using
Confluence macros...

Quoting "Kopylenko, Dmitry" <dko...@ac...>:

> Yes, we could wait for Confluence (coming soon...) and collaborate there !
> 
> -----Original Message-----
> From: sam...@ma... [mailto:sam...@ma...] 
> Sent: Thursday, March 04, 2004 10:32 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] declarative validation rules
> interfaces
> 
> 
> Looks fantastic Keith. I guess I just have to write a simple
> ValidationInterceptor to call the ValidationSource....with that in mind I've
> posted a simple overview diagram showing how my commands get executed and
> invoked at my blog here: http://www.magpiebrain.com/archives/000189.html. We
> could do with a Wiki or website for this stuff perhaps - would make
> documenting spring-rcp a little easier...
> 
> sam
> 
> Quoting Keith Donald <kd...@cs...>:
> 
> > How does this look -  I propose one interface you have to deal with to 
> > the entire declarative validation subsystem.  Let me know what you 
> > think:

<snip>

sam
http://www.magpiebrain.com/