springframework-developer — Spring Framework developers list

RE: [Springframework-developer] StaticMethodPointcut

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

+1
I don't see any immediate problems with changing the signature.

Regards,
Dmitriy.

-----Original Message-----
From: Rod Johnson
To: spr...@li...
Sent: 10/24/2003 8:44 AM
Subject: [Springframework-developer] StaticMethodPointcut

Guys,

I think we should change the signature on the StaticMethodPointcut
applies()
method to introduce a new argument, targetClass, as below:

boolean applies(Method method, Class targetClass, AttributeRegistry
attributeRegistry);

The reason is that sometimes we need to know not just the method, but
the
target class we're invoking.

Consider the getAge() method on class TestBean. A subclass,
SpecialTestBean
adds a class-level metadata attribute that should cause auto-proxying.
With
the old signature, the method argument would be TestBean.getAge() and
without knowledge of the target class we would miss this important
attribute.

Does everyone agree this makes sense? Is there a better solution?

This will break existing static pointcuts, although it's trivial to fix.
I've already revised the source and test tree (although not committed
yet).
Hence I didn't commit it before M2.

Regards,
Rod




-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] StaticMethodPointcut

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

Guys,

I think we should change the signature on the StaticMethodPointcut applies()
method to introduce a new argument, targetClass, as below:

boolean applies(Method method, Class targetClass, AttributeRegistry
attributeRegistry);

The reason is that sometimes we need to know not just the method, but the
target class we're invoking.

Consider the getAge() method on class TestBean. A subclass, SpecialTestBean
adds a class-level metadata attribute that should cause auto-proxying. With
the old signature, the method argument would be TestBean.getAge() and
without knowledge of the target class we would miss this important
attribute.

Does everyone agree this makes sense? Is there a better solution?

This will break existing static pointcuts, although it's trivial to fix.
I've already revised the source and test tree (although not committed yet).
Hence I didn't commit it before M2.

Regards,
Rod

[Springframework-developer] Re: Beans

[Brett B. <br...@po...>]

Hi

I see some one else is having the same problem as me re:
http://sourceforge.net/forum/forum.php?thread_id=948032&forum_id=250340

I will try and look up what to do.

cheers

Brett
> Message: 1
> Date: Fri, 24 Oct 2003 19:48:24 +0100 (BST)
> From: "Brett Bell" <br...@po...>
> To: spr...@li...
> Subject: [Springframework-developer] Beans
> Reply-To: spr...@li...
>
> Hi all,
>
> soz i haven't been around for ages.
>
> I have been trying out the XMLBeanFactory and I have defined a JavaBean
> which has an Integer property which Spring doesn't like.  I can define
> value for Longs and Strings but it throws an exception when it tries to
> convert a String(in the xml file) to an Integer.  Can you throw any light
> on this...
>
> cheers in advance (the stacktrace is below).
>
>
> Brett
>
>
> PropertyVetoExceptionsException: 1 errors:--
> ErrorCodedPropertyVetoException: message=[Failed to convert property value
> of type [java.lang.String] to required type [java.lang.Integer] for
> property named 'age'; nested exception is:
> 	java.lang.IllegalArgumentException: argument type mismatch];
> errorCode=[typeMismatch]
> java.lang.IllegalArgumentException: argument type mismatch
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:324)
> 	at
> org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:531)
> 	at
> org.springframework.beans.BeanWrapperImpl.setPropertyValues(BeanWrapperImpl.java:590)
> 	at
> org.springframework.beans.BeanWrapperImpl.setPropertyValues(BeanWrapperImpl.java:567)
> 	at
> org.springframework.beans.factory.support.AbstractBeanFactory.applyPropertyValues(AbstractBeanFactory.java:375)
> 	at
> org.springframework.beans.factory.support.AbstractBeanFactory.createBean(AbstractBeanFactory.java:309)
> 	at
> org.springframework.beans.factory.support.AbstractBeanFactory.getSharedInstance(AbstractBeanFactory.java:224)
> 	at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:156)
> 	at brett.ioc.ApplicationContext.create(ApplicationContext.java:24)
> 	at brett.ioc.SpringStuff.execute(SpringStuff.java:10)
> 	at brett.Demo.main(Demo.java:40)
>
>

[Springframework-developer] Fw: StaticMethodPointcut

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

I sent this to the list yesterday...don't know why it hasn't shown up.

----- Original Message ----- 
From: "Rod Johnson" <rod...@in...>
To: <spr...@li...>
Sent: Friday, October 24, 2003 1:44 PM
Subject: StaticMethodPointcut


> Guys,
>
> I think we should change the signature on the StaticMethodPointcut
applies()
> method to introduce a new argument, targetClass, as below:
>
> boolean applies(Method method, Class targetClass, AttributeRegistry
> attributeRegistry);
>
> The reason is that sometimes we need to know not just the method, but the
> target class we're invoking.
>
> Consider the getAge() method on class TestBean. A subclass,
SpecialTestBean
> adds a class-level metadata attribute that should cause auto-proxying.
With
> the old signature, the method argument would be TestBean.getAge() and
> without knowledge of the target class we would miss this important
> attribute.
>
> Does everyone agree this makes sense? Is there a better solution?
>
> This will break existing static pointcuts, although it's trivial to fix.
> I've already revised the source and test tree (although not committed
yet).
> Hence I didn't commit it before M2.
>
> Regards,
> Rod
>

Re: [Springframework-developer] FW: [springframework - Help] Index properties in forms

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

Peter,

I tend to agree that JSP EL syntax is preferable, although we are not =
talking about a web-specific thing here. We have to build this into =
BeanWrapperImpl in any case, as we need to do lookups of custom property =
editors etc to provide the same level of functionality as for current =
nested properties. I doubt that we could reuse any existing EL =
implementation for this, as they all work on a JSP PageContext. =
Generally, we should try to avoid any additional dependencies for the =
core bean factory.

Juergen


-----Original Message-----
From: Peter den Haan [mailto:pe...@de...]
Sent: Friday, October 24, 2003 1:25 AM
To: spr...@li...
Subject: [[W3-SPAM]] - Re: [Springframework-developer] FW:
[springframework - Help] Index properties in forms - Email found in
subject



Juergen wrote:

> The question is: When and how to we add support for indexed and mapped
properties?
> I guess that if we do, we should adopt the Commons BeanUtils style of
specifying property
> paths for index and map access.

I disagree. I feel we should use (a subset of) the JSTL Expression =
Language
(EL) syntax as our starting point rather than BeanUtils style syntax. =
Please
consider that this EL will be part of JSP itself as of version 2.0 of =
the
spec; why introduce another language into the mix? If in a JSP you say
${foo.bar}, shouldn't you be able to name the corresponding field =
foo.bar
rather than foo(bar)?

For simple and indexed properties, users won't notice any difference =
anyway.
The most important differences are that the precise meaning of a[b] is
determined by whether "a" evaluates to a List or a Map, and that a.b is
fully equivalent to a["b"]. BeanUtils-style mapped properties (i.e. =
a(b))
aren't part of the EL; they could be supported in a compatible way but =
IMHO
stick with core JavaBeans stuff -- do this only if we can come up with a
compelling use case for it.

And if this is being refactored anyway, it's probably worth taking a =
look at
what would be involved in making the EL implementation pluggable.

 - Peter



-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Documentation

[Mike Cannon-B. <mi...@at...>]

For what it's worth, we use Forrest + CVS versioning for all of the JIRA
docs and it's really good.

M

On 24/10/03 5:03 AM, "Mark Pollack" (mar...@co...) penned the
words:

