springframework-developer — Spring Framework developers list

Re: [Springframework-developer] orm.hibernate* missing from spring.jar in nightly builds

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

Well, doesn't such a manifest classpath entry express the wrong =
direction of
dependency? spring.jar does not depend on spring-hibernate*.jar at all. =
It's
rather the other way round: spring-hibernate*.jar are extensions that =
depend
on spring.jar

Juergen
=20

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Lachezar Dobrev
Sent: Tuesday, December 20, 2005 9:23 AM
To: spr...@li...
Subject: Re: [Springframework-developer] orm.hibernate* missing from
spring.jar in nightly builds

  Ahmm... Maybe if Spring uses the Class-Path attribute in the jars'
MANIFEST.MF this problem would be solved by merely dropping a couple of =
jars
into the library directory without mangling a project's class path.
  Spring.jar should have in the manifest:
  Class-Path: spring-hibernate2.jar spring-hibernate-3.jar ...

  Then the developers would only need to drop the required subset of
sub-jars.

2005/12/15, Colin Sampaleanu <col...@ex...>:
> mraible (sent by Nabble.com) wrote:
>
> It's not about splitting it out just to split it out. The problem is=20
> that having both the Hibernate 2 and Hibernate 3 code together leads=20
> to a lot of confusion. People end up importing the wrong classes all=20
> the time. The actual class names are identical, and the packages as=20
> identical except for one extra char, so it's easy to import the wrong=20
> one when you do an auto import in Eclipse. I see this over and over=20
> during trainings, among other places. So back in the summer I=20
> suggested we split things out to separate jars and have people just=20
> include whichever one they wanted, but it didn't make sense (for drop=20
> in compatibility reasons) to do this in a 1.2 point release, but=20
> rather only now with 2.0...
>
> Colin
>
> --
> Colin Sampaleanu
> Interface21 Principal Consultant
> Spring Training, Consulting and Support - "From the Source"
> http://www.springframework.com


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log =
files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] orm.hibernate* missing from spring.jar in nightly builds

[Lachezar D. <l.d...@gm...>]

  Ahmm... Maybe if Spring uses the Class-Path attribute in the jars'
MANIFEST.MF this problem would be solved by merely dropping a couple
of jars into the library directory without mangling a project's class
path.
  Spring.jar should have in the manifest:
  Class-Path: spring-hibernate2.jar spring-hibernate-3.jar ...

  Then the developers would only need to drop the required subset of sub-ja=
rs.

2005/12/15, Colin Sampaleanu <col...@ex...>:
> mraible (sent by Nabble.com) wrote:
>
> It's not about splitting it out just to split it out. The problem is
> that having both the Hibernate 2 and Hibernate 3 code together leads to
> a lot of confusion. People end up importing the wrong classes all the
> time. The actual class names are identical, and the packages as
> identical except for one extra char, so it's easy to import the wrong
> one when you do an auto import in Eclipse. I see this over and over
> during trainings, among other places. So back in the summer I suggested
> we split things out to separate jars and have people just include
> whichever one they wanted, but it didn't make sense (for drop in
> compatibility reasons) to do this in a 1.2 point release, but rather
> only now with 2.0...
>
> Colin
>
> --
> Colin Sampaleanu
> Interface21 Principal Consultant
> Spring Training, Consulting and Support - "From the Source"
> http://www.springframework.com

[Springframework-developer] spring build.384 Build Fixed

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

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

[Springframework-developer] Spring JIRA Find Issues layout is messed up

[Andreas S. <an...@sc...>]

Hi all,

since a few months, the layout for Spring JIRA Find Issues is a mess: 
The filters on the left hand side overlap with the result view on the 
right hand side, rendering the find issues function nearly useless.

