springframework-developer — Spring Framework developers list

[Springframework-developer] SWF: double _eventId syndrome

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

Hi,

I am faced with the same problem as described in this thread on the forum:

http://forum.springframework.org/viewtopic.php?t=3D6791&highlight=3Deventid

I go to a detail screen from a table through a link. On the details
screen is a form that has a _eventId field. When I submit my browser
sends two _eventId request parameters: one from the URI of the
previous request and one from the form.

The only solution I can think of to solve this problem is to introduce
a _formEventId parameter that precedes over _eventId. It's a bit
broken since users can use _formEventId in URI as well.

Steven

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

Re: [Springframework-developer] Ivy woes (part 2)

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

Steven,

If you're using ivy 1.0 that's because Ivy 1.0 is installed in your ant 
lib dir. The build right now relies on you to have an up-to-date ivy jar 
in your ant lib dir.

Now in fact you need to use a post 1.1 snapshot of ivy. One part of the 
build relies on a bugfix in the publish task as it relates to finding 
the resolved ivy.xml file for what is being published.

I've fixed a few other glitches in dependencies in the SWF samples, and 
also put a current snapshot ivy.jar in the static reposiroty. You should 
check out spring-projects again, and grab the ivy-20050708173612.jar 
from the jayasoft/ivy/jars dir, and drop it into your ant lib dir.