> What system does Hibernate use?
> 
> If we were going to use maven just for the docs, on the surface forrest
> looks like a more appropriate document centric solution.
> 
> - Mark
> 
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
> Of Colin Sampaleanu
> Sent: Tuesday, October 21, 2003 9:39 AM
> To: al...@jt...
> Cc: 'Rod Johnson'; 'Spring Developers'
> Subject: Re: [Springframework-developer] Documentation
> 
> 
> Aside from doing something homebrew, the other choice for documentation
> is probably Forrest, which I've never used:
> http://xml.apache.org/forrest/
> 
> 
> Alef Arendsen (JTeam) wrote:
> 
>> Well, I don't really like Maven for _building_ software. For putting
>> out documentation though, I think it's quite nice...
>> 
>> Alef
>> 
>> 
>>  
>> 
>>> -----Oorspronkelijk bericht-----
>>> Van: spr...@li...
>>> [mailto:spr...@li...]
>>> Namens Colin Sampaleanu
>>> Verzonden: Thursday, October 16, 2003 7:16 PM
>>> Aan: Rod Johnson
>>> CC: 'Spring Developers'
>>> Onderwerp: Re: [Springframework-developer] Documentation
>>> 
>>> 
>>> I actually have a lot of experience with Maven, having
>>> tinkered with it
>>> a bunch over the last year (unfortunately, the multiproject support,
>>> where I think Maven becomes the most useful (along with the
>>> docs) to me, 
>>> is still broken in some respects (property and repository
>>> overrides, for 
>>> one), but that would not have an effect on Spring.
>>> 
>>> If there is consensus on this, I am willing to put in some time to
>>> finish this up, as necessary.
>>> 
>>> 
>>> Rod Johnson wrote:
>>> 
>>>    
>>> 
>>>> I believe Luke Tayler did a Maven build script which works. So we
>>>> certainly have a starting point.
>>>> 
>>>> Rod
>>>> 
>>>> ----- Original Message -----
>>>> From: "Colin Sampaleanu" <col...@ex...>
>>>> To: "'Spring Developers'"
>>>>      
>>>> 
>>> <spr...@li...>
>>>    
>>> 
>>>> Sent: Thursday, October 16, 2003 5:17 PM
>>>> Subject: Re: [Springframework-developer] Documentation
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> From my point of view, while of course there is a general need for
>>>>      
>>>> 
>>>>> more documentation and samples, what would also be of some
>>>>>        
>>>>> 
>>> use is some
>>>    
>>> 
>>>>> general infrastructure for producing consistent and relatively
>>>>> professional looking docs and a website. I am not a big fan
>>>>>        
>>>>> 
>>> of Maven
>>>    
>>> 
>>>>> generated websites with nothing in them, but on the other hand, if
>>>>> people are willing to write documentation, Maven (and other
>>>>> alternatives like Forrest) make it pretty easy to put out
>>>>> documentation without having to worry too much about the look and
>>>>> feel, linking it into the site, etc.
>>>>> 
>>>>> W/regards to the possibility of using Maven, one option would be to
>>>>> use it just for doc generation, if doing the entire build
>>>>>        
>>>>> 
>>> with it is
>>>    
>>> 
>>>>> too onerous. This approach has been used by other projects...
>>>>> 
>>>>> Regards,
>>>>> Colin
>>>>> 
>>>>> Alef Arendsen (JTeam) wrote:
>>>>> 
>>>>>   
>>>>> 
>>>>>        
>>>>> 
>>>>>> Hi all,
>>>>>> 
>>>>>> Since I am busy closing 2002's financial year (doing all the
>>>>>> accounting and stuff; I never should have started a company :), I
>>>>>> desperately need some things I can do when I'm totally sick of all
>>>>>> those numbers and spreadsheets. No internal projects here,
>>>>>>          
>>>>>> 
>>> so I was
>>>    
>>> 
>>>>>> wondering if there already is a plan for how to improve our
>>>>>> documentation base or if there are if there other important things
>>>>>> that need to be addressed.
>>>>>> 
>>>>>> Juergen, other people, any thoughts?
>>>>>> 
>>>>>> Thanx,
>>>>>> 
>>>>>> Alef
>>>>>>          
>>>>>> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by OSDN developer relations Here's your
> chance to show off your extensive product knowledge We want to know what
> you know. Tell us and you have a chance to win $100
> http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: The SF.net Donation Program.
> Do you like what SourceForge.net is doing for the Open
> Source Community?  Make a contribution, and help us add new
> features and functionality. Click here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Re:

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

(I think your email was HTML only, I had to actually copy and past it, 
reply copied all the HTML tags).

I think this would work ok. All usage of properties in 
afterPropertiesSet is qualified by 'if ! null', so one template method 
like this would allow extension on any of them...

Colin



Juergen wrote:
> >>>
Alef,
 
I'd like to keep the final afterPropertiesSet -- it's too easy to break 
superclass functionality if overriding that and not properly doing super 
calls. Currently, you could override newSessionFactory a la:
 
protected SessionFactory newSessionFactory(Configuration config) {
  // add the mapping resources programmatically
  config.addResource("myMappingResource", 
Thread.currentThread().getContextClassLoader());
  return super.newSessionFactory(config);
}
 
Of course, it might make sense to introduce a separate post-processing 
callback, to be invoked by the standard afterPropertiesSet method right 
before the newSessionFactory call:
 
protected void postProcessConfiguration(Configuration config) {
  // add the mapping resources programmatically
  config.addResource("myMappingResource", 
Thread.currentThread().getContextClassLoader());
}
 
What do you think? I guess such a call back wouldn't hurt anyone, and it 
is easier to override for post-processing purposes.
 
Juergen

[Springframework-developer] Beans

[Brett B. <br...@po...>]

Hi all,

soz i haven't been around for ages.

I have been trying out the XMLBeanFactory and I have defined a JavaBean
which has an Integer property which Spring doesn't like.  I can define
value for Longs and Strings but it throws an exception when it tries to
convert a String(in the xml file) to an Integer.  Can you throw any light
on this...

cheers in advance (the stacktrace is below).


Brett


PropertyVetoExceptionsException: 1 errors:--
ErrorCodedPropertyVetoException: message=[Failed to convert property value
of type [java.lang.String] to required type [java.lang.Integer] for
property named 'age'; nested exception is:
	java.lang.IllegalArgumentException: argument type mismatch];
errorCode=[typeMismatch]
java.lang.IllegalArgumentException: argument type mismatch
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:324)
	at
org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:531)
	at
org.springframework.beans.BeanWrapperImpl.setPropertyValues(BeanWrapperImpl.java:590)
	at
org.springframework.beans.BeanWrapperImpl.setPropertyValues(BeanWrapperImpl.java:567)
	at
org.springframework.beans.factory.support.AbstractBeanFactory.applyPropertyValues(AbstractBeanFactory.java:375)
	at
org.springframework.beans.factory.support.AbstractBeanFactory.createBean(AbstractBeanFactory.java:309)
	at
org.springframework.beans.factory.support.AbstractBeanFactory.getSharedInstance(AbstractBeanFactory.java:224)
	at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:156)
	at brett.ioc.ApplicationContext.create(ApplicationContext.java:24)
	at brett.ioc.SpringStuff.execute(SpringStuff.java:10)
	at brett.Demo.main(Demo.java:40)

RE: [Springframework-developer] LocalSessionFactory afterPropertiesSet() = final

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

Alef,
=20
I'd like to keep the final afterPropertiesSet -- it's too easy to break =
superclass functionality if overriding that and not properly doing super =
calls. Currently, you could override newSessionFactory a la:
=20
protected SessionFactory newSessionFactory(Configuration config) {
  // add the mapping resources programmatically
  config.addResource("myMappingResource", =
Thread.currentThread().getContextClassLoader());
  return super.newSessionFactory(config);
}
=20
Of course, it might make sense to introduce a separate post-processing =
callback, to be invoked by the standard afterPropertiesSet method right =
before the newSessionFactory call:
=20
protected void postProcessConfiguration(Configuration config) {
  // add the mapping resources programmatically
  config.addResource("myMappingResource", =
Thread.currentThread().getContextClassLoader());
}
=20
What do you think? I guess such a call back wouldn't hurt anyone, and it =
is easier to override for post-processing purposes.
=20
Juergen
=20
=20