The problem is caused by the overlength String "Spring Framework Eclipse 
Plugins (not used anymore -> use http://springide.org/ instead)".

I can send a screenshot of the problem, if desired.

Could someone fix this?

Regards,

Andreas

[Springframework-developer] spring Build Failed

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

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

[Springframework-developer] spring Build Failed

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

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

[Springframework-developer] spring Build Failed

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

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

Re: [Springframework-developer] Re: Portlet MVC in Spring 2.0-m1

[Rainer S. <Rai...@ab...>]

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

John Lewis wrote:

> One concern I have about the new ModelAndView class is that it does not
> currently allow the View object to be created directly -- it can only be
> set by name and must then be loaded by a ViewResolver.  Adding in the
> methods for setting the View directly would result in one set of API
> methods that reference the servlet-side classes, but given that we use
> the servlet-side infrastructure to do all the rendering I think this
> might be reasonable.  What are your thoughts on this?
Without having spend much time to think about it: we need the servlet
stuff anyway, so I don't see a problem referencing it where it's needed.


> As for the Liferay issue, this sounds like a bug in Liferay.  The
> default behavior of handleActionRequestInternal and
> handleRenderRequestInternal in AbstractController (i.e. throwing
> Exceptions) is modeled after the default behavior of processAction,
> doView, doEdit, and doHelp in the GenericPortlet from the JSR-168 API. 
> In fact, this behavior was requested by a number of users in order to be
> consistent with the API.  I think it would be better to get Liferay to
> fix their bug than to try to work around it in the Spring framework.  As
> I think about, this is actually a pretty serious bug in Liferay.  What
> if you have a bunch of legitimate database manipulation code in your
> handleActionRequestInternal?  Will it try to run that every time you
> change the window state?  That doesn't sound good.  Let me know what you
> think.

Meanwhile I think it's a bug in Liferay, too. The Portlet spec says in
section PLT.11.1.1:

  Commonly, portals provide controls to change the portlet mode and the
  window state of portlets. The URLs these controls use are generated by
  the portal. Client requests triggered by those URLs must be treated as
  render URLs and the existing render parameters must be preserved.

I've found an unresolved issue in the Liferay JIRA providing a simple
patch (LEP-478 if anyone is interested). I also asked a question at the
forums, I hope the bug will be fixed in the next Liferay release.
Anyway, no need to change the Portlet MVC behaviour.


> I should have a new build of the portlet framework out soon that is
> based on the sandbox code.  I'll appreciate your help in testing this.
Sure. As you might have noticed I'm still struggling with porting my
application to Liferay ;-) But after things have stabelized I'm eager to
integrate the newest version of Portlet MVC.

Cheers,
Rainer

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: GnuPT 2.6.1.1 by EQUIPMENTE.DE
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFDoqoGav/AIDHDd+YRAkhRAKCG/1tElC7mFi/oPZnsO1GFX/HbDgCgwS7B
Wf3OGfcsXoyfhmYrqgmYEyk=
=ZdKC
-----END PGP SIGNATURE-----

[Springframework-developer] Re: Portlet MVC in Spring 2.0-m1

[John L. <jl...@ar...>]

Oh, the other thing that changes is that ViewRendererServlet moved from 
the .portlet package to the .servlet package -- that will need to be 
changed in your web.xml file.  That would also cause you to not be able 
to render anything... ;)

John Lewis wrote:

> Rainer!  Good to hear from you.
>
> I think the portlet MVC code that is in 2.0-M1 got pulled out of the 
> sandbox image.  The portlet code in the sandbox is currently not 
> functional.
>
> Juergen has made an extensive pass through the code and has provided a 
> number of improvements.  One is the elimination of references to the 
> org.springframework.web.servlet classes throughout the 
> org.springframework.web.portlet API.  This required a new ModelAndView 
> class and a few other key changes.  This along with some changes to 
> the way the ApplicationContext works in portlets has made things much 
> cleaner.
>
> The current problem with the portlet code in the sandbox is that we 
> have eliminated the LocaleResolver (since the portal is responsible 
> for locale management) but there are appear to be some View 
> rendering-related classes that are looking for it instead of using the 
> LocaleContextHolder.  I am working on straightening out these issues 
> right now and the sandbox code should be functional again soon.
>
> One concern I have about the new ModelAndView class is that it does 
> not currently allow the View object to be created directly -- it can 
> only be set by name and must then be loaded by a ViewResolver.  Adding 
> in the methods for setting the View directly would result in one set 
> of API methods that reference the servlet-side classes, but given that 
> we use the servlet-side infrastructure to do all the rendering I think 
> this might be reasonable.  What are your thoughts on this?
>
> As for the Liferay issue, this sounds like a bug in Liferay.  The 
> default behavior of handleActionRequestInternal and 
> handleRenderRequestInternal in AbstractController (i.e. throwing 
> Exceptions) is modeled after the default behavior of processAction, 
> doView, doEdit, and doHelp in the GenericPortlet from the JSR-168 
> API.  In fact, this behavior was requested by a number of users in 
> order to be consistent with the API.  I think it would be better to 
> get Liferay to fix their bug than to try to work around it in the 
> Spring framework.  As I think about, this is actually a pretty serious 
> bug in Liferay.  What if you have a bunch of legitimate database 
> manipulation code in your handleActionRequestInternal?  Will it try to 
> run that every time you change the window state?  That doesn't sound 
> good.  Let me know what you think.
>
> I should have a new build of the portlet framework out soon that is 
> based on the sandbox code.  I'll appreciate your help in testing this.
>
> Thanks,
> John
>
>
>
>
> Rainer Schmitz wrote:
>
>> Aloha!
>>
>> Is the Portlet MVC in 2.0-M1
>> (spring-framework-2.0-m1-with-dependencies-build.383-20051214.zip)
>> supposed to work?
>> My portlet application works with Portlet MVC as published in the
>> confluence wiki. But after switching to 2.0-M1 the portlet content is
>> not rendered anymore. There are no error messages, and the controllers
>> are processed correctly. Deploying the portlet sample application showed
>> the same effect (uisng Liferay 3.6.1).
>>
>> BTW: I had to change my portlets to use
>> org.springframework.web.portlet.ModelAndView instead of
>> org.springframework.web.servlet.ModelAndView. What's the reason for the
>> new ModelAndView class?
>>
>> Another issue is related to Liferay. It seems Liferay is creating Action
>> Requests to change the portlet window state. This means a portlet will
>> receive action requests even if it is not meant to handle these
>> explicitely.
>> The problem is that the default implementation of
>> handleRenderRequestInternal(ActionRequest, ActionResponse) in
>> AbstractController throws an Exception. To work in Liferay every
>> controller has to overload this method (same for render requests).
>> I propose to change the methods in AbstractController to just do nothing
>> (or maybe to issue a debug or warning message).
>>
>> Rainer
>>
>>  
>>
>

