springframework-developer — Spring Framework developers list

[Springframework-developer] Building webflow under spring-projects

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

Keith/Erwin,

I moved (copied really) all common-build, spring-binding, and 
spring-webflow sources to live under a new spring-projects module in CVS.

Note that the build relies on the use of a nightly snapshot of ivy
   ivy-20050616204129.jar
which may be found in
   spring-projects\repository\jayasoft\ivy\jars
This should be dropped into your ant lib dir to replace the older ivy 
1.1. This If you try to use ivy 1.1 you'll get a failure when trying to 
do a publish of the generated artifact.

-- 
Colin Sampaleanu
Interface21 Principal Consultant
Spring Training, Consulting and Support - "From the Source"
http://www.springframework.com

Re: [Springframework-developer] Annotation to validate required bean attributes

[Seth L. <set...@gm...>]

On 6/16/05, Oliver Hutchison <Ol...@ou...> wrote:
> Are you really saving that much using annotations to validate required
> bean attributes? Since the introduction of the Assert class coding these
> afterPropertiesSet constraint checks has been made really simple. What's
> the difference between typing
>=20
>         @@RequiredDependency()
> And
>         Assert.notNull(property);
> ?
>=20
> Not much. Slightly less typing is required, but by using the annotations
> you introduce a set of dependencies that your POJO would never have had
> before. If you're only going to be creating the object using a bean
> factory this is acceptable, however if you want instantiate these
> annotated objects outside of a bean factory (say in a test) your also
> going to have to create all infrastructure needed to do the required
> validation.

Well, that's just the issue, right?  I'm not overly concerned if my
bean is created outside of the bean factory.  If so, I still have to
call afterPropertiesSet() for verification.

It's not so much an issue of saving typing, it's an issue of
minimizing the need to implement container specific interfaces.  For
me, I think it's less intrusive to add a few annotations for this use
case.  But that's certainly a subjective opinion.

I like the ideas of attributes to help the container perform some of
my work for me.  That is, I'm already asking the container to inject
my dependencies.  It's logical (to me) to also ask the container to
let me know if I've misconfigured the dependencies somehow.

And of course, you can always implement afterPropertiesSet() if you
don't like the dependencies.

You bring up good points.  I don't think the annotations method is
perfect for all cases, but I do think it handles much of what
afterPropertiesSet() is used for in a simple way.

Seth

[Springframework-developer] Retrying transactions with OpenSessionInViewFilter

[Chris R. <chr...@gm...>]

Did anyone have any comments the issue I raised in this post:
http://forum.springframework.org/viewtopic.php?t=3D6311&highlight=3D

The Hibernate documentation recommends closing the Session after a
HibernateException is thrown. That was also the recommendation of
someone on the Hibernate team:
http://forum.hibernate.org/viewtopic.php?p=3D2246627#2246627

However, I noticed that HibernateTransactionManager calls
Session.clear() with the intent to reset the Session to a known state
so that it can be reused by another transaction. This seems to be at
odds with the Hibernate documentation unless the goal was to only
reuse a Session when a non-HibernateException was thrown.

Does anyone have any comments on how to retry transactions when using
OpenSessionInViewFilter?

RE: [Springframework-developer] Annotation to validate required bean attributes

[Oliver H. <Ol...@ou...>]

What are the constraints you're interested in and what are you doing
with them?

Ollie

PS.  I assume you've looked at using Keith's Rules package. I have an
implementation of Rules driven using annotation in the Spring Rich
sandbox (AttributesRulesSource) (given my previous post this might
surprise you :-).=20
=20