-----Original Message-----
From: Alef Arendsen (JTeam) [mailto:al...@jt...]
Sent: Thursday, October 23, 2003 2:50 PM
To: 'Spring Developers'
Subject: [Springframework-developer] LocalSessionFactory =
afterPropertiesSet() =3D final



Juergen,=20

Right now the LocalSessionFactory in the Hibernate package has a final =
afterPropertiesSet()-method. We'd like to extend the factory in order to =
collect mapping files from different sources instead of the fixed =
property 'mappingResources'. Then of course we need to override =
afterPropertiesSet() to set the mappingResources on the superclass and =
then call super.afterPropertiesSet(). However, like I said, the =
afterPropertiesSet() method from LocalSessionFactory is final.

Any objections to 'de-finalizing' this method?=20

Thanx,=20

Alef=20

P.s. getting into the hibernate stuff here, looks good :)=20

=3D=3D=20
JTeam B.V.=20
Donker Curtiusstraat 7-412=20
1051 JL  Amsterdam=20
T: +31 20 486 20 36=20
M: +31 6 24 11 1996=20
F: +31 84 837 00 00=20
E: al...@jt...=20
W:  <http://www.jteam.nl> http://www.jteam.nl=20

RE: [Springframework-developer] Preparing for 1.0 M2

[Mark P. <mar...@co...>]

Hi,

Sorry, I hadn't been checking the list for a while.  I'll clean those =
metadata tests up...they are working inside eclipse but not =
externally...some classpath issue.

Cheers,
Mark



-----Original Message-----
From: spr...@li... =
[mailto:spr...@li...] On Behalf =
Of j=C3=BCrgen h=C3=B6ller [werk3AT]
Sent: Wednesday, October 22, 2003 5:35 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Preparing for 1.0 M2


Thomas,
=20
I've seen those metadata tests fail too. As the whole metadata package =
will not be included in the 1.0 M2 release anyway, this shouldn't really =
matter for the time being. I've excluded them from the test run in my =
local build.properties file.
=20
Juergen
=20

	-----Urspr=C3=BCngliche Nachricht-----=20
	Von: tri...@tr... [mailto:tri...@tr...]=20
	Gesendet: Mi 22.10.2003 22:26=20
	An: spr...@li...=20
	Cc:=20
	Betreff: Re: [Springframework-developer] Preparing for 1.0 M2
=09
=09

	I'm still seeing a few errors running the tests.  If someone has time =
to look at
	this, then we should do this before Friday.  If not, then we should at =
least
	comment out the failing tests and tag them with a TODO note (I can do =
this
	Thursday night).  I don't think we should release without having all =
tests passing.
=09
	Here is more detail:
=09
	Apache Ant version 1.5.2 compiled on February 28 2003
	java version "1.4.2"
	Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28)
	Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)
=09
	BUILD FAILED
	file:C:/eclipse/workspace/spring/build.xml:288: Test =
org.springframework.metadat
	a.bcel.AttributeWriterTests failed
=09
	Testsuite: org.springframework.metadata.bcel.AttributeWriterTests
	Tests run: 5, Failures: 0, Errors: 1, Time elapsed: 1.406 sec
=09
	Testcase: testAttributes took 1.171 sec
	Testcase: testBadAbbreviatedAttribute took 0.11 sec
	Testcase: testAbbreviatedAttribute took 0.047 sec
	        Caused an ERROR
	Could not create class using classnames [PersonAttribute, =
PersonAttributeAttribute]
	org.springframework.metadata.AttributeException: Could not create class =
using
	classnames [PersonAttribute, PersonAttributeAttribute]
	        at
	=
org.springframework.metadata.support.AttributeCreator.resolveClassname(At=
tributeCreator.java:129)
	        at
	=
org.springframework.metadata.support.AttributeCreator.createAttribute(Att=
ributeCreator.java:84)
	        at
	=
org.springframework.metadata.bcel.BcelAttributes.createObject(BcelAttribu=
tes.java:223)
	        at
	=
org.springframework.metadata.bcel.BcelAttributes.getAttributes(BcelAttrib=
utes.java:98)
	        at
	=
org.springframework.metadata.bcel.BcelAttributes.getAttributes(BcelAttrib=
utes.java:71)
	        at
	=
org.springframework.metadata.bcel.AttributeWriterTests.testAbbreviatedAtt=
ribute(AttributeWriterTests.java:161)
	        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	        at =
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java=
:39)
	        at
	=
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI=
mpl.java:25)
=09
	Testcase: testAbbreviatedAttributeTestcase: testMethods took 0.032 sec
	Testcase: testFields took 0.031 sec
=09
=09
=09
	BUILD FAILED
	file:C:/eclipse/workspace/spring/build.xml:288: Test =
org.springframework.metadat
	a.qdox.CompilerTests failed
=09
	Testsuite: org.springframework.metadata.qdox.CompilerTests
	Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 1.25 sec
=09
	Testcase: testSingleFile took 1.235 sec
	        Caused an ERROR
	null
	java.lang.NullPointerException
	        at java.util.StringTokenizer.<init>(StringTokenizer.java:146)
	        at java.util.StringTokenizer.<init>(StringTokenizer.java:162)
	        at
	=
org.springframework.metadata.support.AttributeCreator.pathArrayToURLArray=
(AttributeCreator.java:387)
	        at
	=
org.springframework.metadata.qdox.QDoxMetadataCompiler.getClass(QDoxMetad=
ataCompiler.java:209)
	        at
	=
org.springframework.metadata.qdox.QDoxMetadataCompiler.compile(QDoxMetada=
taCompiler.java:109)
	        at
	=
org.springframework.metadata.qdox.CompilerTests.testSingleFile(CompilerTe=
sts.java:59)
	        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	        at =
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java=
:39)
	        at
	=
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI=
mpl.java:25)
=09
	Testcase: testSingleFile
=09
=09
=09
=09
=09
	> Everybody,
	>
	> Repeating myself from the mail on Velocity support:
	>
	> > Please give everything one last try if possible! If there are no =
issues
	> till tomorrow evening, I will release 1.0 M2 Friday morning at the =
latest.
	>
	> Generally, please re-apply the current codebase to your apps to catch =
any
	> last minute issues. There've been quite some serious refactorings in =
the last
	> few weeks; some things could have slipped through the test suite.
	>
	> BTW, checking our third-party dependencies in the distribution, I've =
omitted
	> the Log4J jar for the time being, as it was commented out in the =
samples
	> anyway due to JBoss issues. Commons Logging logs to the console by =
default
	> now, at INFO level.
	>
	> As Petclinic offers a new Hibernate implementation, the Spring =
distribution
	> contains Hibernate jar files now. The total size is still below 10 =
MB, 9.7 to
	> be exact.
	>
	> Juergen
	>
	>
	> DI J=C3=BCrgen H=C3=B6ller
	> Senior System Architect
	> ______________________________________
	>
	> werk3ATS - division systementwicklung
	> werk3AT informations- und mediensysteme
	>
	> europaplatz 4
	> A - 4020 linz
	>
	> t.  +43 (0) 732 71 65 29 502
	> f.  +43 (0) 732 71 65 29 3
	> mailto:jue...@we...
	> http://www.werk3at.com
	> ______________________________________
	> werk3ATS - WIR ENTWICKELN ERFOLG
	>
	>
	> -------------------------------------------------------
	> This SF.net email is sponsored by OSDN developer relations
	> Here's your chance to show off your extensive product knowledge
	> We want to know what you know. Tell us and you have a chance to win =
$100
	> http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
	> _______________________________________________
	> Springframework-developer mailing list
	> Spr...@li...
	> =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
	>
