springframework-developer — Spring Framework developers list

[Springframework-developer] Streaming (InputStream) support for HttpInvoker

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

I've extended Spring's HttpInvoker to provide support for InputStream 
parameters and return values for remote service methods.  I've posted 
detailed information along with sources and unit tests in this JIRA issue: 
http://opensource.atlassian.com/projects/spring/browse/SPR-1223

To elaborate a little: this allows you to define a service method to take an 
InputStream as a parameter or return an InputStream as a return value (or 
both) and Spring will take care of ensuring the InputStream is streamed 
across the wire. Of course, the major reason for doing this is to handle 
large amounts of data without needing to load all the data into memory first, 
so care is taken to ensure that the InputStream is not fully buffered into 
memory.
See the JIRA issue for more information.

  - Andy

[Springframework-developer] FAILED BUILD: sparc-solaris1 (last 30 lines included)

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

1123746011
FAILED
    [junit] org.springframework.beans.factory.BeanDefinitionStoreException: Error registering bean with name 'testBean' defined in class path resource [org/springframework/jmx/export/naming/lazyNaming.xml]: Bean class [org.springframework.jmx.export.annotation.AnnotationTestBean] not found; nested exception is java.lang.ClassNotFoundException: org.springframework.jmx.export.annotation.AnnotationTestBean
    [junit] java.lang.ClassNotFoundException: org.springframework.jmx.export.annotation.AnnotationTestBean
    [junit] 	at java.net.URLClassLoader$1.run(URLClassLoader.java:198)
    [junit] 	at java.security.AccessController.doPrivileged(Native Method)
    [junit] 	at java.net.URLClassLoader.findClass(URLClassLoader.java:186)
    [junit] 	at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
    [junit] 	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265)
    [junit] 	at java.lang.ClassLoader.loadClass(ClassLoader.java:262)
    [junit] 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:322)
    [junit] 	at java.lang.Class.forName0(Native Method)
    [junit] 	at java.lang.Class.forName(Class.java:207)
    [junit] 	at org.springframework.util.ClassUtils.forName(ClassUtils.java:88)
    [junit] 	at org.springframework.beans.factory.support.BeanDefinitionReaderUtils.createBeanDefinition(BeanDefinitionReaderUtils.java:64)
    [junit] 	at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.parseBeanDefinitionElement(DefaultXmlBeanDefinitionParser.java:369)
    [junit] 	at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.parseBeanDefinitionElement(DefaultXmlBeanDefinitionParser.java:335)
    [junit] 	at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.parseBeanDefinitions(DefaultXmlBeanDefinitionParser.java:266)
    [junit] 	at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.registerBeanDefinitions(DefaultXmlBeanDefinitionParser.java:186)
    [junit] 	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:246)
    [junit] 	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:163)
    [junit] 	at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:125)
    [junit] 	at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:141)
    [junit] 	at org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:113)
    [junit] 	at org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:81)
    [junit] 	at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:89)
    [junit] 	at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:267)
    [junit] 	at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:81)
    [junit] 	at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:66)
    [junit] 	at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:57)
    [junit] 	at org.springframework.jmx.export.naming.MetadataNamingStrategyTests.testWithLazyInit(MetadataNamingStrategyTests.java:59)


This is an automated mail from one of the SF Compile Farm machines.  
The machine name noted in the subject encountered a failure building
or running the Spring test suite.  The last few lines of the output
were included for info.

NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.

See http://springframework.sourceforge.net/test/ for further
information.

[Springframework-developer] FAILED BUILD: x86-solaris1 (last 30 lines included)

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