[Springframework-developer] Re: Portlet MVC in Spring 2.0-m1

[John L. <jl...@ar...>]

Rainer!  Good to hear from you.

I think the portlet MVC code that is in 2.0-M1 got pulled out of the 
sandbox image.  The portlet code in the sandbox is currently not functional.

Juergen has made an extensive pass through the code and has provided a 
number of improvements.  One is the elimination of references to the 
org.springframework.web.servlet classes throughout the 
org.springframework.web.portlet API.  This required a new ModelAndView 
class and a few other key changes.  This along with some changes to the 
way the ApplicationContext works in portlets has made things much cleaner.

The current problem with the portlet code in the sandbox is that we have 
eliminated the LocaleResolver (since the portal is responsible for 
locale management) but there are appear to be some View 
rendering-related classes that are looking for it instead of using the 
LocaleContextHolder.  I am working on straightening out these issues 
right now and the sandbox code should be functional again soon.

One concern I have about the new ModelAndView class is that it does not 
currently allow the View object to be created directly -- it can only be 
set by name and must then be loaded by a ViewResolver.  Adding in the 
methods for setting the View directly would result in one set of API 
methods that reference the servlet-side classes, but given that we use 
the servlet-side infrastructure to do all the rendering I think this 
might be reasonable.  What are your thoughts on this?

As for the Liferay issue, this sounds like a bug in Liferay.  The 
default behavior of handleActionRequestInternal and 
handleRenderRequestInternal in AbstractController (i.e. throwing 
Exceptions) is modeled after the default behavior of processAction, 
doView, doEdit, and doHelp in the GenericPortlet from the JSR-168 API.  
In fact, this behavior was requested by a number of users in order to be 
consistent with the API.  I think it would be better to get Liferay to 
fix their bug than to try to work around it in the Spring framework.  As 
I think about, this is actually a pretty serious bug in Liferay.  What 
if you have a bunch of legitimate database manipulation code in your 
handleActionRequestInternal?  Will it try to run that every time you 
change the window state?  That doesn't sound good.  Let me know what you 
think.

I should have a new build of the portlet framework out soon that is 
based on the sandbox code.  I'll appreciate your help in testing this.

Thanks,
John




Rainer Schmitz wrote:

>Aloha!
>
>Is the Portlet MVC in 2.0-M1
>(spring-framework-2.0-m1-with-dependencies-build.383-20051214.zip)
>supposed to work?
>My portlet application works with Portlet MVC as published in the
>confluence wiki. But after switching to 2.0-M1 the portlet content is
>not rendered anymore. There are no error messages, and the controllers
>are processed correctly. Deploying the portlet sample application showed
>the same effect (uisng Liferay 3.6.1).
>
>BTW: I had to change my portlets to use
>org.springframework.web.portlet.ModelAndView instead of
>org.springframework.web.servlet.ModelAndView. What's the reason for the
>new ModelAndView class?
>
>Another issue is related to Liferay. It seems Liferay is creating Action
>Requests to change the portlet window state. This means a portlet will
>receive action requests even if it is not meant to handle these
>explicitely.
>The problem is that the default implementation of
>handleRenderRequestInternal(ActionRequest, ActionResponse) in
>AbstractController throws an Exception. To work in Liferay every
>controller has to overload this method (same for render requests).
>I propose to change the methods in AbstractController to just do nothing
>(or maybe to issue a debug or warning message).
>
>Rainer
>
>  
>

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

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