> -----Original Message-----
> From: spr...@li...=20
> [mailto:spr...@li...]
>  On Behalf Of Andy Depue
> Sent: Friday, 17 June 2005 9:05 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Annotation to=20
> validate required bean attributes
>=20
> OK, so I've had a hidden agenda all along. :)  My main reason=20
> for wanting to annotate properties with their constraints is=20
> to provide "smart" handling of these in other areas of the=20
> application.  There are various places in my application=20
> where having knowledge of the constraints on a property can=20
> come in handy.  As it is now, this knowledge is typically=20
> coded in one lump in one method, with no way to "introspect"=20
> those constraints on a per-property basis.
>=20
>    - Andy
>=20
> On Thursday 16 June 2005 03:54 pm, Oliver Hutchison wrote:
> > Are you really saving that much using annotations to=20
> validate required=20
> > bean attributes? Since the introduction of the Assert class coding=20
> > these afterPropertiesSet constraint checks has been made really=20
> > simple. What's the difference between typing
> >
> > 	@@RequiredDependency()
> > And
> > 	Assert.notNull(property);
> > ?
> >
> > Not much. Slightly less typing is required, but by using the=20
> > annotations you introduce a set of dependencies that your=20
> POJO would=20
> > never have had before. If you're only going to be creating=20
> the object=20
> > using a bean factory this is acceptable, however if you want=20
> > instantiate these annotated objects outside of a bean=20
> factory (say in=20
> > a test) your also going to have to create all=20
> infrastructure needed to=20
> > do the required validation.
> >
> > There's also the issue of how you express more complex constraints=20
> > using annotations. From Andy's example there's this=20
> (rewritten to use Assert):
> >
> >
> >=20
> Assert.true(!getBeanFactory().containsBean(getViewPrototypeBeanName())
> > , "View bean '" + getViewPrototypeBeanName() + "' must be a=20
> prototype=20
> > (singleton=3D\"false\").");
> >
> > To express this in an annotation you'd probably have to=20
> introduce some=20
> > kind of expression language (Groovy, OGNL?) for the constraint=20
> > checking and some kind of template processor for the=20
> exception message=20
> > generation
> > - suddenly something that was reasonably simple to do in Plain Old=20
> > Java is requiring a considerable amount of support code.=20
> I'd imagine=20
> > your annotation would look something like this:
> >
> > 	@@RequiredDependency("!
> > beanFactory.containsBean(viewPrototypeBeanName)", "View bean=20
> > '${viewPrototypeBeanName}' must be a prototype=20
> > (singleton=3D\"false\").")
> >
> > I hope I'm not giving you ideas here ;-)
> >
> > Just my 2c.
> >
> > Ollie
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration=20
> Strategies from IBM. Find simple to follow Roadmaps,=20
> straightforward articles, informative Webcasts and more! Get=20
> everything you need to get up to speed, fast.=20
> http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20

Re: [Springframework-developer] Annotation to validate required bean attributes

[Andy D. <an...@ma...>]

OK, so I've had a hidden agenda all along. :)  My main reason for wanting to 
annotate properties with their constraints is to provide "smart" handling of 
these in other areas of the application.  There are various places in my 
application where having knowledge of the constraints on a property can come 
in handy.  As it is now, this knowledge is typically coded in one lump in one 
method, with no way to "introspect" those constraints on a per-property 
basis.

   - Andy

On Thursday 16 June 2005 03:54 pm, Oliver Hutchison wrote:
> Are you really saving that much using annotations to validate required
> bean attributes? Since the introduction of the Assert class coding these
> afterPropertiesSet constraint checks has been made really simple. What's
> the difference between typing
>
> 	@@RequiredDependency()
> And
> 	Assert.notNull(property);
> ?
>
> Not much. Slightly less typing is required, but by using the annotations
> you introduce a set of dependencies that your POJO would never have had
> before. If you're only going to be creating the object using a bean
> factory this is acceptable, however if you want instantiate these
> annotated objects outside of a bean factory (say in a test) your also
> going to have to create all infrastructure needed to do the required
> validation.
>
> There's also the issue of how you express more complex constraints using
> annotations. From Andy's example there's this (rewritten to use Assert):
>
>
> Assert.true(!getBeanFactory().containsBean(getViewPrototypeBeanName()),
> "View bean '" + getViewPrototypeBeanName() + "' must be a prototype
> (singleton=\"false\").");
>
> To express this in an annotation you'd probably have to introduce some
> kind of expression language (Groovy, OGNL?) for the constraint checking
> and some kind of template processor for the exception message generation
> - suddenly something that was reasonably simple to do in Plain Old Java
> is requiring a considerable amount of support code. I'd imagine your
> annotation would look something like this:
>
> 	@@RequiredDependency("!
> beanFactory.containsBean(viewPrototypeBeanName)", "View bean
> '${viewPrototypeBeanName}' must be a prototype (singleton=\"false\").")
>
> I hope I'm not giving you ideas here ;-)
>
> Just my 2c.
>
> Ollie

RE: [Springframework-developer] Annotation to validate required bean attributes

[Oliver H. <Ol...@ou...>]

Are you really saving that much using annotations to validate required
bean attributes? Since the introduction of the Assert class coding these
afterPropertiesSet constraint checks has been made really simple. What's
the difference between typing

	@@RequiredDependency()
And
	Assert.notNull(property);
?=20

Not much. Slightly less typing is required, but by using the annotations
you introduce a set of dependencies that your POJO would never have had
before. If you're only going to be creating the object using a bean
factory this is acceptable, however if you want instantiate these
annotated objects outside of a bean factory (say in a test) your also
going to have to create all infrastructure needed to do the required
validation.

There's also the issue of how you express more complex constraints using
annotations. From Andy's example there's this (rewritten to use Assert):

=09
Assert.true(!getBeanFactory().containsBean(getViewPrototypeBeanName()),
"View bean '" + getViewPrototypeBeanName() + "' must be a prototype
(singleton=3D\"false\").");

To express this in an annotation you'd probably have to introduce some
kind of expression language (Groovy, OGNL?) for the constraint checking
and some kind of template processor for the exception message generation
- suddenly something that was reasonably simple to do in Plain Old Java
is requiring a considerable amount of support code. I'd imagine your
annotation would look something like this:

	@@RequiredDependency("!
beanFactory.containsBean(viewPrototypeBeanName)", "View bean
'${viewPrototypeBeanName}' must be a prototype =
(singleton=3D\"false\").")

I hope I'm not giving you ideas here ;-)

Just my 2c.

Ollie

RE: [Springframework-developer] enums, styler, comparator

[Keith D. <ke...@in...>]

Not to harp on this, but...

Creating objects with new is arguably a bad idea here, as now I've got that
new operator spread around everywhere with no capability to plug in custom
value styling strategies for my own types of objects, for example.

On the other hand, with a loader to easily plug-in a custom global
implementation, users can easily switch on custom string styling algorithms
for types they use but don't have control over without any hassle.  They
simply switch it in at runtime when their application is bootstrapped.

In any case, what's most appropriate to customize here is the ValueStyler
strategy, not the ToStringCreator strategy.  It's where the magic for pretty
printing objects of different types happen... 

Keith

-----Original Message-----
From: Keith Donald [mailto:ke...@in...] 
Sent: Thursday, June 16, 2005 6:23 PM
To: 'spr...@li...'
Subject: RE: [Springframework-developer] enums, styler, comparator

Yeah, but injection there is not at al practical.  Singleton usage for this
kind of usage is acceptable IMO.  The singleton has a default that is not
expensive to initialize (its just a POJO with no other dependencies).
Furthermore, that default is still configurable through a static load
method.  I don't see the problem there.

Now, I am up for just changing the exception messages in webflow to rely on
the standard collections toString implementations.  However I admit that
would be a bit of a step back, especially after someone just remarked in a
training how descriptive and "great looking" that one exception message was
;-)

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Juergen Hoeller
Sent: Thursday, June 16, 2005 2:07 PM
To: spr...@li...
Subject: Re: [Springframework-developer] enums, styler, comparator

It's been replaced by the ValueStyler interface and DefaultValueStyler
implementation, in the "core.style" package.

I'm currently discussing with Keith whether a ValueStyler singleton should
be re-introduced. Currently, the only singleton held is ToStringCreator's
DefaultToStringStyler, which in turn holds a DefaultValueStyler instance.

I'd like to keep singletons as minimal as possible. There's always the
option to use "new DefaultValueStyler()" / "new DefaultToStringStyler()" or
even receive a ValueStyler / ToStringStyler through dependency injection.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Thursday, June 16, 2005 6:02 PM
To: spr...@li...
Subject: Re: [Springframework-developer] enums, styler, comparator


Juergen Hoeller wrote:

>Everybody,
>
>Keith's LabeledEnum and ToStringCreator stuff has been moved over from the
>sandbox, to be shipped with Spring 1.2.2 (and to be used by Web Flow PR4).
>
>I've rearranged the structure and also reworked the implementations /
>interfaces quite a bit. ToStringCreator and its helpers reside in the
>"core.style" package now; LabeledEnum and LabeledEnumResolver in
>"core.enums" (without separate support subpackage; it's all in one package
>name).
>
>I've also reworked the generic comparators: they reside in
"util.comparator"
>now. The biggest change there is that there is no SortDefinition class
>anymore. Instead, an InvertibleComparator decorator takes over the same
>role. SortDefinition already was a Comparator decorator before, so was
>arguably misnamed.
>
>Keith / Erwin, could you please make sure that everything's compiling again
>on the Web Flow side of things. Once the Web Flow module has found its
final
>home in the CVS structure, that is ;-)
>
>

What happened to the 'Styler' class?

http://cvs.sourceforge.net/viewcvs.py/springframework/spring/src/org/springf
ramework/core/Attic/Styler.java?view=markup
I tried to make the SWF code compile against current Spring CVS while on
a plane ride back to Toronto yesterday, but Styler seems to be gone. So
right now the SWF code is still building against a snapshot from June 13th.

Colin






-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] spring build.284 Build Successful

[<al...@in...>]

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050617001708Lbuild.284

RE: [Springframework-developer] enums, styler, comparator

[Keith D. <ke...@in...>]

Yeah, but injection there is not at al practical.  Singleton usage for this
kind of usage is acceptable IMO.  The singleton has a default that is not
expensive to initialize (its just a POJO with no other dependencies).
Furthermore, that default is still configurable through a static load
method.  I don't see the problem there.

Now, I am up for just changing the exception messages in webflow to rely on
the standard collections toString implementations.  However I admit that
would be a bit of a step back, especially after someone just remarked in a
training how descriptive and "great looking" that one exception message was
;-)

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Juergen Hoeller
Sent: Thursday, June 16, 2005 2:07 PM
To: spr...@li...
Subject: Re: [Springframework-developer] enums, styler, comparator

It's been replaced by the ValueStyler interface and DefaultValueStyler
implementation, in the "core.style" package.

I'm currently discussing with Keith whether a ValueStyler singleton should
be re-introduced. Currently, the only singleton held is ToStringCreator's
DefaultToStringStyler, which in turn holds a DefaultValueStyler instance.

I'd like to keep singletons as minimal as possible. There's always the
option to use "new DefaultValueStyler()" / "new DefaultToStringStyler()" or
even receive a ValueStyler / ToStringStyler through dependency injection.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Thursday, June 16, 2005 6:02 PM
To: spr...@li...
Subject: Re: [Springframework-developer] enums, styler, comparator


Juergen Hoeller wrote:

>Everybody,
>
>Keith's LabeledEnum and ToStringCreator stuff has been moved over from the
>sandbox, to be shipped with Spring 1.2.2 (and to be used by Web Flow PR4).
>
>I've rearranged the structure and also reworked the implementations /
>interfaces quite a bit. ToStringCreator and its helpers reside in the
>"core.style" package now; LabeledEnum and LabeledEnumResolver in
>"core.enums" (without separate support subpackage; it's all in one package
>name).
>
>I've also reworked the generic comparators: they reside in
"util.comparator"
>now. The biggest change there is that there is no SortDefinition class
>anymore. Instead, an InvertibleComparator decorator takes over the same
>role. SortDefinition already was a Comparator decorator before, so was
>arguably misnamed.
>
>Keith / Erwin, could you please make sure that everything's compiling again
>on the Web Flow side of things. Once the Web Flow module has found its
final
>home in the CVS structure, that is ;-)
>
>

What happened to the 'Styler' class?

http://cvs.sourceforge.net/viewcvs.py/springframework/spring/src/org/springf
ramework/core/Attic/Styler.java?view=markup
I tried to make the SWF code compile against current Spring CVS while on
a plane ride back to Toronto yesterday, but Styler seems to be gone. So
right now the SWF code is still building against a snapshot from June 13th.

Colin






-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] JdoDialect and detach?