1123742112
FAILED
    [junit] org.springframework.beans.factory.BeanDefinitionStoreException: Error registering bean with name 'testBean' defined in class path resource [org/springframework/jmx/export/naming/lazyNaming.xml]: Bean class [org.springframework.jmx.export.annotation.AnnotationTestBean] not found; nested exception is java.lang.ClassNotFoundException: org.springframework.jmx.export.annotation.AnnotationTestBean
    [junit] java.lang.ClassNotFoundException: org.springframework.jmx.export.annotation.AnnotationTestBean
    [junit] 	at java.net.URLClassLoader$1.run(URLClassLoader.java:198)
    [junit] 	at java.security.AccessController.doPrivileged(Native Method)
    [junit] 	at java.net.URLClassLoader.findClass(URLClassLoader.java:186)
    [junit] 	at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
    [junit] 	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:272)
    [junit] 	at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
    [junit] 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
    [junit] 	at java.lang.Class.forName0(Native Method)
    [junit] 	at java.lang.Class.forName(Class.java:217)
    [junit] 	at org.springframework.util.ClassUtils.forName(ClassUtils.java:88)
    [junit] 	at org.springframework.beans.factory.support.BeanDefinitionReaderUtils.createBeanDefinition(BeanDefinitionReaderUtils.java:64)
    [junit] 	at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.parseBeanDefinitionElement(DefaultXmlBeanDefinitionParser.java:369)
    [junit] 	at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.parseBeanDefinitionElement(DefaultXmlBeanDefinitionParser.java:335)
    [junit] 	at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.parseBeanDefinitions(DefaultXmlBeanDefinitionParser.java:266)
    [junit] 	at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.registerBeanDefinitions(DefaultXmlBeanDefinitionParser.java:186)
    [junit] 	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:246)
    [junit] 	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:163)
    [junit] 	at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:125)
    [junit] 	at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:141)
    [junit] 	at org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:113)
    [junit] 	at org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:81)
    [junit] 	at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:89)
    [junit] 	at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:267)
    [junit] 	at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:81)
    [junit] 	at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:66)
    [junit] 	at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:57)
    [junit] 	at org.springframework.jmx.export.naming.MetadataNamingStrategyTests.testWithLazyInit(MetadataNamingStrategyTests.java:59)


This is an automated mail from one of the SF Compile Farm machines.  
The machine name noted in the subject encountered a failure building
or running the Spring test suite.  The last few lines of the output
were included for info.

NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.

See http://springframework.sourceforge.net/test/ for further
information.

[Springframework-developer] FAILED BUILD: sparc-solaris2 (last 30 lines included)

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

1123738624
FAILED
    [junit] org.springframework.beans.factory.BeanDefinitionStoreException: Error registering bean with name 'testBean' defined in class path resource [org/springframework/jmx/export/naming/lazyNaming.xml]: Bean class [org.springframework.jmx.export.annotation.AnnotationTestBean] not found; nested exception is java.lang.ClassNotFoundException: org.springframework.jmx.export.annotation.AnnotationTestBean
    [junit] java.lang.ClassNotFoundException: org.springframework.jmx.export.annotation.AnnotationTestBean
    [junit] 	at java.net.URLClassLoader$1.run(URLClassLoader.java:198)
    [junit] 	at java.security.AccessController.doPrivileged(Native Method)
    [junit] 	at java.net.URLClassLoader.findClass(URLClassLoader.java:186)
    [junit] 	at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
    [junit] 	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265)
    [junit] 	at java.lang.ClassLoader.loadClass(ClassLoader.java:262)
    [junit] 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:322)
    [junit] 	at java.lang.Class.forName0(Native Method)
    [junit] 	at java.lang.Class.forName(Class.java:207)
    [junit] 	at org.springframework.util.ClassUtils.forName(ClassUtils.java:88)
    [junit] 	at org.springframework.beans.factory.support.BeanDefinitionReaderUtils.createBeanDefinition(BeanDefinitionReaderUtils.java:64)
    [junit] 	at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.parseBeanDefinitionElement(DefaultXmlBeanDefinitionParser.java:369)
    [junit] 	at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.parseBeanDefinitionElement(DefaultXmlBeanDefinitionParser.java:335)
    [junit] 	at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.parseBeanDefinitions(DefaultXmlBeanDefinitionParser.java:266)
    [junit] 	at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.registerBeanDefinitions(DefaultXmlBeanDefinitionParser.java:186)
    [junit] 	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:246)
    [junit] 	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:163)
    [junit] 	at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:125)
    [junit] 	at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:141)
    [junit] 	at org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:113)
    [junit] 	at org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:81)
    [junit] 	at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:89)
    [junit] 	at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:267)
    [junit] 	at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:81)
    [junit] 	at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:66)
    [junit] 	at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:57)
    [junit] 	at org.springframework.jmx.export.naming.MetadataNamingStrategyTests.testWithLazyInit(MetadataNamingStrategyTests.java:59)


This is an automated mail from one of the SF Compile Farm machines.  
The machine name noted in the subject encountered a failure building
or running the Spring test suite.  The last few lines of the output
were included for info.

NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.

See http://springframework.sourceforge.net/test/ for further
information.

[Springframework-developer] FAILED BUILD: x86-linux2 (last 30 lines included)

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