One other problem is that we again seem to have a CVS problem with 
trying to check in the right spring-context-1.2.2.jar file ("cvs: 
hash.c:317: findnode: Assertion `key != ((void *)0)' failed."). I need 
to raise a support issue with SF about this. Until then, you're going to 
have to manually get spring-context.jar from the Spring 1.2.2 distro, 
and drop it in the static repo as
   repository/springframework/spring-context/jars/spring-context-1.2.2.jar

This should get you going.

Regards,
Colin


Steven Devijver wrote:

>Colin,
>
>I've checked out spring-projects but when I do "ant publish" in
>spring-binding Ivy throws an exception:
>
>ivy.configure:
>     [echo] reading ivy config
>:: Ivy 1.0 - 20050427114850 :: http://ivy.jayasoft.org/ ::
>
>resolve.pre:
>
>resolve.main:
>[resolve.conf] exception while parsing: invalid version 1.1 in
>file:/Users/stevendevijver/download/spring-projects/spring-binding/ivy.xml
>
>BUILD FAILED
>/Users/stevendevijver/download/spring-projects/common-build/common-targets.xml:329:
>syntax errors in ivy file
>
>
>Apparently Ivy 1.0 is being used and the config file indeed is version 1.1.
>
>Steven
>
>  
>


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

[Springframework-developer] Ivy woes (part 2)

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

Colin,

I've checked out spring-projects but when I do "ant publish" in
spring-binding Ivy throws an exception:

ivy.configure:
     [echo] reading ivy config
:: Ivy 1.0 - 20050427114850 :: http://ivy.jayasoft.org/ ::

resolve.pre:

resolve.main:
[resolve.conf] exception while parsing: invalid version 1.1 in
file:/Users/stevendevijver/download/spring-projects/spring-binding/ivy.xml

BUILD FAILED
/Users/stevendevijver/download/spring-projects/common-build/common-targets.=
xml:329:
syntax errors in ivy file


Apparently Ivy 1.0 is being used and the config file indeed is version 1.1.

Steven

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

[Springframework-developer] CVS pruning

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

W/regards to out of date or wrongly checked in CVS modules in the Spring 
CVS repo, I've gone and done a 'remove' on all files in the following 
obsolte modules (and left a marker file in there that the module is 
obsolete):

common-build        - checked in wrong location
repository               - checked in wrong location
spring-binding        - checked in wrong location
spring-ide               - obsolete, now hosted in their own SVN repository
spring-modules       - obsolete, content is now in spring-projects module
spring-rcp               - obsolete, content is now in another 
SourceForge project
spring-webflow      - checked in wrong location
Spring                     - empty project. note the Uppercase 'S' on 
Spring, not to be confused with the main 'spring' module!

I am going to momentarilly send a maintenance request to SF to remove 
these modules permanently. I'm not 100% sure if they'll accept this from 
me, or will want Rod or Juergen to commit. In any case, with all the 
files gone in the modules, nobody else should be able to accidentally 
get in trouble by checking them out and trying to use them.

This will leave the following modules
spring                       - the current main spring sourcebase
spring-projects         - spring web flow and spring binding
i21                            - historical code from Rod's original 
book, plus first half year of evolution of Spring
samples                     - some aspectj code which I believe is still 
relevant. Some Java 5 code which is no longer relevant

Colin


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

Re: [Springframework-developer] Beans with factory-method treated like FactoryBeans

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

Finally committed.

(It's a busy weekend here: entire apartment freshly painted.)

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Juergen Hoeller
Sent: Sunday, July 10, 2005 9:37 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Beans with factory-method treated
like FactoryBeans

Hi Colin,

Thanks for your feedback. There have indeed been some tricky issues in the
factory method handling, mainly in determining the type upfront. Pre 1.2.2
we simply considered the type undeterminable for all factory methods.

In 1.2.2, we try to figure it out as far as possible, which unfortunately
led to a potential side effect with too early creation of "factory-bean"
targets - even before BeanFactoryPostProcessors. This led to the refinement
that a "factory-method" will only be resolved if the "includeFactoryBeans"
flag is "true" - which it isn't for BeanFactoryPostProcessors.

You got a point there in that this should only apply to actual
"factory-bean" references. For a static "factory-method" on the given class,
we should try to figure out the type statically - as far as possible, even
with "includeFactoryBeans" being "false". If a bean instance is already
created, we'll always return the actual type anyway.

I've just refined this accordingly, through only excluding "factory-bean"
references if "includeFactoryBeans" is off. To figure out the type for a
factory method, AbstractBeanFactory's "getType" delegates to the newly
introduced "getTypeForFactoryMethod" now, which creates the object in case
of a "factory-bean" reference (if appropriate) or checks the return type of
the static factory method else.

However, we can only clearly determine the type if we either only have a
single static factory method of the given name or multiple overloaded
factory methods that all return the same type (there's hardly gonna be any
other case). Else, we'll return null as "undeterminable" upfront: The actual
factory method called will only be clear after converting constructor
arguments and/or autowiring.

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Colin Sampaleanu
Sent: Saturday, July 09, 2005 6:42 PM
To: spr...@li...
Subject: [Springframework-developer] Beans with factory-method treated like
FactoryBeans

Juergen,

I saw you made some changes for how beans with factory-method set are
treated, so that they are essentially treated closer to being a FactoryBean
in some respects. I don't necessarilly disagree or anything (and it looks
like there were some bugs too, in any case), but I'm trying to see the
rationale for the changes.

- for 1.2.2 in DefaultListableBeanFactory, there is a comment:
   "* exclude bean definitions with factory method from pre-instantiation
type matching; pre-instantiate and match beans with factory method /
"factory-bean" definition".
- post 1.2.2, there is a comment:
  "DefaultListableBeanFactory does not create beans with "factory-method"
for type check if "includeFactoryBeans"=false"

As I see the current code, beans with a factory method get treated
essentially the same as a FactoryBean. getBeanNamesForType will now only
match the result of a bean def with a factory-method set if the
'includeFactoryBeans' arg is set to true, and to get this to happen, the
bean will actually always be created (via a getBean).

But unless I'm missing something, I think this might be the wrong behaviour
for static factroy methods. The factory class is known, as well as the
static factory method with the proper return type. The match can be done
properly without ever creating the bean. In this respect, I see the static
factory method being a direct alternative to new/newInstance().

Now a non-static factory method (via a sibling factory-bean ref) is I guess
a different thing. You could even handle some of those statically if you
look at the actual factory-bean referenced, and it's just a normal bean, and
the method declares the return type. But certainly if the referenced
factory-bean is a FactoryBean itself that's not going to work. So for the
non-static case I guess it makes sense to keep the bean def with a
factory-bean ref treated just like a FactoryBean; it's simpler and more
deterministic.

What do you think / can you clarify?

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 the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Beans with factory-method treated like FactoryBeans

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

Hi Colin,

Thanks for your feedback. There have indeed been some tricky issues in the
factory method handling, mainly in determining the type upfront. Pre 1.2.2
we simply considered the type undeterminable for all factory methods.

In 1.2.2, we try to figure it out as far as possible, which unfortunately
led to a potential side effect with too early creation of "factory-bean"
targets - even before BeanFactoryPostProcessors. This led to the refinement
that a "factory-method" will only be resolved if the "includeFactoryBeans"
flag is "true" - which it isn't for BeanFactoryPostProcessors.

You got a point there in that this should only apply to actual
"factory-bean" references. For a static "factory-method" on the given class,
we should try to figure out the type statically - as far as possible, even
with "includeFactoryBeans" being "false". If a bean instance is already
created, we'll always return the actual type anyway.

I've just refined this accordingly, through only excluding "factory-bean"
references if "includeFactoryBeans" is off. To figure out the type for a
factory method, AbstractBeanFactory's "getType" delegates to the newly
introduced "getTypeForFactoryMethod" now, which creates the object in case
of a "factory-bean" reference (if appropriate) or checks the return type of
the static factory method else.

However, we can only clearly determine the type if we either only have a
single static factory method of the given name or multiple overloaded
factory methods that all return the same type (there's hardly gonna be any
other case). Else, we'll return null as "undeterminable" upfront: The actual
factory method called will only be clear after converting constructor
arguments and/or autowiring.

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Colin Sampaleanu
Sent: Saturday, July 09, 2005 6:42 PM
To: spr...@li...
Subject: [Springframework-developer] Beans with factory-method treated like
FactoryBeans

Juergen,

I saw you made some changes for how beans with factory-method set are
treated, so that they are essentially treated closer to being a FactoryBean
in some respects. I don't necessarilly disagree or anything (and it looks
like there were some bugs too, in any case), but I'm trying to see the
rationale for the changes.

- for 1.2.2 in DefaultListableBeanFactory, there is a comment:
   "* exclude bean definitions with factory method from pre-instantiation
type matching; pre-instantiate and match beans with factory method /
"factory-bean" definition".
- post 1.2.2, there is a comment:
  "DefaultListableBeanFactory does not create beans with "factory-method"
for type check if "includeFactoryBeans"=false"

As I see the current code, beans with a factory method get treated
essentially the same as a FactoryBean. getBeanNamesForType will now only
match the result of a bean def with a factory-method set if the
'includeFactoryBeans' arg is set to true, and to get this to happen, the
bean will actually always be created (via a getBean).

But unless I'm missing something, I think this might be the wrong behaviour
for static factroy methods. The factory class is known, as well as the
static factory method with the proper return type. The match can be done
properly without ever creating the bean. In this respect, I see the static
factory method being a direct alternative to new/newInstance().

Now a non-static factory method (via a sibling factory-bean ref) is I guess
a different thing. You could even handle some of those statically if you
look at the actual factory-bean referenced, and it's just a normal bean, and
the method declares the return type. But certainly if the referenced
factory-bean is a FactoryBean itself that's not going to work. So for the
non-static case I guess it makes sense to keep the bean def with a
factory-bean ref treated just like a FactoryBean; it's simpler and more
deterministic.

What do you think / can you clarify?

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 the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] spring build.302 Build Successful

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

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

[Springframework-developer] Beans with factory-method treated like FactoryBeans

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

Juergen,

I saw you made some changes for how beans with factory-method set are 
treated, so that they are essentially treated closer to being a 
FactoryBean in some respects. I don't necessarilly disagree or anything 
(and it looks like there were some bugs too, in any case), but I'm 
trying to see the rationale for the changes.

- for 1.2.2 in DefaultListableBeanFactory, there is a comment:
   "* exclude bean definitions with factory method from 
pre-instantiation type matching; pre-instantiate and match beans with 
factory method / "factory-bean" definition".
- post 1.2.2, there is a comment:
  "DefaultListableBeanFactory does not create beans with 
"factory-method" for type check if "includeFactoryBeans"=false"

As I see the current code, beans with a factory method get treated 
essentially the same as a FactoryBean. getBeanNamesForType will now only 
match the result of a bean def with a factory-method set if the 
'includeFactoryBeans' arg is set to true, and to get this to happen, the 
bean will actually always be created (via a getBean).

But unless I'm missing something, I think this might be the wrong 
behaviour for static factroy methods. The factory class is known, as 
well as the static factory method with the proper return type. The match 
can be done properly without ever creating the bean. In this respect, I 
see the static factory method being a direct alternative to 
new/newInstance().

Now a non-static factory method (via a sibling factory-bean ref) is I 
guess a different thing. You could even handle some of those statically 
if you look at the actual factory-bean referenced, and it's just a 
normal bean, and the method declares the return type. But certainly if 
the referenced factory-bean is a FactoryBean itself that's not going to 
work. So for the non-static case I guess it makes sense to keep the bean 
def with a factory-bean ref treated just like a FactoryBean; it's 
simpler and more deterministic.

What do you think / can you clarify?

Colin

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

Re: [Springframework-developer] Ivy woes

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

Erwin Vervaet wrote:

>> Erwin did make the spring-binding eclipse project dependent on the 
>> spring project, which is a no-no (it shoudl be dependent only on the 
>> static jars), so I've backed that out.
>
>
> Did I do that???
> Anyway, the reason is the have the Spring source code available in the 
> IDE, as we discussed with Keith the other day.
>
I understand the desire, :-), but tha's not the way to do it since the 
module builds against a static Spring version, which (as in this case) 
does not stay in sync with the chaning live source. I'm going to try to 
work on a setup for getting the sources in there too.

Colin

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

Re: [Springframework-developer] Ivy woes

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

> That said, this is going to break right now because it looks like Keith 
> and/or Erwin forgot to check some stuff in. I haven't been in the soure 
> since early this week, when it was ok, but now there is some stuff 
> missing.
>
> I've checked in spring-context-1.2.2.jar in the repo inside 
> spring-projects

The reason that that jar was not in CVS was because of the heinous CVS error 
we got the other day (assertion failed...). If you were able to check it in 
the SF people must have fixed it. Great!

Erwin 

Re: [Springframework-developer] Ivy woes

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

> Erwin did make the spring-binding eclipse project dependent on the spring 
> project, which is a no-no (it shoudl be dependent only on the static 
> jars), so I've backed that out.

Did I do that???
Anyway, the reason is the have the Spring source code available in the IDE, 
as we discussed with Keith the other day.

Erwin 

Re: [Springframework-developer] Ivy woes

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

Ok, I take that back. Once I added spring-context-1.2.2.jar to the 
static repository I was able to properly build and publish 
spring-binding from ant.

Erwin did make the spring-binding eclipse project dependent on the 
spring project, which is a no-no (it shoudl be dependent only on the 
static jars), so I've backed that out.

Also, the numberguess and sellitem SWF samples were not building as for 
some reason Keith had added spurious (unneeded) dependencies on an older 
version of Spring. All the SWF samples just need to depend on 
spring-webflow, and it's transitive dependencies on spring jars pulls in 
all the needed spring stuff.

So everything (spring-binding, spring-webflow, and all the spring web 
flow samples) should build now, if you follow the steps below.

Colin


Colin Sampaleanu wrote:

> Ok, here's the story. You're trying to build the wrong source. All the 
> current spring-binding and spring-webflow related stuff is under 
> spring-projects. The older top-level modules need to be pruned.
>
> You need to pull out spring-projects, then you can go into 
> spring-binding and do an
>  ant publish
> to build an integration version of it and publish it to the local 
> repo, then can go into spring-weblfow and do an
>  ant dist
> or
>  ant publish
> to build that. If you want to build all of spring-webflow including 
> samples, you can go into build-spring-webflow and do
>  ant publish
> which will build all the spring-webflow related stuff (but not 
> binding, that's separate).
>
> That said, this is going to break right now because it looks like 
> Keith and/or Erwin forgot to check some stuff in. I haven't been in 
> the soure since early this week, when it was ok, but now there is some 
> stuff missing.
>
> I've checked in spring-context-1.2.2.jar in the repo inside 
> spring-projects, but spring-binding still doesn't build due to an error:
>
>    [javac] Compiling 4 source files to 
> D:\src\open\spring-colin\spring-projects
> \spring-binding\target\classes
>    [javac] 
> D:\src\open\spring-colin\spring-projects\spring-binding\src\java\org
> \springframework\binding\expression\ExpressionFactory.java:38: cannot 
> find symbo
> l
>    [javac] symbol  : method 
> isInstanceOf(java.lang.Class,org.springframework.bi
> nding.expression.Expression,java.lang.String)
>    [javac] location: class org.springframework.binding.support.Assert
>    [javac]             Assert.isInstanceOf(PropertyExpression.class, 
> evaluator,
> "The expression evaluator is not a PropertyExpressionEvaluator");
>    [javac]                       ^
>    [javac] 1 error
>
> Without binding, you can't build SWF. I may or may not have time now 
> to look at this. Depends when the kids wake up :-)
>
> Colin
>
>
> Steven Devijver wrote:
>
>> Hi all,
>>
>> I really need to build SWF ASAP but there seems to be a problem with
>> the lib repos, I get 404'ed all the time on a number of libs. This is
>> one of the URLs that bounces:
>>
>> http://www.jayasoft.fr/org/ivyrep/ognl/ognl/ivy-2.7.xml
>>
>> This is the complete list:
>>
>>        WARN:   ::::::::::::::::::::::::::::::::::::::::::::::
>>        WARN:   ::          UNRESOLVED DEPENDENCIES         ::
>>        WARN:   ::::::::::::::::::::::::::::::::::::::::::::::
>>        WARN:   :: springframework/spring-binding-1.0: not found
>>        WARN:   :: ognl/ognl-2.7: not found
>>        WARN:   :: springframework/spring-ioc-1.2.2: not found
>>        WARN:   :: springframework/spring-core-1.2.2: not found
>>        WARN:   :: springframework/spring-web-1.2.2: not found
>>        WARN:   :: springframework/spring-mock-1.2.1: not found
>>        WARN:   ::::::::::::::::::::::::::::::::::::::::::::::
>>
>> Please advice.
>>
>> Steven
>>
>>  
>>
>
>


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

Re: [Springframework-developer] Ivy woes

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

Ok, here's the story. You're trying to build the wrong source. All the 
current spring-binding and spring-webflow related stuff is under 
spring-projects. The older top-level modules need to be pruned.

You need to pull out spring-projects, then you can go into 
spring-binding and do an
  ant publish
to build an integration version of it and publish it to the local repo, 
then can go into spring-weblfow and do an
  ant dist
or
  ant publish
to build that. If you want to build all of spring-webflow including 
samples, you can go into build-spring-webflow and do
  ant publish
which will build all the spring-webflow related stuff (but not binding, 
that's separate).

That said, this is going to break right now because it looks like Keith 
and/or Erwin forgot to check some stuff in. I haven't been in the soure 
since early this week, when it was ok, but now there is some stuff missing.

I've checked in spring-context-1.2.2.jar in the repo inside 
spring-projects, but spring-binding still doesn't build due to an error:

    [javac] Compiling 4 source files to 
D:\src\open\spring-colin\spring-projects
\spring-binding\target\classes
    [javac] 
D:\src\open\spring-colin\spring-projects\spring-binding\src\java\org
\springframework\binding\expression\ExpressionFactory.java:38: cannot 
find symbo
l
    [javac] symbol  : method 
isInstanceOf(java.lang.Class,org.springframework.bi
nding.expression.Expression,java.lang.String)
    [javac] location: class org.springframework.binding.support.Assert
    [javac]             Assert.isInstanceOf(PropertyExpression.class, 
evaluator,
 "The expression evaluator is not a PropertyExpressionEvaluator");
    [javac]                       ^
    [javac] 1 error

Without binding, you can't build SWF. I may or may not have time now to 
look at this. Depends when the kids wake up :-)

Colin


Steven Devijver wrote:

>Hi all,
>
>I really need to build SWF ASAP but there seems to be a problem with
>the lib repos, I get 404'ed all the time on a number of libs. This is
>one of the URLs that bounces:
>
>http://www.jayasoft.fr/org/ivyrep/ognl/ognl/ivy-2.7.xml
>
>This is the complete list:
>
>        WARN:   ::::::::::::::::::::::::::::::::::::::::::::::
>        WARN:   ::          UNRESOLVED DEPENDENCIES         ::
>        WARN:   ::::::::::::::::::::::::::::::::::::::::::::::
>        WARN:   :: springframework/spring-binding-1.0: not found
>        WARN:   :: ognl/ognl-2.7: not found
>        WARN:   :: springframework/spring-ioc-1.2.2: not found
>        WARN:   :: springframework/spring-core-1.2.2: not found
>        WARN:   :: springframework/spring-web-1.2.2: not found
>        WARN:   :: springframework/spring-mock-1.2.1: not found
>        WARN:   ::::::::::::::::::::::::::::::::::::::::::::::
>
>Please advice.
>
>Steven
>
>  
>


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

[Springframework-developer] Ivy woes

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

Hi all,

I really need to build SWF ASAP but there seems to be a problem with
the lib repos, I get 404'ed all the time on a number of libs. This is
one of the URLs that bounces:

http://www.jayasoft.fr/org/ivyrep/ognl/ognl/ivy-2.7.xml

This is the complete list:

        WARN:   ::::::::::::::::::::::::::::::::::::::::::::::
        WARN:   ::          UNRESOLVED DEPENDENCIES         ::
        WARN:   ::::::::::::::::::::::::::::::::::::::::::::::
        WARN:   :: springframework/spring-binding-1.0: not found
        WARN:   :: ognl/ognl-2.7: not found
        WARN:   :: springframework/spring-ioc-1.2.2: not found
        WARN:   :: springframework/spring-core-1.2.2: not found
        WARN:   :: springframework/spring-web-1.2.2: not found
        WARN:   :: springframework/spring-mock-1.2.1: not found
        WARN:   ::::::::::::::::::::::::::::::::::::::::::::::

Please advice.

Steven

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

Re: [Springframework-developer] No harm, but seems odd

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

Good point - changed it to "private static final".

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Dave Brosius
Sent: Saturday, July 09, 2005 3:51 AM
To: spr...@li...
Subject: [Springframework-developer] No harm, but seems odd

org.springframework.aop.framework.adapter.ThrowsAdviceInterceptor is
declared final but has a protected member.
Seems confused.


public final class ThrowsAdviceInterceptor implements MethodInterceptor {

 // TODO make serializable (methods are not serializable)

 private static final String AFTER_THROWING = "afterThrowing";

 protected static Log logger = 
LogFactory.getLog(ThrowsAdviceInterceptor.class);




-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] No harm, but seems odd

[Dave B. <dbr...@qi...>]

org.springframework.aop.framework.adapter.ThrowsAdviceInterceptor is 
declared final but has a protected member.
Seems confused.


public final class ThrowsAdviceInterceptor implements MethodInterceptor {

 // TODO make serializable (methods are not serializable)

 private static final String AFTER_THROWING = "afterThrowing";

 protected static Log logger = 
LogFactory.getLog(ThrowsAdviceInterceptor.class);

[Springframework-developer] spring build.301 Build Successful

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

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

Re: [Springframework-developer] old dependencies on spring portlet in webflow

[Yujin K. <net...@gm...>]

Not knowing what's in the scope for 1.2.3, I'd also like to mention
that current versions(both sandbox and john's versions) lacks the unit
testing capabilities.  I did create some really basic mock objects for
portet request and response, but it would be great if some testing
capabilities are included in 1.2.3 or 1.2.4 (not sure what you have in
mind after 1.2.3).

john and some of us also have exchanged emails regarding how to map
the controllers based on both state (as in portlet mode) as well as
custom parameters using nested map.  While we both have somewhat
functional version, i think it's one of the areas that might require a
bit of discussion.   I haven't even started mapping the window state
in the mix yet.  so that could potentially add a little bit more
elements to it.  Probably this is where WebFlow could help a lot I am
guessing.

Yujin

On 7/8/05, Juergen Hoeller <ju...@in...> wrote:
> No worries, that's already in the works :-)
>=20
> It's one of the things I personally wanted to see changed before the move
> into the core.
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf =
Of
> Cris J. Holdorph
> Sent: Thursday, July 07, 2005 5:43 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] old dependencies on spring portl=
et
> in webflow
>=20
> Can we PLEASE PLEASE consider changing the two "handleRequest" methods to
> different names?  This is a violation of what is consider good practice f=
or
> overriding.  They are fundamentally different methods.
> This change REALLY should be made before it is moved into the core.
>=20
> ---- Cris J H
>=20
> Juergen Hoeller wrote:
> > Hi Tim.
> >
> > We actually intend to release the core Portlet support earlier now: as
> > part of Spring 1.2.3 in about two weeks. Web Flow RC1 will in turn
> > build on that release then.
> >
> > For the meantime, there might be a Web Flow PR4 as a remedy for the
> > current situation, but that's up to Keith and Erwin to decide. Else, I
> > would recommend to continue using Web Flow PR3 on Spring 1.2.1 for the
> > time being.
> >
> > Juergen
> >
> >
> > ----------------------------------------------------------------------
> > --
> > *From:* spr...@li...
> > [mailto:spr...@li...] *On
> > Behalf Of *Tim Kettering
> > *Sent:* Wednesday, July 06, 2005 7:56 PM
> > *To:* spr...@li...
> > *Subject:* [Springframework-developer] old dependencies on spring
> > portlet in webflow
> >
> >
> >
> > This really addresses two issues I'm having w/ spring portlet
> > development.  I am attempting to use spring webflow /w the portlets,
> > and the PR3 release of webflow apparently includes references to older
> > versions of portlet code (that exist in the spring sandbox) - and the
> > latest version of spring-portlets as released by john lewis includes
> > significantly updated code, and when attempting to include all those
> > jars in the portlet environment, theres all sorts of classloader
> > issues w/ different versions of DispatchPortlet and PortletController
> > lying around.  I've been trying to rebuild parts to get them all to
> > talk to each other, but it's been a big time-sink.
> >
> >
> >
> > I see the best solution being that John being allowed to merge his
> > portlet code in the cvs - so that webflow can be coded against the
> > proper classes and those classes being dropped from webflow-support.
> > I know that this has been under discussion lately to start with 1.3
> > development, and I'm hoping with the release of 1.2.2 complete, that
> > things can move in that direction.
> >
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies fr=
om
> IBM. Find simple to follow Roadmaps, straightforward articles, informativ=
e
> Webcasts and more! Get everything you need to get up to speed, fast.
> http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar happen=
ing
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
> core and dual graphics technology at this free one hour event hosted by H=
P,
> AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

RE: [Springframework-developer] autowiring exclusion attribute

[Mark V. <MVi...@ev...>]

Sure - so the JIRA issue for it is:
http://opensource.atlassian.com/projects/spring/browse/SPR-626
Attached to the JIRA issue is a zip containing a working implementation of
the feature.
All unit tests still pass.

Regards,
Mark

-----Original Message-----
From: Juergen Hoeller [mailto:ju...@in...]
Sent: Friday, July 08, 2005 2:44 AM
To: spr...@li...
Subject: Re: [Springframework-developer] autowiring exclusion attribute


OK, I see... Well, we can definitely consider that. Can you please create a
JIRA issue for it?

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Mark Vickers
Sent: Thursday, July 07, 2005 6:55 PM
To: 'spr...@li...'
Subject: RE: [Springframework-developer] autowiring exclusion attribute

Hi Juergen, Seth,

(repost - forgive the formatting trainwreck that was the last post)

I'm aware that inner beans are not considered as autowirable candidates,
but, there are some cases where I find that inner bean definitions cannot be
used.

For example:
LazyInitTargetSource, PrototypeTargetSource - These are
BeanFactoryBasedTargetSources which are supplied with bean names, not bean
references.

If I want to wrap a proxy around a LazyInitTargetSource, I don't see how I
can do it without two bean definitions.

There are some other cases where an inner bean definition should not be
used:
	ie:) I want an unproxied/unadvised bean for testing

Or imagine this scenario:
We have an RmiProxyFactoryBean, the target object of which we want to wrap
additional behaviour around.  In 99/100 cases we want the proxied version of
the bean (which we happily autowire into other beans), but in one key case
we need to get at the unproxied version.  But, because its an inner bean
def, its inaccessible.	

In summary, the ability to tag the corner-case beans as non-candidates for
autowiring will help where it is difficult, impossible or otherwise
undesirable to use inner bean defs.

I guess you could call them corner cases, but guess what, we're cornered ;)

Regards,
Mark

-----Original Message-----
From: Juergen Hoeller [mailto:ju...@in...]
Sent: Thursday, July 07, 2005 7:02 AM
To: spr...@li...
Subject: Re: [Springframework-developer] autowiring exclusion attribute


Hi Mark,

I haven't given much thought to this yet. The question is whether there are
enough good use cases for this.

After all, there's always the option to override autowiring at the level of
the bean that receives autowiring: You can always explicitly specify
references for specific properties of constructor arguments there, which
will override any autowiring that you configured for that bean.

In general, I agree with Seth that inner bean definitions can get you quite
far as well, in particular regarding proxy vs target. We're illustrating
that configuration style in JPetStore, for example. Autowiring will always
only consider the outer bean (the proxy) in such a scenario, never the inner
bean (the target).

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Mark Vickers
Sent: Wednesday, July 06, 2005 9:06 PM
To: 'spr...@li...'
Subject: [Springframework-developer] autowiring exclusion attribute

Juergen et al,

I've added a patch which addresses SPR-626 (autowiring exclusion attribute)
http://opensource.atlassian.com/projects/spring/browse/SPR-626

Any chance of this making it into 1.3?
A quick yea or nay would be appreciated - the presence/absence of this
feature will greatly impact our development practices.

Regards,
Mark

Re: [Springframework-developer] fix for AbstractScriptFactory

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

Thanks for spotting this, Seth - fixed!

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Seth Ladd
Sent: Friday, July 08, 2005 3:33 AM
To: spr...@li...
Subject: [Springframework-developer] fix for AbstractScriptFactory

Hello,

Here's a small patch to get AbstractScriptFactory compiling again. 
This was taken from the HEAD.

Thanks,
Seth


Index: AbstractScriptFactory.java
===================================================================
RCS file:
/cvsroot/springframework/spring/sandbox/src/org/springframework/beans/factor
y/script/AbstractScriptFactory.java,v
retrieving revision 1.12
diff -u -r1.12 AbstractScriptFactory.java
--- AbstractScriptFactory.java	23 Jun 2005 12:14:43 -0000	1.12
+++ AbstractScriptFactory.java	8 Jul 2005 01:31:01 -0000
@@ -19,6 +19,7 @@
 import java.util.HashMap;
 import java.util.Map;
 
+import net.sf.cglib.asm.Type;
 import net.sf.cglib.core.Signature;
 import net.sf.cglib.proxy.InterfaceMaker;
 
@@ -36,7 +37,6 @@
 import org.springframework.context.ApplicationContextAware;
 import org.springframework.core.io.ResourceLoader;
 
-import org.objectweb.asm.Type;
 
 /**
  * This superclass has the following responsibilities:


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] autowiring exclusion attribute

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

OK, I see... Well, we can definitely consider that. Can you please create a
JIRA issue for it?

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Mark Vickers
Sent: Thursday, July 07, 2005 6:55 PM
To: 'spr...@li...'
Subject: RE: [Springframework-developer] autowiring exclusion attribute

Hi Juergen, Seth,

(repost - forgive the formatting trainwreck that was the last post)

I'm aware that inner beans are not considered as autowirable candidates,
but, there are some cases where I find that inner bean definitions cannot be
used.

For example:
LazyInitTargetSource, PrototypeTargetSource - These are
BeanFactoryBasedTargetSources which are supplied with bean names, not bean
references.

If I want to wrap a proxy around a LazyInitTargetSource, I don't see how I
can do it without two bean definitions.

There are some other cases where an inner bean definition should not be
used:
	ie:) I want an unproxied/unadvised bean for testing

Or imagine this scenario:
We have an RmiProxyFactoryBean, the target object of which we want to wrap
additional behaviour around.  In 99/100 cases we want the proxied version of
the bean (which we happily autowire into other beans), but in one key case
we need to get at the unproxied version.  But, because its an inner bean
def, its inaccessible.	

In summary, the ability to tag the corner-case beans as non-candidates for
autowiring will help where it is difficult, impossible or otherwise
undesirable to use inner bean defs.

I guess you could call them corner cases, but guess what, we're cornered ;)

Regards,
Mark

-----Original Message-----
From: Juergen Hoeller [mailto:ju...@in...]
Sent: Thursday, July 07, 2005 7:02 AM
To: spr...@li...
Subject: Re: [Springframework-developer] autowiring exclusion attribute


Hi Mark,

I haven't given much thought to this yet. The question is whether there are
enough good use cases for this.

After all, there's always the option to override autowiring at the level of
the bean that receives autowiring: You can always explicitly specify
references for specific properties of constructor arguments there, which
will override any autowiring that you configured for that bean.

In general, I agree with Seth that inner bean definitions can get you quite
far as well, in particular regarding proxy vs target. We're illustrating
that configuration style in JPetStore, for example. Autowiring will always
only consider the outer bean (the proxy) in such a scenario, never the inner
bean (the target).

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Mark Vickers
Sent: Wednesday, July 06, 2005 9:06 PM
To: 'spr...@li...'
Subject: [Springframework-developer] autowiring exclusion attribute

Juergen et al,

I've added a patch which addresses SPR-626 (autowiring exclusion attribute)
http://opensource.atlassian.com/projects/spring/browse/SPR-626

Any chance of this making it into 1.3?
A quick yea or nay would be appreciated - the presence/absence of this
feature will greatly impact our development practices.

Regards,
Mark


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




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


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

Re: [Springframework-developer] old dependencies on spring portlet in webflow

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

We're going for a SWF PR4 release which will temporarily drop Portlet =
support but will work correctly on top of Spring 1.2.2. A SWF 1.0 =
release on top of Spring 1.2.3 with full Potlet support will follow =
shortly, as Juergen indicates.

Erwin Vervaet
erw...@er...
  ----- Original Message -----=20
  From: Juergen Hoeller=20
  To: spr...@li...=20
  Sent: Thursday, July 07, 2005 12:41 PM
  Subject: Re: [Springframework-developer] old dependencies on spring =
portlet in webflow


  Hi Tim.

  We actually intend to release the core Portlet support earlier now: as =
part of Spring 1.2.3 in about two weeks. Web Flow RC1 will in turn build =
on that release then.

  For the meantime, there might be a Web Flow PR4 as a remedy for the =
current situation, but that's up to Keith and Erwin to decide. Else, I =
would recommend to continue using Web Flow PR3 on Spring 1.2.1 for the =
time being.

  Juergen




-------------------------------------------------------------------------=
-----
  From: spr...@li... =
[mailto:spr...@li...] On Behalf =
Of Tim Kettering
  Sent: Wednesday, July 06, 2005 7:56 PM
  To: spr...@li...
  Subject: [Springframework-developer] old dependencies on spring =
portlet in webflow


  =20

  This really addresses two issues I'm having w/ spring portlet =
development.  I am attempting to use spring webflow /w the portlets, and =
the PR3 release of webflow apparently includes references to older =
versions of portlet code (that exist in the spring sandbox) - and the =
latest version of spring-portlets as released by john lewis includes =
significantly updated code, and when attempting to include all those =
jars in the portlet environment, theres all sorts of classloader issues =
w/ different versions of DispatchPortlet and PortletController lying =
around.  I've been trying to rebuild parts to get them all to talk to =
each other, but it's been a big time-sink.

  =20

  I see the best solution being that John being allowed to merge his =
portlet code in the cvs - so that webflow can be coded against the =
proper classes and those classes being dropped from webflow-support.  I =
know that this has been under discussion lately to start with 1.3 =
development, and I'm hoping with the release of 1.2.2 complete, that =
things can move in that direction.

Re: [Springframework-developer] old dependencies on spring portlet in webflow

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

No worries, that's already in the works :-)

It's one of the things I personally wanted to see changed before the =
move
into the core.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Cris J. Holdorph
Sent: Thursday, July 07, 2005 5:43 PM
To: spr...@li...
Subject: Re: [Springframework-developer] old dependencies on spring =
portlet
in webflow

Can we PLEASE PLEASE consider changing the two "handleRequest" methods =
to
different names?  This is a violation of what is consider good practice =
for
overriding.  They are fundamentally different methods.=20
This change REALLY should be made before it is moved into the core.

---- Cris J H

Juergen Hoeller wrote:
> Hi Tim.
> =20
> We actually intend to release the core Portlet support earlier now: as =

> part of Spring 1.2.3 in about two weeks. Web Flow RC1 will in turn=20
> build on that release then.
> =20
> For the meantime, there might be a Web Flow PR4 as a remedy for the=20
> current situation, but that's up to Keith and Erwin to decide. Else, I =

> would recommend to continue using Web Flow PR3 on Spring 1.2.1 for the =

> time being.
> =20
> Juergen
> =20
>=20
> ----------------------------------------------------------------------
> --
> *From:* spr...@li...
> [mailto:spr...@li...] *On=20
> Behalf Of *Tim Kettering
> *Sent:* Wednesday, July 06, 2005 7:56 PM
> *To:* spr...@li...
> *Subject:* [Springframework-developer] old dependencies on spring=20
> portlet in webflow
>=20
> =20
>=20
> This really addresses two issues I'm having w/ spring portlet=20
> development.  I am attempting to use spring webflow /w the portlets,=20
> and the PR3 release of webflow apparently includes references to older =

> versions of portlet code (that exist in the spring sandbox) - and the=20
> latest version of spring-portlets as released by john lewis includes=20
> significantly updated code, and when attempting to include all those=20
> jars in the portlet environment, theres all sorts of classloader=20
> issues w/ different versions of DispatchPortlet and PortletController=20
> lying around.  I've been trying to rebuild parts to get them all to=20
> talk to each other, but it's been a big time-sink.
>=20
> =20
>=20
> I see the best solution being that John being allowed to merge his=20
> portlet code in the cvs - so that webflow can be coded against the=20
> proper classes and those classes being dropped from webflow-support. =20
> I know that this has been under discussion lately to start with 1.3=20
> development, and I'm hoping with the release of 1.2.2 complete, that=20
> things can move in that direction.
>=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_idt77&alloc_id=16492&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] fix for AbstractScriptFactory

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

Hello,

Here's a small patch to get AbstractScriptFactory compiling again.=20
This was taken from the HEAD.

Thanks,
Seth


Index: AbstractScriptFactory.java
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/springframework/spring/sandbox/src/org/springframework/b=
eans/factory/script/AbstractScriptFactory.java,v
retrieving revision 1.12
diff -u -r1.12 AbstractScriptFactory.java
--- AbstractScriptFactory.java=0923 Jun 2005 12:14:43 -0000=091.12
+++ AbstractScriptFactory.java=098 Jul 2005 01:31:01 -0000
@@ -19,6 +19,7 @@
 import java.util.HashMap;
 import java.util.Map;
=20
+import net.sf.cglib.asm.Type;
 import net.sf.cglib.core.Signature;
 import net.sf.cglib.proxy.InterfaceMaker;
=20
@@ -36,7 +37,6 @@
 import org.springframework.context.ApplicationContextAware;
 import org.springframework.core.io.ResourceLoader;
=20
-import org.objectweb.asm.Type;
=20
 /**
  * This superclass has the following responsibilities:

Re: [Springframework-developer] old dependencies on spring portlet inwebflow

[Cris J. H. <hol...@un...>]

Um... whoops, I of course meant "overloading"... sorry for the wrong 
word.  (that's what I get for typing in haste)

---- Cris J H

Cris J. Holdorph wrote:
> Can we PLEASE PLEASE consider changing the two "handleRequest" methods 
> to different names?  This is a violation of what is consider good 
> practice for overriding.  They are fundamentally different methods. This 
> change REALLY should be made before it is moved into the core.