[Marc L. <ma...@lo...>]

Hi,

forget something in my last email a few minutes ago. JdoDialect only 
handles vendor differences regarding JdbcConnection obtaining, it would 
be nice to have the same for attach/detach APIs. This is of course 
non-existant when we all have JDO2, but the same goes for the JDBC 
connection issue.

Or is this allready handled somewhere else? Have not found something yet.


-- 
regards
Marc Logemann
[blog] http://www.logemann.org
[busn] http://www.logentis.de

[Springframework-developer] SimpleConnectionHandle

[Marc L. <ma...@lo...>]

Hi,

is there a reason that SimpleConnectionHandle does not supply a default 
releaseConnection implementation?

I wonder why releaseConnection() cant simply close the Connection it got 
upon creation. Instead people tend to close the connection in 
JDODialect childs in method releaseJdbcConnection() by getting the 
connection from the handle and close it there.

-- 
regards
Marc Logemann
[blog] http://www.logemann.org
[busn] http://www.logentis.de

Re: [Springframework-developer] Annotation to validate required bean attributes

[Seth L. <set...@gm...>]

On 6/16/05, Andy Depue <an...@ma...> wrote:
> This is awesome stuff!  How flexible is it?  Take a look at this
> "afterPropertiesSet()":

Well, it's only written to check that a property has been set.  And
'set' is defined as:

- if property is an object, make sure it's not null
- if property is a primitive, make sure it's value isn't either the
default unset value, or the specified unset value

Your checks to see if something is a prototype aren't handled by this
code.  But, it could easily be handled with something like

@@RequiredDependency(singleton=3D"false")

Which would have the semantics you want here.  Of course, this would
be an optional check.  That is, omitting it would not check that
singleton =3D true.

Seth

>=20
> -----
>   public final void afterPropertiesSet() throws Exception
>   {
>     if(getViewPrototypeBeanName() =3D=3D null) {
>       throw new IllegalArgumentException("viewPrototypeBeanName property =
must
> be set.");
>     }
>     if(getBeanFactory() =3D=3D null) {
>       throw new IllegalArgumentException("beanFactory property must be se=
t.");
>     }
>     if(!getBeanFactory().containsBean(getViewPrototypeBeanName())) {
>       throw new IllegalArgumentException("There is no bean in the bean fa=
ctory
> with the given name '" + getViewPrototypeBeanName() + "'");
>     }
>     if(getBeanFactory().isSingleton(getViewPrototypeBeanName())) {
>       throw new IllegalArgumentException("View bean '" +
> getViewPrototypeBeanName() + "' must be a prototype (singleton=3D\"false\=
").");
>     }
>     if(!View.class.isAssignableFrom(getBeanFactory().getType(getViewProto=
typeBeanName())))
> {
>       throw new IllegalArgumentException("Prototype View bean '" +
> getViewPrototypeBeanName() + "' does not implement the View interface.");
>     }
>   }
> -----
>=20
> I would love to do away with this method entirely by just annotating the
> class.
>=20
>   - Andy
>

Re: [Springframework-developer] Annotation to validate required bean attributes

[Andy D. <an...@ma...>]

This is awesome stuff!  How flexible is it?  Take a look at this 
"afterPropertiesSet()":

-----
  public final void afterPropertiesSet() throws Exception
  {
    if(getViewPrototypeBeanName() == null) {
      throw new IllegalArgumentException("viewPrototypeBeanName property must 
be set.");
    }
    if(getBeanFactory() == null) {
      throw new IllegalArgumentException("beanFactory property must be set.");
    }
    if(!getBeanFactory().containsBean(getViewPrototypeBeanName())) {
      throw new IllegalArgumentException("There is no bean in the bean factory 
with the given name '" + getViewPrototypeBeanName() + "'");
    }
    if(getBeanFactory().isSingleton(getViewPrototypeBeanName())) {
      throw new IllegalArgumentException("View bean '" + 
getViewPrototypeBeanName() + "' must be a prototype (singleton=\"false\").");
    }
    if(!View.class.isAssignableFrom(getBeanFactory().getType(getViewPrototypeBeanName()))) 
{
      throw new IllegalArgumentException("Prototype View bean '" + 
getViewPrototypeBeanName() + "' does not implement the View interface.");
    }
  }
-----

I would love to do away with this method entirely by just annotating the 
class.

  - Andy

On Thursday 16 June 2005 11:04 am, Seth Ladd wrote:
> On 6/16/05, Heino Magnus <mag...@lm...> wrote:
> > http://opensource.atlassian.com/projects/spring/browse/SPR-1047
> >
> > Good/bad idea? Has someone else done a better implementation thats
> > already integrated that I have missed?
>
> I think it's a great idea.  Of course, I'm biased, as I also wrote an
> implementation of this concept.
>
> http://opensource.atlassian.com/projects/spring/browse/SPR-774
>
> Two major differences between 774 and 1047:
>
> My impl uses the attributes facade, so that pre 1.5 installs can use
> this functionality.
>
> It also can handle primitives.  That is, it can check if the value of
> a primitive was not set in the bean definition.
>
> My favorite part about this idea is it gets rid of all that code
> inside afterPropertiesSet(), where many beans check if their
> dependencies are set.  Each bean shouldn't have to do that, IMHO.
>
> Seth
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=Click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] enums, styler, comparator

[Juergen H. <ju...@in...>]

It's been replaced by the ValueStyler interface and DefaultValueStyler
implementation, in the "core.style" package.

I'm currently discussing with Keith whether a ValueStyler singleton should
be re-introduced. Currently, the only singleton held is ToStringCreator's
DefaultToStringStyler, which in turn holds a DefaultValueStyler instance.

I'd like to keep singletons as minimal as possible. There's always the
option to use "new DefaultValueStyler()" / "new DefaultToStringStyler()" or
even receive a ValueStyler / ToStringStyler through dependency injection.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Thursday, June 16, 2005 6:02 PM
To: spr...@li...
Subject: Re: [Springframework-developer] enums, styler, comparator


Juergen Hoeller wrote:

>Everybody,
>
>Keith's LabeledEnum and ToStringCreator stuff has been moved over from the
>sandbox, to be shipped with Spring 1.2.2 (and to be used by Web Flow PR4).
>
>I've rearranged the structure and also reworked the implementations /
>interfaces quite a bit. ToStringCreator and its helpers reside in the
>"core.style" package now; LabeledEnum and LabeledEnumResolver in
>"core.enums" (without separate support subpackage; it's all in one package
>name).
>
>I've also reworked the generic comparators: they reside in
"util.comparator"
>now. The biggest change there is that there is no SortDefinition class
>anymore. Instead, an InvertibleComparator decorator takes over the same
>role. SortDefinition already was a Comparator decorator before, so was
>arguably misnamed.
>
>Keith / Erwin, could you please make sure that everything's compiling again
>on the Web Flow side of things. Once the Web Flow module has found its
final
>home in the CVS structure, that is ;-)
>
>

What happened to the 'Styler' class?

http://cvs.sourceforge.net/viewcvs.py/springframework/spring/src/org/springf
ramework/core/Attic/Styler.java?view=markup
I tried to make the SWF code compile against current Spring CVS while on
a plane ride back to Toronto yesterday, but Styler seems to be gone. So
right now the SWF code is still building against a snapshot from June 13th.

Colin






-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Annotation to validate required bean attributes

[Seth L. <set...@gm...>]

On 6/16/05, Heino Magnus <mag...@lm...> wrote:
>=20
> http://opensource.atlassian.com/projects/spring/browse/SPR-1047
>=20
> Good/bad idea? Has someone else done a better implementation thats alread=
y
> integrated that I have missed?

I think it's a great idea.  Of course, I'm biased, as I also wrote an
implementation of this concept.

http://opensource.atlassian.com/projects/spring/browse/SPR-774

Two major differences between 774 and 1047:

My impl uses the attributes facade, so that pre 1.5 installs can use
this functionality.

It also can handle primitives.  That is, it can check if the value of
a primitive was not set in the bean definition.

My favorite part about this idea is it gets rid of all that code
inside afterPropertiesSet(), where many beans check if their
dependencies are set.  Each bean shouldn't have to do that, IMHO.

Seth

Re: [Springframework-developer] enums, styler, comparator

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

Juergen Hoeller wrote:

>Everybody,
>
>Keith's LabeledEnum and ToStringCreator stuff has been moved over from the
>sandbox, to be shipped with Spring 1.2.2 (and to be used by Web Flow PR4).
>
>I've rearranged the structure and also reworked the implementations /
>interfaces quite a bit. ToStringCreator and its helpers reside in the
>"core.style" package now; LabeledEnum and LabeledEnumResolver in
>"core.enums" (without separate support subpackage; it's all in one package
>name).
>
>I've also reworked the generic comparators: they reside in "util.comparator"
>now. The biggest change there is that there is no SortDefinition class
>anymore. Instead, an InvertibleComparator decorator takes over the same
>role. SortDefinition already was a Comparator decorator before, so was
>arguably misnamed.
>
>Keith / Erwin, could you please make sure that everything's compiling again
>on the Web Flow side of things. Once the Web Flow module has found its final
>home in the CVS structure, that is ;-)
>  
>

What happened to the 'Styler' class?
  
http://cvs.sourceforge.net/viewcvs.py/springframework/spring/src/org/springframework/core/Attic/Styler.java?view=markup
I tried to make the SWF code compile against current Spring CVS while on 
a plane ride back to Toronto yesterday, but Styler seems to be gone. So 
right now the SWF code is still building against a snapshot from June 13th.

Colin

[Springframework-developer] Annotation to validate required bean attributes

[Heino M. <mag...@lm...>]

http://opensource.atlassian.com/projects/spring/browse/SPR-1047

Good/bad idea? Has someone else done a better implementation thats already
integrated that I have missed?

Comments please.

--

  /Magnus Heino 

Re: [Springframework-developer] Rules code missing?

[Rob H. <rob...@in...>]

Guess we stole the good name ;)

I agree with both Colin and Juergen. Spring Modules was set up to help 
integration with other OSS projects that are not covered in the core. We 
have our own team of comitters all working on a variety of different 
code. In my eyes I would prefer to push all that code back into the 
product we are integrating and have SM serve as a sort of incubator.

I am certainly no fan of java.net although I could not bring myself to 
set up another project on SF with the dreadful CVS performance.

I'll be happy to have SM move over to shared infrastructure but it would 
be nice to maintain separate permissions and a separate package name. I 
would like to use the common-build system so that each module in SM can 
be distributed separately.

Rob

Colin Sampaleanu wrote:
> Erwin Vervaet wrote:
> 
>>> I'm not incredibly attached (or at all) to spring-modules as the name 
>>> of the CVS module for the new stuff. Any name is ok as long as we're 
>>> all ok with it. What about:
>>>  spring-projects
>>>  projects
>>>
>>> Any other suggestions are welcome.
>>
>>
>>
>> What about spring-parts? or spring-components?
>> I also pretty much like "spring-projects", as you suggest.
>>
>> Arguably "spring-modules" is pretty much on the money. Maybe the 
>> Java.net stuff is unfortunately named: "spring-extensions" or 
>> something to that extent would have been more appropriate.
> 
> 
> Well yeah, that's why I went with spring-modules despite the java.net 
> project. I had been thinking of that name before the java.net project 
> every existed. I guess I'll go with spring-projects. The intent is after 
> all that the main projects which make up the various core spring 
> projects move there...
> 
> 

Re: [Springframework-developer] Rules code missing?

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

Erwin Vervaet wrote:

>> I'm not incredibly attached (or at all) to spring-modules as the name 
>> of the CVS module for the new stuff. Any name is ok as long as we're 
>> all ok with it. What about:
>>  spring-projects
>>  projects
>>
>> Any other suggestions are welcome.
>
>
> What about spring-parts? or spring-components?
> I also pretty much like "spring-projects", as you suggest.
>
> Arguably "spring-modules" is pretty much on the money. Maybe the 
> Java.net stuff is unfortunately named: "spring-extensions" or 
> something to that extent would have been more appropriate.

Well yeah, that's why I went with spring-modules despite the java.net 
project. I had been thinking of that name before the java.net project 
every existed. I guess I'll go with spring-projects. The intent is after 
all that the main projects which make up the various core spring 
projects move there...


-- 
Colin Sampaleanu
Interface21 Principal Consultant
Spring Training, Consulting and Support - "From the Source"
http://www.springframework.com

Re: [Springframework-developer] Article on not using ThreadLocal

[Dain S. <da...@iq...>]

On Jun 15, 2005, at 1:23 PM, John Watson wrote:

> The real question (IMHO) is why thread-pool vendors don't clear  
> threadlocals!  I do agree that it can be very dangerous to use  
> theThreadLocal.  You do need to know what you're doing when you use  
> them. I wish that vendors would help protect us from our own  
> sloppiness,though.

 From what I heard, Websphere used to do exactly that (you just use  
setAccesable and clear the hashmap).  The problem was that way too  
much of their customer's code depended on thread locals not being  
cleared.  Customers were doing dumb stuff like using it for a cache  
between requests.

Anyway, I agree with Juergen; the problem is improper use of thread  
locals.  I just recently fixed a bunch of memory leaks in Geronimo do  
to poor thread local handling.  BTW a related issue is clearing the  
context class loader as it can cause class loaders to not be garbage  
collected.  Basically any thread state needs to be carefully managed  
since they are GC roots.

-dain

Re: [Springframework-developer] Article on not using ThreadLocal

[Andy D. <an...@ma...>]

Many times ThreadLocal is used to maintain information concerning the current 
call stack, with that information being discarded as the stack unwinds.  The 
basic idea is effectively like this:

  ((SomeStack)threadLocal.get()).push(info);
  try {
    ...
  } finally {
    ((SomeStack)threadLocal.get()).pop();
    ... code to clean up threadLocal if empty stack ...
  }

ThreadLocals come in handy when you want code in a particular call stack to 
have access to context information that can't be passed around as parameters.  
Transactions, security, auditing, etc, are all examples of things that often 
utilize ThreadLocals for the duration of a single "call stack".  In my mind, 
this particular pattern should be resilient to the effect described in the 
blog.  The pattern looks something like this (pseudo flow):

1. Request comes in from client
2. J2EE container pulls a thread from the pool to handle request
3. J2EE container eventually invokes Spring based code which happens to use 
Spring for transaction management.
4. Spring sets up transaction context in a ThreadLocal.
5. Spring based code invokes various service beans (which in turn can invoke 
other service beans), utilizing the ThreadLocal transaction context for 
transaction management.
6. Spring based code finishes, Spring cleans up ThreadLocal and returns to the 
J2EE Container.
7. J2EE Container puts thread back in pool, possibly wiping ThreadLocals.

The one thing developers need to be careful of in this usage pattern is 
properly cleaning up ThreadLocals (for security reasons) before returning 
control to the J2EE container.

Where I see a problem is if any code expects ThreadLocal to survive between 
client requests (if using the above example).  The only other problem would 
be if Spring code happens to invoke some interface that jumps threads:
  a. Spring code invokes EJB interface
  b. Container decides to handle invocation in another thread.
  c. Spring code is blocked while other thread handles invocation.
     - This other thread has no access to ThreadLocal contextual information 
from calling thread.
  d. Other thread finishes.
  e. Container wakes up original thread, passing in the return value.
As silly as this seems, it can happen in practice depending on the 
architecture of the system.

As long as Spring sticks to this usage pattern, then I'm not seeing a problem 
- or am I missing something?

  - Andy


On Wednesday 15 June 2005 01:01 pm, Tim Kettering wrote:
> This guy (presumably a senior dev @ IBM) says not to use ThreadLocal.  He
> says that usage should be removed from open-source projects (mentioning
> Spring specifically).
>
>
>
> Wanted to pass this url on - see what you Spring developers thought about
> this.
>
>
>
> http://www.devwebsphere.com/devwebsphere/2005/06/dont_use_thread.html

Re: [Springframework-developer] Article on not using ThreadLocal

[Juergen H. <ju...@in...>]

Quoting myself from my reply to Billy's post:

Actually, Spring does not use ThreadLocals in the way you describe. Spring
always just uses ThreadLocals temporarily, while guaranteed to be on the
same thread, with proper cleanup at the end (in any case). This applies to
transaction ThreadLocals as well as to others.

IMO, this is completely valid: As long as the ThreadLocal is always
guaranteed to be cleaned up when returning the thread to the server's pool,
I cannot see anything going wrong... So it's not about using ThreadLocals in
general, it's about _properly_ using ThreadLocals.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of John Watson
Sent: Wednesday, June 15, 2005 10:24 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Article on not using
ThreadLocal


The real question (IMHO) is why thread-pool vendors don't clear thread
locals!  I do agree that it can be very dangerous to use the
ThreadLocal.  You do need to know what you're doing when you use them.
 I wish that vendors would help protect us from our own sloppiness,
though.

John


On 6/15/05, Tim Kettering <tim...@vi...> wrote:
>
>
>
> This guy (presumably a senior dev @ IBM) says not to use ThreadLocal.  He
> says that usage should be removed from open-source projects (mentioning
> Spring specifically).
>
>
>
> Wanted to pass this url on – see what you Spring developers thought about
> this…
>
>
>
> http://www.devwebsphere.com/devwebsphere/2005/06/dont_use_thread.html
HSµéŠX²š²Šu¼ŠÇ½êjÌŠ{2(jØ+j׉뮉ÁÛš™¶‡–ZF†™ª²ÚŠ~Šj·®Ø•ëú™«½åmƶÆvjxgz÷ÊØ
žºwvÚzÛ¶‹yçj˶Úý§¢Çr‰iØ¾í©¡È^÷j
ÉrD®)~¶{
‘×zZz¹ŠX‚Xµ*Šx­©ÂŠuë–Š®X¶Ëº·~Šzw†Û³ÿŠË²‹qç®zߊËþX¶)£û®)~¶{
‘×zZ

Re: [Springframework-developer] Article on not using ThreadLocal

[John W. <jkw...@gm...>]

VGhlIHJlYWwgcXVlc3Rpb24gKElNSE8pIGlzIHdoeSB0aHJlYWQtcG9vbCB2ZW5kb3JzIGRvbid0
IGNsZWFyIHRocmVhZApsb2NhbHMhICBJIGRvIGFncmVlIHRoYXQgaXQgY2FuIGJlIHZlcnkgZGFu
Z2Vyb3VzIHRvIHVzZSB0aGUKVGhyZWFkTG9jYWwuICBZb3UgZG8gbmVlZCB0byBrbm93IHdoYXQg
eW91J3JlIGRvaW5nIHdoZW4geW91IHVzZSB0aGVtLgogSSB3aXNoIHRoYXQgdmVuZG9ycyB3b3Vs
ZCBoZWxwIHByb3RlY3QgdXMgZnJvbSBvdXIgb3duIHNsb3BwaW5lc3MsCnRob3VnaC4KCkpvaG4K
CgpPbiA2LzE1LzA1LCBUaW0gS2V0dGVyaW5nIDx0aW0ua2V0dGVyaW5nQHZpdmFrb3MuY29tPiB3
cm90ZToKPiAgCj4gIAo+IAo+IFRoaXMgZ3V5IChwcmVzdW1hYmx5IGEgc2VuaW9yIGRldiBAIElC
TSkgc2F5cyBub3QgdG8gdXNlIFRocmVhZExvY2FsLiAgSGUKPiBzYXlzIHRoYXQgdXNhZ2Ugc2hv
dWxkIGJlIHJlbW92ZWQgZnJvbSBvcGVuLXNvdXJjZSBwcm9qZWN0cyAobWVudGlvbmluZwo+IFNw
cmluZyBzcGVjaWZpY2FsbHkpLiAKPiAKPiAgIAo+IAo+IFdhbnRlZCB0byBwYXNzIHRoaXMgdXJs
IG9uIJYgc2VlIHdoYXQgeW91IFNwcmluZyBkZXZlbG9wZXJzIHRob3VnaHQgYWJvdXQKPiB0aGlz
hSAKPiAKPiAgIAo+IAo+IGh0dHA6Ly93d3cuZGV2d2Vic3BoZXJlLmNvbS9kZXZ3ZWJzcGhlcmUv
MjAwNS8wNi9kb250X3VzZV90aHJlYWQuaHRtbAo=

[Springframework-developer] Article on not using ThreadLocal

[Tim K. <tim...@vi...>]

This guy (presumably a senior dev @ IBM) says not to use ThreadLocal.  He
says that usage should be removed from open-source projects (mentioning
Spring specifically).

 

Wanted to pass this url on - see what you Spring developers thought about
this.

 

http://www.devwebsphere.com/devwebsphere/2005/06/dont_use_thread.html

Re: [Springframework-developer] Rules code missing?

[Erwin V. <erw...@er...>]

> I'm not incredibly attached (or at all) to spring-modules as the name of 
> the CVS module for the new stuff. Any name is ok as long as we're all ok 
> with it. What about:
>  spring-projects
>  projects
>
> Any other suggestions are welcome.

What about spring-parts? or spring-components?
I also pretty much like "spring-projects", as you suggest.

Arguably "spring-modules" is pretty much on the money. Maybe the Java.net 
stuff is unfortunately named: "spring-extensions" or something to that 
extent would have been more appropriate.

Erwin