1123724412
FAILED
    [junit] org.springframework.beans.factory.BeanDefinitionStoreException: Error registering bean with name 'testBean' defined in class path resource [org/springframework/jmx/export/naming/lazyNaming.xml]: Bean class [org.springframework.jmx.export.annotation.AnnotationTestBean] not found; nested exception is java.lang.ClassNotFoundException: org.springframework.jmx.export.annotation.AnnotationTestBean
    [junit] java.lang.ClassNotFoundException: org.springframework.jmx.export.annotation.AnnotationTestBean
    [junit] 	at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
    [junit] 	at java.security.AccessController.doPrivileged(Native Method)
    [junit] 	at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
    [junit] 	at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
    [junit] 	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)
    [junit] 	at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
    [junit] 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
    [junit] 	at java.lang.Class.forName0(Native Method)
    [junit] 	at java.lang.Class.forName(Class.java:219)
    [junit] 	at org.springframework.util.ClassUtils.forName(ClassUtils.java:88)
    [junit] 	at org.springframework.beans.factory.support.BeanDefinitionReaderUtils.createBeanDefinition(BeanDefinitionReaderUtils.java:64)
    [junit] 	at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.parseBeanDefinitionElement(DefaultXmlBeanDefinitionParser.java:369)
    [junit] 	at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.parseBeanDefinitionElement(DefaultXmlBeanDefinitionParser.java:335)
    [junit] 	at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.parseBeanDefinitions(DefaultXmlBeanDefinitionParser.java:266)
    [junit] 	at org.springframework.beans.factory.xml.DefaultXmlBeanDefinitionParser.registerBeanDefinitions(DefaultXmlBeanDefinitionParser.java:186)
    [junit] 	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:246)
    [junit] 	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:163)
    [junit] 	at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:125)
    [junit] 	at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:141)
    [junit] 	at org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:113)
    [junit] 	at org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:81)
    [junit] 	at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:89)
    [junit] 	at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:267)
    [junit] 	at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:81)
    [junit] 	at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:66)
    [junit] 	at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:57)
    [junit] 	at org.springframework.jmx.export.naming.MetadataNamingStrategyTests.testWithLazyInit(MetadataNamingStrategyTests.java:59)


This is an automated mail from one of the SF Compile Farm machines.  
The machine name noted in the subject encountered a failure building
or running the Spring test suite.  The last few lines of the output
were included for info.

NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.

See http://springframework.sourceforge.net/test/ for further
information.

[Springframework-developer] spring build.324 Build Successful

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

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

Re: [Springframework-developer] build: spring-context-1.2.3.jar missing

[Steven D. <ste...@gm...>]

Okay, thanks. I didn't get it when updating from CVS but that's my bad.

On 8/10/05, Colin Sampaleanu <col...@ex...> wrote:
> Steven,
>=20
> It's there and has been for quite a while:
>  http://cvs.sourceforge.net/viewcvs.py/springframework/spring-projects/re=
pository/springframework/spring-context/jars/
>=20
>=20
> Steven Devijver wrote:
>=20
> >Hey,
> >
> >Apparently the spring-context jar in the build repository needs
> >updating. It currently stands at version 1.2.2 while 1.2.3 is required
> >by spring-binding.
> >
> >Steven
> >
> >
> >
>=20
>=20
> --
> Colin Sampaleanu
> Interface21 Principal Consultant
> Spring Training, Consulting and Support - "From the Source"
> http://www.springframework.com
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20


--=20
"If you want to be a different fish, you gotta jump out of the school."
-- Captain Beefheart

Re: [Springframework-developer] build: spring-context-1.2.3.jar missing

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

Steven,

It's there and has been for quite a while:
 http://cvs.sourceforge.net/viewcvs.py/springframework/spring-projects/repository/springframework/spring-context/jars/


Steven Devijver wrote:

>Hey,
>
>Apparently the spring-context jar in the build repository needs
>updating. It currently stands at version 1.2.2 while 1.2.3 is required
>by spring-binding.
>
>Steven
>
>  
>


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

[Springframework-developer] FAILED BUILD: ppc-osx2 (last 30 lines included)

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

1123704858
FAILED
Buildfile: build.xml

clean:
   [delete] Deleting directory /home/users/d/da/davison/checkouts/spring/target/ppc-osx2/classes
   [delete] Deleting directory /home/users/d/da/davison/checkouts/spring/target/ppc-osx2/test-classes
   [delete] Deleting directory /home/users/d/da/davison/checkouts/spring/target/ppc-osx2/mock-classes
   [delete] Deleting directory /home/users/d/da/davison/checkouts/spring/target/ppc-osx2/test-reports