=09
=09
=09
=09
=09
	-------------------------------------------------------
	This SF.net email is sponsored by OSDN developer relations
	Here's your chance to show off your extensive product knowledge
	We want to know what you know. Tell us and you have a chance to win =
$100
	http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
	_______________________________________________
	Springframework-developer mailing list
	Spr...@li...
	https://lists.sourceforge.net/lists/listinfo/springframework-developer
=09

                     +=12=17 =
=E9=9A=8AX'u=DE=BCH3]z=ED=BD=96=ED=B2=97Z*'=E9=B6=B0w{2 =DC=85z =
,(}=E7=B1=B5 =ED=BD=A6=ED=BE=87nr'=D9=A3	^v {=06$=DA=9E0r'=0F zYn jr=16q =
h) M!=ED=BC=AA=ED=B7=B6  0 g=E8=A2=ABjxr {/ /D _tX@ W
5%w=13                  )~=ED=9F=97=ED=B6=A6{+^ h j)b	=
b=ED=9F=9F=ED=BD=A9)~=E0=B6=A6{+^ h +-(=1E~ { =1Bm X  y + z l =
X)=E8=92=9A=ED=B2=A3)) ~{+^ h

[Springframework-developer] LocalSessionFactory afterPropertiesSet() = final

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

Juergen,

Right now the LocalSessionFactory in the Hibernate package has a final
afterPropertiesSet()-method. We'd like to extend the factory in order to
collect mapping files from different sources instead of the fixed
property 'mappingResources'. Then of course we need to override
afterPropertiesSet() to set the mappingResources on the superclass and
then call super.afterPropertiesSet(). However, like I said, the
afterPropertiesSet() method from LocalSessionFactory is final.

Any objections to 'de-finalizing' this method?

Thanx,

Alef

P.s. getting into the hibernate stuff here, looks good :)

==
JTeam B.V.
Donker Curtiusstraat 7-412
1051 JL  Amsterdam
T: +31 20 486 20 36
M: +31 6 24 11 1996
F: +31 84 837 00 00
E: al...@jt...
W: http://www.jteam.nl

Re: [Springframework-developer] FW: [springframework - Help] Index properties in forms

[Peter d. H. <pe...@de...>]

Juergen wrote:

> The question is: When and how to we add support for indexed and mapped
properties?
> I guess that if we do, we should adopt the Commons BeanUtils style of
specifying property
> paths for index and map access.

I disagree. I feel we should use (a subset of) the JSTL Expression Language
(EL) syntax as our starting point rather than BeanUtils style syntax. Please
consider that this EL will be part of JSP itself as of version 2.0 of the
spec; why introduce another language into the mix? If in a JSP you say
${foo.bar}, shouldn't you be able to name the corresponding field foo.bar
rather than foo(bar)?

For simple and indexed properties, users won't notice any difference anyway.
The most important differences are that the precise meaning of a[b] is
determined by whether "a" evaluates to a List or a Map, and that a.b is
fully equivalent to a["b"]. BeanUtils-style mapped properties (i.e. a(b))
aren't part of the EL; they could be supported in a compatible way but IMHO
stick with core JavaBeans stuff -- do this only if we can come up with a
compelling use case for it.

And if this is being refactored anyway, it's probably worth taking a look at
what would be involved in making the EL implementation pluggable.

 - Peter

Re: [Springframework-developer] Re: Spring Framework 1.0 M2 released

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

Juergen,

I have updated the website - let me know if I missed something.

Thomas


> Thomas,
>  
> Can you please update the website accordingly, including the documentation
> articles?
>  
> Thanks,
> Juergen
>  
>  
> 
> 	-----Ursprüngliche Nachricht----- 
> 	Von: jürgen höller [werk3AT] 
> 	Gesendet: Fr 24.10.2003 01:08 
> 	An: spr...@li... 
> 	Cc: spr...@li... 
> 	Betreff: Spring Framework 1.0 M2 released
> 	
> 	
> 	Hi Spring followers,
> 	 
> 	I'm pleased to announce that we've just released 1.0 M2, the second
> milestone release towards 1.0 and fourth public release in total. It contains
> numerous bug fixes and new features; see the change log for details.
> 	 
> 	A major change in terms of samples is that Petclinic is now available in
> alternative implementations for JDBC and Hibernate; therefore, the minimum
> Hibernate jars are now included in the distribution. Furthermore, the
> skeletons have been repackaged into "webapp-minimal" and "webapp-typical",
> the latter with multiple application context configurations.
> 	 
> 	An important change in recommendation is for the <ref .../> tag in XML bean
> definitions: <ref bean="..."/> is now a general reference to any bean name in
> the context, while <ref local="..."/> references a bean id in the same XML
> file (allowing for validation by the XML parser). <ref external="..."/> is
> deprecated now; it behaves the same as <ref bean="..."/> for the time being.
> 
> 	 
> 	So consider <ref bean="..."/> as the general reference now, no matter if
> local or in a parent context, and <ref local="..."/> as the optional one for
> strong validation in the local XML file. All existing bean definitions will
> still work, although we recommend to replace <ref external="..."/> tags with
> <ref bean="..."/>.
> 	 
> 	Finally, I'd like to note one minor incompatible API change:
> AbstractFormController's former "processSubmit" method is now called
> "processFormSubmission" to avoid confusion with the "onSubmit" callback of
> SimpleFormController. This will only affect you if you have subclassed
> AbstractFormController directly; simply rename your implementation method
> then.
> 	 
> 	Regards,
> 	Juergen
> 
> 

RE: [Springframework-developer] RE: Class file manipulation with BCEL safe?

[Mark P. <mar...@co...>]

Hi,

Interesting indeed, I never though of that.

I think the "side" file approach is also valid...it really tends to be a
matter of taste. I believe the JSR175 committe also debated long and
hard about where to put the attributes and ended up putting it in the
bytecode.

I'm curious if CGLIB would behave the way suggested. Java already stores
a custom attribute in the bytecode, the 'depreacted' attribute. CGLIB
might strip this out as well. It needs some investigation, I'll look
into it. If it does strip out attributes there are probably implications
for jdk1.5 based code.

Should I provide the "side file" or "side class" approach (ala BeanInfo)
as well? There is a need for side-files anyway if someone wants to
over-ride the settings in an existing class without having to
subclass... JSR181 has a thread on this over ridding stuff, I'll read up
on it.

The side-file approach does feel better to people, those who typically
dislike anything touching their bytecode and it does mean you don't have
to copy the bcel.jar into ANT_HOME/lib, so it feels more lightweight. 

I guess there is a danger of offering too many possiblities for storing
the attributes instead of presenting a "best of breed" solution. If we
offer side file support, then aside from the plugability issue, we start
to look very much like the current attributes-commons stuff. Of course,
plugability is important if we want to co-exist with the avalance of
jdk1.5 attributes that are sure to come.

Cheers,
Mark

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of Chris Nokleberg
Sent: Thursday, October 23, 2003 2:42 AM
To: spr...@li...
Subject: [Springframework-developer] RE: Class file manipulation with
BCEL safe?


Alef Arendsen (JTeam) wrote:
> In a Spring Validator, I'm retrieving the attributes using 
> BcelAttributes and then inspect the class... Works kind of neat,
>  
> but still, won't this conflict with the ASM way hibernate does things?

In short, no. Hibernate uses CGLIB mostly for generating lazy-loading
proxies. Since the proxies are subclasses of the mapped classes, you
should be able to retrieve your attribute data from the superclass of
the proxy. You can tell a proxy from a non proxy by seeing if your
object is an instanceof net.sf.cglib.Factory.

If a framework ends up using CGLIB or something like it to actually
transform your classes at build time or run time you will have to be
careful. It is likely that any attributes in the original class would be
stripped out. For this reason I would suggest storing the attribute
metadata outside of the classfile. Personally I have had good success
using QDox to parse the source files, generating a .attributes
properties file per class.