1134697651
FAILED
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,042 sec
    [junit] Testsuite: org.springframework.transaction.interceptor.TransactionAttributeSourceAdvisorTests
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,042 sec

    [junit] Testcase: testSerializability took 0,024 sec
    [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0,113 sec
    [junit] Testsuite: org.springframework.transaction.interceptor.TransactionAttributeSourceEditorTests
    [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0,113 sec

    [junit] Testcase: testNull took 0,001 sec
    [junit] Testcase: testInvalid took 0,001 sec
    [junit] Testcase: testMatchesSpecific took 0,002 sec
    [junit] Testcase: testMatchesAll took 0,001 sec
    [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0,026 sec
    [junit] Testsuite: org.springframework.transaction.interceptor.TransactionAttributeSourceTests
    [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0,026 sec

    [junit] Testcase: testMatchAlwaysTransactionAttributeSource took 0,007 sec
    [junit] Testcase: testMethodMapTransactionAttributeSource took 0,002 sec
    [junit] Testcase: testNameMatchTransactionAttributeSource took 0,001 sec
    [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0,039 sec
    [junit] Testsuite: org.springframework.transaction.interceptor.TransactionInterceptorTests
    [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0,039 sec

    [junit] Testcase: testSerializableWithAttributeProperties took 0,012 sec
    [junit] 	FAILED
    [junit] null
    [junit] junit.framework.AssertionFailedError
    [junit] 	at org.springframework.transaction.interceptor.TransactionInterceptorTests.testSerializableWithAttributeProperties(TransactionInterceptorTests.java:68)

Last CVS updates prior to this build were:
1134695581
? ?
? junit423465713.properties
? junittestcases2136842450.properties
? sandbox/src/org/springframework/core/closure/ElementGenerator.java
? sandbox/src/org/springframework/core/closure/support/AbstractElementGenerator.java
? sandbox/src/org/springframework/core/closure/support/AbstractElementGeneratorWorkflow.java
? sandbox/src/org/springframework/core/closure/support/IfBlock.java
? sandbox/src/org/springframework/jms/listener
? test/org/springframework/beans/factory/xml/dependencies-prop-inTheMiddle.xml
C test/org/springframework/beans/factory/xml/dependencies-prop-inTheMiddle.xml

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
successful build occurs on the machine in question.

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

[Springframework-developer] spring Build Failed

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

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

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

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

1134683374
FAILED
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,065 sec
    [junit] Testsuite: org.springframework.transaction.interceptor.TransactionAttributeSourceAdvisorTests
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,065 sec

    [junit] Testcase: testSerializability took 0,038 sec
    [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0,024 sec
    [junit] Testsuite: org.springframework.transaction.interceptor.TransactionAttributeSourceEditorTests
    [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0,024 sec

    [junit] Testcase: testNull took 0,001 sec
    [junit] Testcase: testInvalid took 0,001 sec
    [junit] Testcase: testMatchesSpecific took 0,003 sec
    [junit] Testcase: testMatchesAll took 0,002 sec
    [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0,028 sec
    [junit] Testsuite: org.springframework.transaction.interceptor.TransactionAttributeSourceTests
    [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0,028 sec

    [junit] Testcase: testMatchAlwaysTransactionAttributeSource took 0,008 sec
    [junit] Testcase: testMethodMapTransactionAttributeSource took 0,002 sec
    [junit] Testcase: testNameMatchTransactionAttributeSource took 0,001 sec
    [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0,056 sec
    [junit] Testsuite: org.springframework.transaction.interceptor.TransactionInterceptorTests
    [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0,056 sec

    [junit] Testcase: testSerializableWithAttributeProperties took 0,018 sec
    [junit] 	FAILED
    [junit] null
    [junit] junit.framework.AssertionFailedError
    [junit] 	at org.springframework.transaction.interceptor.TransactionInterceptorTests.testSerializableWithAttributeProperties(TransactionInterceptorTests.java:68)

Last CVS updates prior to this build were:
1134681181
? ?
? junit423465713.properties
? junittestcases2136842450.properties
? sandbox/src/org/springframework/core/closure/ElementGenerator.java
? sandbox/src/org/springframework/core/closure/support/AbstractElementGenerator.java
? sandbox/src/org/springframework/core/closure/support/AbstractElementGeneratorWorkflow.java
? sandbox/src/org/springframework/core/closure/support/IfBlock.java
? sandbox/src/org/springframework/jms/listener
? test/org/springframework/beans/factory/xml/dependencies-prop-inTheMiddle.xml
C test/org/springframework/beans/factory/xml/dependencies-prop-inTheMiddle.xml

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
successful build occurs on the machine in question.

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

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

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

1134676153
FAILED
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,075 sec
    [junit] Testsuite: org.springframework.transaction.interceptor.TransactionAttributeSourceAdvisorTests
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,075 sec

    [junit] Testcase: testSerializability took 0,058 sec
    [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0,025 sec
    [junit] Testsuite: org.springframework.transaction.interceptor.TransactionAttributeSourceEditorTests
    [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0,025 sec

    [junit] Testcase: testNull took 0,001 sec
    [junit] Testcase: testInvalid took 0 sec
    [junit] Testcase: testMatchesSpecific took 0,003 sec
    [junit] Testcase: testMatchesAll took 0,001 sec
    [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0,027 sec
    [junit] Testsuite: org.springframework.transaction.interceptor.TransactionAttributeSourceTests
    [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0,027 sec

    [junit] Testcase: testMatchAlwaysTransactionAttributeSource took 0,008 sec
    [junit] Testcase: testMethodMapTransactionAttributeSource took 0,002 sec
    [junit] Testcase: testNameMatchTransactionAttributeSource took 0,001 sec
    [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0,056 sec
    [junit] Testsuite: org.springframework.transaction.interceptor.TransactionInterceptorTests
    [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0,056 sec

    [junit] Testcase: testSerializableWithAttributeProperties took 0,018 sec
    [junit] 	FAILED
    [junit] null
    [junit] junit.framework.AssertionFailedError
    [junit] 	at org.springframework.transaction.interceptor.TransactionInterceptorTests.testSerializableWithAttributeProperties(TransactionInterceptorTests.java:68)

Last CVS updates prior to this build were:
1134673981

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
successful build occurs on the machine in question.

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

[Springframework-developer] Portlet MVC in Spring 2.0-m1

[Rainer S. <Rai...@ab...>]

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

Aloha!

Is the Portlet MVC in 2.0-M1
(spring-framework-2.0-m1-with-dependencies-build.383-20051214.zip)
supposed to work?
My portlet application works with Portlet MVC as published in the
confluence wiki. But after switching to 2.0-M1 the portlet content is
not rendered anymore. There are no error messages, and the controllers
are processed correctly. Deploying the portlet sample application showed
the same effect (uisng Liferay 3.6.1).

BTW: I had to change my portlets to use
org.springframework.web.portlet.ModelAndView instead of
org.springframework.web.servlet.ModelAndView. What's the reason for the
new ModelAndView class?

Another issue is related to Liferay. It seems Liferay is creating Action
Requests to change the portlet window state. This means a portlet will
receive action requests even if it is not meant to handle these
explicitely.
The problem is that the default implementation of
handleRenderRequestInternal(ActionRequest, ActionResponse) in
AbstractController throws an Exception. To work in Liferay every
controller has to overload this method (same for render requests).
I propose to change the methods in AbstractController to just do nothing
(or maybe to issue a debug or warning message).

Rainer

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDocRPav/AIDHDd+YRAhV+AKCCRpmWEJQT9+fnFfC2Tx3kyfmTVQCgh4Go
ESCH2Dt+erVxUQqb5yfVbRg=
=T/uY
-----END PGP SIGNATURE-----

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

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

1134671874
FAILED
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,026 sec
    [junit] Testsuite: org.springframework.transaction.interceptor.TransactionAttributeSourceAdvisorTests
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,026 sec

    [junit] Testcase: testSerializability took 0,016 sec
    [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0,021 sec
    [junit] Testsuite: org.springframework.transaction.interceptor.TransactionAttributeSourceEditorTests
    [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0,021 sec

    [junit] Testcase: testNull took 0,001 sec
    [junit] Testcase: testInvalid took 0,001 sec
    [junit] Testcase: testMatchesSpecific took 0,002 sec
    [junit] Testcase: testMatchesAll took 0,001 sec
    [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0,221 sec
    [junit] Testsuite: org.springframework.transaction.interceptor.TransactionAttributeSourceTests
    [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0,221 sec

    [junit] Testcase: testMatchAlwaysTransactionAttributeSource took 0,21 sec
    [junit] Testcase: testMethodMapTransactionAttributeSource took 0,001 sec
    [junit] Testcase: testNameMatchTransactionAttributeSource took 0 sec
    [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0,026 sec
    [junit] Testsuite: org.springframework.transaction.interceptor.TransactionInterceptorTests
    [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0,026 sec

    [junit] Testcase: testSerializableWithAttributeProperties took 0,009 sec
    [junit] 	FAILED
    [junit] null
    [junit] junit.framework.AssertionFailedError
    [junit] 	at org.springframework.transaction.interceptor.TransactionInterceptorTests.testSerializableWithAttributeProperties(TransactionInterceptorTests.java:68)

Last CVS updates prior to this build were:
1134670381
? ?
? junit423465713.properties
? junittestcases2136842450.properties
? sandbox/src/org/springframework/core/closure/ElementGenerator.java
? sandbox/src/org/springframework/core/closure/support/AbstractElementGenerator.java
? sandbox/src/org/springframework/core/closure/support/AbstractElementGeneratorWorkflow.java
? sandbox/src/org/springframework/core/closure/support/IfBlock.java
? sandbox/src/org/springframework/jms/listener
? test/org/springframework/beans/factory/xml/dependencies-prop-inTheMiddle.xml
U aspectj/src/META-INF/aop.xml
U aspectj/src/org/springframework/beans/factory/aspectj/AbstractBeanConfigurer.aj
U aspectj/src/org/springframework/beans/factory/aspectj/AnnotationBeanConfigurer.aj
U aspectj/src/org/springframework/beans/factory/aspectj/BeanWiringInfo.java
U aspectj/src/org/springframework/beans/factory/aspectj/BeanWiringInfoResolver.java
U aspectj/src/org/springframework/beans/factory/aspectj/Configurable.java
U aspectj/src/org/springframework/transaction/aspectj/AbstractTransactionAspect.aj
U aspectj/src/org/springframework/transaction/aspectj/TransactionalAnnotationTransactionAspect.aj
P aspectj/test/org/springframework/beans/factory/aspectj/BeanConfigurerTests.java
U aspectj/test/org/springframework/transaction/aspectj/ITransactional.java
U aspectj/test/org/springframework/transaction/aspectj/MethodAnnotationOnClassWithNoInterface.java
U aspectj/test/org/springframework/transaction/aspectj/TransactionAspectTests.java
U aspectj/test/org/springframework/transaction/aspectj/TransactionalAnnotationOnlyOnClassWithNoInterface.java
U aspectj/test/org/springframework/transaction/aspectj/txtests.xml
P src/org/springframework/aop/config/AopNamespaceHandler.java
P src/org/springframework/transaction/interceptor/TransactionAspectSupport.java
P src/org/springframework/transaction/interceptor/TransactionInterceptor.java
C test/org/springframework/beans/factory/xml/dependencies-prop-inTheMiddle.xml
P test/org/springframework/transaction/CallCountingTransactionManager.java

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
successful build occurs on the machine in question.

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

Re: [Springframework-developer] orm.hibernate* missing from spring.jar in nightly builds

[mraible (s. by Nabble.com) <li...@na...>]

Colin Sampaleanu wrote: 
> 
> It's not about splitting it out just to split it out. The problem is 
> that having both the Hibernate 2 and Hibernate 3 code together leads to 
> a lot of confusion. People end up importing the wrong classes all the 
> time. The actual class names are identical, and the packages as 
> identical except for one extra char, so it's easy to import the wrong 
> one when you do an auto import in Eclipse. I see this over and over 
> during trainings, among other places. So back in the summer I suggested 
> we split things out to separate jars and have people just include 
> whichever one they wanted, but it didn't make sense (for drop in 
> compatibility reasons) to do this in a 1.2 point release, but rather 
> only now with 2.0...
> 
> Colin
> 

This makes sense - I've seen this same confusion in my experience. Thanks Colin.

Matt
--
Sent from the springframework-developer forum at Nabble.com:
http://www.nabble.com/orm.hibernate*-missing-from-spring.jar-in-nightly-builds-t743148.html#a1962085

Re: [Springframework-developer] orm.hibernate* missing from spring.jar in nightly builds

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

mraible (sent by Nabble.com) wrote:

>     Craig Walls wrote:
>     I stopped Rob, Rod, and Juergen in the lobby on the last day of
>     TSE and
>     asked the same question. It seems that Juergen has split out most
>     of the
>     vendor-specific ORM stuff into independent JARs
>     (spring-hibernate.jar or
>     spring-hibernate3.jar for instance). It's my understanding that the
>     decision was made because (1) the main JAR was getting quite large
>     and (2)
>     Hibernate/iBATIS/OJB/etc-specific stuff is not central to Spring
>     and thus
>     should not be in the main JAR.
>
>     So, yes, from a JAR dependency perspective, backwards
>     compatibility is
>     broken. But fixing it is simply a matter of including an addition
>     JAR file
>     in the classpath. Code-wise, backwards compatibility is still intact.
>
> Right, I discovered that much.  However, all the other persistence
> frameworks are still included in spring.jar and Hibernate seems to be
> the only one that's been left out.

It's not about splitting it out just to split it out. The problem is 
that having both the Hibernate 2 and Hibernate 3 code together leads to 
a lot of confusion. People end up importing the wrong classes all the 
time. The actual class names are identical, and the packages as 
identical except for one extra char, so it's easy to import the wrong 
one when you do an auto import in Eclipse. I see this over and over 
during trainings, among other places. So back in the summer I suggested 
we split things out to separate jars and have people just include 
whichever one they wanted, but it didn't make sense (for drop in 
compatibility reasons) to do this in a 1.2 point release, but rather 
only now with 2.0...

Colin

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

Re: [Springframework-developer] orm.hibernate* missing from spring.jar in nightly builds

[mraible (s. by Nabble.com) <li...@na...>]

Craig Walls wrote: 
> 
> 
> I stopped Rob, Rod, and Juergen in the lobby on the last day of TSE and
> asked the same question. It seems that Juergen has split out most of the
> vendor-specific ORM stuff into independent JARs (spring-hibernate.jar or
> spring-hibernate3.jar for instance). It's my understanding that the
> decision was made because (1) the main JAR was getting quite large and (2)
> Hibernate/iBATIS/OJB/etc-specific stuff is not central to Spring and thus
> should not be in the main JAR.
> 
> So, yes, from a JAR dependency perspective, backwards compatibility is
> broken. But fixing it is simply a matter of including an addition JAR file
> in the classpath. Code-wise, backwards compatibility is still intact.
> 
> 

Right, I discovered that much.  However, all the other persistence 
frameworks are still included in spring.jar and Hibernate seems to be 
the only one that's been left out.

Matt
--
Sent from the springframework-developer forum at Nabble.com:
http://www.nabble.com/orm.hibernate*-missing-from-spring.jar-in-nightly-builds-t743148.html#a1946280

Re: [Springframework-developer] orm.hibernate* missing from spring.jar in nightly builds

[Craig W. <cr...@ha...>]

I stopped Rob, Rod, and Juergen in the lobby on the last day of TSE and
asked the same question. It seems that Juergen has split out most of the
vendor-specific ORM stuff into independent JARs (spring-hibernate.jar or
spring-hibernate3.jar for instance). It's my understanding that the
decision was made because (1) the main JAR was getting quite large and (2)
Hibernate/iBATIS/OJB/etc-specific stuff is not central to Spring and thus
should not be in the main JAR.

So, yes, from a JAR dependency perspective, backwards compatibility is
broken. But fixing it is simply a matter of including an addition JAR file
in the classpath. Code-wise, backwards compatibility is still intact.



>
> I've downloading the nightly build of 2.0 M1, and for some reason
> neither org.springframework.orm.hibernate.* nor
> org.springframework.orm.hibernate3.* are in spring.jar.  Is this "as
> designed"?  If Spring 2.0 is a drop-in replacement for Spring 1.2.x, it
> seems like these classes should be included in spring.jar.
>
> I tried running "ant alljars" with JDK 1.4.2, but got the following
> error using 2.0-M1-with-dependencies.
>
> buildmain:
>     [mkdir] Created dir: C:\Temp\spring-framework-2.0-m1\target\classes
> [mkdir] Created dir:
> C:\Temp\spring-framework-2.0-m1\target\classes\META-INF [javac]
> Compiling 1257 source files to
> C:\Temp\spring-framework-2.0-m1\target\classes [javac]
> C:\Temp\spring-framework-2.0-m1\src\org\springframework\aop\aspectj\AbstractAspectJAdvice.java:22:
> package org.aspectj.weaver.tools does not exist [javac] import
> org.aspectj.weaver.tools.PointcutExpression;
>
>
> Matt
> --
> Sent from the springframework-developer forum at Nabble.com:
> http://www.nabble.com/orm.hibernate*-missing-from-spring.jar-in-nightly-builds-t743148.html#a1944607

[Springframework-developer] orm.hibernate* missing from spring.jar in nightly builds

[mraible (s. by Nabble.com) <li...@na...>]

I've downloading the nightly build of 2.0 M1, and for some reason neither org.springframework.orm.hibernate.* nor org.springframework.orm.hibernate3.* are in spring.jar.  Is this "as designed"?  If Spring 2.0 is a drop-in replacement for Spring 1.2.x, it seems like these classes should be included in spring.jar.

I tried running "ant alljars" with JDK 1.4.2, but got the following error using 2.0-M1-with-dependencies.

buildmain:
    [mkdir] Created dir: C:\Temp\spring-framework-2.0-m1\target\classes
    [mkdir] Created dir: C:\Temp\spring-framework-2.0-m1\target\classes\META-INF
    [javac] Compiling 1257 source files to C:\Temp\spring-framework-2.0-m1\target\classes
    [javac] C:\Temp\spring-framework-2.0-m1\src\org\springframework\aop\aspectj\AbstractAspectJAdvice.java:22: package org.aspectj.weaver.tools does not exist
    [javac] import org.aspectj.weaver.tools.PointcutExpression;


Matt
--
Sent from the springframework-developer forum at Nabble.com:
http://www.nabble.com/orm.hibernate*-missing-from-spring.jar-in-nightly-builds-t743148.html#a1944607

[Springframework-developer] spring build.383 Build Successful

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

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

[Springframework-developer] Multiple setters on a same property (cf JMX support)

[Thierry T. <te...@ya...>]

Hi all,

I want to know if the use of multiple setters (with
the same name but not the same signature) for the same
property must be supported by the Spring framework.
For example, the first setter is a method with the
type of the property and the second with a different
type which converts this type to the type of the
property.

My question comes from the support of notifications in
the JMX support of Spring. It allows applications to
define notification listeners both with a list or a
map with the following methods:

1°) public void
setNotificationListeners(NotificationListenerBean[]
notificationListeners) {...}
2°) public void setNotificationListeners(Map
listeners) throws MalformedObjectNameException {...}

You can only use the second within the application
context because the use of the other throws this
exception:

org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'exporter' defined in
class path resource [applicationContext.xml]: Error
setting property values; nested exception is
org.springframework.beans.PropertyAccessExceptionsException:
PropertyAccessExceptionsException (1 errors); nested
propertyAccessExceptions are:
[org.springframework.beans.TypeMismatchException:
Failed to convert property value of type
[java.util.ArrayList] to required type [java.util.Map]
for property 'notificationListeners']
PropertyAccessExceptionsException (1 errors)
org.springframework.beans.TypeMismatchException:
Failed to convert property value of type
[java.util.ArrayList] to required type [java.util.Map]
for property 'notificationListeners'
	at
org.springframework.beans.BeanWrapperImpl.doTypeConversionIfNecessary(BeanWrapperImpl.java:947)
	at
org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:693)
	at
org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:574)
	at
org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:734)
	at
org.springframework.beans.BeanWrapperImpl.setPropertyValues(BeanWrapperImpl.java:761)
	at
org.springframework.beans.BeanWrapperImpl.setPropertyValues(BeanWrapperImpl.java:750)

Thanks for any help you can provide.
Thierry

Take a look at my blog:
http://jroller.com/page/Templth/
(old: http://templth.blogspot.com/)


	

	
		
___________________________________________________________________________ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com

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

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

1134387856
FAILED
    [junit] Testcase: testAutowireWithDefault took 0.107 sec
    [junit] Testcase: testAutowireByConstructor took 0.09 sec
    [junit] Testcase: testAutowireByConstructorWithSimpleValues took 0.139 sec
    [junit] Testcase: testConstructorArgResolution took 0.171 sec
    [junit] Testcase: testConstructorArgWithSingleMatch took 0.298 sec
    [junit] Testcase: testThrowsExceptionOnTooManyArguments took 0.092 sec
    [junit] Testcase: testThrowsExceptionOnAmbiguousResolution took 0.066 sec
    [junit] Testcase: testFactoryBeanDefinedAsPrototype took 0.194 sec
    [junit] Testcase: testDependsOn took 0.756 sec
    [junit] Testcase: testDependsOnInInnerBean took 0.181 sec
    [junit] Testcase: testDependenciesThroughConstructorArguments took 0.048 sec
    [junit] Testcase: testDependenciesThroughConstructorArgumentAutowiring took 0.116 sec
    [junit] Testcase: testDependenciesThroughConstructorArgumentsInInnerBean took 0.08 sec
    [junit] Testcase: testDependenciesThroughProperties took 0.053 sec
    [junit] Testcase: testDependenciesThroughPropertiesWithInTheMiddle took 0.235 sec
    [junit] Testcase: testDependenciesThroughPropertyAutowiringByName took 0.041 sec
    [junit] Testcase: testDependenciesThroughPropertyAutowiringByType took 0.111 sec
    [junit] Testcase: testDependenciesThroughPropertiesInInnerBean took 0.041 sec
    [junit] Testcase: testClassNotFoundWithDefault took 0.124 sec
    [junit] Testcase: testClassNotFoundWithNoBeanClassLoader took 0.037 sec
    [junit] Testcase: testResourceAndInputStream took 0.229 sec
    [junit] Testcase: testClassPathResourceWithImport took 0.129 sec
    [junit] Testcase: testUrlResourceWithImport took 0.08 sec
    [junit] Testcase: testFileSystemResourceWithImport took 0.154 sec
    [junit] Testcase: testLookupOverrideMethodsWithSetterInjection took 1.788 sec
    [junit] 	FAILED
    [junit] null
    [junit] junit.framework.AssertionFailedError
    [junit] 	at org.springframework.beans.factory.xml.XmlBeanFactoryTests.testLookupOverrideMethodsWithSetterInjection(XmlBeanFactoryTests.java:908)

Last CVS updates prior to this build were:
1134385982
? ?
? junit423465713.properties
? junittestcases2136842450.properties
? sandbox/src/org/springframework/core/closure/ElementGenerator.java
? sandbox/src/org/springframework/core/closure/support/AbstractElementGenerator.java
? sandbox/src/org/springframework/core/closure/support/AbstractElementGeneratorWorkflow.java
? sandbox/src/org/springframework/core/closure/support/IfBlock.java
? sandbox/src/org/springframework/jms/listener
? test/org/springframework/beans/factory/xml/dependencies-prop-inTheMiddle.xml
C test/org/springframework/beans/factory/xml/dependencies-prop-inTheMiddle.xml

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
successful build occurs on the machine in question.

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

[Springframework-developer] (no subject)

[Victor G. <vic...@gm...>]