This is an automated mail from one of the SF Compile Farm machines.  
The machine name noted in the subject encountered a failure building
or running the Spring test suite.  The last few lines of the output
were included for info.

NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.

See http://springframework.sourceforge.net/test/ for further
information.

[Springframework-developer] build: spring-context-1.2.3.jar missing

[Steven D. <ste...@gm...>]

Hey,

Apparently the spring-context jar in the build repository needs
updating. It currently stands at version 1.2.2 while 1.2.3 is required
by spring-binding.

Steven

--=20
"If you want to be a different fish, you gotta jump out of the school."
-- Captain Beefheart

[Springframework-developer] clarification on spring:transform tag

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

Hi,

 

I just wanted to pass this along, to see if a clarification could be
inserted in the spring:transform document - to note that spring:transform
should not be used to enclose any jsp body.  I was kind of running around in
circles a bit because I did something like this.

 

<spring:bind path="foo.bar">

            <spring:transform value="${status.value}" var-"valueString">

                        <c:out value="${valueString"/>

            </spring:transform>

</spring:bind>

 

And I was baffled for a while why I was getting no output, and no helpful
statements from the logs.  It wasn't until I walked thru the TransformTag
source and noticed that it was returning BODY_SKIP that I took a closer look
at the example jsp given in spring:transform document when I saw that the
transform tag is closed immediately (does not wrap the jsp in question).

 

So the example is indeed correct, but with virtually all other jsp tags
wrapping the affected JSP in question, it's easy to assume that
spring:transform works similarly, and I thought maybe it'd be helpful to
future users if a note was added to head off any confusion on that.   Just
my two cents.

 

-tim

[Springframework-developer] spring build.322 Build Fixed

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

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

[Springframework-developer] reg.springframework-developer@jhaile.fastmail.fm

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

We're getting tons of bounces from
   reg...@jh...
I think Rod or Jeurgen (project leads on the SF project) need to remove 
the address from the mailing list.

Colin

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

Re: [Springframework-developer] springmodules:Valang build fails

[Steven D. <ste...@gm...>]

Micheal,

You can put an & in front of the bean name of
ValangValidatorFactoryBean in the ref element to get the factory. See
here for more details:

http://static.springframework.org/spring/docs/1.2.x/reference/beans.html#d0=
e1686

Steven