Chris




-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations Here's your
chance to show off your extensive product knowledge We want to know what
you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] FW: [springframework - Help] Index properties in forms

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

I really like OGNL. I think it would be a better choice than Commons 
Beanutils, being more powerful, well documented, and well supported... 
The library jar is about 30% bigger though...


jürgen höller [werk3AT] wrote:

>Everybody,
>
>Seems like we've got two people inquiring for indexed property support. The second already dates back to mid-September :-(
>
>I've just rechecked the BeanWrapper implementation and discovered that there is no proper support for indexed properties yet. The existing getIndexedProperty method was not complete (e.g. no support for nesting) and untested (no unit test covered it), so I've decided to remove it for the time being (for 1.0 M2). It just confused both of those guys that were looking for indexed property support.
>
>Jakarta Commons BeanUtils does support nested and mapped properties, quoting from the javadocs of their PropertyUtils class:
>
><quote>
>For the purposes of this class, five formats for referencing a particular property value of a bean are defined, with the layout of an identifying String in parentheses: 
>
>* Simple (name) - The specified name identifies an individual property of a particular JavaBean. The name of the actual getter or setter method to be used is determined using standard JavaBeans instrospection, so that (unless overridden by a BeanInfo class, a property named "xyz" will have a getter method named getXyz() or (for boolean properties only) isXyz(), and a setter method named setXyz(). 
>
>* Nested (name1.name2.name3) The first name element is used to select a property getter, as for simple references above. The object returned for this property is then consulted, using the same approach, for a property getter for a property named name2, and so on. The property value that is ultimately retrieved or modified is the one identified by the last name element. 
>
>* Indexed (name[index]) - The underlying property value is assumed to be an array, or this JavaBean is assumed to have indexed property getter and setter methods. The appropriate (zero-relative) entry in the array is selected. List objects are now also supported for read/write. You simply need to define a getter that returns the List 
>
>* Mapped (name(key)) - The JavaBean is assumed to have an property getter and setter methods with an additional attribute of type java.lang.String. 
>
>* Combined (name1.name2[index].name3(key)) - Combining mapped, nested, and indexed references is also supported
></quote>
>
>The question is: When and how to we add support for indexed and mapped properties? I guess that if we do, we should adopt the Commons BeanUtils style of specifying property paths for index and map access. This means that we wouldn't need additional methods in the BeanWrapper interface but rather just support for respective property paths in the BeanWrapperImpl implementation.
>
>Any thoughts on this? I've completely forgotten about these things in face of all the enterprise stuff we've been addressing lately ;-)
>
>Juergen
>
>
>-----Original Message-----
>From: SourceForge.net [mailto:no...@so...]
>Sent: Thursday, October 23, 2003 3:54 PM
>To: no...@so...
>Subject: [[W3-SPAM]] - [springframework - Help] Index properties in
>forms - Found word(s) receiving this email email in the Text body.
>
>
>
>Read and respond to this message at: 
>https://sourceforge.net/forum/message.php?msg_id=2251775
>By: breidenr
>
>I am using a SimpleFormController to help create an object using an HTTP form.
>Obviously, if my form object is a Vendor, that object has a setName(String)
>method, and my HTTP form has a field named "name", the Controller will try call
>Vendor.setName(String) and pass in the value from the form. This also goes for
>nested properties: address.setCity -> vendor.getAddress().setCity(String).
>
>My question is, is there any support for *indexed* properties? By that, I mean
>purchaseOrder[0].number -> ( (PurchaseOrder)
>vendor.getPurchaseOrders().get(0)).setNumber(). I know that some expression
>languages support something like this. IIRC, Struts has something like this,
>but it has a little kludgy.
>
>From what I can tell, nested porperies are supported by the Spring BeanWrapperImpl,
>but that is it. If this is correct and I want to implement nested properties,
>any suggestion as to the best route.
>
>Thanks.
>
>Ryan
>
>
>
>Read and respond to this message at: 
>https://sourceforge.net/forum/message.php?msg_id=2193984
>By: hogie
>
>Hi,
>
>
>
>If I have a command object that stores a collection and I want the data binder
>to populate that collection from the servlet request, how should I name the
>parameters in my servlet request?
>
>
>In Struts I can do field[index], but I can't see if the same is possible in
>Spring.  I see BeanWrapper.getIndexedPropertyValue() , but no set() equivalent.
>
>
>Many thanks,
>
>Mike.
>  
>

Re: [Springframework-developer] App Testing

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

On Tuesday 21 October 2003 12:49, Alef Arendsen (JTeam) wrote:

> > iv. Dependencies need careful consideration in how they may
> > affect test
> > results given a widespread test environment.  The database
> > problem has
> > already been remarked upon, local dependencies such as db
> > drivers, different
> > versions of libraries in the lib/ext (or equivalent)
> > directory of the server
> > installation and even possibly different JDK versions are
> > elements that will
> > have to be dealt with which wouldn't necessarily be issues in
> > a testing lab.
> > It may be possible to report some of this information within
> > the test results
> > where sensible values can be retreived.  Does anyone have
> > thoughts on this?
>
> JUnit does this automatically for the VM performing the test, doesn't
> it? As far as server configs are involved, are the tests going to move
> around across server that much to make it desirable to automate this?

What I was thinking was that it's likely that the same application tests 
will be run in totally different environments, dependent on who can donate 
the resources to do it.  What we can't do in such a situation, is isolate 
the application server as the only variable in the test.  If a test passes 
on your server running Tomcat (say) and fails on mine running WebSphere, we 
can't say very much about that failure with any certainty.  You may simply 
have had a slightly different version of some dependency that we're unable 
to ship as part of the test but which still influenced it.

If it were possible to have the tests verify version information for major 
components and report them as part of the results, we may later see 
patterns emerging in the failures.  On the other hand, it may be nothing of 
an issue if we can indeed include all the major components (JDK and J2EE 
server aside of course) for whatever tests we're running.  I suspect for 
the most part we will be able to.

-- 

Darren Davison
Public Key: http://www.davison.uk.net/key.jsp

[Springframework-developer] Re: Spring Framework 1.0 M2 released

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

VGhvbWFzLA0KIA0KQ2FuIHlvdSBwbGVhc2UgdXBkYXRlIHRoZSB3ZWJzaXRlIGFjY29yZGluZ2x5
LCBpbmNsdWRpbmcgdGhlIGRvY3VtZW50YXRpb24gYXJ0aWNsZXM/DQogDQpUaGFua3MsDQpKdWVy
Z2VuDQogDQogDQoNCgktLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tIA0KCVZvbjog
asO8cmdlbiBow7ZsbGVyIFt3ZXJrM0FUXSANCglHZXNlbmRldDogRnIgMjQuMTAuMjAwMyAwMTow
OCANCglBbjogc3ByaW5nZnJhbWV3b3JrLXVzZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0IA0KCUNj
OiBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldCANCglCZXRy
ZWZmOiBTcHJpbmcgRnJhbWV3b3JrIDEuMCBNMiByZWxlYXNlZA0KCQ0KCQ0KCUhpIFNwcmluZyBm
b2xsb3dlcnMsDQoJIA0KCUknbSBwbGVhc2VkIHRvIGFubm91bmNlIHRoYXQgd2UndmUganVzdCBy
ZWxlYXNlZCAxLjAgTTIsIHRoZSBzZWNvbmQgbWlsZXN0b25lIHJlbGVhc2UgdG93YXJkcyAxLjAg
YW5kIGZvdXJ0aCBwdWJsaWMgcmVsZWFzZSBpbiB0b3RhbC4gSXQgY29udGFpbnMgbnVtZXJvdXMg
YnVnIGZpeGVzIGFuZCBuZXcgZmVhdHVyZXM7IHNlZSB0aGUgY2hhbmdlIGxvZyBmb3IgZGV0YWls
cy4NCgkgDQoJQSBtYWpvciBjaGFuZ2UgaW4gdGVybXMgb2Ygc2FtcGxlcyBpcyB0aGF0IFBldGNs
aW5pYyBpcyBub3cgYXZhaWxhYmxlIGluIGFsdGVybmF0aXZlIGltcGxlbWVudGF0aW9ucyBmb3Ig
SkRCQyBhbmQgSGliZXJuYXRlOyB0aGVyZWZvcmUsIHRoZSBtaW5pbXVtIEhpYmVybmF0ZSBqYXJz
IGFyZSBub3cgaW5jbHVkZWQgaW4gdGhlIGRpc3RyaWJ1dGlvbi4gRnVydGhlcm1vcmUsIHRoZSBz
a2VsZXRvbnMgaGF2ZSBiZWVuIHJlcGFja2FnZWQgaW50byAid2ViYXBwLW1pbmltYWwiIGFuZCAi
d2ViYXBwLXR5cGljYWwiLCB0aGUgbGF0dGVyIHdpdGggbXVsdGlwbGUgYXBwbGljYXRpb24gY29u
dGV4dCBjb25maWd1cmF0aW9ucy4NCgkgDQoJQW4gaW1wb3J0YW50IGNoYW5nZSBpbiByZWNvbW1l
bmRhdGlvbiBpcyBmb3IgdGhlIDxyZWYgLi4uLz4gdGFnIGluIFhNTCBiZWFuIGRlZmluaXRpb25z
OiA8cmVmIGJlYW49Ii4uLiIvPiBpcyBub3cgYSBnZW5lcmFsIHJlZmVyZW5jZSB0byBhbnkgYmVh
biBuYW1lIGluIHRoZSBjb250ZXh0LCB3aGlsZSA8cmVmIGxvY2FsPSIuLi4iLz4gcmVmZXJlbmNl
cyBhIGJlYW4gaWQgaW4gdGhlIHNhbWUgWE1MIGZpbGUgKGFsbG93aW5nIGZvciB2YWxpZGF0aW9u
IGJ5IHRoZSBYTUwgcGFyc2VyKS4gPHJlZiBleHRlcm5hbD0iLi4uIi8+IGlzIGRlcHJlY2F0ZWQg
bm93OyBpdCBiZWhhdmVzIHRoZSBzYW1lIGFzIDxyZWYgYmVhbj0iLi4uIi8+IGZvciB0aGUgdGlt
ZSBiZWluZy4gDQoJIA0KCVNvIGNvbnNpZGVyIDxyZWYgYmVhbj0iLi4uIi8+IGFzIHRoZSBnZW5l
cmFsIHJlZmVyZW5jZSBub3csIG5vIG1hdHRlciBpZiBsb2NhbCBvciBpbiBhIHBhcmVudCBjb250
ZXh0LCBhbmQgPHJlZiBsb2NhbD0iLi4uIi8+IGFzIHRoZSBvcHRpb25hbCBvbmUgZm9yIHN0cm9u
ZyB2YWxpZGF0aW9uIGluIHRoZSBsb2NhbCBYTUwgZmlsZS4gQWxsIGV4aXN0aW5nIGJlYW4gZGVm
aW5pdGlvbnMgd2lsbCBzdGlsbCB3b3JrLCBhbHRob3VnaCB3ZSByZWNvbW1lbmQgdG8gcmVwbGFj
ZSA8cmVmIGV4dGVybmFsPSIuLi4iLz4gdGFncyB3aXRoIDxyZWYgYmVhbj0iLi4uIi8+Lg0KCSAN
CglGaW5hbGx5LCBJJ2QgbGlrZSB0byBub3RlIG9uZSBtaW5vciBpbmNvbXBhdGlibGUgQVBJIGNo
YW5nZTogQWJzdHJhY3RGb3JtQ29udHJvbGxlcidzIGZvcm1lciAicHJvY2Vzc1N1Ym1pdCIgbWV0
aG9kIGlzIG5vdyBjYWxsZWQgInByb2Nlc3NGb3JtU3VibWlzc2lvbiIgdG8gYXZvaWQgY29uZnVz
aW9uIHdpdGggdGhlICJvblN1Ym1pdCIgY2FsbGJhY2sgb2YgU2ltcGxlRm9ybUNvbnRyb2xsZXIu
IFRoaXMgd2lsbCBvbmx5IGFmZmVjdCB5b3UgaWYgeW91IGhhdmUgc3ViY2xhc3NlZCBBYnN0cmFj
dEZvcm1Db250cm9sbGVyIGRpcmVjdGx5OyBzaW1wbHkgcmVuYW1lIHlvdXIgaW1wbGVtZW50YXRp
b24gbWV0aG9kIHRoZW4uDQoJIA0KCVJlZ2FyZHMsDQoJSnVlcmdlbg0KDQo=

[Springframework-developer] Spring Framework 1.0 M2 released

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

SGkgU3ByaW5nIGZvbGxvd2VycywNCiANCkknbSBwbGVhc2VkIHRvIGFubm91bmNlIHRoYXQgd2Un
dmUganVzdCByZWxlYXNlZCAxLjAgTTIsIHRoZSBzZWNvbmQgbWlsZXN0b25lIHJlbGVhc2UgdG93
YXJkcyAxLjAgYW5kIGZvdXJ0aCBwdWJsaWMgcmVsZWFzZSBpbiB0b3RhbC4gSXQgY29udGFpbnMg
bnVtZXJvdXMgYnVnIGZpeGVzIGFuZCBuZXcgZmVhdHVyZXM7IHNlZSB0aGUgY2hhbmdlIGxvZyBm
b3IgZGV0YWlscy4NCiANCkEgbWFqb3IgY2hhbmdlIGluIHRlcm1zIG9mIHNhbXBsZXMgaXMgdGhh
dCBQZXRjbGluaWMgaXMgbm93IGF2YWlsYWJsZSBpbiBhbHRlcm5hdGl2ZSBpbXBsZW1lbnRhdGlv
bnMgZm9yIEpEQkMgYW5kIEhpYmVybmF0ZTsgdGhlcmVmb3JlLCB0aGUgbWluaW11bSBIaWJlcm5h
dGUgamFycyBhcmUgbm93IGluY2x1ZGVkIGluIHRoZSBkaXN0cmlidXRpb24uIEZ1cnRoZXJtb3Jl
LCB0aGUgc2tlbGV0b25zIGhhdmUgYmVlbiByZXBhY2thZ2VkIGludG8gIndlYmFwcC1taW5pbWFs
IiBhbmQgIndlYmFwcC10eXBpY2FsIiwgdGhlIGxhdHRlciB3aXRoIG11bHRpcGxlIGFwcGxpY2F0
aW9uIGNvbnRleHQgY29uZmlndXJhdGlvbnMuDQogDQpBbiBpbXBvcnRhbnQgY2hhbmdlIGluIHJl
Y29tbWVuZGF0aW9uIGlzIGZvciB0aGUgPHJlZiAuLi4vPiB0YWcgaW4gWE1MIGJlYW4gZGVmaW5p
dGlvbnM6IDxyZWYgYmVhbj0iLi4uIi8+IGlzIG5vdyBhIGdlbmVyYWwgcmVmZXJlbmNlIHRvIGFu
eSBiZWFuIG5hbWUgaW4gdGhlIGNvbnRleHQsIHdoaWxlIDxyZWYgbG9jYWw9Ii4uLiIvPiByZWZl
cmVuY2VzIGEgYmVhbiBpZCBpbiB0aGUgc2FtZSBYTUwgZmlsZSAoYWxsb3dpbmcgZm9yIHZhbGlk
YXRpb24gYnkgdGhlIFhNTCBwYXJzZXIpLiA8cmVmIGV4dGVybmFsPSIuLi4iLz4gaXMgZGVwcmVj
YXRlZCBub3c7IGl0IGJlaGF2ZXMgdGhlIHNhbWUgYXMgPHJlZiBiZWFuPSIuLi4iLz4gZm9yIHRo
ZSB0aW1lIGJlaW5nLiANCiANClNvIGNvbnNpZGVyIDxyZWYgYmVhbj0iLi4uIi8+IGFzIHRoZSBn
ZW5lcmFsIHJlZmVyZW5jZSBub3csIG5vIG1hdHRlciBpZiBsb2NhbCBvciBpbiBhIHBhcmVudCBj
b250ZXh0LCBhbmQgPHJlZiBsb2NhbD0iLi4uIi8+IGFzIHRoZSBvcHRpb25hbCBvbmUgZm9yIHN0
cm9uZyB2YWxpZGF0aW9uIGluIHRoZSBsb2NhbCBYTUwgZmlsZS4gQWxsIGV4aXN0aW5nIGJlYW4g
ZGVmaW5pdGlvbnMgd2lsbCBzdGlsbCB3b3JrLCBhbHRob3VnaCB3ZSByZWNvbW1lbmQgdG8gcmVw
bGFjZSA8cmVmIGV4dGVybmFsPSIuLi4iLz4gdGFncyB3aXRoIDxyZWYgYmVhbj0iLi4uIi8+Lg0K
IA0KRmluYWxseSwgSSdkIGxpa2UgdG8gbm90ZSBvbmUgbWlub3IgaW5jb21wYXRpYmxlIEFQSSBj
aGFuZ2U6IEFic3RyYWN0Rm9ybUNvbnRyb2xsZXIncyBmb3JtZXIgInByb2Nlc3NTdWJtaXQiIG1l
dGhvZCBpcyBub3cgY2FsbGVkICJwcm9jZXNzRm9ybVN1Ym1pc3Npb24iIHRvIGF2b2lkIGNvbmZ1
c2lvbiB3aXRoIHRoZSAib25TdWJtaXQiIGNhbGxiYWNrIG9mIFNpbXBsZUZvcm1Db250cm9sbGVy
LiBUaGlzIHdpbGwgb25seSBhZmZlY3QgeW91IGlmIHlvdSBoYXZlIHN1YmNsYXNzZWQgQWJzdHJh
Y3RGb3JtQ29udHJvbGxlciBkaXJlY3RseTsgc2ltcGx5IHJlbmFtZSB5b3VyIGltcGxlbWVudGF0
aW9uIG1ldGhvZCB0aGVuLg0KIA0KUmVnYXJkcywNCkp1ZXJnZW4NCg==