On 7/27/05, Michael E. Moores <mm...@re...> wrote:
> thanks.  that is very helpful.
> my only problem left is that I can't set up a ValangValidatorFactoryBean
> as a bean property of type FactoryBean.
> org.springframework.beans.TypeMismatchException: Failed to convert
> property value of type
> [org.springmodules.validation.ValangValidatorFactoryBean$1] to required
> type [org.springframework.beans.factory.FactoryBean] for property
> 'chargeValidatorFactory'
>=20
> Steven Devijver wrote:
>=20
> > Did you already have a look at the language document on the Spring wiki=
?
> >
> > http://opensource.atlassian.com/confluence/spring/display/MODULES/Using=
+Valang+validator
> >
> > Steven
> >
> > On 7/27/05, *Michael E. Moores* <mm...@re...
> > <mailto:mm...@re...>> wrote:
> >
> >     nice work, i have been looking at the language.
> >     when Valang moves out of the sandbox, will there be a bit more java=
doc
> >     and (va)language "specs"?
> >     if i use this, my peers need to be confident we can fix problems
> >     and/or
> >     extend it.
> >
> >     Steven Devijver wrote:
> >
> >     >Micheal,
> >     >
> >     >Thanks for spotting this, I've checked in the updated class.
> >     >
> >     >Steven
> >     >
> >     >On 7/26/05, Michael E. Moores < mm...@re...
> >     <mailto:mm...@re...>> wrote:
> >     >
> >     >
> >     >>I checked out springmodules from cvs.dev.java.net
> >     <http://cvs.dev.java.net> and
> >     >>attempted to build the sandbox jar with "ant sandbox.jar ":
> >     >>
> >     >>    [javac]
> >     >>/home/mmoores/download/springmodulessandbox/springmodules/sandbox=
/src/org/springmodules/beans/factory/bfl/parser/BeanFactoryLanguageParser.j=
ava:171:
> >     >><anonymous
> >     >>org.springmodules.beans.factory.bfl.parser.BeanFactoryLanguagePar=
ser$6>
> >     >>is not abstract and does not override abstract method
> >     >>setFactoryMethod(java.lang.String) in
> >     >>org.springmodules.beans.factory.drivers.Bean
> >     >>    [javac]                         public void setAutowire(Strin=
g
> >     >>autowire) {
> >     >>    [javac]                                     ^
> >     >>    [javac] Note: * uses or overrides a deprecated API.
> >     >>    [javac] Note: Recompile with -Xlint:deprecation for details.
> >     >>    [javac] 1 error
> >     >>    [javac] 8 warnings
> >     >>
> >     >>BUILD FAILED
> >     >>
> >     >>
> >     >>
> >     >>-------------------------------------------------------
> >     >>SF.Net email is sponsored by: Discover Easy Linux Migration
> >     Strategies
> >     >>from IBM. Find simple to follow Roadmaps, straightforward article=
s,
> >     >>informative Webcasts and more! Get everything you need to get up =
to
> >     >>speed, fast.
> >     http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick
> >     <http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick>
> >     >>_______________________________________________
> >     >>Springframework-developer mailing list
> >     >>Spr...@li...
> >     <mailto:Spr...@li...>
> >     >>https://lists.sourceforge.net/lists/listinfo/springframework-deve=
loper
> >     >>
> >     >>
> >     >>
> >     >>
> >     >
> >     >
> >     >
> >     >
> >
> >
> >     -------------------------------------------------------
> >     SF.Net email is sponsored by: Discover Easy Linux Migration Strateg=
ies
> >     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=3D7477&alloc_id=3D16492&op=3Dclick
> >     <http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick>
> >     _______________________________________________
> >     Springframework-developer mailing list
> >     Spr...@li...
> >     <mailto:Spr...@li...>
> >     https://lists.sourceforge.net/lists/listinfo/springframework-develo=
per
> >
> >
> >
> >
> > --
> > "If you want to be a different fish, you gotta jump out of the school."
> > -- Captain Beefheart
>=20
>=20
>=20
> -------------------------------------------------------
> 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=3D7477&alloc_id=3D16492&op=3Dclic=
k
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20


--=20
"If you want to be a different fish, you gotta jump out of the school."
-- Captain Beefheart

[Springframework-developer] spring build.323 Build Successful

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

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

Re: [Springframework-developer] Re: Annotations

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

On the property name -> bean name topic: This is exactly what autowiring by
name does. Why do we need annotations for that? An annotation on bean
properties that says "I want to be wired with a bean of the same name as the
property" isn't really different from autowiring that bean by name.
Autowiring can even be specified at the <beans> level and by default simply
skips properties that it can't find a matching bean for, so annotations
aren't even more concise.

I strongly believe that putting arbitrary, concrete target bean names into
annotations is a bad idea. Expressing a dependency through the property name
and the service interface of the dependent bean should be perfectly
sufficient: This allows for autowiring by name respectively type. And of
course, there's always the option to explicitly specify the target bean name
in configuration, in particular for cases where autowiring would be
ambiguous.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Martin Kersten
Sent: Monday, August 08, 2005 2:55 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Re: Annotations

Hi ya,

>> Speaking as a non-Spring developer....(i.e. wait for Rod, Juergen, etc..
>> comments)...
>>
>> Is this something that you really want?   There are valid uses of
>> Annotations...(i.e. transactions, security)...
>> but I dont think its a good idea to use it for everything (i.e.  IoC)
>>
>> EJB3 is annotation-"crazy"... for lack of a better word.... I still 
>> really do not think @Inject is appropriate.
>
> Inject is probably one of the things I'm looking for. That is being 
> able to do the assembly level stuff using annotations. The reason that 
> we have the XML configuration file is because we can change assembly 
> level things easily (right?). However, this can just as easily be 
> achieved using annotations which retain code locality. Majority of 
> applications are pretty static in nature and there's no need to change 
> the assembly stuff once the app if finished. And if you do need to 
> change something you need to tear open the WAR archive anyways which 
> is not far from doing a full recompile.

It is an interesting topic. Annotations are highly interesting stuff. But I
dont know if the 'Annotation for everything' speech will hold in the future.
But it is still amazing how far you can push things with annotations (beside
the @SupressWarning and @Override annotations of cause (I dislike them)).

There is also something like a counter-movement  going on. Skip all the xml
/ IOC things and go for the hot cake first. For example Tapestry, Trails and
Rails mostly favour annotations instead of xml files or even hard-wire the
application within the code.

I find hard-wiring it, is the least preferable to do. But it is all we
always do. I always fail by getting where the border is. You know methods
are hardwired, some objects are hard-wired.
For the next granularity level (moduls being formed by collaborating
objects) I would clearly favour annotations. And on application level, I
strongly tend to favour xml.

The fun part is, that by having a complete annotation support, it would be
more relaxing for find the best way to wire everthing together.

Level     -> Type
Objects / Classes -> hard-wired
Packages/Modules/Layers -> hard + soft (Annotations mainly) Layers /
Application -> soft (XML + Annotation)

Where to apply which kind of wiring depends on the requirements. But as
nearly always, the test-cases are your saviour in the storm here. I - for
example - mostly push everything from hard-wired to soft to ease my
test-cases. That's all.

Using Spring I mostly go for either hard-wired or xml. I would like to go
for complete annotations first.

And about the introducing the logical names stuff to the code, I don't buy
this one fully. I guess I know what the implications are but it is like the
property names. Having a get/setPropertyName method introduces the logical
name propertyName of the property (which can even be virtual (logical)). So
for wiring we mostly end up with the class DomainModelService implicating
the logical name domainModelService for a service object.

So I think a annotation with that smart thinking, which works by referring
Classes rather than logical names (or better being able to derieve the names
from the class name) would be nice.
But I truely lack knowledge and experience here. It is just what I feel
would ease everyday's pain overhere... .

So I really would appreciate a near to complete annotation support being
able to substitute nearly all the xml-beans definition file(s) (as best as
possible).


Cheers,

Martin (Kersten)

>
>> I still think there will be some sort of level of configuration that 
>> you cannot get away from.
>
> Ofcourse.
>
> * Janne Kario
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO 
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle 
> Practices Agile & Plan-Driven Development * Managing Projects & Teams 
> * Testing & QA Security * Process Improvement & Measurement * 
> http://www.sqe.com/bsce5sf 
> _______________________________________________
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile &
Plan-Driven Development * Managing Projects & Teams * Testing & QA Security
* Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Re: Annotations

[Martin K. <Mar...@St...>]

Hi ya,

>> Speaking as a non-Spring developer....(i.e. wait for Rod, Juergen, etc..
>> comments)...
>>
>> Is this something that you really want?   There are valid uses of
>> Annotations...(i.e. transactions, security)...
>> but I dont think its a good idea to use it for everything (i.e.  IoC)
>>
>> EJB3 is annotation-"crazy"... for lack of a better word.... I still 
>> really
>> do not think @Inject is appropriate.
>
> Inject is probably one of the things I'm looking for. That is being able 
> to do the assembly level stuff using annotations. The reason that we have 
> the XML configuration file is because we can change assembly level things 
> easily (right?). However, this can just as easily be achieved using 
> annotations which retain code locality. Majority of applications are 
> pretty static in nature and there's no need to change the assembly stuff 
> once the app if finished. And if you do need to change something you need 
> to tear open the WAR archive anyways which is not far from doing a full 
> recompile.

It is an interesting topic. Annotations are highly interesting stuff. But
I dont know if the 'Annotation for everything' speech will hold in the
future. But it is still amazing how far you can push things with
annotations (beside the @SupressWarning and @Override annotations
of cause (I dislike them)).

There is also something like a counter-movement  going on. Skip
all the xml / IOC things and go for the hot cake first. For example
Tapestry, Trails and Rails mostly favour annotations instead of
xml files or even hard-wire the application within the code.

I find hard-wiring it, is the least preferable to do. But it is all
we always do. I always fail by getting where the border is. You
know methods are hardwired, some objects are hard-wired.
For the next granularity level (moduls being formed by
collaborating objects) I would clearly favour annotations. And
on application level, I strongly tend to favour xml.

The fun part is, that by having a complete annotation support,
it would be more relaxing for find the best way to wire everthing
together.

Level     -> Type
Objects / Classes -> hard-wired
Packages/Modules/Layers -> hard + soft (Annotations mainly)
Layers / Application -> soft (XML + Annotation)

Where to apply which kind of wiring depends on the
requirements. But as nearly always, the test-cases are your
saviour in the storm here. I - for example - mostly push
everything from hard-wired to soft to ease my test-cases. That's all.

Using Spring I mostly go for either hard-wired or xml. I would
like to go for complete annotations first.

And about the introducing the logical names stuff to the code, I don't
buy this one fully. I guess I know what the implications are but
it is like the property names. Having a get/setPropertyName method
introduces the logical name propertyName of the property (which
can even be virtual (logical)). So for wiring we mostly end up with
the class DomainModelService implicating the logical name
domainModelService for a service object.

So I think a annotation with that smart thinking, which works
by referring Classes rather than logical names (or better being
able to derieve the names from the class name) would be nice.
But I truely lack knowledge and experience here. It is
just what I feel would ease everyday's pain overhere... .

So I really would appreciate a near to complete annotation support
being able to substitute nearly all the xml-beans definition file(s)
(as best as possible).


Cheers,

Martin (Kersten)

>
>> I still think there will be some sort of level of configuration that you
>> cannot get away from.
>
> Ofcourse.
>
> * Janne Kario
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle 
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer 

Re: [Springframework-developer] spring Build Failed

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

It's MBeanClientInterceptorTests.testLazyConnectionToRemote() again.

I've added a catch clause to skip the remainder of that test if binding to
the local port failed (for whatever reason).

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
al...@in...
Sent: Monday, August 08, 2005 12:20 AM
To: spr...@li...
Subject: [Springframework-developer] spring Build Failed
Importance: High

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


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile &
Plan-Driven Development * Managing Projects & Teams * Testing & QA Security
* Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] spring Build Failed

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

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

Re: [Springframework-developer] spring Build Failed

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

Rob, could you please have a look at that?
MBeanClientInterceptorTests.testWithLazyConnectionToRemote seems to be
failing, which apparently has been added very recently.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
al...@in...
Sent: Sunday, August 07, 2005 12:23 AM
To: spr...@li...
Subject: [Springframework-developer] spring Build Failed
Importance: High

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


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile &
Plan-Driven Development * Managing Projects & Teams * Testing & QA Security
* Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] spring Build Failed

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

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

Re: [Springframework-developer] Annotations

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

The problem with dependency injection annotations is that you're coding some
level of symbolic name into your Java classes: either JNDI names or logical
names from some container's namespace. Neither of the two belongs in there,
as it introduces a logical dependency on a naming system that really
shouldn't be of any concern to the implementation class.

Keep in mind that you will have to define your service implementation
classes in some configuration file anyway: How else would the container know
which component implementation classes to instantiate and under which names
to expose? Arguably, references between those components belong into that
same file, as they're expressed at the same level - named components.

Configuration properties (booleans, ints, Strings) belong into such a
configuration file as well. After all, the very point of a configuration
bean property is to allow specifying values in configuration files: Default
values can be defined by the bean implementation class itself anyway. Hence,
no need for annotations for such configuration properties - they would be
completely pointless.