RE: [Springframework-developer] Documentation

[Mark P. <mar...@co...>]

What system does Hibernate use?

If we were going to use maven just for the docs, on the surface forrest
looks like a more appropriate document centric solution.

- Mark


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of Colin Sampaleanu
Sent: Tuesday, October 21, 2003 9:39 AM
To: al...@jt...
Cc: 'Rod Johnson'; 'Spring Developers'
Subject: Re: [Springframework-developer] Documentation


Aside from doing something homebrew, the other choice for documentation 
is probably Forrest, which I've never used:
  http://xml.apache.org/forrest/


Alef Arendsen (JTeam) wrote:

>Well, I don't really like Maven for _building_ software. For putting 
>out documentation though, I think it's quite nice...
>
>Alef
>
>
>  
>
>>-----Oorspronkelijk bericht-----
>>Van: spr...@li...
>>[mailto:spr...@li...]
>> Namens Colin Sampaleanu
>>Verzonden: Thursday, October 16, 2003 7:16 PM
>>Aan: Rod Johnson
>>CC: 'Spring Developers'
>>Onderwerp: Re: [Springframework-developer] Documentation
>>
>>
>>I actually have a lot of experience with Maven, having
>>tinkered with it 
>>a bunch over the last year (unfortunately, the multiproject support, 
>>where I think Maven becomes the most useful (along with the 
>>docs) to me, 
>>is still broken in some respects (property and repository 
>>overrides, for 
>>one), but that would not have an effect on Spring.
>>
>>If there is consensus on this, I am willing to put in some time to
>>finish this up, as necessary.
>>
>>
>>Rod Johnson wrote:
>>
>>    
>>
>>>I believe Luke Tayler did a Maven build script which works. So we
>>>certainly have a starting point.
>>>
>>>Rod
>>>
>>>----- Original Message -----
>>>From: "Colin Sampaleanu" <col...@ex...>
>>>To: "'Spring Developers'"
>>>      
>>>
>><spr...@li...>
>>    
>>
>>>Sent: Thursday, October 16, 2003 5:17 PM
>>>Subject: Re: [Springframework-developer] Documentation
>>>
>>>
>>> 
>>>
>>>>From my point of view, while of course there is a general need for
>>>      
>>>
>>>>more documentation and samples, what would also be of some
>>>>        
>>>>
>>use is some
>>    
>>
>>>>general infrastructure for producing consistent and relatively
>>>>professional looking docs and a website. I am not a big fan 
>>>>        
>>>>
>>of Maven
>>    
>>
>>>>generated websites with nothing in them, but on the other hand, if
>>>>people are willing to write documentation, Maven (and other 
>>>>alternatives like Forrest) make it pretty easy to put out 
>>>>documentation without having to worry too much about the look and 
>>>>feel, linking it into the site, etc.
>>>>
>>>>W/regards to the possibility of using Maven, one option would be to
>>>>use it just for doc generation, if doing the entire build 
>>>>        
>>>>
>>with it is
>>    
>>
>>>>too onerous. This approach has been used by other projects...
>>>>
>>>>Regards,
>>>>Colin
>>>>
>>>>Alef Arendsen (JTeam) wrote:
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>Hi all,
>>>>>
>>>>>Since I am busy closing 2002's financial year (doing all the
>>>>>accounting and stuff; I never should have started a company :), I 
>>>>>desperately need some things I can do when I'm totally sick of all 
>>>>>those numbers and spreadsheets. No internal projects here, 
>>>>>          
>>>>>
>>so I was
>>    
>>
>>>>>wondering if there already is a plan for how to improve our
>>>>>documentation base or if there are if there other important things 
>>>>>that need to be addressed.
>>>>>
>>>>>Juergen, other people, any thoughts?
>>>>>
>>>>>Thanx,
>>>>>
>>>>>Alef
>>>>>          
>>>>>




-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations Here's your
chance to show off your extensive product knowledge We want to know what
you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] FW: [springframework - Help] Index properties in forms

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

Everybody,