If you define your service implementation classes in a Spring bean
definition file, maybe with some configuration properties, and want to keep
the definition of explicit references to a minimum, why not use autowiring?
In terms of separation of concerns, this is much cleaner than polluting your
implementation classes with configuration annotations that point to concrete
bean names in a specific namespace.

Regarding JNDI names: You will typically only have very few JNDI names in an
application, even in a large one, so it's hardly a concern to define them in
such a configuration file and let your application classes only deal with
the type of object that they want to talk to. Wiring a JNDI-located
DataSource into bean properties of type DataSource is hardly a major burden,
even if done explicitly. And JNDI names do tend to change on a
per-deployment basis, from server to server: Would you really want to have
multiple versions of your class sources, just for different JNDI names?

A JNDI lookup annotation like EJB3's Inject simply doesn't add any value
other than syntactic sugar: In all other respects, this is hardly different
from hardcoding a programmatic JNDI lookup (to be executed when no explicit
reference has been passed into your object). Externalized JNDI names in a
configuration file, on the other hand, separate such configuration
information from implementation classes: allowing to adapt the concrete JNDI
names names on a per-deployment basis (while that need doesn't arise often,
it does arise, even if you don't anticipate it).

As a concrete example for some further added value of a configuration file,
consider a JNDI-located DataSource that you need to proxy, for example to
seamlessly inject specific default user credentials (needed when you can't
control the JNDI DataSource's default credentials; see Spring's
UserCredentialsDataSourceAdapter). This is straightforward in a Spring bean
definition file, with your application objects simply getting wired to that
DataSource proxy rather than the raw JNDI DataSource. With JNDI lookups
hard-coded into your DAOs, you'd lose that flexibility.

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Janne Kario
Sent: Saturday, August 06, 2005 5:32 PM
To: spr...@li...
Subject: [Springframework-developer] Re: Annotations

Mark St Godard wrote:
> 
> 
> 
> Speaking as a non-Spring developer....(i.e. wait for Rod, Juergen, etc..
> comments)...
> 
> Is this something that you really want?   There are valid uses of
> Annotations...(i.e. transactions, security)...
> but I dont think its a good idea to use it for everything (i.e.  IoC)
> 
> EJB3 is annotation-"crazy"... for lack of a better word.... I still 
> really do not think @Inject is appropriate.

Inject is probably one of the things I'm looking for. That is being able to
do the assembly level stuff using annotations. The reason that we have the
XML configuration file is because we can change assembly level things easily
(right?). However, this can just as easily be achieved using annotations
which retain code locality. Majority of applications are pretty static in
nature and there's no need to change the assembly stuff once the app if
finished. And if you do need to change something you need to tear open the
WAR archive anyways which is not far from doing a full recompile.

> I still think there will be some sort of level of configuration that 
> you cannot get away from.

Ofcourse.

* Janne Kario



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile &
Plan-Driven Development * Managing Projects & Teams * Testing & QA Security
* Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] SWF: why is parent request scope empty after sub flow completion?

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

> I noticed the parent request scope is empty when a sub flow
> terminates. Why is this, it makes sense to keep it.

I'm not sure what you're hinting at here, but the request scope is shared 
between parent en sub flow. It is scoped for the lifetime of the request, so 
when a subflow-state passes a request from the parent to a subflow the 
request scope remains unchanged. The same is true when an end-state moves 
the request from an ending subflow back up to the parent flow.

> If I want to select an entity from a form I submit the entire for to a
> form action. Next I start a sub flow to do the selection and the
> output part of the flow attribute mapper gets the command object from
> the request and binds the selected entity to the command object.

Yes, that seems normal practice so far.

> But since the request is empty after the sub flow completion I have to
> put the form action in flow scope and put the command object in the
> request scope myself after the sub flow completes so that the form
> view in the parent flow renders propertly.

???
Yes you'll have to put the form object in flow scope of the parent flow 
since you want it to stick around for use when the subflow returns (i.e. you 
want to map the selected entity into one of its properties in the subflow 
output mapper). Why would you have to put the command object in the request 
scope to get the view to render properly? The merged content of request and 
flow scope is exposed to the view in the model, so it should not matter 
where the command object is.

> Keeping the request scope intact would be easier.

As I said, the request scope remains untouched when moving between parent 
and subflows, so I don't really see the problem...


Erwin 

[Springframework-developer] Re: Annotations

[Janne K. <ka...@me...>]

Mark St Godard wrote:
> 
> 
> 
> Speaking as a non-Spring developer....(i.e. wait for Rod, Juergen, etc..
> comments)...
> 
> Is this something that you really want?   There are valid uses of
> Annotations...(i.e. transactions, security)...
> but I dont think its a good idea to use it for everything (i.e.  IoC)
> 
> EJB3 is annotation-"crazy"... for lack of a better word.... I still really
> do not think @Inject is appropriate.

Inject is probably one of the things I'm looking for. That is being able 
to do the assembly level stuff using annotations. The reason that we 
have the XML configuration file is because we can change assembly level 
things easily (right?). However, this can just as easily be achieved 
using annotations which retain code locality. Majority of applications 
are pretty static in nature and there's no need to change the assembly 
stuff once the app if finished. And if you do need to change something 
you need to tear open the WAR archive anyways which is not far from 
doing a full recompile.

> I still think there will be some sort of level of configuration that you
> cannot get away from.

Ofcourse.

* Janne Kario

[Springframework-developer] SWF: why is parent request scope empty after sub flow completion?

[Steven D. <ste...@gm...>]

Hi,

I noticed the parent request scope is empty when a sub flow
terminates. Why is this, it makes sense to keep it.

If I want to select an entity from a form I submit the entire for to a
form action. Next I start a sub flow to do the selection and the
output part of the flow attribute mapper gets the command object from
the request and binds the selected entity to the command object.

But since the request is empty after the sub flow completion I have to
put the form action in flow scope and put the command object in the
request scope myself after the sub flow completes so that the form
view in the parent flow renders propertly.

Keeping the request scope intact would be easier.

Please advise

Steven=20

--=20
"If you want to be a different fish, you gotta jump out of the school."
-- Captain Beefheart