Seems like we've got two people inquiring for indexed property support. =
The second already dates back to mid-September :-(

I've just rechecked the BeanWrapper implementation and discovered that =
there is no proper support for indexed properties yet. The existing =
getIndexedProperty method was not complete (e.g. no support for nesting) =
and untested (no unit test covered it), so I've decided to remove it for =
the time being (for 1.0 M2). It just confused both of those guys that =
were looking for indexed property support.

Jakarta Commons BeanUtils does support nested and mapped properties, =
quoting from the javadocs of their PropertyUtils class:

<quote>
For the purposes of this class, five formats for referencing a =
particular property value of a bean are defined, with the layout of an =
identifying String in parentheses:=20

* Simple (name) - The specified name identifies an individual property =
of a particular JavaBean. The name of the actual getter or setter method =
to be used is determined using standard JavaBeans instrospection, so =
that (unless overridden by a BeanInfo class, a property named "xyz" will =
have a getter method named getXyz() or (for boolean properties only) =
isXyz(), and a setter method named setXyz().=20

* Nested (name1.name2.name3) The first name element is used to select a =
property getter, as for simple references above. The object returned for =
this property is then consulted, using the same approach, for a property =
getter for a property named name2, and so on. The property value that is =
ultimately retrieved or modified is the one identified by the last name =
element.=20

* Indexed (name[index]) - The underlying property value is assumed to be =
an array, or this JavaBean is assumed to have indexed property getter =
and setter methods. The appropriate (zero-relative) entry in the array =
is selected. List objects are now also supported for read/write. You =
simply need to define a getter that returns the List=20

* Mapped (name(key)) - The JavaBean is assumed to have an property =
getter and setter methods with an additional attribute of type =
java.lang.String.=20

* Combined (name1.name2[index].name3(key)) - Combining mapped, nested, =
and indexed references is also supported
</quote>

The question is: When and how to we add support for indexed and mapped =
properties? I guess that if we do, we should adopt the Commons BeanUtils =
style of specifying property paths for index and map access. This means =
that we wouldn't need additional methods in the BeanWrapper interface =
but rather just support for respective property paths in the =
BeanWrapperImpl implementation.

Any thoughts on this? I've completely forgotten about these things in =
face of all the enterprise stuff we've been addressing lately ;-)

Juergen


-----Original Message-----
From: SourceForge.net [mailto:no...@so...]
Sent: Thursday, October 23, 2003 3:54 PM
To: no...@so...
Subject: [[W3-SPAM]] - [springframework - Help] Index properties in
forms - Found word(s) receiving this email email in the Text body.



Read and respond to this message at:=20
https://sourceforge.net/forum/message.php?msg_id=3D2251775
By: breidenr

I am using a SimpleFormController to help create an object using an HTTP =
form.
Obviously, if my form object is a Vendor, that object has a =
setName(String)
method, and my HTTP form has a field named "name", the Controller will =
try call
Vendor.setName(String) and pass in the value from the form. This also =
goes for
nested properties: address.setCity -> =
vendor.getAddress().setCity(String).

My question is, is there any support for *indexed* properties? By that, =
I mean
purchaseOrder[0].number -> ( (PurchaseOrder)
vendor.getPurchaseOrders().get(0)).setNumber(). I know that some =
expression
languages support something like this. IIRC, Struts has something like =
this,
but it has a little kludgy.

From what I can tell, nested porperies are supported by the Spring =
BeanWrapperImpl,
but that is it. If this is correct and I want to implement nested =
properties,
any suggestion as to the best route.

Thanks.

Ryan



Read and respond to this message at:=20
https://sourceforge.net/forum/message.php?msg_id=3D2193984
By: hogie

Hi,



If I have a command object that stores a collection and I want the data =
binder
to populate that collection from the servlet request, how should I name =
the
parameters in my servlet request?


In Struts I can do field[index], but I can't see if the same is possible =
in
Spring.  I see BeanWrapper.getIndexedPropertyValue() , but no set() =
equivalent.


Many thanks,

Mike.

Re: [Springframework-developer] Message history

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

On Thursday 23 October 2003 11:57, Cameron Braid wrote:

> I couldn't find a way to request archived messages from the mailing list
> server.


http://sourceforge.net/mail/?group_id=73357

has archives of both lists which are searchable.

hth,

-- 

Darren Davison
Public Key: http://www.davison.uk.net/key.jsp

[Springframework-developer] Message history

[Cameron B. <ca...@da...>]

I have just subscribed to this mailing list, and I was won...
anyone who has the last 30 days of emails in mbox format could zip em up
and sent them to me.

I really like having a copy of the old emails in my history.
 
I couldn't find a way to request archived messages from the mailing list
server.

Cheers,

Cameron
 

Re: [Springframework-developer] App Testing

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

On Wednesday 22 October 2003 14:18, Rod Johnson wrote:

> I agree. With JBoss/Tomcat I'd unzip it. Also Orion if we wanted to. I
> don't know much about WebSphere configuration. WebLogic has nice clean
> separate server config directories, so we should be able to handle it at
> that level.

WebSphere will probably prove too tricky.  It requires an RDBMS to store its 
config per WebSphere Domain (cluster) and will install DB2 for the purpose 
if you don't have something already available for the job.  It's not beyond 
the realms of possibility to script it all, but it's a greatly diminished 
return for the effort.

> I think a first goal might be Tomcat + HSQL. Easy to do the "just unzip"
> approach and meets the basic goal of verifying that we didn't break
> everyone's web app in changes today.

I'll start along these lines.

Regards,


-- 

Darren Davison
Public Key: http://www.davison.uk.net/key.jsp

[Springframework-developer] RE: Class file manipulation with BCEL safe?

[Chris N. <ch...@si...>]

Alef Arendsen (JTeam) wrote:
> In a Spring Validator, I'm retrieving the attributes using
> BcelAttributes and then inspect the class... Works kind of neat,
>  
> but still, won't this conflict with the ASM way hibernate does things?

In short, no. Hibernate uses CGLIB mostly for generating lazy-loading
proxies. Since the proxies are subclasses of the mapped classes, you should
be able to retrieve your attribute data from the superclass of the proxy.
You can tell a proxy from a non proxy by seeing if your object is an
instanceof net.sf.cglib.Factory.

If a framework ends up using CGLIB or something like it to actually
transform your classes at build time or run time you will have to be
careful. It is likely that any attributes in the original class would be
stripped out. For this reason I would suggest storing the attribute
metadata outside of the classfile. Personally I have had good success using
QDox to parse the source files, generating a .attributes properties file
per class.

Chris

RE: [Springframework-developer] Class file manipulation with BCEL safe?

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

Yeah of course. I've been working with the Struts validation framework
for years and I'm getting sick of it. So I'm trying to incorporate the
validation information as source level metadata:
 
/**
 * @jteam.validation.MaxLength ( 1 )
 * @jteam.validation.RequiredIfEmpty ( anotherProperty )
 * @jteam.validation.Unique ( )
 */
public String setName();
 
In a Spring Validator, I'm retrieving the attributes using
BcelAttributes and then inspect the class... Works kind of neat,
 
but still, won't this conflict with the ASM way hibernate does things?
 
alef
 

-----Oorspronkelijk bericht-----
Van: spr...@li...
[mailto:spr...@li...] Namens
Kopylenko, Dmitry
Verzonden: Tuesday, October 21, 2003 8:16 PM
Aan: 'spr...@li...'
CC: 'al...@jt...'
Onderwerp: RE: [Springframework-developer] Class file manipulation with
BCEL safe?


Alef,
 
just out of curiosity, can you explain what you're trying to do, may be
with some examples.
 
Regards,
Dmitriy.
 

-----Original Message-----
From: Alef Arendsen (JTeam) [mailto:al...@jt...] 
Sent: Tuesday, October 21, 2003 11:41 AM
To: 'Spring Developers'
Subject: [Springframework-developer] Class file manipulation with BCEL
safe?



Hi all, 

I'm playing around with the source level metadata stuff and it looks
really cool! I'm trying to implement some of our validation features
using it and have successfully generated some classes using the
MetaDataCompiler. However, I was wondering how BCEL affects the classes
and if this is not going to bring us major problem when for instance
serializing classes and stuff...

Also, I once heard Hibernate uses asm and stuff, won't this bring any
conflicts? I'm to use the functionality in our domain model...

Might not be the right place to ask those kind of quesitons, but
anyway... 

Thanx, 

Alef 

P.s. Joost, one of our people and the main backend guy here has moved to
Spring completely by the way. He just said: hmmmm, it seems like those
spring guys are actually doing a good job (it's really something if
sceptic joost says something like that :-)

== 
JTeam B.V. 
Donker Curtiusstraat 7-412 
1051 JL  Amsterdam 
T: +31 20 486 20 36 
M: +31 6 24 11 1996 
F: +31 84 837 00 00 
E: al...@jt... 
W:  <http://www.jteam.nl> http://www.jteam.nl